Severity Is Not Priority: What to Fix First After an SEO Audit

A remediation list usually arrives pre-sorted. Critical at the top, then high, then medium, then low, and an implicit instruction to work downwards. Two weeks later the list has barely moved. The two items at the top turned out to need a platform change nobody has scheduled, a third is owned by a vendor who has not replied, and the change that would actually have altered something is sitting three screens further down under a medium label. The sort was not wrong. It was answering a different question from the one you are trying to answer.

Severity answers how far the observed state sits from a stated criterion. Priority answers what you should do next. Those are separable questions, and the first cannot produce the second on its own, because most of the information priority needs was not available at the moment the severity label was assigned.

A severity label is a comparison compressed into a single word. It encodes four things and no more: which criterion is being applied, what the observed state is, how far apart those two are, and how confident the assessor is that the gap is real. That is a genuinely useful compression. It lets a reader scan a long document and find the places where the distance is largest. It also lets a second reader disagree, because a label that names its criterion can be argued with.

The compression is lossy in one particular direction. Everything that determines what you should do next is a property of your organisation rather than a property of the gap, and none of it is visible from where the label was assigned.

• How much of the site the condition touches, and whether those parts of the site carry anything a visitor or a crawler would care about.
• What the change will cost in hours, in review, in coordination, and in release windows you do not control.
• Who owns the code, the template, the DNS record or the third-party script in question, and whether that person has capacity this quarter.
• Whether some other change has to land first for this one to be worth making, or worth measuring.
• Whether the fix can be undone in an afternoon if it turns out to be the wrong call.
• What happens if the condition is simply left in place for another year.

Severity is a measurement. Priority is a decision. Only one of them can be made without knowing your business.

This is a claim about labels, not about assessors and not about any particular piece of software. A perfectly calibrated severity judgement, made by the most careful reviewer you could hire, is still silent on cost, because cost is not a property of the deviation. It is a property of the codebase, the release process and the calendar. No amount of rigour at the point of assessment recovers information that was never in the room.

The standard response to a long list is an impact versus effort matrix. Plot everything on two axes, do the top-left quadrant first, defer the rest. It is a reasonable instinct and it is better than working alphabetically. The problem is that impact is doing an enormous amount of quiet work. It bundles together how far the condition sits from the criterion, how much of the site it touches, and what the consequence would be if nothing changed. Those three move independently. A condition can be a large deviation on one page with a tolerable consequence, or a small deviation across every page with a consequence that compounds.

Effort is bundled in the same way. It contains the technical difficulty of the change and the organisational friction of getting it shipped, and those two also move independently. A one-line change that requires a security review and a vendor ticket is not a low-effort item, whatever the diff looks like.

Four variables genuinely matter and they deserve to be separated before anything is plotted: severity, scope, effort and reversibility. Dependency is a fifth consideration, but it is a constraint on ordering rather than a score, which is why it belongs in its own section rather than on an axis. This is not an argument against the impact versus effort matrix. It is an argument about when to draw it. Separate the variables first, then plot. If you plot first, every disagreement in the room becomes an argument about where a dot belongs, and nobody can say which variable they are actually disagreeing about.

Severity is measured against a criterion, not against your business

A finding is only defensible when it names the rule it is being measured against, which is the subject of a longer argument in the piece on what makes an audit finding defensible. Take the definition from there and use it here: the criterion is the thing being deviated from, and where it comes from determines how much weight its severity label deserves.

Some criteria are published standards with defined pass conditions. The WCAG 2.2 success criteria are written so that a given state either satisfies a criterion or does not, and the criterion text says which; there is no interpretation budget to spend. Some criteria are documented product behaviours. The indexing and canonicalisation directives described in Google Search Central documentation define what a crawler is being told to do, so a page carrying a canonical that points somewhere the site does not intend is a genuine deviation from documented behaviour rather than a matter of taste. And some criteria are internal conventions the assessor brought with them, which are perfectly legitimate provided they are declared as conventions rather than dressed up as rules.

None of those criteria were written about your business. A conflicting canonical is exactly as much of a deviation on a page that receives nothing as on a page that receives everything. The severity is identical in both cases, and it should be, because severity measures distance. What differs is the consequence, and consequence is the thing only you can supply. This is the precise point at which a severity-sorted list stops being useful and a prioritised list has to begin.

None of this is licence to dismiss anything inconvenient as low priority. Where a criterion carries an external obligation, the consequence has already been decided for you, and severity sits very close to priority as a result. Accessibility criteria are the clearest case: the obligation attaches to the state of the interface, not to whether the affected page is commercially interesting, and a person who cannot operate a control is not made whole by an argument about traffic volumes. Treat obligation-backed findings as a separate class and stop discounting them by scope, because the discount you are applying is a discount on somebody else's ability to use the thing you built.

Effort is a variable no severity label can contain

The same finding, expressed in the same words, can be twenty minutes of work or a quarter of somebody's roadmap. A missing element in a page head is a template edit on a site with one template, and a per-page migration on a site where fifty pages were hand-built by different people over six years. The label cannot tell those two situations apart, because both sites present exactly the same observed state. Nothing about the deviation carries information about the shape of the codebase underneath it.

