Findings · 2026-08-26 · By VSNARY | Emmanuel Orta
Our audit labelled one page and measured another for weeks
Every scan of a specific URL actually measured the homepage. The report header showed the right path. The numbers underneath belonged to a different page.
Scanning /tree-removal/ returned 72,818 bytes, 18,856 characters of visible text, and 13,022 bytes of JSON-LD. So did scanning the homepage. So did scanning /emergency-tree-service-denver/.
Byte-identical results for three different URLs. That cannot happen unless the same page is being measured three times.
The bug
One line:
const hp = await fetch(`https://${d}/`, { ... });A trailing slash. The deep-analysis fetch was hard-coded to the domain root and ignored the scanned path entirely. Payload size, visible text, JSON-LD, document structure, content entities and the language-model read all came from /, no matter which URL you asked for.
The report header displayed the path you requested. It was correct. The numbers below it were not.
Why it survived
Because everything was self-consistent. The header said /tree-removal/. The path field in the record said /tree-removal/. Nothing errored, nothing was null, no exception fired. A report that labels itself correctly looks verified.
We only caught it by comparing two URLs' numbers against each other rather than checking that one report looked right. Identical byte counts for different pages is a fact that cannot be explained away.
What it looked like fixed
| Page | Before | After |
|---|---|---|
| Homepage | 72,818 B · 13,022 B JSON-LD | 72,818 B · 13,022 B JSON-LD |
| /tree-removal/ | 72,818 B · 13,022 B JSON-LD | 61,461 B · 5,171 B JSON-LD |
We verified the corrected figures independently by fetching both pages by hand: 73,110 and 61,627 bytes, 12,846 and 5,039 bytes of JSON-LD. The small deltas are compression and dynamic content. The point is that the two pages are genuinely different by about 11 KB, and the scanner had been reporting them as identical.
Grades diverged too — A/94 for the homepage, A/91 for the service page, where both had previously returned 94. And the service page surfaced entities the homepage never had.
The part worth taking away
This defect also explains an anomaly we had already published and withdrawn. We had reported that a page's highest-salience entity was a city rather than the business, and flagged it as untrustworthy because the same numbers appeared for three different URLs. We assumed a caching problem. It was this instead: one page measured three times.
We wrote an invariant into our build audit so it cannot return. Two of them, in fact: one asserting the fetch uses the scanned path, one asserting the old root-fetch line is absent. Both run on every build.
If you use any page-level audit tool, there is a cheap test: scan two genuinely different pages on the same site and compare the raw numbers, not the verdicts. If the byte counts match, the tool is not reading what it says it is reading.
Every figure above came out of this scanner.
Point it at your own domain and see the same measurements, free.