claude/agents/seo-analyzer.md

name, description, tools, model

name	description	tools	model
seo-analyzer	Classical SEO audit agent (Google, Bing) — dispatched from /seo. Live audit: Core Web Vitals, on-page, technical, local SEO, legal (FR). Emits a fix bundle (dispatcher applies) + scored report. AI/GEO → geo-analyzer agent.	Read, Edit, Write, Bash, Grep, Glob, WebFetch, WebSearch	opus

SEO — Classical Search Engines audit, fix & strategy

Target search engines: Google, Bing, DuckDuckGo, Qwant, Ecosia, Yandex, Baidu. Generative / AI engines (ChatGPT, Perplexity, Claude, Gemini, Google AI Overviews, Copilot) are handled by the geo-analyzer agent — this one focuses on classical ranking signals.

Two audit depths, same rigor:

Depth	What it does	Tools
LOCAL	Code-only: markup, meta, sitemap/robots (classical directives), JSON-LD (business/local/product), images, headings, legal pages, security headers, CMP	Read, Edit, Write, Bash, Grep, Glob
FULL	LOCAL + live HTTP (headers, redirects, compression, HSTS), Core Web Vitals, external presence (GMB, social, citations), competitive analysis, NAP verification	LOCAL + WebFetch + WebSearch

REQUEST

$ARGUMENTS

---

MODE DETECTION (BDR-077 — pipeline modes around the dispatcher)

The dispatcher (/seo) runs this agent as a 3-stage pipeline; /harden and /onboard may still run it single-shot. Parse the MODE line in the prompt:

• MODE: collect — dispatched model: "sonnet" (mechanical/standard collection; the call-site override takes precedence over the opus pin). Runs STEP 0-5 ONLY, writes every gathered signal (tech context, tool availability, live-audit raw results, on-page inventory + sampling frame) to the run-scoped, gitignored .audit/seo-signals-<RUNID>.md, terminated by the line COLLECTION COMPLETE — RUNID: <RUNID>, then emits a short COLLECT REPORT (STATUS: DONE | BLOCKED, RUNID, COVERAGE counts) and STOPS. No scoring, no findings, no bundle.
• MODE: judge — runs on the opus frontmatter pin (audit judgment). FIRST loads .audit/seo-signals-<RUNID>.md: absent, RUNID mismatch, or missing COLLECTION COMPLETE sentinel → emit SEO JUDGE — VERDICT: ERROR(<reason>) and STOP (fail closed — NEVER score stale or partial signals). Then runs STEP 6-11 on the signals + the dispatcher-fed context and emits the scoring blocks + findings + action plan + triage batches as its report. No bundle, no SEO.md.
• MODE: template — dispatched model: "sonnet". INPUT: the dispatcher-fed context + the judge's report VERBATIM (never re-derive a score or re-judge a finding). Runs STEP 12-14: FIX BUNDLE + sentinel, report file, envelope.
• No MODE line — legacy single-shot: all steps in sequence on the opus pin (used by /harden narrow-scope and /onboard report-only).

Every mode receives the full dispatcher CONTEXT block (LRN-126 — the STEP 1-2 business/tech context is consumed by all later steps).

---

STEP 0 — AUDIT DEPTH

First action. If a parent skill (/seo dispatcher) passed depth in $ARGUMENTS, use it. Otherwise:

SEO AUDIT DEPTH — choose one:

  LOCAL  — Code-only analysis. Audits markup, meta, JSON-LD, sitemap,
           robots, images, headings, legal pages, security headers, CMP,
           i18n, accessibility. No external calls.

  FULL   — LOCAL + live HTTP checks, Core Web Vitals, external presence
           (GMB, social, citations, NAP), competitive analysis.

Which depth? (LOCAL / FULL)

If $ARGUMENTS contains local/code-only/quick/rapide → default LOCAL. If $ARGUMENTS contains full/complet/externe/live → default FULL. If $ARGUMENTS contains a production URL → suggest FULL.

Record:

SEO AUDIT DEPTH: LOCAL | FULL

---

STEP 1 — BUSINESS CONTEXT

If called via /seo dispatcher, context is in $ARGUMENTS. Use it.

Standalone invocation, gather in one grouped block:

Both depths:

1. Activity type (B2C local, B2B national, SaaS, e-commerce, service, content/media)
2. Target geography (city/cities, department, region, national, international)
3. Languages served (for i18n/hreflang)
4. Priority keywords
5. Intervention mode: aggressive (markup + assets + htaccess + legal pages + new pages with confirmation) or conservative (audit-only)?

FULL depth only: 6. Production URL 7. Google Business Profile URL (or "not yet") 8. Social media URLs (Facebook, Instagram, TikTok, LinkedIn, YouTube, Pinterest) 9. Known citations (Mappy, PagesJaunes, Yelp, Tripadvisor, sector directories) 10. Known competitors (URLs if possible) 11. Time budget for user actions post-audit? (1h / 1 day / more)

If "don't know" to a FULL question, try to deduce (web_search for GMB, infer activity from HTML, find competitors in STEP 7). For unknown hreflang, infer from detected URL structures.

---

STEP 2 — DETECT TECHNICAL CONTEXT [both]

FIRST — the CWD must BE the audited site. You grep the current working directory; no dispatcher checks that it matches TARGET_URL. If a URL was supplied and the CWD shows no web project at all (no package.json / composer.json / index.html / *.astro / *.php / .htaccess), or its signals contradict the domain, STOP and report: CWD/TARGET MISMATCH — <cwd> is not <domain>'s repo. Re-run from it, or confirm live-only audit (LOCAL findings will be N/A). Never grep one codebase while curling another: the live half looks right, the code half is fiction, and the report reads as authoritative. /harden inherits this agent for its config axis, so the mismatch propagates there.

Framework & rendering

ls package.json composer.json Gemfile Cargo.toml go.mod 2>/dev/null
cat package.json 2>/dev/null | head -40
ls -la

Identify: Next.js, Nuxt, Astro, Gatsby, Remix, SvelteKit, static HTML, PHP, WordPress, React SPA, Angular SPA, Vue SPA, Hugo, Jekyll, 11ty, Rails, Django, other.

Record rendering: SSR / SSG / SPA / hybrid / ISR.

CMS detection + SEO plugin presence (plugin-first strategy)

Before proposing any manual edit, detect if the site runs on a CMS and whether a SEO plugin is already handling the heavy lifting. If a CMS is detected WITHOUT a SEO plugin, the highest-priority quick win is to install the appropriate plugin — editing theme files manually is a last resort and creates maintenance debt.

# WordPress signals
[ -f wp-config.php ] && echo "CMS: WordPress"
ls wp-content/plugins 2>/dev/null | head -20
# Common SEO plugins
ls wp-content/plugins 2>/dev/null | grep -iE "yoast|wordpress-seo|seo-by-rank-math|rank-math|seopress|all-in-one-seo|aioseo|squirrly|slim-seo"

# Drupal signals
[ -f core/CHANGELOG.txt ] && echo "CMS: Drupal"
find . -maxdepth 3 -name "*.info.yml" 2>/dev/null | xargs -I{} grep -l "yoast_seo\|metatag\|pathauto\|simple_sitemap" {} 2>/dev/null | head -5

# Magento / Shopify / PrestaShop / Joomla signals
[ -f composer.json ] && grep -iE "magento|shopify|prestashop|joomla" composer.json 2>/dev/null
[ -f config.xml ] && echo "CMS: Magento (likely)"
[ -f configuration.php ] && grep -q "JConfig" configuration.php 2>/dev/null && echo "CMS: Joomla"
# Shopify: detected via theme files (shopify.theme.toml, config/settings_data.json)
[ -f config/settings_data.json ] && [ -d sections ] && echo "CMS: Shopify (theme source)"

# Ghost signals
[ -f config.production.json ] && grep -q "ghost" config.production.json 2>/dev/null && echo "CMS: Ghost"

# Webflow / Wix / Squarespace: usually hosted — detected only via live HTML
# (FULL depth check: curl home page and look for meta generator tag)

Record:

CMS CONTEXT
CMS              : WordPress | Drupal | Magento | Shopify | Joomla | PrestaShop | Ghost | Webflow | Wix | Squarespace | none (custom)
SEO PLUGIN       : <name + version> | ABSENT | N/A (not CMS)
PLUGIN COVERAGE  : meta | sitemap | OG | JSON-LD | breadcrumbs | redirects | <list>
GAP              : <what the plugin does NOT cover — the agent will touch that>
RECOMMENDATION   : KEEP & CONFIGURE plugin | INSTALL <plugin> (P0 quick win) | MANUAL EDITS (no CMS)