It helps to break effort into its components, because the one everybody estimates is usually the smallest.

• The change itself, which is the part people picture when they hear the word effort.
• Review: who reads the diff, and whether that person exists and has time this month.
• The deploy path, including release cadence, freeze windows, and whether anything else has to ship alongside it.
• Coordination, meaning the cost of every person outside the team who has to agree, including vendors and platform owners who have their own queues.
• Verification, meaning the work of establishing afterwards that the condition is actually gone rather than merely edited.

Effort estimates should come from whoever will do the work. An estimate produced by the person who wrote the finding is a guess about somebody else's codebase, and it is systematically optimistic, because the estimator can see the change itself and none of the other four components. A finding with no named owner therefore has no effort estimate at all. Record it as unknown rather than as small. Unknown effort attached to high severity is a prompt to go and find out, which is a task in its own right and should be scheduled as one rather than left to resolve itself in a meeting.

Scope is how much of the site the condition touches, and it is tempting to treat it as a third dimension on the chart. It behaves better as a multiplier. A medium-severity condition living in a template applied to every page multiplies into something that reasonably outranks a high-severity condition on a single page, and the arithmetic is intuitive enough that most people perform it without being asked to.

The multiplication only holds over parts of the site that matter. A condition affecting thousands of pages nobody enters through, that carry no links anybody follows, and that exist only because a filter combination generated them, is smaller than the page count suggests. The count flatters it, and a large number in a report is persuasive in a way that has nothing to do with whether the number is meaningful. The honest version of the multiplier is not pages affected but consequential pages affected, and working out which pages are consequential is the part of prioritisation that cannot be delegated to anybody outside the organisation, because it depends on what the business is actually trying to do.

Scope also cuts the other way on effort, and this is where it earns its place in the model rather than merely complicating it. A condition that lives in a shared template has enormous scope and very small per-unit effort, because a single edit resolves every instance of it. A condition of identical severity spread across the same number of independently authored pages has the same scope and enormous effort. Two items that sit on top of each other on an impact versus effort chart turn out, on inspection, to be a first-week item and a second-quarter item. Separating the variables is what makes that visible; plotting them first is what hides it.

Two findings can share a severity, a scope and a consequence, and still belong in different quarters, because only one of them lives in a template.

Reversibility is how easily you can put things back, and it sits on a short scale. At one end are changes trivially undone: a title, a description, an attribute, a heading. In the middle are changes reversible in technique but not in effect, such as a redirect that other people have already linked to, or a URL that has been shared into places you cannot edit. At the far end are changes that cannot meaningfully be undone at all: deleted content with no copy anywhere else, a restructured URL scheme whose old paths were never recorded, pages removed from a site that was the only place they existed.

This variable deserves its own axis because quick-win selection is done on effort alone. Somebody scans for the cheapest items and starts there, which is sensible right up to the moment it selects a change that is cheap to make and impossible to unmake. Bulk operations are the usual culprits, and the reason is structural rather than careless: the property that makes a bulk operation cheap is exactly the property that makes it dangerous, namely one action applied everywhere with no per-item judgement in between.

So the rule is not that irreversible work goes first. It is that irreversible work faces a higher bar before it is done at all. A named approver rather than a general nod in a meeting. A written statement of how it would be reversed, produced before the change rather than after, because the act of writing the reversal is what reveals whether reversal is actually possible. A verification step scheduled rather than assumed. And, where the change is large, a window that somebody is watching, rather than a Friday evening deployment discovered on Monday.

That rule has a real cost and it should be stated plainly rather than glossed. It slows down a category of work everybody enjoys, because bulk cleanups feel productive and gating them feels bureaucratic. It also produces a queue in which an expensive but entirely safe change ships before a cheap and permanent one, which looks inefficient on any measure of throughput. Accept the inefficiency. The asymmetry justifies it: the downside of over-reviewing a reversible change is a few wasted hours, and the downside of under-reviewing an irreversible one is a state you cannot return from, discovered at a moment you did not choose.

What would make this wrong is the case where the irreversible change is also the urgent one, and every week of delay carries its own permanent cost. That case genuinely exists. It is rarer than the people who invoke it believe, and the correct response is to argue it explicitly, in writing, with the person who will own the outcome, rather than to let urgency quietly suspend the rule and then discover afterwards that nobody had agreed to suspend it.

Ranking produces a list. Sequencing produces an order. They are not the same output, and dependency is the reason. Some items cannot usefully be done before others, regardless of how they score on any of the four variables, and a ranked list that ignores this will send somebody to do work that is thrown away a fortnight later when the item it depended on finally lands.

• Technical dependency: templates have to be consolidated before it is worth correcting the same condition on every page that inherits from them.
• Evidential dependency: measurement has to be in place before the change is made, or nobody can say afterwards whether it helped, and a fixable question becomes a permanent argument.
• Structural dependency: information architecture settles before internal linking is reworked, because links drawn against a structure that is about to move are effort spent twice.
• Organisational dependency: a legal review, a contract renewal or a platform migration already on the calendar, where doing the work now means doing it again in six months.

