Most sites decay quietly. A page ships without a meta description, an image loses its dimensions, a redesign replaces landmarks with generic containers. Nothing breaks, so nothing tells you. Two years later the site is slower, harder to find, and nobody can point at the change that did it.
What runs on every push
After each deploy, the live site is measured three times and the median run is scored against a fixed rubric covering four things: how fast it is, how visible it is to search, whether the design reads as current, and how legible the site is to the AI answer engines that increasingly sit between a question and a click.
The structural checks have no tolerance at all. A sitemap either exists or it does not, so any nonzero score there is a real regression rather than noise. Speed is judged differently, on the raw measurement rather than a derived penalty, because a score that moves a point between two identical runs should never decide whether a build ships.
Why the rubric lives somewhere else
No site contains its own scoring logic. Each one knows a URL and a token, and the scoring happens in one place.
That is deliberate. Scores have to stay comparable across every site and across time, and a dozen separate codebases cannot each keep their own idea of what good looks like without drifting apart. When the rubric improves, every site's report improves at once, and not one line of their code changes.
What it means if you own the site
The health page on your own admin shows the current result as a plain checklist: what each check is, what it does for your business, whether it passed, and what failing it would cost. No jargon, and no score you have to take on faith.
The point is not the number. The point is that the site cannot quietly get worse after handover, because the build refuses to let it.