How to test
Most of what you will believe about your own site is unverified.
Everything else on this site is one site's findings, and the honest position is that they may not transfer. This page is the part that does. The loop is simple — ask, capture, change one thing, ask again — and running it against your own site produces your own findings, which are worth more to you than anyone else's.
What makes it work is the discipline around it: knowing which question you asked, which version was live, and whether the thing you changed is the thing that moved. Each of those has a way of going wrong quietly.
Ask for a verdict, not a description
The same model, the same page, the same day will tell you different things depending on the shape of the question.
[measured]
"Describe this site" produced an accurate, fluent summary and zero corrections. "Grade this site" found a real factual error. A verdict requires checking; a description does not.
Run both. The description tells you what your page communicates. The verdict tells you what it gets wrong. And run the adversarial version — find a claim here that does not hold up — because that is the only prompt with a right answer you can check.
Test the surface people actually use
[measured]
Same prompt, same day. The developer API found the site and described it correctly. The consumer chat product cited fifteen sources, none of them the site, and returned a cautious non-answer. The two are different systems. Automating against the API and concluding you are fine is a common and expensive mistake.
Use a fresh or incognito session. An account with history on your project is not a cold reader, and the whole value of the exercise is that it is cold.
Date what the model actually read
The hardest problem in this loop: models routinely answer from a cached copy of a page that no longer exists, and nothing in their answer says so.
[measured]
A model delivered a confident, current-tense assessment of a site and reported having verified two specific claims. One of those claims had been deleted from the page three hours earlier. Nothing in its language signalled staleness.
The technique that resolves this is cheap: keep dated snapshots of every version of your copy, then bracket the read using two phrases — one you recently added and one you recently removed. A read that contains the removed phrase predates the removal. That is a hard bound, and the presence of deleted content is far stronger evidence than the absence of new content.
[reasoned]
Check what a reader quotes before acting on what it concludes. Feedback on a version that no longer exists is worse than no feedback, because it is actionable and wrong.
One passing fetch does not confirm a deploy
[measured]
A cache-busted request returned the new copy. The very next request returned the old one. Edge nodes do not flip together, and a single passing check can pass on a stale copy — so a stability check that runs once is a coin toss.
Require several consecutive passes on every surface, and compare the served bytes against your local file rather than grepping for a phrase, since a grep can match a fragment that survived the edit. Poll every new path explicitly: newly added files propagate later than edited ones, and a check watching only what you changed will pass while a new sibling is still 404ing.
[reasoned]
And keep the two clocks separate. Your origin serving the new file does not mean anything downstream has it. Only one of those is yours to control.
Keep a record you can be wrong in
The log is the instrument. Write down what you changed and why, including the changes you reverted — the why is what makes an old decision re-examinable rather than merely visible. State a finding only once it has appeared twice; one instance is a hypothesis and should be labelled as one.
Two habits worth stealing. Mark every claim [measured] or [reasoned] as you write it, not afterwards. And when you cannot verify something, record that you could not — "I could not verify this" and "this is not verifiable" are different findings, and quietly converting the first into the second is the more damaging direction.
Next: what didn't work — the things built and then removed.