When two findings count the same pages twice

By Matt Kerr·Published 18 September 2026

A report lists two findings with the same title, the same fix and different numbers. You add them up and the total is larger than the number of pages crawled. At that point the useful question is not which number is right — it is what the tool split, and why.

The same job, reported twice

On a shoe retailer's crawl of about thirty pages, the report carried two entries with the same check identifier and the same remedy, their titles differing only in a count of pages with incomplete product markup. Most of the pages appeared under both. Add the two and you have more pages in trouble than the crawl contained.

The cause was the grouping key. Findings were keyed on the type and the list of missing fields, so one type split into as many findings as it had field combinations — and a common commerce platform reliably produces two, because the main product block is missing one property and the recommendation carousel is missing another.

The repair was one finding per type, with the combinations moved into the detail where they inform without splitting the count. Two reasons, and the second is the better one:

• Completing the markup is one job in one template. The reader is not going to do it twice.
• The platform's own testing tool reports one verdict per type, so one finding per type is also the shape of the thing being checked against.

A number a reader can immediately disprove costs more than the finding is worth. The underlying problem was real; the sentence carrying it was not believable, and an unbelievable sentence takes the believable ones down with it.

The explanation that was written from a guess

The same check answers a question readers ask constantly: why are there more markup blocks than pages? The count is executed against your markup and is right. The explanation beside it used to be a single sentence asserted for every site — that a listing or variant picker repeats the type, so each copy is read separately.

On one site there were twice as many organisation blocks as pages and not one of them was a listing. They were references pointing at a definition the page never provided. A reader sent looking for a variant picker would have searched their templates for something that was not there — and the actual repair is the opposite shape: define the node once rather than de-duplicate copies.

The tool could tell the two apart from the data it already had. It simply was not looking. ⇒ A count can be computed while the sentence explaining it is assumed, and the assumed half is the one nobody tests.

The explanation gated on the wrong condition

Sharper still, and the reason this is worth a page rather than a changelog line.

The sentence explaining that blocks were references was attached to the "more blocks than pages" branch. So a site with exactly one reference per page — the ordinary shape, and by far the commonest — was told only that a property was missing, and never that its blocks were pointers at all.

A hotel group had three pages, three blocks, every one a reference to a definition that did not exist on the page. The explanation was withheld because three is not more than three. The other site received it only because it happened to carry two stubs per page. The underlying data was computed identically in both cases; only the printing differed.

That is a class of bug worth recognising in any report you read: an explanation attached to the wrong condition is invisible, because the people who most need it are exactly the ones who never see it.

Reading a report whose numbers do not add up

• Add the counts. If the total exceeds the pages crawled, findings are overlapping and at least one grouping is wrong.
• Compare the URL lists. Two findings naming the same pages are one finding with a split key, not two problems.
• Check whether the fixes are identical. Same remedy, same check, different number is the signature.
• Treat the explanation and the count differently. The count was probably measured. The sentence saying why may have been written once, for a different kind of site, and never revisited.

When the split is legitimate

Not every division is a defect, and two are worth keeping:

• Different types. Incomplete product markup and incomplete organisation markup are genuinely different jobs in different templates.
• Different severities. A missing required property and a missing recommended one deserve separate treatment even on one type, because only one of them costs you eligibility for anything.

What is not legitimate is splitting by the combination of things missing, because that is a property of the data rather than of the work.

The fixes that make it worse

• Working both findings as separate tickets. The second is the first, and you will "fix" a template that was already corrected.
• Adding the missing property to the reference blocks. See an @id is a pointer, not a definition → — that duplicates a definition rather than completing one.
• Hunting for a listing because the report mentioned one. If your blocks are references, there is no listing to find.

How the count gets smaller without anything improving

Crawl fewer pages. Every page-count finding shrinks, the report reads better, and the templates are unchanged — which is the standing hazard of any measure expressed as a number of pages rather than a number of templates. For the general version of that, see when a finding blames the whole site →.

Where this sits in an audit

The registered check is schema.incomplete, which covers incomplete structured data. For what an @id reference actually is, and when one is a genuine defect rather than a misread, see an @id is a pointer, not a definition →. For the number attached to any finding and what it feeds, see a finding's count is not decoration →.

Common questions

My audit lists two findings with the same title and different numbers. Why?

Almost always a grouping key that includes something other than the job. If the fixes are identical and the URL lists overlap, it is one finding split in two.

The page counts add up to more than my site has. Which is right?

Neither, on its own. Overlapping findings double-count the pages they share, so compare the URL lists rather than trusting either total.

Should incomplete markup be one finding per type or per missing field?

Per type. Completing the markup is one job in one template, and the validator you will check against reports one verdict per type.

Why does my report say a listing repeats my markup when I have no listing?

Because the explanation may be asserted rather than measured. A count is usually computed from your markup; the sentence explaining it can be a guess written for a different kind of site.

Can I trust a finding whose explanation is wrong?

Treat the two separately. The measured part is often right and the narrative around it weaker — but an explanation you can disprove will cost the finding its credibility whether or not it deserves that.