What principles is The Website Specification built on?

The Website Specification (specification.website) is built on three stated principles: it follows standards rather than opinions, it is platform-agnostic, and it is built in the open. Together these principles explain why the spec is structured as a set of yes/no checklist items that link back to authoritative sources, and why it applies the same way whether you ship WordPress, Drupal, TYPO3, Next.js, Astro, Hugo, a Django app, or plain HTML.

Principle 1: Standards, not opinions

Every topic in the spec links back to the source standard that defines it. The site names WHATWG, W3C, IETF RFCs, WCAG, MDN, and "the organisations defining the modern web" as the references behind its pages.

What this means in practice:

• Each item is framed as a yes/no check, so you can audit against it rather than debate it.
• The justification for an item comes from an external standard, not from the site's own preference.
• Sources are credited on every page.

For example, an accessibility item about contrast traces back to WCAG rather than to a design opinion, and a security header item traces back to the relevant IETF RFC or W3C document.

Principle 2: Platform agnostic

The spec describes technical features a website should have, independent of the tool used to build it. The site explicitly lists WordPress, Drupal, TYPO3, Next.js, Astro, Hugo, a Django app, and plain HTML as equally valid implementations.

The stated relationship between spec and implementation is one-directional: "Implementation hints follow it, not the other way round." In other words, the spec is not derived from what any particular CMS or framework happens to do by default — implementation guidance is written to serve the spec, not to describe one platform's behaviour.

This is what makes the checklist reusable across a portfolio of sites built on different stacks: the same yes/no items apply, and only the "how to implement" step changes.

Principle 3: Built in the open

The spec is published under an MIT licence and developed publicly. Two concrete signals support this:

• Every page has an "Edit on GitHub" link, and pull requests are welcome.
• Sources are credited on every page.

The site also reports a public change history, with a full changelog and dated additions — for example, additions on 30 September 2026 (auth.md agent registration guidance), 25 September 2026 (a page on status messages), and 24 September 2026 (a page on /.well-known/gpc.json). A visible changelog is consistent with the open-development principle: you can see what changed and when.

How the principles shape the spec's scope

The spec organises its 173 topics into ten categories, described as "mapped to widely-accepted standards":

The range — from /.well-known/security.txt to WCAG contrast — illustrates the standards-first approach: each category maps onto an existing body of standards (WHATWG/W3C for foundations, WCAG for accessibility, IETF RFCs for well-known URIs and security, Core Web Vitals for performance) rather than onto a vendor's feature set.

What the principles imply for you

• If you want a checklist you can defend to a client or reviewer, the standards-first principle means each item has an external citation you can follow.
• If you run multiple sites on different platforms, the platform-agnostic principle means one checklist covers all of them; only the fix differs.
• If you need to verify or challenge an item, the open-build principle gives you the page's edit link and credited sources.

The spec is also designed to be consumed by agents, not only humans: the whole spec is available as an open, read-only MCP server with no authentication, plus a published Agent Skill, per-page Markdown via /llms.txt, and Accept: text/markdown on any spec URL. That agent-readiness is itself an application of the same principles — a standard interface, no platform lock-in, and openly documented access.