What the verifier catches

A dynamic site fails loudly. Something throws, a page 500s, an alert fires and somebody is woken up. A static site does not have that courtesy. It fails by omission, and omission has no symptom.

Here is the one that pays for the whole file. A post builds. It renders correctly. The link works, the typography is right, you read it twice and it is good. It is also absent from sitemap.xml, because of a one-character mistake in a slug three weeks ago.

Nothing anywhere will tell you. The page is perfect and nobody will ever see it.

The sitemap protocol, which is what a missing entry means you are not speaking →

The rule

Write the verifier before you write the content. Not after the first bug, and not when you get round to it. Before.

This is not a testing-discipline argument, it is an arithmetic one. Checks are cheap to write once and free to run forever, and the class of bug they catch is the class you cannot catch by reading, because reading shows you what is on the page and this is a bug about what is not.

What is checked here

Every relative link resolves to a file on disk. Every page has a canonical, and the canonical points at your domain and not at whichever domain you copied the config from. Every published post appears in both the sitemap and the feed. Every block of structured data parses. The security headers exist and have not quietly grown an unsafe-inline. No colour literal has escaped the token block. No authoring file is about to be published at your domain by accident.

About twenty-five assertions a page, so a three-post site runs around 150 of them and a fifteen-post one runs just under 400. The deploy script refuses to upload anything if a single one fails. Not a warning. A refusal.

Every check exists because something went wrong once. The list is not a specification somebody designed; it is a scar record, and that is the only kind of check list worth having.

••••••

No. 2 in How It Works, a series of 3.

NextSetting it up