Guides
How to Prioritise SEO Fixes After an Audit
An audit produces findings. A plan produces changes. The difference is an ordering that accounts for what blocks what, and the honesty to leave things undone.
Run a fresh DomainLens audit and use the report as your priority list.
Dependency first, impact second
Some findings block others. A page that is noindexed cannot benefit from better content, so content work on it is wasted until the directive is removed. Order by dependency before you consider impact at all.
Once nothing is blocking, switch to expected impact divided by effort. That ratio, not severity, is what should drive the sequence.
| Tier | Contains | Why it is here |
|---|---|---|
| 0 — Blocking | noindex, robots block, 5xx, soft 404 | Nothing downstream works until fixed |
| 1 — Structural | Canonical conflicts, redirect chains, duplicates | One fix affects many pages |
| 2 — High-value content | Pages at position 8–15, weak intent match | Fastest measurable movement |
| 3 — Broad content | Thin pages, missing depth | Slow, but sets the ceiling |
| 4 — Polish | Alt text, minor metadata, cosmetic markup | Real, never the constraint |
Estimating impact without pretending
Precise traffic forecasts from an audit finding are fiction. What you can do honestly is rank findings relative to each other using things you actually know: how many pages are affected, how much traffic those pages already get, and how close they are to a threshold that matters.
A canonical bug on a template covering 400 pages that receive 60% of your traffic outranks a missing H1 on a page with twelve visits, and you did not need a model to say so.
- How many URLs share this cause? Template-level beats page-level almost always.
- What traffic do the affected pages already have, or plausibly could?
- Is the page near a threshold — position 11, or just failing a Core Web Vital?
- Does fixing it unblock anything else on the list?
- How confident are you that this is actually the cause?
Effort is a real input, not an excuse
A finding requiring a platform migration and a finding requiring a config change are not comparable even at equal impact. Group by who does the work and how long it takes, because a plan that ignores capacity is a wish list.
The useful move is separating quick wins from projects explicitly. A dozen config-level fixes shipped this week beats one architectural change that starts next quarter, even when the architectural change is more important — because the first delivers and the second may not survive planning.
What to deliberately not do
Writing down what you are not doing, and why, is what stops the same findings reappearing in every audit as permanent open items.
- Findings on pages with no traffic and no prospect of any.
- Chasing a perfect Lighthouse score once field metrics pass.
- Fixing every instance of a cosmetic issue across a large site.
- Anything whose only justification is a tool marking it red.
- Re-auditing before the previous fixes have had time to show.
Sequencing the work
The waiting step is the one teams skip and the one that makes the difference between knowing what worked and guessing. See the SEO audit report example for presenting the plan and the prioritisation template for the scoring sheet.
- 1Fix everything in tier 0 immediately, regardless of effort.
- 2Ship tier 1 structural fixes as a batch, since they usually touch the same templates.
- 3Wait four to eight weeks and measure before starting tier 2 — otherwise you cannot attribute anything.
- 4Work tier 2 continuously, prioritising pages already close to visibility.
- 5Revisit the list rather than the report; findings age and some resolve themselves.
How DomainLens contributes
DomainLens groups its findings by severity and reports which are blocking, which is the tier-0 list you need before anything else. The relative-impact judgement — which of your pages matter commercially — is the part a tool cannot make. See what an SEO audit is .
- What should I fix first after an audit?
- Anything preventing indexation — noindex directives, robots blocks, server errors, soft 404s. Nothing else works until those do.
- How do I estimate the impact of a fix?
- Relatively, not absolutely. Count affected pages, look at their existing traffic, and check whether they sit near a threshold. Precise forecasts are guesses.
- How long before I can measure a fix?
- Four to eight weeks for indexed pages. Core Web Vitals field data needs the full 28-day window before it fully reflects a change.
- Should I fix every finding?
- No. Findings on pages with no traffic prospect are noise. Deciding not to fix something, and recording why, is part of the plan.