Static SEO
Audits and improves the SEO setup of a static HTML site against nine categories — head metadata, structured data, content quality, Open Graph images, sitemaps and indexing, agent discovery, performance, redirects, and CI validation. Recipes are platform-neutral: raw <meta> tags, raw JSON-LD, hand-rolled sitemap.xml, generic CI tooling. Audit framework parallels astro-seo but without the @jdevalk/astro-seo-graph spine.
Code recipes live in AGENTS.md — read it when you need to implement a specific fix. This file has the workflow and audit checklist.
Workflow
- Detect the project — confirm this is a static site, identify the build tool, find where to apply changes.
- Audit — score nine categories and produce actionable findings.
- Improve — generate or modify files to close the gaps. Recipes are in
AGENTS.md.
- Metadata pass — invoke
metadata-check on every short string the skill generated (titles, descriptions, schema description fields, FAQ answers).
- Verify — run any build, validate the output, remind the user about non-file tasks (Search Console, Bing Webmaster Tools, IndexNow key submission).
Phase 0: Detect the project
Confirm the basics before auditing:
- It is actually a static site. Look for built HTML —
index.html at the repo root, or under _site/ (Jekyll), public/ (Hugo / 11ty / Gatsby), dist/ (Vite / Astro static), out/ (Next.js with output: export). If everything is server-rendered (Express, PHP, dynamic routes), this is the wrong skill — point at astro-seo for Astro, wp-readme-optimizer for WP plugin pages, or recommend a generic SEO audit instead.
- Source build tool. Drives where to apply head metadata changes:
_config.yml / _layouts/ → Jekyllconfig.toml / config.yaml / themes/ → Hugo.eleventy.js / _includes/ → 11tygatsby-config.js / src/components/SEO.* → Gatsbynext.config.js with output: 'export' and pages/_document.tsx → Next.js static exportastro.config.mjs → Astro (in which case use astro-seo instead)- No build config, just HTML files → hand-rolled or scraped (e.g.
wp-static-clone output). Edit the HTML directly or use a post-process script.
- Canonical site URL. Search the repo for the production origin — typically in
_config.yml, config.toml, astro.config, or hardcoded into a layout. If it's missing, empty, or localhost, flag as a blocking issue before anything else. Canonicals, sitemaps, OG image URLs, and JSON-LD @id values all derive from this.
- Deployment target. Read
vercel.json, netlify.toml, wrangler.toml, or public/_headers to determine the host. Drives redirect and header syntax in Phase 2.
- Is the site multilingual? Check for locale subdirectories (
/en/, /nl/, /de/) or build-tool i18n config. If yes, hreflang matters; if no, skip it.
- What's already in
<head>? Open one built HTML file and inventory: title, description, canonical, robots, Open Graph, Twitter cards, JSON-LD, hreflang. The audit in Phase 1 is faster if you can reference what's there.
Ask only what you can't detect.
Phase 1: Audit
Score each category out of 10. For each, give 2–4 specific findings that quote the actual HTML, config, or template. Within each category, checks are tiered:
- Must — ship blockers. A failure causes visible SEO regression.
- Should — standard practice. Skipping costs reach.
- Nice — forward-looking or situational. Useful but not baseline for every site.
Skip Nice checks for small personal sites unless the user asks for the full treatment.
1. Head metadata (/10)
- Must — every page has a
<title> and <meta name="description">.
- Must —
<link rel="canonical"> set, with tracking parameters stripped, derived from the production origin.
- Must — canonical omitted when the page is
noindex (per Google's recommendation).
- Must —
<title> length 30–65 characters, <meta name="description"> length 70–200 characters (the SERP-truncation bounds; same as metadata-check defaults).
- Should —
<meta name="robots"> includes max-snippet:-1, max-image-preview:large, max-video-preview:-1.
- Should — Open Graph (
og:title, og:description, og:image, og:url, og:type, og:site_name) on every page.
- Should — Twitter Card tags (
twitter:card) suppressed when they duplicate Open Graph (Twitter falls back automatically).
- Should —
hreflang alternates on multilingual sites. Skip if monolingual.
- Should — single
<meta name="robots"> and single og:image per page (legacy tooling sometimes emits duplicates).
2. Structured data / JSON-LD (/10)
- Must — at least one
<script type="application/ld+json"> block on every important page.
- Should — linked
@graph rather than a flat Article object — entities wired with @id references so a BlogPosting can point at its Person author and WebPage parent.
- Should —
WebSite, Blog / WebPage, Person / Organization, BlogPosting / Article, BreadcrumbList, ImageObject all present where relevant.
- Should — trust signals:
publishingPrinciples, copyrightHolder, copyrightYear, knowsAbout, SearchAction.
- Must — validates in Rich Results Test and ClassySchema.
3. Content quality (/10)
- Must — every page has a unique
<title> and <meta name="description"> (no duplicate metadata across the site).
- Must — exactly one
<h1> per page.
- Should —
<title> and <meta name="description"> audited via metadata-check (Phase 2.5) for front-loading, concreteness, and SERP fit.
- Should — body prose audited via
readability-check for individual long-form posts (don't bulk-audit).
- Should — every
<img> has an alt attribute (or alt="" / role="presentation" for decorative).
- Should — internal links use root-relative paths (
/foo/) not absolute (https://...) — survives domain changes and previews.
4. Open Graph images (/10)
- Must — every page has an OG image.
- Must — 1200×675 (Google Discover minimum 1200px wide, 16:9 ratio).
- Should — JPEG (social platforms don't reliably support WebP / AVIF for OG).
- Should — generated at build time (satori-cli, sharp, ImageMagick, Vercel OG, Bannerbear) rather than uploaded manually per page — prevents drift.
- Should — URL derived deterministically from the slug (e.g.
/og/<slug>.jpg) so adding a page automatically gets an image.
- Should — every
<img> in body content has an alt attribute (or alt="" / role="presentation"). Validated in CI via html-proofer or similar.
5. Sitemaps and indexing (/10)
- Must —
/sitemap.xml (or /sitemap_index.xml for split sitemaps) reachable, valid XML, every URL returns 200.
- Must —
robots.txt present at the site root and references the sitemap.
- Must — RSS feed exists, advertised via
<link rel="alternate" type="application/rss+xml">, contains full post content (not truncated excerpts).
- Should — split per-section if the site has multiple content types (
sitemap-posts.xml, sitemap-pages.xml) — easier to debug indexing in GSC.
- Should —
<lastmod> populated from git commit timestamps (most accurate), build timestamps (acceptable), or frontmatter dates (last resort). Filesystem mtime from CI checkout is wrong — it's the checkout date, not the content date.
- Should — IndexNow integrated. Verification key as a static
/<key>.txt route at the site root, plus a build-or-deploy hook that POSTs new URLs to https://api.indexnow.org/IndexNow. Gate the submission on the production host (e.g. CF_PAGES_BRANCH=main, VERCEL_ENV=production, CONTEXT=production) — unconditional submission pings the endpoint from local builds with URLs the production host hasn't served yet, which gets the key marked invalid (403) and forces rotation.
6. Agent discovery (/10)
- Should — schema endpoints (
/schema/<type>.json) exposing corpus-wide JSON-LD per content type. Static JSON files committed to the repo or regenerated by the build.
- Should — schema map (
/schemamap.xml) listing every schema endpoint, with Schemamap: directive in robots.txt.
- Should —
llms.txt at the site root listing pages (title + description) for LLM consumers. Static text file; one line per page.
- Should — markdown-alternate URLs (
/blog/post.md next to /blog/post/) serving clean markdown with YAML frontmatter so AI agents can consume content without HTML parsing. Either commit .md siblings, or use a Cloudflare Transform Rule + Vary: Accept for content negotiation (CF Pages strips custom Vary headers, so use the Transform Rule's URL rewrite alone — recipe in AGENTS.md).
- Should — API catalog at
/.well-known/api-catalog per RFC 9727, as application/linkset+json (RFC 9264). Lists schema endpoints, schemamap, RSS feed, and any site-specific APIs. Static JSON file.
- Should — Content Signals directive in
robots.txt (Content-Signal: ai-train=yes, search=yes, ai-input=yes or your preferred policy). One line, IETF draft, low cost.
- Should —
Link header on /* pointing to discovery files (sitemap, llms.txt, api-catalog, schemamap). Agents reading response headers find them without parsing HTML. Host-specific (_headers on Cloudflare Pages / Netlify, vercel.json on Vercel, server config elsewhere).
- Nice — MCP server card at
/.well-known/mcp/server-card.json and / or A2A agent card at /.well-known/agent-card.json. Only relevant when the site exposes an MCP server or A2A agent.
- Nice —
<link rel="nlweb"> pointing to a conversational endpoint. NLWeb adoption is early; the tag is one line and worth having, but not a scoring blocker in 2026.
- Nice — ARD (Agentic Resource Discovery) catalog at
/.well-known/ai-catalog.json, listing what the domain offers (MCP server, A2A agent, OKF bundle, site-specific APIs). v0.9 draft, so optional — but it's the discovery layer the MCP / A2A cards and OKF bundle pay off through. Two gotchas: the base spec (Agent-Card/ai-catalog) names the media-type field mediaType while the ARD layer (ards-project/ard-spec) names it type — emit both keys with the same value so the entry validates under either reading (both specs require consumers to ignore unknown keys). ARD also adds an optional representativeQueries array of sample prompts per entry. Static JSON file.
- Nice — OKF (Open Knowledge Format) bundle: a tree of typed Markdown concept files (one per page, paths mirroring canonical URLs) packaged as a single
.tar.gz, with index files in between. Serving and discovery are explicit non-goals of OKF — that's what the ARD catalog entry is for. v0.9 draft, optional. There's no registered media type yet, so the interim string is application/okf-bundle+gzip (tracked in knowledge-catalog#111 and ard-spec#27); mark it interim, it may change. Best generated from the same source the rest of the site derives from rather than a hand-maintained copy.
7. Performance (/10)
- Must — hashed assets serve
Cache-Control: public, max-age=31536000, immutable (or equivalent) so they only download once.
- Should — primary web font preloaded as
woff2 via <link rel="preload" as="font" crossorigin>.
- Should —
No-Vary-Search response header strips UTM parameters from cache key (so /?utm_source=x and / share a cache entry).
- Should — no render-blocking JavaScript on first paint (defer or async non-critical scripts).
- Should — images use modern formats (WebP / AVIF for in-page content; JPEG only for OG cards) and
loading="lazy" below the fold.
- Should — all Lighthouse / PageSpeed Core Web Vitals in the green: LCP < 2.5s, INP < 200ms, CLS < 0.1.
8. Redirects and error handling (/10)
- Must —
_redirects / vercel.json / server config maintained for every URL that ever existed and moved.
- Must —
301 not 302 for permanent moves.
- Must —
404.html (or equivalent) returns a 404 status, not 200. Verify with curl -I against a deliberately wrong URL.
- Should — fuzzy-match suggestion on the 404 page ("did you mean…?") for typos in URLs. Static implementation: pre-build a JSON index of valid slugs, fuzzy-match client-side.
9. CI validation (/10)
- Must — broken-link checker in CI. linkinator or lychee on every push that touches content. Internal and external links both — internal catches build regressions, external catches link rot. Schedule a weekly run for external-only checks.
- Should — HTML validation via html-proofer or W3C Validator — catches malformed markup that breaks crawlers.
- Should — Lighthouse CI on every push, with score thresholds (e.g. SEO ≥ 95, Performance ≥ 80).
- Should — JSON-LD validation in CI via the Schema.org JSON-LD validator (no official CLI; pipe through a Node script that POSTs to the API).
- Should — title and description length validation in CI: a small script that walks built HTML, extracts
<title> and <meta name="description">, flags anything outside SERP-truncation bounds (title 30–65, description 70–200).
Phase 2: Improve
Based on the audit, produce concrete code. Always ask before overwriting. Read AGENTS.md for detailed recipes.
Branch on the Phase 0 findings. If the site is a known build tool (Hugo, Jekyll, 11ty, Gatsby, Next.js), apply changes at the source level (templates, config, frontmatter). For hand-rolled or scraped HTML, post-process the built output. The recipes in AGENTS.md are output-shape recipes — show the HTML you want to land at — and a per-tool note on where to plumb them through.
AGENTS.md sections: Head metadata (the canonical block), JSON-LD graph, OG image generation (build-script options), sitemap.xml and robots.txt, IndexNow, llms.txt, Markdown alternates, API catalog, Content Signals, Link headers, Performance headers, Redirects by host, CI workflows.
Phase 2.5: Metadata and readability pass
Invoke the metadata-check skill on every short string the skill generated or modified: page titles, meta descriptions, schema description fields, FAQ answers, and any frontmatter excerpt values you wrote. It checks front-loading, concreteness, filler, active voice, title / description duplication, difficult words, SERP-truncation fit (title 30–65, description 70–200), and one-idea-per-field. Apply fixes directly. Skip the pass for technical strings (URLs, schema @id values, enum values).
If the project has a blog or docs section, mention as a follow-up that the readability-check skill can audit individual posts for multi-paragraph prose quality — but don't audit the entire content corpus yourself.
Phase 3: Verify
- Build the site (or rebuild if mid-iteration). Surface any build warnings.
- Spot-check the built HTML: one page's
<head> should be clean, canonical correct, JSON-LD graph present and linked.
- Run the homepage through Rich Results Test and ClassySchema.
- Confirm
/sitemap.xml exists, returns 200, and references the right URLs.
- Confirm
/robots.txt references the sitemap and includes Content Signals.
- If IndexNow is wired, confirm the key verification route returns the key at
/<key>.txt.
- Run the local broken-link check (
linkinator http://localhost:8080 --recurse).
- Remind the user about tasks that can't be automated:
Output format
## Static SEO audit: [site name]
### Score
| Category | Score |
| ------------------------------------- | ----: |
| 1. Head metadata | x/10 |
| 2. Structured data / JSON-LD | x/10 |
| 3. Content quality | x/10 |
| 4. Open Graph images | x/10 |
| 5. Sitemaps and indexing | x/10 |
| 6. Agent discovery | x/10 |
| 7. Performance | x/10 |
| 8. Redirects and error handling | x/10 |
| 9. CI validation | x/10 |
| **Total** | xx/90 |
### Findings
[Grouped by category. Quote actual HTML / config. Be specific.]
### Files generated or changed
[List with short description of each.]
### Next steps
[Non-file tasks: GSC, Bing Webmaster Tools, IndexNow key, analytics.]
Key principles
- Audit the output, fix at the source. The skill checks the built HTML, but recommends changes at whatever layer produces it (Hugo template, Jekyll layout, 11ty include, post-process script). Don't recommend a fix that won't survive the next build.
- Static = host-portable. Every recipe should work on any static host. Where syntax differs (
_redirects vs vercel.json), give both forms.
- Topics, not keyphrases. When reviewing content, focus on topical coverage and readability, not keyword density.
- Agent discovery matters now. Schema endpoints, schema map, llms.txt, API catalog, markdown alternates, MCP / A2A cards — the crawler is no longer the only consumer.
- Defer to
astro-seo for Astro. That skill produces less hand-rolled boilerplate via @jdevalk/astro-seo-graph. static-seo is for everything else.
1---2name: static-seo3description: Audits and improves SEO for static HTML sites. Use when the user asks to audit, set up, or improve SEO on a static site (Hugo, Jekyll, 11ty, Gatsby, Next.js static export, hand-rolled HTML, or `wp-static-clone` output), or mentions head metadata, structured data, JSON-LD, sitemaps, IndexNow, Open Graph images, schema endpoints, NLWeb, hreflang, or search engine indexing for a static site. For Astro projects, use `astro-seo` instead — its recipes produce less hand-rolled boilerplate by routing through `@jdevalk/astro-seo-graph`.4---5
6# Static SEO
7
8Audits and improves the SEO setup of a static HTML site against nine categories — head metadata, structured data, content quality, Open Graph images, sitemaps and indexing, agent discovery, performance, redirects, and CI validation. Recipes are platform-neutral: raw `<meta>` tags, raw JSON-LD, hand-rolled `sitemap.xml`, generic CI tooling. Audit framework parallels [`astro-seo`](../astro-seo/) but without the `@jdevalk/astro-seo-graph` spine.
9
10**Code recipes live in `AGENTS.md`** — read it when you need to implement a specific fix. This file has the workflow and audit checklist.
11
12## Workflow
13
141. **Detect the project** — confirm this is a static site, identify the build tool, find where to apply changes.
152. **Audit** — score nine categories and produce actionable findings.
163. **Improve** — generate or modify files to close the gaps. Recipes are in `AGENTS.md`.
174. **Metadata pass** — invoke `metadata-check` on every short string the skill generated (titles, descriptions, schema `description` fields, FAQ answers).
185. **Verify** — run any build, validate the output, remind the user about non-file tasks (Search Console, Bing Webmaster Tools, IndexNow key submission).
19
20---
21
22## Phase 0: Detect the project
23
24Confirm the basics before auditing:
25
26- **It is actually a static site.** Look for built HTML — `index.html` at the repo root, or under `_site/` (Jekyll), `public/` (Hugo / 11ty / Gatsby), `dist/` (Vite / Astro static), `out/` (Next.js with `output: export`). If everything is server-rendered (Express, PHP, dynamic routes), this is the wrong skill — point at `astro-seo` for Astro, `wp-readme-optimizer` for WP plugin pages, or recommend a generic SEO audit instead.
27- **Source build tool.** Drives where to apply head metadata changes:
28 - `_config.yml` / `_layouts/` → Jekyll
29 - `config.toml` / `config.yaml` / `themes/` → Hugo
30 - `.eleventy.js` / `_includes/` → 11ty
31 - `gatsby-config.js` / `src/components/SEO.*` → Gatsby
32 - `next.config.js` with `output: 'export'` and `pages/_document.tsx` → Next.js static export
33 - `astro.config.mjs` → Astro (in which case **use `astro-seo` instead**)
34 - No build config, just HTML files → hand-rolled or scraped (e.g. `wp-static-clone` output). Edit the HTML directly or use a post-process script.
35- **Canonical site URL.** Search the repo for the production origin — typically in `_config.yml`, `config.toml`, `astro.config`, or hardcoded into a layout. **If it's missing, empty, or `localhost`, flag as a blocking issue before anything else.** Canonicals, sitemaps, OG image URLs, and JSON-LD `@id` values all derive from this.
36- **Deployment target.** Read `vercel.json`, `netlify.toml`, `wrangler.toml`, or `public/_headers` to determine the host. Drives redirect and header syntax in Phase 2.
37- **Is the site multilingual?** Check for locale subdirectories (`/en/`, `/nl/`, `/de/`) or build-tool i18n config. If yes, hreflang matters; if no, skip it.
38- **What's already in `<head>`?** Open one built HTML file and inventory: title, description, canonical, robots, Open Graph, Twitter cards, JSON-LD, hreflang. The audit in Phase 1 is faster if you can reference what's there.
39
40Ask only what you can't detect.
41
42---
43
44## Phase 1: Audit
45
46Score each category out of 10. For each, give 2–4 specific findings that quote the actual HTML, config, or template. Within each category, checks are tiered:
47
48- **Must** — ship blockers. A failure causes visible SEO regression.
49- **Should** — standard practice. Skipping costs reach.
50- **Nice** — forward-looking or situational. Useful but not baseline for every site.
51
52Skip **Nice** checks for small personal sites unless the user asks for the full treatment.
53
54### 1. Head metadata (/10)
55
56- **Must** — every page has a `<title>` and `<meta name="description">`.
57- **Must** — `<link rel="canonical">` set, with tracking parameters stripped, derived from the production origin.
58- **Must** — canonical omitted when the page is `noindex` (per Google's recommendation).
59- **Must** — `<title>` length 30–65 characters, `<meta name="description">` length 70–200 characters (the SERP-truncation bounds; same as `metadata-check` defaults).
60- **Should** — `<meta name="robots">` includes `max-snippet:-1`, `max-image-preview:large`, `max-video-preview:-1`.
61- **Should** — Open Graph (`og:title`, `og:description`, `og:image`, `og:url`, `og:type`, `og:site_name`) on every page.
62- **Should** — Twitter Card tags (`twitter:card`) suppressed when they duplicate Open Graph (Twitter falls back automatically).
63- **Should** — `hreflang` alternates on multilingual sites. Skip if monolingual.
64- **Should** — single `<meta name="robots">` and single `og:image` per page (legacy tooling sometimes emits duplicates).
65
66### 2. Structured data / JSON-LD (/10)
67
68- **Must** — at least one `<script type="application/ld+json">` block on every important page.
69- **Should** — linked `@graph` rather than a flat `Article` object — entities wired with `@id` references so a `BlogPosting` can point at its `Person` author and `WebPage` parent.
70- **Should** — `WebSite`, `Blog` / `WebPage`, `Person` / `Organization`, `BlogPosting` / `Article`, `BreadcrumbList`, `ImageObject` all present where relevant.
71- **Should** — trust signals: `publishingPrinciples`, `copyrightHolder`, `copyrightYear`, `knowsAbout`, `SearchAction`.
72- **Must** — validates in [Rich Results Test](https://search.google.com/test/rich-results) and [ClassySchema](https://classyschema.org/Visualisation).
73
74### 3. Content quality (/10)
75
76- **Must** — every page has a unique `<title>` and `<meta name="description">` (no duplicate metadata across the site).
77- **Must** — exactly one `<h1>` per page.
78- **Should** — `<title>` and `<meta name="description">` audited via `metadata-check` (Phase 2.5) for front-loading, concreteness, and SERP fit.
79- **Should** — body prose audited via `readability-check` for individual long-form posts (don't bulk-audit).
80- **Should** — every `<img>` has an `alt` attribute (or `alt=""` / `role="presentation"` for decorative).
81- **Should** — internal links use root-relative paths (`/foo/`) not absolute (`https://...`) — survives domain changes and previews.
82
83### 4. Open Graph images (/10)
84
85- **Must** — every page has an OG image.
86- **Must** — 1200×675 (Google Discover minimum 1200px wide, 16:9 ratio).
87- **Should** — JPEG (social platforms don't reliably support WebP / AVIF for OG).
88- **Should** — generated at build time (satori-cli, sharp, ImageMagick, Vercel OG, Bannerbear) rather than uploaded manually per page — prevents drift.
89- **Should** — URL derived deterministically from the slug (e.g. `/og/<slug>.jpg`) so adding a page automatically gets an image.
90- **Should** — every `<img>` in body content has an `alt` attribute (or `alt=""` / `role="presentation"`). Validated in CI via `html-proofer` or similar.
91
92### 5. Sitemaps and indexing (/10)
93
94- **Must** — `/sitemap.xml` (or `/sitemap_index.xml` for split sitemaps) reachable, valid XML, every URL returns 200.
95- **Must** — `robots.txt` present at the site root and references the sitemap.
96- **Must** — RSS feed exists, advertised via `<link rel="alternate" type="application/rss+xml">`, contains full post content (not truncated excerpts).
97- **Should** — split per-section if the site has multiple content types (`sitemap-posts.xml`, `sitemap-pages.xml`) — easier to debug indexing in GSC.
98- **Should** — `<lastmod>` populated from git commit timestamps (most accurate), build timestamps (acceptable), or frontmatter dates (last resort). Filesystem `mtime` from CI checkout is wrong — it's the checkout date, not the content date.
99- **Should** — IndexNow integrated. Verification key as a static `/<key>.txt` route at the site root, plus a build-or-deploy hook that POSTs new URLs to `https://api.indexnow.org/IndexNow`. **Gate the submission on the production host** (e.g. `CF_PAGES_BRANCH=main`, `VERCEL_ENV=production`, `CONTEXT=production`) — unconditional submission pings the endpoint from local builds with URLs the production host hasn't served yet, which gets the key marked invalid (403) and forces rotation.
100
101### 6. Agent discovery (/10)
102
103- **Should** — schema endpoints (`/schema/<type>.json`) exposing corpus-wide JSON-LD per content type. Static JSON files committed to the repo or regenerated by the build.
104- **Should** — schema map (`/schemamap.xml`) listing every schema endpoint, with `Schemamap:` directive in `robots.txt`.
105- **Should** — [`llms.txt`](https://llmstxt.org) at the site root listing pages (title + description) for LLM consumers. Static text file; one line per page.
106- **Should** — markdown-alternate URLs (`/blog/post.md` next to `/blog/post/`) serving clean markdown with YAML frontmatter so AI agents can consume content without HTML parsing. Either commit `.md` siblings, or use a Cloudflare Transform Rule + `Vary: Accept` for content negotiation (CF Pages strips custom Vary headers, so use the Transform Rule's URL rewrite alone — recipe in `AGENTS.md`).
107- **Should** — API catalog at `/.well-known/api-catalog` per [RFC 9727](https://www.rfc-editor.org/rfc/rfc9727), as `application/linkset+json` ([RFC 9264](https://www.rfc-editor.org/rfc/rfc9264)). Lists schema endpoints, schemamap, RSS feed, and any site-specific APIs. Static JSON file.
108- **Should** — Content Signals directive in `robots.txt` (`Content-Signal: ai-train=yes, search=yes, ai-input=yes` or your preferred policy). One line, IETF draft, low cost.
109- **Should** — `Link` header on `/*` pointing to discovery files (sitemap, llms.txt, api-catalog, schemamap). Agents reading response headers find them without parsing HTML. Host-specific (`_headers` on Cloudflare Pages / Netlify, `vercel.json` on Vercel, server config elsewhere).
110- **Nice** — MCP server card at `/.well-known/mcp/server-card.json` and / or A2A agent card at `/.well-known/agent-card.json`. Only relevant when the site exposes an MCP server or A2A agent.
111- **Nice** — `<link rel="nlweb">` pointing to a conversational endpoint. NLWeb adoption is early; the tag is one line and worth having, but not a scoring blocker in 2026.
112- **Nice** — ARD ([Agentic Resource Discovery](https://agenticresourcediscovery.org/)) catalog at `/.well-known/ai-catalog.json`, listing what the domain offers (MCP server, A2A agent, OKF bundle, site-specific APIs). v0.9 draft, so optional — but it's the discovery layer the MCP / A2A cards and OKF bundle pay off through. Two gotchas: the base spec ([`Agent-Card/ai-catalog`](https://github.com/Agent-Card/ai-catalog)) names the media-type field `mediaType` while the ARD layer ([`ards-project/ard-spec`](https://github.com/ards-project/ard-spec)) names it `type` — emit **both keys with the same value** so the entry validates under either reading (both specs require consumers to ignore unknown keys). ARD also adds an optional `representativeQueries` array of sample prompts per entry. Static JSON file.
113- **Nice** — OKF ([Open Knowledge Format](https://github.com/GoogleCloudPlatform/knowledge-catalog)) bundle: a tree of typed Markdown concept files (one per page, paths mirroring canonical URLs) packaged as a single `.tar.gz`, with index files in between. Serving and discovery are explicit non-goals of OKF — that's what the ARD catalog entry is for. v0.9 draft, optional. There's **no registered media type yet**, so the interim string is `application/okf-bundle+gzip` (tracked in [knowledge-catalog#111](https://github.com/GoogleCloudPlatform/knowledge-catalog/issues/111) and [ard-spec#27](https://github.com/ards-project/ard-spec/issues/27)); mark it interim, it may change. Best generated from the same source the rest of the site derives from rather than a hand-maintained copy.
114
115### 7. Performance (/10)
116
117- **Must** — hashed assets serve `Cache-Control: public, max-age=31536000, immutable` (or equivalent) so they only download once.
118- **Should** — primary web font preloaded as `woff2` via `<link rel="preload" as="font" crossorigin>`.
119- **Should** — `No-Vary-Search` response header strips UTM parameters from cache key (so `/?utm_source=x` and `/` share a cache entry).
120- **Should** — no render-blocking JavaScript on first paint (defer or async non-critical scripts).
121- **Should** — images use modern formats (WebP / AVIF for in-page content; JPEG only for OG cards) and `loading="lazy"` below the fold.
122- **Should** — all Lighthouse / PageSpeed Core Web Vitals in the green: LCP < 2.5s, INP < 200ms, CLS < 0.1.
123
124### 8. Redirects and error handling (/10)
125
126- **Must** — `_redirects` / `vercel.json` / server config maintained for every URL that ever existed and moved.
127- **Must** — `301` not `302` for permanent moves.
128- **Must** — `404.html` (or equivalent) returns a 404 status, not 200. Verify with `curl -I` against a deliberately wrong URL.
129- **Should** — fuzzy-match suggestion on the 404 page ("did you mean…?") for typos in URLs. Static implementation: pre-build a JSON index of valid slugs, fuzzy-match client-side.
130
131### 9. CI validation (/10)
132
133- **Must** — broken-link checker in CI. [linkinator](https://github.com/JustinBeckwith/linkinator) or [lychee](https://github.com/lycheeverse/lychee-action) on every push that touches content. Internal and external links both — internal catches build regressions, external catches link rot. Schedule a weekly run for external-only checks.
134- **Should** — HTML validation via [html-proofer](https://github.com/gjtorikian/html-proofer) or [W3C Validator](https://validator.w3.org/) — catches malformed markup that breaks crawlers.
135- **Should** — [Lighthouse CI](https://github.com/GoogleChrome/lighthouse-ci) on every push, with score thresholds (e.g. SEO ≥ 95, Performance ≥ 80).
136- **Should** — JSON-LD validation in CI via the [Schema.org JSON-LD validator](https://validator.schema.org/) (no official CLI; pipe through a Node script that POSTs to the API).
137- **Should** — title and description length validation in CI: a small script that walks built HTML, extracts `<title>` and `<meta name="description">`, flags anything outside SERP-truncation bounds (title 30–65, description 70–200).
138
139---
140
141## Phase 2: Improve
142
143Based on the audit, produce concrete code. Always ask before overwriting. **Read `AGENTS.md` for detailed recipes.**
144
145**Branch on the Phase 0 findings.** If the site is a known build tool (Hugo, Jekyll, 11ty, Gatsby, Next.js), apply changes at the source level (templates, config, frontmatter). For hand-rolled or scraped HTML, post-process the built output. The recipes in `AGENTS.md` are output-shape recipes — show the HTML you want to land at — and a per-tool note on where to plumb them through.
146
147`AGENTS.md` sections: Head metadata (the canonical block), JSON-LD graph, OG image generation (build-script options), `sitemap.xml` and `robots.txt`, IndexNow, llms.txt, Markdown alternates, API catalog, Content Signals, Link headers, Performance headers, Redirects by host, CI workflows.
148
149---
150
151## Phase 2.5: Metadata and readability pass
152
153Invoke the `metadata-check` skill on every short string the skill generated or modified: page titles, meta descriptions, schema `description` fields, FAQ answers, and any frontmatter `excerpt` values you wrote. It checks front-loading, concreteness, filler, active voice, title / description duplication, difficult words, SERP-truncation fit (title 30–65, description 70–200), and one-idea-per-field. Apply fixes directly. Skip the pass for technical strings (URLs, schema `@id` values, enum values).
154
155If the project has a blog or docs section, mention as a follow-up that the `readability-check` skill can audit individual posts for multi-paragraph prose quality — but don't audit the entire content corpus yourself.
156
157---
158
159## Phase 3: Verify
160
161- Build the site (or rebuild if mid-iteration). Surface any build warnings.
162- Spot-check the built HTML: one page's `<head>` should be clean, canonical correct, JSON-LD graph present and linked.
163- Run the homepage through [Rich Results Test](https://search.google.com/test/rich-results) and [ClassySchema](https://classyschema.org/Visualisation).
164- Confirm `/sitemap.xml` exists, returns 200, and references the right URLs.
165- Confirm `/robots.txt` references the sitemap and includes Content Signals.
166- If IndexNow is wired, confirm the key verification route returns the key at `/<key>.txt`.
167- Run the local broken-link check (`linkinator http://localhost:8080 --recurse`).
168- Remind the user about tasks that can't be automated:
169 - Register the site in [Google Search Console](https://search.google.com/search-console) and [Bing Webmaster Tools](https://www.bing.com/webmasters).
170 - Submit the sitemap in both.
171 - Generate an IndexNow key and commit the `.txt` verification file.
172 - Install [Plausible](https://plausible.io/) or equivalent privacy-friendly analytics.
173
174---
175
176## Output format
177
178```markdown
179## Static SEO audit: [site name]
180
181### Score
182| Category | Score |
183| ------------------------------------- | ----: |
184| 1. Head metadata | x/10 |
185| 2. Structured data / JSON-LD | x/10 |
186| 3. Content quality | x/10 |
187| 4. Open Graph images | x/10 |
188| 5. Sitemaps and indexing | x/10 |
189| 6. Agent discovery | x/10 |
190| 7. Performance | x/10 |
191| 8. Redirects and error handling | x/10 |
192| 9. CI validation | x/10 |
193| **Total** | xx/90 |
194
195### Findings
196[Grouped by category. Quote actual HTML / config. Be specific.]
197
198### Files generated or changed
199[List with short description of each.]
200
201### Next steps
202[Non-file tasks: GSC, Bing Webmaster Tools, IndexNow key, analytics.]
203```
204
205---
206
207## Key principles
208
209- **Audit the output, fix at the source.** The skill checks the built HTML, but recommends changes at whatever layer produces it (Hugo template, Jekyll layout, 11ty include, post-process script). Don't recommend a fix that won't survive the next build.
210- **Static = host-portable.** Every recipe should work on any static host. Where syntax differs (`_redirects` vs `vercel.json`), give both forms.
211- **Topics, not keyphrases.** When reviewing content, focus on topical coverage and readability, not keyword density.
212- **Agent discovery matters now.** Schema endpoints, schema map, llms.txt, API catalog, markdown alternates, MCP / A2A cards — the crawler is no longer the only consumer.
213- **Defer to `astro-seo` for Astro.** That skill produces less hand-rolled boilerplate via `@jdevalk/astro-seo-graph`. `static-seo` is for everything else.
jdevalk