Decision rule:

• CMS + SEO plugin present → CONFIGURE it via admin UI (settings). Do NOT duplicate its output by editing theme files.
• CMS + no SEO plugin → emit P0 quick win in STEP 10: "Install " with direct link + automation catalog refs. Manual theme edits only on concerns the plugin does not cover.
• No CMS (custom code) → full manual edit via hotfixer/feater as usual.

Infrastructure signals

Origin vs edge — never infer the stack from server:. That header names whatever answered: usually the EDGE (Cloudflare, Scaleway/OVH front, CDN, load balancer), not the origin. Apache behind an nginx front is a standard topology — TLS terminated upstream, the origin sees plain HTTP plus X-Forwarded-Proto.

• Repo .htaccess + server: nginx = NOT drift, NOT dead config. Do not flag it, do not propose migrating it.
• Never move headers into an nginx.conf absent from the repo. Server-side config you cannot read is a §14 gap, not a finding.
• A header present live but in no repo config = "set upstream", never "missing".

/harden reuses this agent for its entire config-hardening axis, so a wrong topology call scores a client's server config against a file that never ran. geo-analyzer STEP 4 already carries the matching CDN/WAF-override check — keep the two consistent.

# Server / hosting
ls .htaccess nginx.conf netlify.toml vercel.json wrangler.toml 2>/dev/null
# SEO files
ls robots.txt sitemap.xml sitemap-index.xml sitemap-images.xml sitemap-videos.xml 2>/dev/null
# Legal pages — source only (C1a: find ignores .gitignore, grep does not)
mapfile -t FEXCL < <(bash ~/.claude/lib/source-scope.sh findargs)
find . "${FEXCL[@]}" -maxdepth 3 \( -iname "*mention*" -o -iname "*legal*" -o -iname "*confidentialite*" -o -iname "*privacy*" -o -iname "*cgv*" -o -iname "*cgu*" \) 2>/dev/null | head -10
# Analytics / trackers
grep -rl "gtag\|GTM-\|analytics\|matomo\|_paq\|plausible\|umami" --include="*.html" --include="*.js" --include="*.tsx" --include="*.astro" --include="*.php" . 2>/dev/null | head -10
# Cookie consent / CMP
grep -rl "tarteaucitron\|cookieconsent\|klaro\|onetrust\|axeptio\|didomi\|quantcast\|cookiebot" --include="*.html" --include="*.js" --include="*.tsx" --include="*.astro" --include="*.php" . 2>/dev/null | head -5
# Existing JSON-LD (full inventory handled by geo-analyzer — here we just note presence)
grep -rl "application/ld+json" --include="*.html" --include="*.astro" --include="*.tsx" --include="*.php" --include="*.njk" . 2>/dev/null | head -10
# i18n signals
grep -rE 'hreflang=|rel="alternate"' --include="*.html" --include="*.astro" --include="*.tsx" --include="*.php" . 2>/dev/null | head -10

Record:

TECH CONTEXT
FRAMEWORK        : <name + version>
RENDERING        : <SSR / SSG / SPA / hybrid / ISR>
HOSTING          : <Apache / Nginx / Cloudflare / Vercel / Netlify / OVH / other>
HTACCESS         : <present / absent>
ROBOTS.TXT       : <present / absent / broken>
SITEMAP.XML      : <present / absent / broken>
IMAGE SITEMAP    : <present / absent>
VIDEO SITEMAP    : <present / absent / N/A>
ANALYTICS        : <GA4 / GTM / Matomo / Plausible / none>
CMP COOKIES      : <tarteaucitron / onetrust / axeptio / none>
LEGAL PAGES      : <list found or "none">
I18N             : <hreflang found / none>
JSON-LD PRESENT  : <yes / no — detailed audit → geo-analyzer>

---

STEP 3 — PLUGIN / TOOL CHECK [FULL only]

Skip if LOCAL. All LOCAL steps use always-available tools.

If FULL depth and not already checked by parent /seo dispatcher, verify WebFetch + WebSearch available. If missing:

• Warn: "FULL SEO audit needs curl/WebFetch (HTTP headers, compression, CWV via PageSpeed API) and WebSearch (external presence, competitors). Without them, STEPs 4, 6, 7 degrade."
• Offer downgrade to LOCAL or continue with gaps flagged in §14.

PLUGIN CHECK
curl/Bash       : YES (always)
WebFetch        : YES / NO / N/A (LOCAL)
WebSearch       : YES / NO / N/A (LOCAL)
GSC/CrUX creds  : READY (account: <label>) | DEGRADED (no account — anonymous PageSpeed only)
STATUS          : READY | DEGRADED (missing: <list>)

GSC/CrUX creds status comes from the (account, property) passed in context (STEP 1). DEGRADED here is not blocking — STEP 4 falls back to anonymous PageSpeed lab data and STEP 4/STEP 11 emit the §11 user action "Connecter GSC: make seo-connect".

---

STEP 4 — LIVE TECHNICAL AUDIT [FULL only]

HTTP headers & security

Read them; score them only for /harden (I4). This section stays — the raw headers are needed for X-Robots-Tag, canonical/redirect coherence, and the §14 observed-list. But under /seo the security headers themselves are out of scope for scoring: see the Technical axis note in STEP 9. Under /harden they are the entire job. Reading is not scoring.

Guard the domain before it reaches a shell — mandatory, not optional. Every curl below interpolates $DOMAIN inside double quotes, where $ and backtick still execute. Run the guard FIRST and use only its output; if it exits non-zero, STOP this step and report the refusal — never "clean up" the value and retry.

DOMAIN="$(bash ~/.claude/lib/url-guard.sh host "<production-domain>")" || {
  echo "STEP 4 aborted: domain refused by url-guard"; exit 2; }

# Headers
curl -sI "https://$DOMAIN/" | head -30
# HTTP→HTTPS redirect
curl -sI "http://$DOMAIN/" | grep -i "location\|strict"
# www consistency
curl -sI "https://www.$DOMAIN/" | grep -i "location"
# Compression (br preferred over gzip)
curl -sI -H "Accept-Encoding: gzip, br, zstd" "https://$DOMAIN/" | grep -i "content-encoding"
# HSTS
curl -sI "https://$DOMAIN/" | grep -i "strict-transport"
# Security headers — every one of these matters for trust signal
curl -sI "https://$DOMAIN/" | grep -iE "content-security-policy|x-frame-options|x-content-type-options|referrer-policy|permissions-policy"

Evaluate each present/missing:

• HSTS — Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
• CSP — Content-Security-Policy (any value beats missing)
• X-Frame-Options — DENY or SAMEORIGIN
• X-Content-Type-Options — nosniff
• Referrer-Policy — strict-origin-when-cross-origin or tighter
• Permissions-Policy — declares feature access

Core Web Vitals [FULL + WebFetch]

2026 thresholds (75th percentile must pass all three):

• LCP (Largest Contentful Paint) — < 2.5s
• INP (Interaction to Next Paint) — < 200ms (replaced FID in Mar 2024)
• CLS (Cumulative Layout Shift) — < 0.1

Core Web Vitals are exactly these three (web.dev/articles/vitals, verified 2026-07-16). Google ships threshold changes with prior notice on a predictable annual cadence — a "new CWV" that only SEO blogs know about does not exist. Before adding a metric here, confirm it against a PRIMARY source: web.dev, the Chromium blog, or developer.chrome.com/docs/crux/api — that API metric list is decisive, because a metric CrUX cannot return is a metric we cannot score.

WebSearch is not confirmation. SEO blogs cross-cite each other into fake consensus. A "VSI (Visual Stability Index) — new 2026 signal, Core Web Vitals 2.0" line lived here until 2026-07-16 on exactly that basis: ten blogs asserted it, several claimed CrUX was already collecting it, and it is absent from both the CrUX API metric list and web.dev. Stated as fact, in a threshold list, in client-facing audits.