Dependency is the axis nobody sequences on because it is invisible on a chart. Two dots at identical coordinates can occupy completely different positions in a dependency graph, and a scatter plot has no way to draw the arrow between them. The remedy is unglamorous: before the list is agreed, walk it once and ask of each item whether anything else has to land first. Most items have no predecessor and the pass is quick. The few that do have one tend to reorder the top of the queue, which is precisely where reordering is worth the most.

When a dependency cannot be resolved on any reasonable timescale, split the item rather than parking it whole. There is nearly always a component that is independent of the blocked predecessor, and shipping that component keeps the item alive in people's minds and in the record. An item parked whole tends to become an item quietly abandoned, and a list that accumulates a stratum of permanently blocked entries trains everybody who reads it to stop reading past the first screen.

Every substantial audit surfaces conditions the recipient cannot fix. A platform that does not expose the part of the document the change requires. A third-party script whose behaviour is set by the vendor. A hosting arrangement, a shared codebase owned by another business unit, a template locked by a licence. These findings are real and their severity is real. The mistake is not in reporting them. It is in what happens to them next.

The common error is quiet reclassification. The item cannot be fixed, so somebody moves it down to low, and the record now understates a condition that has not changed in any respect. Severity describes the deviation. Control describes who is able to act. Conflating the two corrupts the record, and the corruption is durable, because in a year nobody will remember that the low label was a scheduling compromise rather than a judgement about the deviation. The next person to read the document will take it at face value, which is what documents are for.

The honest treatment keeps the severity intact and changes the disposition instead. Name the party who can actually act, whether that is a vendor, a platform team or a parent organisation. State the specific ask in a sentence somebody could paste into an email without rewriting it. State the fallback if the ask is refused, including the uncomfortable version where the fallback is to accept the condition permanently or to change the platform. Then give it a decision date. A dated item with a named owner outside the organisation is a live item. An undated one is a permanent decoration, and permanent decorations are how remediation lists stop being read.

Some findings are never going to be actioned, and pretending otherwise is the most common form of dishonesty in remediation tracking. A list that only ever grows is a list nobody trusts, because every reader can see that a good portion of it is fiction and has no way to tell which portion. The remedy is a disposition of accepted, recorded properly, which is a resolution rather than an evasion.

Recorded properly means four things: the reason, the person who accepted it, the date it was accepted, and the date it will be looked at again. All four are load-bearing. The reason is what a future reader needs in order to disagree intelligently. The named person is what stops the acceptance being attributed to nobody, which is the state most abandoned items are actually in. The date is what lets you notice that a decision was made under conditions that no longer hold. And the review date is the only thing that distinguishes an accepted risk from a forgotten one.

Three reasons for acceptance are legitimate. The consequence is genuinely tolerable at this size of business. The cost of the fix exceeds the harm by a margin nobody in the room disputes. Or the criterion is a convention the organisation has deliberately chosen not to adopt, having first understood what adopting it would mean. The illegitimate version is acceptance used as list hygiene, where items are closed to make a report read better and no reason is written down. The tell is easy to spot from the outside: an accepted item with an empty reason field is not a decision, it is a deletion wearing a label.

One category resists acceptance. Where the criterion carries an external obligation, choosing not to fix is a decision to persist in a known breach, and it should be written in exactly those words so that the person signing it understands what they are signing. That may still be the right operational call in a given quarter, with a real date attached to the remedy. It is not the same kind of decision as declining a stylistic convention, and a record that presents the two identically is not telling the truth to whoever inherits it.

Prioritisation done in a meeting evaporates. Six weeks later the person who understood the reasoning has moved teams, the list is inherited by somebody who was not in the room, and the new owner falls back on the only ordering visible in the document, which is severity. Everything argued above is lost, not because anybody disagreed with it but because it was never written anywhere durable. The order has to be an artefact, and each item has to carry enough for a stranger to reconstruct the decision without finding the people who made it.

• The criterion the finding is measured against, named specifically enough to be looked up by somebody who doubts it.
• The observed state, described so it can be re-checked rather than taken on trust.
• Severity, unchanged by anything that follows it in this list.
• Scope, expressed as consequential surface rather than as a raw page count.
• Effort, attributed to the person who estimated it, or explicitly marked unknown.
• Reversibility, with the reversal method written out for anything that is not trivially undone.
• Dependency, naming the predecessor item where one exists.
• Owner and disposition: scheduled, blocked on a named external party, or accepted with a reason, an approver and a review date.

That set of fields is why a serious audit output is a document rather than a sorted table. Zealsync builds Prooflin, a product for audits and professional reports, so this is an argument the company has a direct interest in and a reason to set out carefully rather than gesture at. The distinction holds whoever produced your report and whatever stands behind it: an assessment can establish the deviation and describe it defensibly, and the ordering decision belongs to whoever knows the consequence, the cost and the calendar. That is not a limitation to apologise for. It is the correct division of labour, and any report claiming otherwise would be asserting knowledge of your business that it does not have.

Zealsync operates Intense Path as its brand, growth and technology agency, and this is the shape of the conversation that tends to precede any remediation work rather than follow it. If you are holding a list and would rather have the ordering argued through than inherited, start there.