Severity or Priority: What to Fix First After an SEO Audit
An audit ranks findings by how wrong they are. Your Monday needs them ranked by how much they move and how little they cost. Those are two different lists, and only one of them is a plan.
On This Page
The audit arrives as a document with forty-one findings, nine of them marked red. The red ones say critical. Your developer has two days this month and a release already scheduled. So which two days do you buy?
That question is not answered anywhere in the document, and that is not a defect in the document. Severity is a property of the finding: it describes how far the current state sits from correct. Priority is a property of your quarter: it describes what to do first given who is free, what is already in flight, and how much of the site each change touches. A scanner can compute the first without knowing anything about you. Only you can compute the second.
Most SEO audit prioritisation goes wrong at exactly this seam. Red gets scheduled because it is red. Grey gets ignored because it is grey. Six weeks later the site has an immaculate heading structure on pages nobody lands on, and the global navigation still sends every internal link through a redirect. The work happened. Nothing moved.
What follows is the model we use to re-sort a delivered SEO audit into an order of work: two axes, four findings run through them, and then the harder question of what a finding must contain before it can be prioritised at all.
Severity and priority are two different lists
Severity is graded against a rule. Missing canonical, duplicate title, broken internal link, image without alternative text, response time above a threshold. The rule is either satisfied or it is not, and the grade is the same on every site in the world. That consistency is the whole value of a scanner and also its whole limitation.
Priority is graded against your site. A missing canonical tag is a severe finding anywhere. On a page with no duplicates, no parameters and no traffic, it is also a perfectly reasonable thing to leave until Thursday. Nothing about the grade changed. Everything about the decision did, because a scanner grades the rule, not your business.
This is the first thing to check when an audit lands from outside: whether it was written to be actioned or written to look thorough. Our parent company has a piece on reading an audit you were sold that covers the tell-tale signs. The short version: a report with hundreds of findings and no order of work has handed you its hardest job.
The two axes that decide it
You need two numbers per finding, and you can estimate both in under a minute. Reach: how much of the site that earns something is affected. Effort: what it actually costs to change, including the parts that are not typing. Nothing else goes on the axes. Every extra score we have seen a team add turns the exercise into a spreadsheet nobody updates.
Reach is not traffic
Reach is the count of URLs a change touches, weighted by whether those URLs do anything. A finding on one template that renders eight thousand pages has enormous reach even when the finding itself is small. A finding on eight thousand individual pages that all sit behind a noindex directive has none.
Separate two kinds of reach while you are at it. Crawl reach is how much of the crawler’s attention the problem consumes. Landing reach is how many real arrivals pass through the affected pages. A parameter explosion has huge crawl reach and almost no landing reach; a broken title on the pricing page is the reverse. Both matter, and they justify completely different amounts of engineering. If you cannot yet tell which pages earn arrivals, that is a measurement problem to solve before the audit, not after it.
Effort is not hours
Effort is hours multiplied by friction. Who has to be free. How many approvals it needs. Whether it can be reverted in one command or requires a data migration. Whether the file lives in a theme a contractor owns. A one-line change in a template nobody on your team can deploy is not a one-line change, which is the whole subject of why small content edits keep becoming developer tickets.
Reversibility deserves its own mention inside the effort estimate. A change you can undo in a minute can be shipped on a hunch. A change that rewrites URLs cannot, and it should carry the ceremony of a project even when the edit itself is trivial.
Before scoring anything, collapse the findings by template. Forty-one findings usually turn out to be nine problems appearing in different places. Scoring the collapsed list is faster, and it stops a single template defect from outvoting everything else simply because it was counted eight thousand times.
Three findings that are severe and can wait
These three appear in almost every report we are handed, and they are almost always graded near the top. Run them through the axes and they fall a long way down.
Duplicate meta descriptions across an archive
The scanner is right that they are duplicated, and the fix is not one change. It is a piece of copy per page, written by a person, forever, on pages that mostly exist to route visitors deeper. Effort is high because it never ends. Reach is thin because search engines routinely rewrite descriptions to match the query anyway. Write real descriptions for the pages people actually land on, template the rest, and move on.
Core Web Vitals failing on the wrong template
A site-wide performance grade is an average over templates, and averages hide their own shape. When the failure is concentrated in a tag archive and the landing pages already pass, rebuilding the asset pipeline buys you a better number and very little else. Field data is what settles whether the problem is real, which is the argument we make at length in whether Core Web Vitals are still worth chasing.
Missing headings on URLs that are already excluded
Four hundred filtered listing views with no H1 — every one of them carrying a noindex directive and a canonical to the parent. The rule is broken. The consequence is not. There is a reasonable accessibility argument for fixing it, and that argument should be made on its own terms rather than smuggled in as a search finding, because it will be prioritised differently and usually by different people.
The minor finding that should ship today
Here is the one that gets graded low and deserves the top of the list. After a redesign, the global navigation started emitting URLs without a trailing slash, and every one of them redirects to the canonical form. The scanner grades it low, and correctly: the redirects resolve, nothing is lost, no page is missing. Severity is genuinely minor.
Priority is not. Reach is every internal link on every page, which is the widest reach a finding can have. Effort is one line in one navigation component. It compounds quietly, it makes every future crawl less efficient, and it is exactly the kind of defect that gets copied into a hundred hand-written links before anybody notices. Wide reach, trivial effort, reversible in a minute. Ship it before anything red.
The same class of finding shows up after every replatform, which is why redirect and link integrity sit near the top of our website migration checklist rather than in the tidy-up phase. Low-severity, wide-reach defects are the ones that survive a launch, because nothing about them looks broken.
The grid, and what each quadrant means
Plot every finding on reach against effort. Four quadrants, four different decisions, and only one of them is a fix.
| Reach | Effort | What it usually is | What to do with it |
|---|---|---|---|
| Wide | Low | One template, one component, one rule | Ship it this week, ahead of anything graded higher |
| Wide | High | Architecture, URL structure, a replatform | Scope it as a project with a date, not as a fix |
| Narrow | Low | A single page, a single edit | Batch it into the next scheduled content pass |
| Narrow | High | A bespoke fix on a page that earns little | Write down why you are declining it, then decline it |
The wide-and-cheap quadrant is where audits under-deliver, because those findings rarely look impressive in a report. The wide-and-expensive quadrant is where they over-promise: information architecture and topical structure belong there, and calling them fixes rather than projects is how they end up half-done. The bottom-right quadrant is the one nobody writes down, and writing it down is the point. A declined finding with a reason attached stops being raised every quarter.
What a finding must contain to be prioritised at all
Half the reason teams cannot prioritise an audit is that the findings were not written in a form that supports prioritisation. A defensible finding carries five things, and if any one is missing you are guessing.
- The claim. One sentence stating what is wrong, in language a non-specialist can repeat accurately to somebody else.
- The evidence. The affected URL set, and how it was produced. Not a screenshot of three examples. Without the set you cannot compute reach, and without reach you cannot rank the finding against anything.
- The mechanism. Why this costs something. Not "best practice", but the actual chain from the defect to the outcome. If that chain cannot be written down, the finding may be true and still not worth money.
- The change. What specifically to alter, in which file or which field, and what the correct state looks like once it is done.
- The cost. Who has to do it, roughly how long, what it might break, and whether it can be reversed. This is the field that separates a report from a plan.
That shape is worth insisting on whether findings are written by a person or assembled by a tool. Reporting software such as Prooflin works this way deliberately: findings, severities, priorities and recommendations are resolved into a report a reviewer signs off, rather than a scanner export forwarded as it came. The structural argument for it is set out in the anatomy of a finding.
The order we would ship in
Given a scored list, this is the sequence. It is not the severity order, and on most sites it is not close to it.
- Anything removing pages from the index. A stray noindex, a robots rule blocking a live directory, a canonical pointing at a staging host. Reach is irrelevant here; these are stop-the-line items and they are usually one line each.
- Wide reach, low effort. Template and component defects. This is the quadrant that pays for the audit, and it is normally exhausted inside a week.
- Anything on the pages that already earn. Fix the top of the site before the tail. A finding on a page with existing demand turns into something you can observe far sooner than the same finding on a page nobody has found yet.
- Structural and content work. Coverage gaps, thin clusters, and the question of how many pages a site needs before search takes it seriously. These are projects with owners and dates, and they belong on a content calendar that survives a busy quarter rather than on a fix list.
- Everything else, or nothing. Give the remainder a review date. Anything still unscheduled at that date gets deleted with a note, not rolled forward silently into the next quarter.
When severity should overrule the grid
The honest limit of this model: some findings are not economic decisions, and running them through a reach-and-effort grid is a category error. Personal data exposed in an indexed URL is fixed today at any cost. A missing security control on a form endpoint is fixed today. An accessibility barrier that stops somebody completing a task is a commitment question, not a traffic question. None of those care how many pages are affected.
There is a softer exception too. Some narrow, cheap fixes are worth doing purely to end an argument. If a stakeholder has raised the same red item in three consecutive meetings and it takes twenty minutes, the twenty minutes buys quiet and a cleaner report, and quiet has real value. Just be honest with yourself that you are buying quiet rather than performance.
Severity tells you the finding is real. Reach tells you whether anyone will notice it being fixed. Only the second one belongs on a roadmap.
Where we would start on Monday
Open the audit and add two columns: which template each finding lives in, and who is allowed to change that template. Then sort by those columns instead of by severity. Most lists re-order themselves in about twenty minutes, and the top of the new list is usually three or four template changes nobody had thought to group together.
Then agree the smallest possible commitment: one week of technical SEO work drawn only from the wide-and-cheap quadrant, shipped and verified before anything else is scheduled. It is the fastest way to find out whether the audit understood your site, and it costs less than the meeting about the audit did.
And the condition under which we would reverse all of this: if engineering capacity genuinely exceeds the size of the list, stop modelling and fix everything. The grid is a rationing instrument. It earns its keep only when there is less time than there are findings, which is nearly always — but not quite always. If you want a second read on a report somebody handed you, send us the findings and tell us what you have already tried.
Common questions.
What is the difference between severity and priority in an SEO audit?
Severity measures how far the current state sits from a technical rule, and it is graded the same way on every site. Priority measures what your team should do first, given how much of the site a change affects and what it costs to make. A finding can be severe and low priority, or minor and urgent. Severity is computed by a tool; priority is a judgement about your own constraints.
How do I decide which SEO audit findings to fix first?
Score each finding on two axes: reach, meaning how many pages that earn something are affected, and effort, meaning hours multiplied by approvals, ownership and reversibility. Fix anything that removes pages from the index first, then everything with wide reach and low effort. Findings with narrow reach and high effort should be declined in writing, so they stop reappearing every quarter.
Should I fix every critical finding in an audit report?
No. A critical grade means a rule is broken, not that the consequence matters on your site. Duplicate meta descriptions on an archive, missing headings on pages already excluded from indexing, and performance failures on templates nobody lands on are all genuinely broken and rarely worth scheduling first. Fix the ones with real reach, and record a reason for the ones you decline.
What makes an audit finding actionable?
An actionable finding contains five parts: the claim in one plain sentence, the full list of affected URLs and how that list was produced, the mechanism explaining why it costs something, the specific change to make, and the cost in people and time. Missing any part forces the reader to guess. The affected URL set matters most, because reach cannot be estimated without it.
Why do low-severity findings sometimes need fixing immediately?
Because severity ignores reach. A navigation component that emits URLs which all redirect is graded low, since the redirects resolve and no page is lost. It also affects every internal link on the site, wastes crawling on every visit, and gets copied into hand-written links until somebody notices. Wide reach with trivial effort beats a red grade with narrow consequences almost every time.
How long should an SEO audit backlog stay open?
Give the remainder an explicit review date, usually the end of the next quarter, and delete anything still unscheduled when that date arrives. Rolling findings forward silently creates a list nobody reads and nobody trusts. Deleting a finding with a written reason is a decision. Carrying it for two years without discussing it is the absence of one, and it makes the next audit harder to take seriously.
Facing this in your
own business?
Tell us where you’re headed — we’ll map the shortest honest route.