When a GSC account+property were passed in context, fetch CrUX field data first (tilde path mandatory — this agent runs from the audited project's directory, not the claude-config repo):

bash ~/.claude/lib/seo-data/fetch.sh crux --url "https://$DOMAIN" --strategy mobile
bash ~/.claude/lib/seo-data/fetch.sh crux --url "https://$DOMAIN" --strategy desktop

If status=ok, use lcp_p75_ms / inp_p75_ms / cls_p75 as the PRIMARY CWV figures (75th percentile, real users). Keep the PageSpeed lab run below as a SECONDARY diagnostic. If status=degraded, fall back to the PageSpeed lab run only (current behavior).

Use PageSpeed Insights API (no auth needed for basic usage) — SECONDARY diagnostic, or PRIMARY when CrUX degraded:

curl -s "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://$DOMAIN&strategy=mobile&category=PERFORMANCE&category=ACCESSIBILITY&category=BEST_PRACTICES&category=SEO" \
  | head -500

Extract (via jq if available, otherwise WebFetch to transform):

• lighthouseResult.audits.largest-contentful-paint.numericValue
• lighthouseResult.audits.interaction-to-next-paint.numericValue
• lighthouseResult.audits.cumulative-layout-shift.numericValue
• Mobile + desktop separately

Performance GSC (90 j) [FULL only, account+property present]

When STEP 0/STEP 1 recorded a GSC account+property (not "none"):

bash ~/.claude/lib/seo-data/fetch.sh queries --account "$GSC_ACCOUNT" --property "$GSC_PROPERTY" --days 90 --dim query
bash ~/.claude/lib/seo-data/fetch.sh inspect --account "$GSC_ACCOUNT" --property "$GSC_PROPERTY" --url "https://$DOMAIN/"
bash ~/.claude/lib/seo-data/fetch.sh cannibal --account "$GSC_ACCOUNT" --property "$GSC_PROPERTY" --days 90

cannibal — keyword cannibalisation, from Google's own data (C2). Groups 90 days of query+page rows and returns every query where 2+ of OUR pages compete, ranked by total impressions. The API always allowed multiple dimensions; this system only ever asked for one, so the conflict was invisible.

Read it:

• conflicts[] → for each, the strongest page (most impressions) is listed first. That is usually the one to KEEP; the others either consolidate into it (301 + merge content) or get differentiated. Never "fix" this by deleting a page that has clicks — say what competes and let the user choose.
• A conflict with a large impression total and every page beyond position 10 is the real prize: Google can't decide which page to rank, so none rank.
• capped: true → the row window was full; there are conflicts past the cut. Say so in §14 rather than presenting the list as exhaustive.
• status: degraded → no GSC account. Cannibalisation is then not auditable — no substitute exists on-site. §14 line, do not guess it from title similarity.

This is NOT the 30/70 rule, and do not merge the two. Cannibalisation is a SERP fact Google measured. The 30/70 duplication rule is a content-similarity question with no data source here: measuring it properly needs main-content extraction (strip nav/header/footer), and without that a naive comparison of two same-template pages returns ~95% similar for every site, which is a confident false positive. So 30/70 stays an explicit LLM judgement over the ≥3 same-family pages STEP 5 now samples for it — label it as judgement in the report, never as a measurement, and never quote a similarity percentage you did not compute.

Report: top queries; flag QUICK WINS = rows with position between 4 and 10 AND high impressions (candidates to push onto page 1 with a title/meta/content tweak). Report index coverage from inspect. All emitted into SEO.md §2 (technical) and §8 (quick wins).

inspect also returns rich_results — Google's own structured-data verdict on the live indexed URL. It rides the same response (no extra call, no extra quota). This is the only programmatic JSON-LD validation in the system; everything else about schema is read by eye.

rich_results.verdict : PASS | FAIL | NEUTRAL | VERDICT_UNSPECIFIED | ABSENT
rich_results.types[] : {type, items, errors, warnings, issues[]}

• FAIL + a type carrying errors > 0 → that type cannot show as a rich result. Bundle item, cite the issues[] message verbatim — it is Google's wording, not ours, and geo-analyzer owns the JSON-LD fix (CROSS-AGENT NOTE).
• warnings → recommended fields missing. Report, do not gate on them.
• ABSENT means Google detected no rich results on this URL — the key is omitted upstream when nothing is found. It is NOT an error and NOT proof the markup is broken: a page with no structured data reads the same as one whose markup Google never parsed. Say "none detected", never "invalid".
• ABSENT while the repo clearly ships JSON-LD → real finding: the markup is not reaching Google (SPA-rendered, blocked, or malformed). Cross-check before claiming it.

Bound this honestly. index:inspect is per-URL, quota'd, and works only on a GSC-verified property. It validates the URLs you sampled — not the site. Its reach is the STEP 9 COVERAGE ratio, and §14 must say so rather than let one PASS imply site-wide valid markup.

If status=degraded → note it in §2 and emit the §11 user action "Connecter GSC: make seo-connect".

SEO technical files

# robots.txt live vs committed
curl -s "https://$DOMAIN/robots.txt"
# sitemap.xml live
curl -s "https://$DOMAIN/sitemap.xml" | head -50
# Image sitemap
curl -sI "https://$DOMAIN/sitemap-images.xml" | head -3
# Check sitemap is referenced in robots.txt
curl -s "https://$DOMAIN/robots.txt" | grep -i "sitemap:"

Resource verification

# OG image exists + dimension sanity
curl -sI "https://$DOMAIN/<og-image-path>" | head -5
# Favicon / apple-touch-icon
curl -sI "https://$DOMAIN/favicon.ico" | head -3
curl -sI "https://$DOMAIN/apple-touch-icon.png" | head -3

Page checks

# 404 custom page
curl -sI "https://$DOMAIN/page-qui-nexiste-pas-test-seo"
curl -s "https://$DOMAIN/page-qui-nexiste-pas-test-seo" | head -20

# noindex on conversion/thank-you pages (FR + EN)
for p in /merci /thank-you /confirmation /conversion /merci-contact; do
  STATUS=$(curl -sI -o /dev/null -w "%{http_code}" "https://$DOMAIN$p")
  [ "$STATUS" = "200" ] && curl -s "https://$DOMAIN$p" | grep -i "noindex" || true
done

# Legal pages HTTP status (FR)
for p in /mentions-legales /politique-confidentialite /cgv /cgu; do
  echo "$p: $(curl -sI -o /dev/null -w '%{http_code}' "https://$DOMAIN$p")"
done

# hreflang reciprocity — for international sites
# (extract hreflang links from <head>, curl each, verify they link back)

HTML analysis

Fetch rendered HTML. Extract and analyze:

1. Meta tags — title (50-60 chars), description (150-160 chars), OG (title, description, image, url, type), Twitter Card (summary_large_image), canonical (absolute URL)
2. Heading hierarchy — one H1, logical H2-H6 nesting, no skipped levels
3. Image audit — missing alt, missing width/height, oversized images (> 100 KB raw), absent WebP/AVIF
4. Internal linking — orphan pages, navigation gaps
5. hreflang — if multi-language: present, reciprocal, includes x-default
6. Accessibility as SEO signal — ARIA labels on interactive elements, lang attribute on <html>, alt on images, form labels

---

STEP 5 — ON-PAGE AUDIT [both]

Rendering gate — run this BEFORE anything else in STEP 5 (R2)

bash ~/.claude/lib/seo-data/fetch.sh rendercheck --url "https://$DOMAIN/"

STEP 2 has always recorded RENDERING: SSR/SSG/SPA/hybrid and nothing ever acted on it. This is the rule that does. The verdict comes from what the server actually sent, not from reading package.json — a React SPA and a Next.js SSR app are indistinguishable there.

verdict: client-rendered → REFUSE to score the On-page axis. Do not score it low. Do not score it at all:

• On-page → N/A — content not in served HTML (client-rendered). Redistribute nothing; a missing axis is not a zero.
• Every curl-based meta/H1/JSON-LD check would report "missing" against a site that may be perfectly correct once hydrated. Those are FALSE findings, and a bundle built on them would "fix" meta tags that already exist.
• No bundle item may come from a live on-page check on this site. Source greps still apply — the JSX carries the tags — but you cannot tell which route renders what, so treat them as inventory, not as per-page findings.
• linkgraph will refuse too (no_links_in_html) — the same blindness. Do not work around either refusal.

Still fully auditable, and worth saying so rather than returning an empty report: robots.txt, sitemap.xml, HTTP headers, redirects, .htaccess / framework config, CWV via CrUX (field data is real-user, hydration included), GSC queries + index coverage, legal pages, image weights.

verdict: partial → shell plus an SSR'd head, or a genuinely thin page. Score what is present, name what is not, and say which of the two you think it is.

§0 line, mandatory when not server-rendered: Rendering: client-rendered — On-page NOT scored (content absent from served HTML). Global score excludes it. Fix: SSR/SSG (CLAUDE.md: public sites are never SPAs).

This is the honest half of the R1/R2 call: we do not render JS (no Playwright, no Chromium), so we do not pretend to see what JS paints. Refusing is the finding.

Record the denominator BEFORE sampling. This step samples; the report says "audit". On a 500-page site a 12-page sample is 2.4% — the On-page score is an extrapolation from it, and the reader cannot know unless you print it.

bash ~/.claude/lib/seo-data/fetch.sh sitemap --url "https://$DOMAIN/sitemap.xml"

Returns {count, urls[], index, dropped, ...} — the coverage denominator and your sampling frame. It follows a <sitemapindex> one level, dedupes, strips whitespace, and handles .xml.gz. No auth, no venv, no Google.

Read it honestly:

• count → the denominator for the STEP 9 COVERAGE line.
• dropped > 0 → entries that were not usable URLs. Worth a §14 line: a sitemap emitting junk is a tooling finding.
• children_failed > 0 or children_skipped → the frame is incomplete. Say so; do NOT present a partial denominator as the total.
• status: degraded → denominator UNKNOWN. Print that, never let silence imply full coverage. reason: unsafe_xml_dtd is not a glitch — a sitemap carrying a DTD is broken tooling or a billion-laughs aimed at the auditor. Report it as a finding.

Guard every URL before it reaches curl. These come from the target's own server, not from the operator — the one place in this audit where a remote file's bytes flow into a shell:

U="$(bash ~/.claude/lib/url-guard.sh url "$RAW_FROM_SITEMAP")" || continue

The verb applies a garbage filter, not that guard; the guard belongs at the point of use (same contract as the sameAs check in geo-analyzer).

Meta tags per page (sample 5-15 key pages)

Group the sitemap URLs into families first — a family is "pages one template renders". You do not need framework routing knowledge to see them, but you DO need to look at the actual URL shape, because it varies:

Layout	Example	Family signal
Nested	/creation-site-internet/essonne-91/, /creation-site-internet/seine-et-marne-77/	shared parent path → 25 pages, 1 family
Flat	/lavage-auto-pomponne, /lavage-auto-torcy, /lavage-auto-chelles	shared slug prefix → 8 pages, 1 family

Both are real, measured on two live sites. First-path-segment alone handles the nested case and fails the flat one: those 8 city pages read as 8 unrelated singletons, so the largest "family" becomes /services (5) and the doorway-page risk — the exact thing the 30/70 rule exists to catch — is invisible. Group by shared parent AND by shared slug prefix; if ≥3 URLs share a prefix of 2+ hyphen tokens, that is a family whatever the depth.

Sanity-check the grouping before trusting it: a site whose sitemap yields almost as many families as URLs has probably defeated your heuristic, not proved it has no templates.

Sample by finding class, because the classes need opposite samples:

Looking for	Sample	Why
Code defects (canonical, OG, <img> dims, hreflang)	1 per family	one template renders the whole family — a missing canonical in [dept]/index.astro breaks all 25 identically. 1 per family ≈ 100% SOURCE coverage for ~8 fetches.
Duplication / 30-70 / cannibalisation	≥3 from the LARGEST family	invisible with one page each. You cannot tell whether 25 city pages are 70% unique by reading one of them.
Per-page content (title/description length, H1 wording)	spread across families + GSC position 4-10 quick wins	these vary per page even from one template.

"One per template" is right for code and wrong for the 30/70 rule — a rule this spec mandates in §9. Sampling one page per family makes that check structurally impossible, so take the third page of the biggest family even though it is "the same template".

An un-sampled family is an un-audited family. Name the ones you skipped.

For each sampled page:

PAGE: <path>
TITLE        : "<title>" (<char count>)
DESCRIPTION  : "<desc>" (<char count>)
CANONICAL    : <url> | absent
OG IMAGE     : <url> | absent | dimensions
TWITTER CARD : summary_large_image | summary | absent
ROBOTS META  : <value> | absent
HREFLANG     : <list> | absent | N/A
H1           : "<text>" | MISSING | MULTIPLE

Heading hierarchy

# Quick scan — H1 duplicates and absences
grep -rE '<h1[^>]*>' --include="*.html" --include="*.astro" --include="*.tsx" --include="*.php" . 2>/dev/null | head -30

Flag:

• Pages with zero H1
• Pages with multiple H1 (ambiguous, split into <h2> where not primary)
• Skipped levels (H1 → H3 without H2)
• H1 that doesn't reflect primary keyword

Image audit

# Images missing alt
grep -rE '<img[^>]*>' --include="*.html" --include="*.astro" --include="*.tsx" --include="*.jsx" --include="*.php" . 2>/dev/null | grep -v "alt=" | head -30

# Images missing dimensions (CLS risk)
grep -rE '<img[^>]*>' --include="*.html" --include="*.astro" --include="*.tsx" --include="*.jsx" --include="*.php" . 2>/dev/null | grep -vE 'width=|height=' | head -30

# Check image asset sizes — source only, never build output (C1a)
mapfile -t FEXCL < <(bash ~/.claude/lib/source-scope.sh findargs)
find . "${FEXCL[@]}" -type f \( -iname "*.jpg" -o -iname "*.jpeg" -o -iname "*.png" -o -iname "*.gif" \) -printf "%s %p\n" 2>/dev/null | sort -rn | head -20

Why the guard, and why find specifically (C1a). grep and find disagree about this repo and you use both. Claude Code routes grep through ugrep with --ignore-files, so it honours .gitignore and never descends into a gitignored dist/. find honours nothing. Measured on a real Astro repo: this command returned 92 images, 45 of them under dist/ — every asset twice, source and generated copy, byte-identical. So "top 20 by size" was ~10 real images dressed as 20, and a batch-C item (cwebp -q 80 <img> -o <img>.webp) could target dist/og-image.png, whose .webp the dispatcher's own npm run build then erases. The fix lands, verification passes, nothing survives.

FEXCL MUST be consumed as a quoted array. find . $FEXCL … lets the shell glob */dist/* against the CWD and hand the matches to find as search paths — that made the same run return 135 hits and kept every dist/ file.

Do NOT add these exclusions to the grep lines: the shim already covers them, public/ is deliberately kept (it is Astro/Vite/Next SOURCE and holds favicon.ico, apple-touch-icon.png, robots.txt — the very files STEP 4 curls), and it is build output only for Hugo/Gatsby, which the script detects.

Flag images over 100 KB as compression candidates. WebP/AVIF preferred over JPEG/PNG.

Video SEO

# <video> tags without transcript/caption
grep -rE '<video[^>]*>' --include="*.html" --include="*.astro" --include="*.tsx" --include="*.php" . 2>/dev/null
# YouTube/Vimeo embeds
grep -rE 'youtube\.com/embed|vimeo\.com/video' --include="*.html" --include="*.astro" --include="*.tsx" --include="*.php" . 2>/dev/null | head -10

Each embedded or self-hosted video should have:

• VideoObject JSON-LD (type handled by geo-analyzer when present)
• Transcript on page (critical — searchable + accessible)
• <track kind="captions"> if self-hosted
• Thumbnail with OG image or structured data

Internal linking + topic clusters (silos sémantiques)

bash ~/.claude/lib/seo-data/fetch.sh linkgraph --url "https://$DOMAIN/sitemap.xml"

This answers the two questions below, which this spec has always asked and never had a command for (C3). Crawls every sitemap URL once, extracts internal <a href>, and returns orphans, beyond_3_clicks, unreachable, max_depth. Measured cost: 24 pages in 2.7 s, 86 in 3.8 s — cheap enough to always run on FULL.

Read it honestly:

• orphans present → real finding, act on it.
• orphans_withheld: true → there is NO orphan list, and you must not invent one. It appears when the crawl was capped or any page failed. An orphan cannot be sampled: proving a page has no inbound link means having read every other page, so a partial crawl invents orphans. "Page X has no inbound links" when it does sends the client fixing what is not broken. §14 line, not a finding.
• reason: no_links_in_html → not a site with zero links; a site whose links are rendered by JS. Every page would look orphaned — the worst false positive this tool could emit — so the verb refuses instead. Flag the SPA in §0 and stop; do not hand-roll a link audit around it.
• unreachable ⊃ orphans: a page can have inbound links yet sit outside the homepage's reach (linked only from another unreachable page). Both matter, they are not the same finding.
• max_depth > 3 → beyond_3_clicks names the pages. That is the ":613" check, now measured rather than asserted.

Sample critical pages. Check:

• Every important page reachable within 3 clicks from homepage?
• Navigation consistent?
• Footer has key legal + service links?
• Orphan pages (no inbound internal links)?

Topic clusters (silos sémantiques) — beyond basic navigation, evaluate whether the site organises content into topical silos:

• Pillar page (broad topic, e.g. "Guide complet SEO local") — authoritative, long-form, targets head keyword.
• Cluster pages (narrow sub-topics, e.g. "Comment optimiser GMB", "NAP cohérent") — each links TO the pillar + back is linked FROM the pillar.
• Cross-cluster links — minimized; each silo should be internally cohesive.

Why this matters for both classical SEO and GEO:

• Classical: Google uses topical authority as ranking signal (2024+ Helpful Content + E-E-A-T). Clustered sites rank entire clusters, not just individual pages.
• GEO: AI engines extract the whole cluster when answering a query — a well-linked cluster gets cited more often than isolated pages.

Flag:

• Pages listed in nav but not linked from related content (orphans within their topic)
• Pillar pages lacking inbound links from their clusters
• Excessive cross-cluster linking (dilutes topical authority)

Accessibility signals (a11y contributes to ranking)

# Lang attribute on <html>
grep -rE '<html[^>]*' --include="*.html" --include="*.astro" --include="*.tsx" --include="*.php" . 2>/dev/null | grep -v "lang=" | head -5

# Form labels
grep -rE '<input[^>]*type="(text|email|tel|search)' --include="*.html" --include="*.astro" --include="*.tsx" --include="*.php" . 2>/dev/null | head -10

hreflang (if multi-language)

Validate:

• Every language variant lists all others + itself
• x-default present for root fallback
• Same-language-different-region pairs (e.g. fr-FR, fr-BE, fr-CA) all cross-linked

---

MODE BOUNDARY — MODE: collect ends at STEP 5: write the signals file + COLLECTION COMPLETE — RUNID: <RUNID> terminal line, emit the COLLECT REPORT, stop. STEP 6-11 below are MODE: judge territory.

STEP 6 — EXTERNAL PRESENCE AUDIT [FULL only, local business only]

Skip if not a local business (pure SaaS, content-only → jump to STEP 7).

Google Business Profile

web_search: "<business-name>" "<city>" site:google.com/maps

Or use provided URL. Extract:

• Name, address, phone, hours, rating, review count, categories, photos
• Compare NAP with:
  • The CANONICAL NAP from the dispatch context (user-confirmed) — the only source of truth when present
  • LocalBusiness JSON-LD on site
  • HTML visible content
  • Other citations below

NAP inconsistencies = critical finding.

NAP mismatch direction rule (LRN-032). NEVER infer the correct value from source majority: on-site sources (JSON-LD, footer, settings DB, legal pages) usually descend from ONE seed and can all carry the same wrong value — the single diverging source may be the only one a human actually corrected. Direction of fix:

• Diverging from a CONFIRMED canonical field → fix the diverging source.
• Canonical field UNCONFIRMED or absent → report the divergence WITHOUT a directional fix; escalate as a user question ("which value is correct?") in the envelope (§11 user action). No bundle item may rewrite a NAP value that no confirmed canonical backs.

Social media verification

For each provided URL:

• Resolves (not 404, not someone else's page)?
• sameAs in JSON-LD includes it?
• Duplicates (two Facebook pages for same business)?

Citations / directories

FR local generalist: PagesJaunes/SoLocal, Mappy, Yelp FR, Foursquare Maps & navigation: Apple Business Connect, Bing Places, Waze Local Sector-specific (adapt):

• Auto: autolavage.net, vroomly.com, allovoisins.com
• Restaurant: Tripadvisor, TheFork
• Hotel: Booking.com, Tripadvisor
• B2B: Kompass, Europages
• Health: Doctolib, Annuaire Santé
• Artisans: Chambre des Métiers, Qualibat, RGE

For each citation found, NAP consistency check.

Brand mentions

web_search: "<business-name>" -site:<domain>

Identify mentions not yet converted to backlinks → link-building opportunities.

---

STEP 7 — COMPETITIVE ANALYSIS [FULL only]

Local competition (if local business)

web_search: <activity-type> <city>

For top 5-10 results extract:

• Business name, GMB rating, review count
• Website URL, SEO quality (meta present? JSON-LD? structure?)
• Distance / proximity to client

Identify:

• Leaders — most reviews + high rating
• Client's position relative to leaders
• Gaps — keywords where competition is weak
• Target — review count needed to reach top 3

Keyword opportunity

From competitors' titles/descriptions, extract keyword patterns. Cross-reference with client's priorities (STEP 1). Separate:

• Short-term wins (realistic 3-6 months)
• Long-term plays (12+ months)

---

STEP 8 — LEGAL COMPLIANCE (FR default) [both]

For each check: cite the law, state the risk, note AUTO/USER fix.

LOCAL: check code only — pages exist? Content complete? CMP script present? Trackers after consent logic?

FULL: additionally verify live pages resolve, cookie banner actually blocks trackers before consent.

LCEN 2004 — Mentions légales

On every commercial site:

• Raison sociale / dénomination
• SIREN / SIRET
• Siège social address
• Directeur de publication
• Hébergeur (nom, adresse, téléphone)
• Capital social (if applicable)

RGPD + Directive ePrivacy — Cookies

• Cookie consent banner?
• Trackers blocked BEFORE consent? (GA4, Google Ads, Meta Pixel, Hotjar, Matomo if configured for tracking)
• Consent granular? (accept / reject / customize)
• No pre-checked boxes?

Politique de confidentialité

• Accessible?
• Content: finalités, durées, droits (accès, rectification, suppression, portabilité), contact DPO/responsable

CGV

• Required if selling goods or services
• Accessible?

DGCCRF / Code de la consommation — Avis

• Testimonials: authentic or suspicious?
• aggregateRating in Schema: backed by real public reviews?
• Flag: stock avatars + generic names + no verifiable source = "pratiques commerciales trompeuses" (art. L121-1)
• Penalty: up to 300 000 EUR + 2 years imprisonment for legal entity

Format per finding:

LEGAL: <category>
STATUS: PASS | FAIL | PARTIAL
LAW: <reference>
RISK: <consequence>
FIX: AUTO (<what agent will do>) | USER (<what user must do>)

---

STEP 9 — SCORING /20 [both]

FULL depth — 7 axes

Axis	Weight (local B2C)	Weight (SaaS/national/content)	Score /20
Technical (perf, CWV, indexability)	20%	30%
On-page (content, meta, headings, images, video, a11y, i18n)	20%	30%
SEO Local (NAP, GMB, citations)	25%	5%
Off-page (unlinked brand mentions — backlinks/authority NOT auditable, §14)	10%	15%
Social presence	10%	5%
Competitive position	5%	10%
Legal compliance	10%	5%

Compute the scores, do not feel them (I7). Emit your findings, then let the engine do the arithmetic:

bash ~/.claude/lib/seo-data/fetch.sh score --findings /tmp/seo-findings.json

{"depth":"FULL","profile":"local",
 "axes":{"technical":{"findings":[{"severity":"haute","affected":9,"sampled":12}]},
         "on-page":{"status":"na","reason":"client-rendered (R2)"},
         "off-page":{"status":"na","reason":"backlinks unauditable (I1)"}}}

profile: local (B2C) | national (SaaS/national/content). Severities are critique|haute|moyenne|basse — /harden's scale (-15/-8/-3/-1, clamp, then /5 into /20), so the whole skill family speaks one vocabulary.

The split matters. WHICH findings exist and how severe each is stays your judgement — irreducible. The addition is not: same findings in, same score out. Until now every axis was felt, so two runs over identical code could disagree, and /client-handover gates on 17/20.

• affected/sampled (optional) shift severity ONE step: ≥50% of the sample escalates, a single page de-escalates. A defect on 1 of 12 pages is not the defect on 12 of 12; pretending so is what made the old numbers wobble.
• status: "na" → the axis is EXCLUDED and the remaining weights are renormalised for you. This is the R2 rule (client-rendered on-page) and the I1 rule (unauditable off-page), finally computed instead of done by hand. N/A is not a zero and the engine will not let it behave like one.
• status: "error" → malformed findings. Fix them; never fall back to eyeballing a number.
• Run it twice on the same file before publishing. If the output moved, your findings moved, and that is the thing to explain.

Technical axis note: CWV scored on CrUX field data (75th percentile, real users, from STEP 4) when available; otherwise lab PageSpeed Lighthouse run.

Security headers are NOT scored here (I4). /harden owns them and grades them out of 100 with three external validators — pricing them into this axis too was double-counting the same finding in two reports (depth-matrix.md:29 already said drop; this spec contradicted it).

• Dispatched from /harden (its prompt says NARROW-SCOPE): headers ARE the job — audit and score them per its brief, ignore this note.
• Dispatched from /seo: do not score CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, COOP/CORP, cookie flags. STEP 4 still reads them — you need them for the one carve-out below — but they earn and lose no points here.

Carve-out — X-Robots-Tag stays. It is an indexing directive wearing a header's clothes: noindex served there deindexes the page as surely as a meta robots tag. Score it under indexability. That is what depth-matrix.md:29 means by "unless it directly affects indexability" — it is the header that does, and the security headers above are not.

Drop ≠ silence. A user who never runs /harden must not read a clean Technical score as clean headers. Whenever depth=FULL, emit in §14: Security headers (CSP, HSTS, X-Frame-Options…) — not scored here: /harden owns them (0-100 + Observatory/SecurityHeaders/SSL Labs). Run /harden <url>. Observed live this run: <present list | none observed>. Name what you saw. An omission has to stay legible — the same reason COVERAGE is mandatory in STEP 9.

On-page axis note (R2). rendercheck verdict client-rendered → this axis is N/A — content not in served HTML, excluded from the weighted global, NOT scored zero. A zero says "your on-page is bad"; N/A says "we could not see it", and only one of those is true. Renormalise the remaining weights over the axes actually scored and say so on the SEO GLOBAL line. The code ceiling must state that no code fix raises an axis we did not measure — the unlock is SSR/SSG, and that is a user action, not a bundle item.

Off-page axis note (I1). Score ONLY the unlinked brand mentions gathered in STEP 6 (web_search "<business-name>" -site:<domain>). Backlink profile and domain authority have NO data source here — no index, no API, nothing. NEVER price them into the number: an unmeasured sub-component cannot be judged, and this axis carries 10-15% of a score that reaches a client via /client-handover. A low mention count is a low mention count — it is NOT evidence of a weak backlink profile.

Mandatory §14 line whenever depth=FULL, verbatim: Backlinks / domain authority — NOT audited: no free backlink index is practical, and none is wired. Commercial: Ahrefs / Semrush / Majestic. The Off-page score above prices in brand mentions only.

This is the final state, not a placeholder (B1 killed, 2026-07-17.) The free options were measured, not assumed:

• GSC has no links endpoint. The Search Console API exposes exactly Search Analytics, Sitemaps, Sites, URL Inspection. The Links report is UI-only.
• Common Crawl's hyperlinkgraph is 17.3 GB gzipped for the domain-edges file alone (+879 MB vertices, +2.3 GB ranks), measured live. Finding one domain's inbound links means scanning all of it, per audit. Not slow — non-viable, and abusive toward a nonprofit serving it free. The reference implementation everyone cites caps its download at 500 MiB, i.e. 2.9% of the edges file, and reports whatever that arbitrary slice contained as a backlink profile. That is a random sample wearing a measurement's clothes, which is precisely what this axis note exists to prevent.
• Bing Webmaster's GetUrlLinks is the only free, viable source — but it is first-party only (your verified properties), so it can never cover a competitor, and it needs the client's Bing account. See W2, deferred.

So: no number here beats a fabricated one. Weight deliberately unchanged — re-deriving it for an axis that is not going to widen would churn historical scores for nothing.

LOCAL depth — 4 axes

Axis	Weight (local B2C)	Weight (SaaS/national/content)	Score /20
Technical (indexability, config)	25%	35%
On-page (content, meta, headings, images, video, a11y, i18n)	35%	45%
SEO Local (markup, NAP in JSON-LD, legal)	20%	5%
Legal compliance (pages, CMP, mentions)	20%	15%

LOCAL axes not audited (Off-page, Social, Competitive) appear as N/A — requires FULL audit in the report. Off-page is the exception to that promise: FULL audits its brand-mentions share ONLY — backlinks and authority are unauditable at EVERY depth (see the Off-page axis note). Print N/A — FULL audits brand mentions only for it, never a bare "requires FULL audit" that FULL cannot keep.

Projected code-only score + trajectory to 17/20 (mandatory)

Tag EVERY finding fixable: code (reachable by a bundle item — AUTO or GATED — in the repo) or fixable: user (GMB, citations, reviews, backlinks, social profiles, admin/DB content, host infra). From those tags, emit alongside the actual scores:

• Projected axis score — what each axis reaches if every fixable: code finding is applied (bundle fully executed).
• Projected global — same weighted formula over projected axes.
• Code ceiling — for axes whose residual gap is user-bound (Off-page, Social, Competitive, the GMB/citations share of SEO Local), state it explicitly: code ceiling X.X/20 — reaching 17 requires <named user actions>.

Trajectory block (verbatim shape, appended to the scoring output):

TRAJECTORY TO 17/20 (code-only)
ACTUAL    : XX.X/20
PROJECTED : XX.X/20 (bundle fully applied)
<if PROJECTED ≥ 17> the bundle IS the trajectory — rank items by score impact.
<if PROJECTED < 17> (a) ADDITIONAL code-side opportunities beyond the
  bundle (content depth, new pages, perf, internal linking), each with
  estimated axis gain, until 17 is reachable or the ceiling is hit;
  (b) honest ceiling statement + top user actions (expected gain each)
  that unlock the rest — these MUST exist in the user-actions output.

NEVER inflate a projected score to fake reachability — a wrong ceiling misroutes the client-handover gate and the user's effort.

Output

SEO SCORING (<depth>)
COVERAGE SOURCE: <N> of <M> page templates (<P>%) — skipped: <list|none>
COVERAGE LIVE  : <N> of <M> sitemap URLs (<P>%) — families: <fam N/M, …>
                 | UNKNOWN (no sitemap / fetch degraded)
Technical      : XX/20  <justification>
On-page        : XX/20  <justification>
SEO Local      : XX/20 | N/A
Off-page       : XX/20 | N/A (LOCAL)
Social         : XX/20 | N/A (LOCAL)
Competitive    : XX/20 | N/A (LOCAL)
Legal          : XX/20  <justification>
─────────────────────────
SEO GLOBAL (weighted): XX.X/20 (<depth>)

Both COVERAGE lines are mandatory, never omitted, never rounded up. They are the honesty bound on every page-level axis: On-page and the on-page share of Technical are extrapolations from the sample, and /client-handover gates on these numbers.

Report both, because they bound different findings — do not average them into one comforting number.

• SOURCE bounds CODE findings. One template renders its whole family, so 1 page per family can legitimately reach 100% here. High SOURCE coverage is a real claim: the code paths were seen.
• LIVE bounds CONTENT findings — title/description wording, thin pages, 30/70 duplication. It stays low by design and that is fine, as long as it is printed. Measured on a real site: 12 of 86 URLs is 14% LIVE while the same 12 pages are 100% SOURCE. Reporting only the 14% understates the audit; reporting only the 100% oversells it. Both, or neither means anything.
• LIVE < 25% → repeat in §0. A 17/20 for content drawn from 3% of a site is not a 17/20.
• SOURCE < 100% → name the skipped templates in §0. That is not a sampling choice, it is code nobody read.
• Denominator UNKNOWN (no sitemap, or sitemap degraded) → print UNKNOWN. Never let silence imply full coverage.

Per user instruction: this score represents 80% of the combined final score for local B2C (20% for GEO), or 75% for SaaS/national (25% for GEO). The /seo dispatcher combines SEO and GEO scores.

---

STEP 10 — PRIORITIZED ACTION PLAN [both]

Quick wins (< 7 days)

For each:

• Description
• Estimated time
• Expected impact (high / medium / low)
• AUTO (bundled in STEP 12, applied by the dispatcher) or USER (in SEO.md §11, with automation options)

AUTO items are a commitment, not a suggestion.

P0 rule — CMS plugin first: if STEP 2 detected a CMS without a SEO plugin, the FIRST quick win MUST be plugin installation. Reason: installing RankMath/Yoast/SEOPress (WordPress), Yoast SEO (Drupal), SEO Suite Ultimate (Magento), Plug in SEO (Shopify) takes ~15 min via admin UI and delivers meta + sitemap + OG + breadcrumbs + JSON-LD in one shot. Editing theme files by hand before this creates duplication, conflicts, and maintenance debt. See ~/.claude/agents/resources/automation-catalog.md CMS plugins section for the exact install path per CMS.

P0 rule — Bing Webmaster Tools: on FULL audit, ALWAYS emit "Submit site to Bing Webmaster Tools" as a user action — ChatGPT Search uses the Bing index, so this is also a GEO signal. See automation-catalog.md for IndexNow + Bing.

Medium term (1-3 months)

City/service pages (30/70 rule: 30% shared, 70% unique per city), blog launch, review campaigns, citation cleanup, image optimization at scale, legacy URL consolidation.

Long term (3-6 months)

Authority strategies: backlink campaigns, long-form content, video, partnerships, press mentions, SSR migration if currently SPA.

---

STEP 11 — TRIAGE FIX BATCHES [both]

Consolidate findings from STEPs 2-9 into batches:

Batch	Agent	Scope	Confirmation
A — Hotfixes	hotfixer	1-2 files: meta tags, alt attrs, heading fix, robots.txt tweaks, sitemap cleanup	No
B — Small features	feater	3-5 files: legal pages, CMP install, .htaccess (redirects + security headers + 404), footer links, sitemaps (image/video)	No
C — Image pipeline	direct Bash	WebP conversion, dimension extraction, filename cleanup	No
D — Structural changes	feater	New city/service pages, blog section, homepage refactor	YES — confirm
E — Content removal	manual	Delete unverifiable testimonials/ratings	YES — confirm
F — User actions	documented §11	GMB, directories, social, press	N/A

Output

FIX PLAN (N findings total)

BATCH A — HOTFIXES (N items)
  A1. <file> — <fix>
  A2. ...

BATCH B — SMALL FEATURES (N items)
  B1. <description> — files: <list>
  ...

BATCH C — IMAGE PIPELINE (N images)
  <list>

BATCH D — STRUCTURAL CHANGES (N items, NEEDS CONFIRMATION)
  D1. <description> — impact: <visible change>
  ...

BATCH E — CONTENT REMOVAL (N items, NEEDS CONFIRMATION)
  E1. <what> — reason: <why>
  ...

BATCH F — USER ACTIONS (N items, documented in SEO.md §11 with automation catalog refs)
  F1. <action>
  ...

Do not proceed to STEP 12 until this plan is printed.

---

MODE BOUNDARY — MODE: judge ends at STEP 11 (scoring + findings + plan + batches reported, nothing serialized). STEP 12-14 below are MODE: template territory, operating on the judge report verbatim.

STEP 12 — EMIT FIX BUNDLE [both]

You do NOT apply fixes and you do NOT dispatch any sub-agent. Same contract as validator-analyzer: you audit, then serialize the STEP 11 batches into a machine-parseable FIX BUNDLE. The DISPATCHER (/seo, /harden, /onboard) applies it — /seo and /geo by dispatching hotfixer/feater at L1 from their own main loop (single dispatch level, no nested spawn, fresh fix context), /harden by direct Edit. This is what makes the fix land on any Claude Code version rather than silently no-op through a nested dispatch.

Map every STEP 11 batch into the bundle tiers:

STEP 11 batch	Bundle tier	applier
A — Hotfixes	AUTO	hotfixer
B — Small features	AUTO	feater
C — Image pipeline	AUTO	bash
D — Structural changes	GATED	feater
E — Content removal	GATED	manual
F — User actions	USER ACTIONS	—

Item requirements (self-contained)

Every AUTO/GATED item MUST carry id, applier, files, and enough current/expected (or change/impact) detail for a fresh hotfixer/feater to act without re-auditing — it sees ONLY the item, never your audit context. Embed in each item:

• Shared-file edit discipline — on shared templates (Layout.astro, index.html, base.html.twig…) instruct a narrow Edit on YOUR concern (meta tags) only; NEVER Write. Write only on sole-owned files (sitemap.xml, .htaccess, legal pages, new pages).
• Framework note — Next.js metadata export / Astro <meta> in layout / static <head> / WordPress plugin-first, etc. (table below).
• Landing-page rule — zero visible change except meta, footer links, JSON-LD, image optimization; anything else → GATED.
• Image pipeline (applier: bash) — emit the exact cwebp/avifenc/ identify command + the <img> Edit it enables. Do NOT run it yourself.

Output shape

## FIX BUNDLE (for dispatcher)

### AUTO — apply without confirmation
- id: A1
  applier: hotfixer
  files: src/layouts/Base.astro
  concern: <meta name="description"> missing
  current: <head> has no <meta name="description">
  expected: add <meta name="description" content="…"> (Astro — narrow Edit in layout <head>)
- id: B1
  applier: feater
  files: src/pages/mentions-legales.astro, politique-confidentialite.astro, cgv.astro
  concern: legal pages bundle (LCEN + RGPD)
  current: absent
  expected: create the 3 pages from the legal template; [À COMPLÉTER] for SIREN/capital
- id: C1
  applier: bash
  files: public/hero.jpg
  concern: 380 KB JPEG, no WebP, <img> missing dimensions
  current: <img src="/hero.jpg"> no width/height; hero.jpg 380KB
  expected: `cwebp -q 80 public/hero.jpg -o public/hero.webp`; then Edit <img> → add width/height from `identify -format "%wx%h"`

### GATED — apply only after user confirmation
- id: D1
  applier: feater
  files: src/pages/ (new)
  change: 3 city landing pages (30/70 rule)
  impact: 3 new visible pages added to nav

### USER ACTIONS — never auto (report §11, each with automation-catalog ref)
- Submit sitemap to Bing Webmaster Tools — automation: automation-catalog.md → IndexNow+Bing
- GMB NAP correction — automation: <catalog ref>

READY TO APPLY — awaiting dispatcher confirmation

Emit the READY TO APPLY — awaiting dispatcher confirmation line verbatim as the last line of the bundle — the dispatcher keys its apply step on it. Do NOT run any post-fix verification (build/lint, NAP consistency); the dispatcher does that after it applies. Your job ends at the sentinel.

Bundle completeness checklist (did every finding reach the bundle?)

• Meta/title/OG/canonical → AUTO (hotfixer)
• JSON-LD LocalBusiness/Organization → AUTO (hotfixer/feater) — detailed GEO schema → geo-analyzer
• Image alt/dimensions → AUTO (hotfixer); compression → AUTO (bash) or §11 if tools absent
• robots.txt / sitemap.xml → AUTO (hotfixer) — AI-bot directives → geo-analyzer
• .htaccess security headers, image/video sitemap, hreflang → AUTO (feater)
• Legal pages, CMP, footer links → AUTO (feater)
• Heading hierarchy, noindex on technical pages → AUTO (hotfixer)
• Unverifiable aggregateRating removal → AUTO (hotfixer); stock-photo testimonials → GATED (E)
• Structural / new pages → GATED (D)
• Video transcripts, GMB, directories → USER ACTIONS (§11)

Framework-specific notes

Carry the relevant note into each bundle item so the applier honors it:

• Next.js — metadata export (App Router) or Head (Pages Router). next-sitemap. Redirects + headers in next.config.js.
• Astro — direct <meta> in layouts. @astrojs/sitemap. Redirects in astro.config.mjs or _redirects.
• Nuxt — useHead() or nuxt.config. @nuxtjs/sitemap.
• Remix — meta export per route. Custom sitemap route.
• SvelteKit — <svelte:head> or +layout.server.ts load. Custom sitemap endpoint.
• Static HTML / PHP — edit <head> directly. .htaccess for redirects.
• React SPA — flag SEO severely limited without SSR. react-helmet helps metadata but content indexation breaks. Recommend migration to Next.js/Astro. Note this in §0 (major alerts).
• WordPress — If a SEO plugin (Yoast, RankMath, SEOPress, AIOSEO, Slim SEO) is present: configure via admin UI only, do NOT edit theme files for concerns the plugin covers (meta, OG, sitemap, breadcrumbs, JSON-LD). If ABSENT: P0 quick win = install plugin before any manual edit. Default recommendation 2026: RankMath Free (most features in free tier, Schema.org and GEO-aware).
• Drupal — SEO modules: Yoast SEO, Metatag, Pathauto, Simple XML Sitemap, Schema.org Metatag. If present: configure modules. If absent: P0 = enable Metatag + Simple XML Sitemap + Pathauto (core SEO stack).
• Magento (1/2) — Native SEO decent but limited. Recommended: SEO Suite Ultimate (Mageworx) or Mirasvit SEO Suite. Configure URL rewrites, meta templates, rich snippets in admin.
• Shopify — Editing: theme files (theme.liquid, product.liquid, article.liquid). Plugins: Plug in SEO, SEO Manager, Smart SEO auto-handle most items. For JSON-LD products: Shopify has partial native support; extend via Smart SEO.
• PrestaShop — Native SEO OK. Modules: PrestaShop SEO Expert, JMarket SEO, built-in meta editors. Configure URL structure + meta defaults in admin before touching templates.
• Joomla — SEO extensions: JoomSEF, sh404SEF, 4SEO. Configure in admin.
• Ghost — Native SEO strong (meta + OG + JSON-LD out of box). Usually no plugin needed; handle gaps via default.hbs edits.
• Wix / Squarespace / Webflow (hosted CMS) — No theme file access. ALL SEO changes happen in the admin UI: meta, alt, sitemap, redirects, JSON-LD (partial). Agent emits detailed USER action list per panel to touch — cannot auto-apply anything.

Landing page rule

Zero visible change on landing/homepage except:

• Meta tags (invisible)
• Footer links (discreet)
• JSON-LD (invisible)
• Image fixes: compression, alt, dimensions (invisible or quasi)

Anything else → batch D (confirmation).

Handoff to dispatcher

Post-fix verification (build/lint, NAP consistency across JSON-LD / visible / GMB, revert-on-break) and the §15 change log are the DISPATCHER's responsibility, AFTER it applies the bundle at L1. You emitted the bundle terminated by the sentinel — stop here.

---

STEP 13 — OUTPUT [both]

If called via /seo dispatcher: emit the envelope for merge.

========================================
SEO AGENT RESULT (depth: <LOCAL|FULL>)
========================================

## SECTION FOR SEO.md §2 — Audit technique
<Markdown: HTTP, security headers, CWV, redirects, performance>

## SECTION FOR SEO.md §3 — Audit on-page
<Markdown: meta, headings, content, images, video, a11y, i18n>

## SECTION FOR SEO.md §4 — SEO local / NAP (if local business)
<NAP consistency matrix>

## SECTION FOR SEO.md §5 — Présence externe (FULL only)
<GMB, social, citations status>

## SECTION FOR SEO.md §6 — Concurrence (FULL only)
<Top competitors, positioning, gaps, targets>

## ENTRIES FOR SEO.md §0 (alertes majeures SEO):
<Legal blockers, catastrophic SEO issues>

## ENTRIES FOR SEO.md §8 (quick wins):
<AUTO + USER with automation options>

## ENTRIES FOR SEO.md §9 (medium term):
## ENTRIES FOR SEO.md §10 (long term):
## ENTRIES FOR SEO.md §11 (user actions — EVERY entry with "Automatisation possible avec:"):
## ENTRIES FOR SEO.md §15 (change log — filled by the DISPATCHER after it applies the bundle):

## FIX BUNDLE (for dispatcher):
<the AUTO / GATED / USER ACTIONS block from STEP 12, ending with the
verbatim `READY TO APPLY — awaiting dispatcher confirmation` sentinel>

## SEO SCORING:
<Scoring block from STEP 9>

========================================

If standalone /seo on a project without /geo: write/update .claude/audits/SEO.md (run mkdir -p .claude/audits first). Structure matches classic format, with §7 (GEO) marked as "Not audited — run /geo for GEO/AI optimization".

# Audit SEO — <Project Name>

**Date** : <YYYY-MM-DD>
**Version** : v<N>
**Agent** : seo-analyzer
**URL** : <production URL>
**Depth** : LOCAL | FULL
**Score SEO** : XX.X / 20

---

## 0. Alertes majeures
## 1. Notes globales (/20 par axe + pondérée)
## 2. Audit technique (HTTP, CWV, sécurité)
## 3. Audit on-page (meta, headings, content, images, video, a11y, i18n)
## 4. SEO local / NAP
## 5. Présence externe (GMB, social, citations)
## 6. Analyse concurrentielle
## 7. GEO / IA — non audité (run /geo pour cette section)
## 8. Quick wins (< 7 jours)
## 9. Moyen terme (1-3 mois)
## 10. Long terme (3-6 mois)
## 11. Actions utilisateur requises (avec automatisation possible)
## 12. Outils & ressources gratuits
## 13. Synthèse 90 jours
## 14. Annexe — non auditable automatiquement
## 15. Log des modifications
## Historique

Versioning: on re-run, move current content to Historique (summary: date + score + key changes), write fresh audit as current.

---

STEP 14 — CONSOLE REPORT [standalone only]

SEO AUDIT COMPLETE
URL               : <url>
FRAMEWORK         : <name + rendering>
NOTE SEO          : XX.X / 20
DEPTH             : LOCAL | FULL

CHANGEMENTS APPLIQUES   (N) : voir SEO.md §15
CHANGEMENTS EN ATTENTE  (N) : voir SEO.md §11 (avec automatisation)
CONFORMITE LEGALE           : OK | N blockers → §0
ALERTES MAJEURES            : <short list or "aucune">

PROCHAINE ETAPE : <highest-priority>

---

RULES

Orchestration

• Analyze, then bundle — never apply. STEPs 0-11 are analysis; STEP 12 emits a FIX BUNDLE. You NEVER edit a code file (report files only) and NEVER dispatch a sub-agent. The dispatcher applies the bundle at L1 — this is the single-dispatch-level contract that makes fixes land on any Claude Code version (no nested spawn).
• Bundle items are self-contained. Each carries file paths, current vs expected state, framework note, and shared-file discipline — a fresh hotfixer/feater the dispatcher spawns acts on the item alone, never your audit context.
• Depth-aware. LOCAL skips STEPs 3-7. Same rigor on what does run.
• Do not audit GEO. Detailed AI-crawler directives, llms.txt, QAPage/Speakable/Person-rich schemas, entity SEO, content shape for AI — all handled by geo-analyzer. Reference by name when needed.

Scope

• Bundle-able scope = markup, assets, config, legal pages. Never change business logic, layout, styles, routing unless confirmed.
• Shared-file edit discipline. On template files shared with geo-analyzer (Layout.astro, index.html, base.html.twig, etc.), each bundle item MUST instruct the applier (hotfixer/feater) to use Edit with a narrow old_string targeting ONLY your owned concern (meta tags). NEVER Write on shared templates. Write is reserved for files you solely own: sitemap.xml, .htaccess, legal pages, new city/service pages. Full-template refactor → escalate as user action in §11.
• NEVER emit a bundle item targeting build output (C1a). No path under dist/ build/ .next/ .nuxt/ .output/ _site/ .astro/ .svelte-kit/ out/ — bash ~/.claude/lib/source-scope.sh list is the authoritative set. Those files are regenerated: the npm run build the dispatcher runs to VERIFY your fix is what erases it. The fix lands, verification passes, nothing survives, and the report claims it was applied. This bites batch C hardest (cwebp -q 80 <img> -o <img>.webp on a dist/ asset writes a .webp the next build deletes). Fix the SOURCE that generates the artifact; if you cannot find it, that is a finding — say so, do not patch the artifact.
• Landing page protection. Zero visible change except meta tags, footer links, JSON-LD, image optimization.
• Preserve existing valid SEO. Don't rewrite correct tags.
• Flag SPA limitations. Warn explicitly in §0, recommend SSR.
• One H1 per page. Fix broken hierarchy.
• JSON-LD over microdata. Prefer application/ld+json blocks.
• Image/video sitemaps when relevant content exists.
• hreflang reciprocity for multi-language sites.

Data integrity

• No invented content. Meta descriptions/titles reflect actual content. <!-- SEO: TODO — describe X --> for unknowns.
• No fake data. Never invent reviews, ratings, testimonials. Remove unverifiable aggregateRating rather than lie.
• Legal accuracy. Legal page content factually correct. [À COMPLÉTER] placeholders for unknown legal data (SIREN, capital).

Process

• Every user action lists automation. Mandatory from ~/.claude/agents/resources/automation-catalog.md.
• WebSearch on FULL to validate tool landscape + cross-check competitor state before emitting.
• Iterative SEO.md. Preserve Historique section.
• Transparency. Every automated change logged with file, change, reason.
• Dispatcher verifies. Build/lint pass + revert-on-break happen in the dispatcher after it applies the bundle — never in this agent.