What categories and topics does The Website Specification cover?

Updated

The Website Specification (specification.website) organises its content into ten categories covering 173 topics in total. Each category maps to widely-accepted standards, and every topic links back to its source standard — WHATWG, W3C, IETF RFCs, WCAG, or MDN. The categories are: Foundations, SEO, Accessibility, Security, Well-Known URIs, Agent Readiness, Performance, Privacy, Resilience, and Internationalisation.

The ten categories at a glance

Category Topics What it covers
Foundations 20 The HTML, head, and document basics every page needs
SEO 14 Search visibility — robots.txt, sitemaps, canonicals, structured data
Accessibility 30 WCAG-aligned rules so people of all abilities can use the site
Security 20 Headers, transport, and policies that keep visitors safe
Well-Known URIs 13 Standard, agreed-upon paths under /.well-known/
Agent Readiness 22 Things that make a site legible to AI agents and crawlers
Performance 26 Core Web Vitals, caching, images, fonts, network behaviour
Privacy 7 Consent, signals, and respecting visitor choice
Resilience 8 Graceful failure — error pages, offline, redirects
Internationalisation 13 Language, localisation, and related concerns

Accessibility (30) and Performance (26) are the largest categories; Privacy (7) and Resilience (8) are the smallest.

What each category actually contains

Foundations (20 topics)

The HTML, head, and document basics every page needs. This is the layer that everything else builds on — document structure, metadata, and the core markup decisions that apply regardless of platform.

SEO (14 topics)

Search visibility concerns: robots.txt, sitemaps, canonical URLs, and structured data. These are the signals that determine how search engines discover, index, and present your pages.

Accessibility (30 topics)

WCAG-aligned rules so people of all abilities can use the site. The excerpt specifically cites WCAG contrast as an example of the kind of detail covered here.

Security (20 topics)

Headers, transport, and policies that keep visitors safe. The excerpt names /.well-known/security.txt as one example topic in this area.

Well-Known URIs (13 topics)

Standard, agreed-upon paths under /.well-known/. These are the conventional locations that other systems and tools expect to find — for example /.well-known/security.txt and /.well-known/gpc.json (the latter added 24 September 2026).

Agent Readiness (22 topics)

Things that make a site legible to AI agents and crawlers. The spec itself practises what it preaches here: it publishes an open MCP server (read-only, no auth), an Agent Skill, per-page Markdown via /llms.txt, and supports Accept: text/markdown on any spec URL. Recent additions include auth.md agent registration guidance (30 September 2026).

Performance (26 topics)

Core Web Vitals, caching, images, fonts, and network behaviour. This is the second-largest category and covers the technical delivery side of a site.

Privacy (7 topics)

Consent, signals, and respecting visitor choice. The smallest category alongside Resilience.

Resilience (8 topics)

Graceful failure — error pages, offline behaviour, and redirects. What happens when things go wrong.

Internationalisation (13 topics)

Language, localisation, and related concerns for sites serving multiple languages or regions.

How the topics are structured

Each topic is a yes/no checklist item. For every item you get three things:

  1. What it is — the feature or requirement in plain terms.
  2. Why it matters — the rationale, linked to the source standard.
  3. How to implement it — implementation hints that follow the spec rather than any particular platform.

The spec is explicitly platform-agnostic: whether you ship WordPress, Drupal, TYPO3, Next.js, Astro, Hugo, a Django app, or plain HTML, the spec stays the same and implementation hints follow it, not the other way round.

Where to start

If you want to work through the categories systematically, the spec's own three-step flow is:

  1. Audit — run the checklist against your site, or let your agent do it. Each item is a yes/no.
  2. Learn — open any item for what it is, why it matters, and how to implement it.
  3. Improve — fix what's missing, then re-check.

The full topic list is browsable at specification.website, and the project is built in the open under an MIT licence with every page carrying an "Edit on GitHub" link.