How to Use The Website Specification to Audit and Improve Your Website

The Website Specification (specification.website) is a platform-agnostic checklist of 173 technical topics a good website should cover, organised into ten categories and each linked back to an underlying standard (WHATWG, W3C, IETF RFCs, WCAG, MDN). You use it in three steps: audit your site against the checklist, read the page for any item you fail to learn what it is and how to implement it, then fix and re-check. It works whether you run WordPress, Drupal, TYPO3, Next.js, Astro, Hugo, Django, or plain HTML — the spec stays the same, and implementation hints follow it rather than the other way round.

Step 1: Audit

Run the checklist against your site. Every item is a yes/no question, so the output is a pass/fail list rather than a score.

You can do this two ways:

• Manually — browse the topics and check each one against your site.
• With an agent — the spec is exposed as a read-only, no-auth MCP server, so a compatible agent can query it and run the audit for you.

To connect an agent over MCP, use this configuration:

{
  "mcpServers": {
    "specification-website": {
      "transport": "http",
      "url": "https://mcp.specification.website/mcp"
    }
  }
}

There is also a published Agent Skill that teaches a compatible agent when and how to use the spec. If you prefer to pull content directly, per-page Markdown is available via /llms.txt and by sending Accept: text/markdown on any spec URL.

What to expect: a list of items your site passes and fails. Because each item is binary, you can hand the failures straight to whoever implements the fix without interpreting a score.

Step 2: Learn

Open any item you failed. Each page tells you three things: what the item is, why it matters, and how to implement it. Every topic links back to its source standard, so you can go deeper than the spec itself when you need to.

The ten categories, with topic counts, are:

If you are new to the spec, start with the categories where a failure has the widest blast radius — Security and Accessibility — then work outward. The spec is also actively maintained: recent additions include auth.md agent registration guidance, a page on status messages, and a page on /.well-known/gpc.json, so it is worth re-checking the changelog before a fresh audit.

Step 3: Improve and re-check

Fix what is missing, then run the checklist again. Re-auditing after changes is what turns the spec from a reading exercise into a working process — the same yes/no items give you a clean before-and-after.

Two things make this easier:

• Every page has an "Edit on GitHub" link. If a topic is unclear or you spot a gap, you can contribute a fix directly. The spec is built in the open under an MIT licence, and sources are credited on every page.
• The spec is platform-agnostic by design. Implementation hints follow the standard, not a particular CMS or framework, so a fix you make in Next.js and a fix you make in Drupal are both judged against the same item.

Choosing how to run it

Either way, the loop is the same: audit, learn, improve, re-check.