Machine layer
Three problems that look like one.
A growing share of the people asking about your site never visit it. They ask something else, and that thing answers on your behalf. This is a record of trying to make one site work properly under those conditions — what moved, what did not, and what turned out to be the wrong problem entirely.
It is one site, over three weeks. Everything here is either marked [measured], meaning it was observed and written down at the time, or [reasoned], meaning it follows from something measured but was not tested directly. Nothing is presented as a rule of the web. It is a method, and one worked example of running it.
Three problems, not one
Almost everything written about this treats it as a single subject. It is not, and the confusion is expensive: the fixes for each are unrelated, and work on one is invisible to the others.
reach did the system get your page at all? understanding having got it, did it parse what you meant? credence having parsed it, did it treat your claims as true?
They fail in that order, and a failure upstream makes everything downstream unmeasurable. A site that is never fetched produces the same hedging, sourceless answer as a site that is fetched and disbelieved — and you will spend weeks on the wrong one if you cannot tell them apart.
Understanding is not your problem
This is the finding that saves the most time, and it is the opposite of what almost everyone assumes.
[measured]
Every model that actually reached the page parsed it correctly. Across every trial, without exception: they catalogued the contents, separated sourced claims from computed ones, tracked which chain an item was on, and sometimes volunteered which claims they had not independently checked. Comprehension was nowhere near the failure boundary.
If a model has your page and still describes it wrongly, the likely cause is that your page does not say the thing you think it says. That is an editing problem, not a machine-readability one, and no amount of structured data fixes it.
Which leaves two problems worth your time. Reach is mostly infrastructure and mostly not yours. Credence is almost entirely writing, and it is where the returns are.
What is actually proven here
The honest accounting, because a playbook that overstates its evidence fails its own credence chapter on the first page.
[reasoned]
Improvement is not attribution. If you iterate hard on one thing and the outcome improves, you will credit the thing you iterated on. On this site the flagging problem cleared completely — and the copy cannot have caused it, because the failing system had never fetched the page. Two candidate causes, acting on different axes, and only one targeted test separates them.
So: the credence findings are supported, because they were tested by changing copy and watching what models said afterwards. The reach findings are mostly observations about how systems behaved, not proof that anything you do will change them.
How to read this
Every page stands on its own and every section has its own address, so a single idea can be linked without the rest. There is no required order, but if you want one:
reach start here — most failures happen before your page loads credence the part that is actually writing what to build the specific files, tags and code how to test how to run this on a site that is not this one what didn't work built, then removed — the shortest chapter to act on the evidence the subject, dated, including the reverted changes
Next: reach — why a cautious answer about your site usually means nobody read it.