How Docket decides what to fix first
Every audit tool hands you a list of problems. The hard part is not finding them — it is knowing which one to do on Monday morning. Docket answers that with a single number it computes for every finding, and this page is that number written out in full, because a priority you cannot audit is just an opinion with a sort order.
The formula
Each finding gets a priority score of severity weight x impact x reach, divided by effort cost. Higher goes first. Three of those four multiply the case for doing something; the fourth divides by what it costs you. That is the whole of it, and the four inputs are worth taking one at a time.
Severity — how badly it hurts
There are 5 severities that represent a problem, and their weights are not evenly spaced:
- Critical, weight 10 — reserved, in the engine's own words, for "this page or site cannot rank at all": a noindex on a page that earns money, a robots.txt that disallows everything, a server returning 5xx. Anything that merely reduces performance is High or below, deliberately, because a critical bucket that fills with noise stops meaning anything.
- High, weight 5.
- Medium, weight 2.
- Low, weight 0.7.
- Notice, weight 0.15 — including every finding where Docket is reporting its own blind spot rather than a fault in your site.
Two honest notes about those numbers. They are ratios, not measurements: nothing was timed or tested to establish that a critical is worth exactly 67 notices. They are an editorial judgement about relative harm, held steady so that two audits of the same site agree with each other. And the gap between Critical and High is the largest in the table on purpose, because the distinction it encodes — cannot rank at all, versus ranks worse than it should — is the only one that changes what you do today.
Impact — how much this particular instance matters
Severity is a property of the kind of problem. Impact is set per finding, so two findings at the same severity can rank differently. It is also the field that decides which phase of the plan a finding lands in, at a threshold of 5.
Reach — how much of the site is affected, with the volume turned down
This is the input most tools get wrong, and the way Docket handles it is the most opinionated thing on this page. Reach does not scale with the number of affected pages. It follows a square-root curve that stops growing altogether:
- 1 page — multiplier 2
- 9 pages — multiplier 4
- 25 pages — multiplier 6
- 100 pages — multiplier 11
- 144 pages — multiplier 13, and it never goes higher
- 5,000 pages — still 13
Past 144 affected pages, one more changes nothing. The reason is written into the code as a failure mode to avoid: with a raw count, one trivial nit repeated across 5,000 template-generated pages would outrank a critical noindex on your homepage. That is exactly why large-site audits from big tools are so often unusable — the top of the list is whatever the CMS happens to do everywhere. Docket caps reach so that breadth matters, but cannot win on its own.
Effort — the divisor
Effort is the only input that makes a score smaller, and the spread is wide:
- Trivial, cost 1 — one tag or one line of config, minutes.
- Small, cost 2 — a template change, under an hour.
- Medium, cost 5 — a few hours, several templates or some content.
- Large, cost 12 — a project: a migration, a rebuild, net-new content.
A Large fix is divided by 12 times as much as a Trivial one, which is a strong enough thumb on the scale to reorder the list — and it is meant to be. A fix nobody has time for is worth less than a smaller fix that ships this afternoon.
A worked example, where the milder finding wins
Two findings on the same site:
- A High on one page, impact 7, requiring a Large project. Score: 5 x 7 x 2 / 12 = 5.8.
- A Medium across 25 pages, impact 6, fixed by a Trivial edit. Score: 2 x 6 x 6 / 1 = 72.
The Medium ranks far above the High, and that is the formula working rather than failing. One is an afternoon's work that improves 25 pages; the other is a quarter's project that improves one. If you have a morning, the arithmetic agrees with what an experienced consultant would tell you.
Four phases, because a sorted list is still not a plan
The score orders findings, but the plan groups them first, so it reads as a sequence rather than a leaderboard:
- Stop the bleeding — everything Critical, regardless of effort. If a page cannot rank at all, nothing else you do to it matters.
- Quick wins — impact 5 or above, at trivial or small effort.
- Build — impact 5 or above, but real work.
- Polish — everything else worth doing.
Within each phase, items stay in priority order. The plan prints 40 items at most — a plan of two hundred things is not a plan — and every item it keeps carries the true total, so the report can say how many it is not showing. That last part exists because of a mistake described below.
Where Docket does not let the score decide
Two places, both deliberate.
The summary at the top of the report is ordered by severity, not priority. Priority is the right answer to "what should I do first", because reach genuinely should decide the work order. It is the wrong answer to "what are the five biggest problems", and a section headed that way which lists five Mediums above a High contradicts the severity label the same report prints beside each one. When two things on one page disagree, the reader cannot tell which to believe. So the summary sorts by severity band and uses priority only to order within a band.
Findings that describe Docket's own blind spots cost your score nothing. When a check cannot see enough to answer — a link graph assembled by JavaScript, an external link that could not be fetched — it says so rather than guessing, and that finding is marked as a limit of the tool. Those are excluded from the score deduction entirely, because a site Docket cannot read should not score below one it can for that reason alone.
When we got this wrong
Both of the rules above are repairs, and the repository records what prompted them.
The summary ordering was found by reading a full report for a roofing company rather than looking at its score. All five headline items were Medium, while both High findings — one of them invisible rating markup, which carries a Google manual-action risk — sat past position ten, which is further than anyone reads. Nothing was broken; priority was doing exactly what it was designed to do, in a section where that was the wrong question.
The plan cap was found on an agency report of several hundred pages whose cover promised fifty items while the plan printed 40 numbered ones, with nothing explaining the gap. A reader who counted would conclude the report withheld ten fixes it had charged for. The cap stayed — it is there for a reason — but every item now carries the total so the renderers can say what was left out.
And the tool-limit exclusion was subtler than it looks. Those findings were given an impact of zero, which everyone assumed protected the score. It did not: impact never enters the score calculation at all, which is driven by severity and reach, so a blind-spot notice deducted from a lane exactly like any other notice. The test that was supposed to guard this asserted that impact was zero — the premise, not the behaviour it was named for. The fix was two lines; the lesson was that a test should assert the thing it claims to protect.
Checking it yourself
None of this has to be taken on trust. Every finding in a Docket report carries its own severity, impact, effort and affected-page count, and the JSON export carries the computed priority alongside them, so you can recompute any score on this page from the numbers in your own report. If our arithmetic and yours disagree, one of us has a bug, and we would like to know which.
Common questions
How does Docket decide which SEO problem to fix first?
It computes a priority score for every finding: severity weight multiplied by impact and by reach, divided by the effort the fix takes. Findings are then grouped into four phases — critical problems, quick wins, longer builds, and polish — and ordered by score inside each phase.
Why does a medium-severity issue rank above a high one?
Because reach and effort are in the formula. A medium problem across dozens of pages that one template edit fixes will outrank a high-severity problem on a single page that needs a rebuild. That is intended: it matches what an experienced consultant would tell you to do with one free afternoon.
Does a problem on more pages always rank higher?
No. Reach follows a square-root curve that stops growing entirely past 144 affected pages, so breadth matters but cannot win on its own. Without that cap, one trivial issue repeated across thousands of template-generated pages would outrank a critical problem on the homepage, which is the usual reason large-site audits are unreadable.
Are Docket's severity weights based on measured ranking data?
No, and the page says so. They are an editorial judgement about relative harm, held consistent so that two audits of the same site agree. No study backs a claim that any particular issue costs a specific amount of traffic, and Docket does not make one.
What is a tool-limit finding and why does it not affect my score?
It is Docket reporting its own blind spot rather than a fault in your site — a link graph it could not read, an external link it could not fetch. Those are excluded from the score deduction, because a site Docket cannot fully read should not score lower than one it can for that reason alone.