A finding's count is not decoration
Every finding in an audit report carries a small number beside it — a badge, a tag, a "…and more" under a shortened list of URLs. It looks like a detail. It is not: that number is usually what decides how far up your plan the finding sits, so a count of the wrong thing quietly moves work you do not need to do above work you do.
The badge that argued with its own headline
On a hospital's report, a finding's badge read sixteen profiles directly above the headline Only two recognised profiles in sameAs. Two quantities, one finding, and no reader can reconcile them.
The headline counted the profiles the site had. The badge counted the ones it did not — the remainder of the tool's own list of recognised profile types. A complement, presented in the place a reader expects a total.
That is bad writing, and it is also a bad instruction. A complement implies a target: it says the hospital should hold every profile type on the list. Nobody needs a Better Business Bureau listing, a developer-platform organisation and an app-store page, and a finding that implies otherwise is asking for work that would not help anyone.
Why a wrong count is not cosmetic
The number feeds the score. Docket's deduction grows with the logarithm of a finding's count, so a finding that claims to affect many things takes a larger bite out of your score than the same finding claiming to affect one.
On that report the effect ran backwards. The inflated count sat on a low
severity finding — you have some profiles, here are more you could add — and pushed its
deduction above the untouched deduction of the medium finding for having no
sameAs at all. The smaller problem outweighed the bigger one, and nothing in the
report said why.
It also broke a quieter thing. When a plan item names a section of your site, the tool decides whether that item covers the section completely by comparing the count against the list of URLs it is showing you. A count of sixteen against a single URL can never come out complete, so the item could never be described accurately however true it was.
The default that causes it
Here is the mechanism, because it tells you what to look for in any tool. A finding's count carries a unit, and in Docket that unit defaults to pages. Every surface that renders a count — the badge, the summary line, the "…and N more" under a truncated URL list — reads that unit. So a check that counts anything other than pages and forgets to say so does not produce a vague number. It produces a confident, specific, wrong sentence about your pages.
The same bug wearing different clothes
The phone check had it too, and its version is the clearer one to picture. A phone number lives in a template. Write it wrongly and you have written it wrongly everywhere, so a site with one bad number can have that number linked in a header, a footer and a contact block on every page.
Counting the links, the finding said several numbers were affected and offered "for example" before one of them — promising a set the reader did not have. And because the count was occurrences rather than pages, a single page carrying the number in its header and again in its footer produced a finding tagged two pages, with "…and one more" printed underneath a list containing the only page there was.
Four links to one number is one number. The repair is one edit to one template, and every part of the report said otherwise.
What to check on your own report
- Read the badge against the headline. If they disagree, the headline is usually the honest one — it was written by a person. The badge came from a variable.
- Compare the count to the list of URLs. A count larger than the list is either a genuine truncation or a unit error, and the "…and N more" line tells you which: if the list is already showing everything, there is no more.
- Ask what one fix would cover. If the answer is "all of them, in one edit", the count is measuring your evidence rather than your work.
- Distrust a count that implies a completion target — anything phrased as what you are missing out of a list the tool is holding.
When this does not matter
Keep the severity in view. A miscounted low-severity finding at the bottom of a plan costs you nothing, because you were not going to reach it this quarter and the ordering among items you will not do is not worth auditing.
It matters when a count moves something across a boundary — above an item you would otherwise have done first, or into an earlier phase of a plan. That is the case worth the minute it takes to check, and it is almost always a finding whose count is much larger than the number of URLs listed beneath it.
The fixes that make it worse
- Working the list top to bottom without reading it. An ordered plan is a recommendation, and the ordering is the part most likely to be wrong.
- Fixing every instance the count implies. On a template-set value there is one instance. Opening thirty pages to change a number that lives in one file is the wasted afternoon this defect causes.
- Chasing a completion target you were never set. A count of what you lack, out of a list somebody else wrote, is not a goal.
How to move a finding up the plan without fixing anything
Worth knowing, because it tells you how much weight the ordering can bear. Split one problem into more instances — the same bad value in more places, the same broken link on more pages — and its count rises, its deduction grows, and it climbs. Nothing about the underlying fault changed, and the fix is still one edit.
Which means an ordering built on counts rewards fragmentation. Any tool that sorts by volume has this property, including this one. The defence is the question above: what would one fix cover?
Where this sits in an audit
The two registered checks behind the cases here are ai.entity, which covers
entity definition and sameAs, and cvr.unusable_phone, which reads the
href of every phone link. Both now count what their headlines count, and the phone
one names its unit explicitly rather than taking the default.
For how the ordering is actually computed — severity, effort and reach, and where the score is deliberately not allowed to decide — see how findings are prioritised →. For the related case where a count is right but its unit should have been templates rather than pages, see when a finding blames the whole site →.
Common questions
What does the number next to an audit finding mean?
Usually how many pages it affects — that is the default unit in Docket and in most tools. It also feeds the score and the ordering of your plan, so it is not only a label.
The count and the headline of a finding disagree. Which is right?
Usually the headline, because a person wrote it and the badge came from a variable. Compare the count against the list of URLs under the finding before acting on it.
Why would a count be larger than the number of pages listed?
Either the list was truncated, which the report should say, or the count is measuring something other than pages — link occurrences, or items missing from a list the tool holds.
Does a wrong count change my score?
Yes. The deduction grows with the count, so an inflated count takes a bigger bite and can lift a low-severity finding above a more serious one.
How do I tell whether a count is measuring my work?
Ask what a single fix would cover. If one edit to one template resolves every instance, the count is measuring evidence rather than work.