Skip to content
SEOWofSEOWof
Browse the standard
SEO audits11 min read

Why SEO audits never get actioned (and how to structure one that does)

The audit is not the problem. What happens in the four weeks after the audit is the problem — and it is fixable with structure rather than willpower.

Published Updated

Ask any agency what they deliver in week one of an engagement and most will say a technical SEO audit. It is a good deliverable. It looks substantial, it demonstrates expertise, and it justifies the onboarding fee.

Then ask them, honestly, what proportion of the recommendations in the last one were implemented within ninety days.

The answers cluster somewhere between “about fifteen percent” and a pained silence. This is a widely acknowledged pattern in the industry: audits are produced, reviewed, filed, and quietly abandoned while organic performance stays flat. The agency loses the retention conversation in month four. The client concludes SEO does not work.

Neither party did anything wrong. The failure is structural, and it happens in a predictable sequence.

The five failure points, in the order they occur

1. The audit is written for the wrong reader

A technical audit is usually written by an SEO specialist, for an SEO specialist, and delivered to a marketing manager who must persuade a developer to act on it. That is two translation steps, and the document is optimised for none of them.

The specialist writes “canonical tags are inconsistent across paginated series.” The marketing manager cannot assess whether that matters. The developer cannot tell what the acceptance criterion is. So it becomes a Jira ticket titled “SEO: fix canonicals” with the PDF attached, and it sits behind a security patch and a checkout bug forever.

2. Everything is flagged, so nothing is urgent

Crawlers are thorough, which is their job. A mid-size e-commerce site will surface several hundred distinct issues on a first crawl. Presented as a list, this is worse than useless.

The most damaging version is the flat severity scale. A missing meta description on a 2019 blog post and an X-Robots-Tag: noindex on your product template are both rendered as a red row in a spreadsheet. One of these costs nothing. The other is removing your entire catalogue from the index.

When a client sees 200 red rows they do not experience urgency. They experience paralysis, followed by the reasonable conclusion that if everything is broken then nothing is really broken.

3. Findings are not connected to money

“You have 47 crawl errors” is a fact about a crawler. It is not a fact about the business, and no budget holder has ever approved developer time on the strength of it.

The translation that works looks like this:

Eighty-four product URLs are serving a noindex directive from the CDN. These pages received 12,400 organic sessions in the equivalent period last year. They are currently ineligible to appear in search at all. Removing one CDN rule restores eligibility. Estimated effort: under two hours.

Same finding. Now it is a decision anybody can make in thirty seconds.

4. Nobody owns the item

Audit findings cross at least four functions — development, content, design, and whoever controls the CMS or CDN. A single undifferentiated list assigns all of it to “the client,” which means it is assigned to nobody.

The fix is unglamorous and extremely effective: every finding names one owner discipline. Not a person — you do not know their org chart — but a discipline. Developer. Content. Design. SEO. Owner. It immediately becomes obvious that your list of 200 items is really five lists of 40, most of which can proceed in parallel.

5. There is no definition of done

This is the one that quietly destroys trust. Work gets marked complete. Nobody re-tests. Three months later the same finding appears in the next audit, and now the client believes either that the agency is recycling findings or that the developer lied.

Usually neither is true — the fix was partial, or it was correct in staging and never deployed, or a later release reverted it. Without a verification step there is no way to tell which, and no way to demonstrate progress.

The work order format

Here is the structure that survives contact with a real backlog. Every field exists because its absence causes a specific, observed failure.

FieldWhy it exists
Fault referenceTies the job to a published criterion, not to an opinion. Makes it auditable later.
EvidenceExact URLs, headers and observed values. The developer should never have to reproduce the diagnosis.
Business impactThe sessions, revenue or risk at stake. This is what gets it prioritised against non-SEO work.
Owner disciplineDeveloper, Content, Design, SEO or Owner. Routes the item to somebody who can actually do it.
Effort bandS/M/L/XL with an hour range. Enables sprint planning. Bands, not false precision.
Scope boundaryWhat is explicitly out. This is what prevents the scope creep that kills goodwill on both sides.
Acceptance criteriaObjectively testable conditions. Written before work starts.
Verification methodWhich test re-runs and what it must return. Removes “done” from the realm of opinion.

Sequencing: why the biggest problem should rarely go first

The instinct is to order by severity. This is wrong, and it is wrong for a behavioural reason rather than a technical one.

If item one is a three-week site architecture project, nothing happens. The queue stalls at the first entry, momentum never establishes, and the whole programme is abandoned. If item one is a two-hour CDN configuration change that restores 84 pages to the index, it gets done this week — and the visible result buys you permission for the three-week project later.

A defensible priority formula weights impact against effort:

priority = (severity × impact × certainty) ÷ effort

Applied to a real pair of findings:

  • Accidental noindex, critical severity (4), high impact (3), certain (1.0), effort S (1) → priority 12
  • LCP remediation, major severity (3), high impact (3), certain (1.0), effort L (3) → priority 3

Both matter enormously. The two-hour job that clears a critical fault goes first, and it is not close.

What to do with an audit you have already been given

If you are holding a 200-item audit right now, you do not need a new one. You need to restructure this one. It takes about two hours.

  1. Extract only the pass-blocking items. Anything that makes pages ineligible for search: robots directives, noindex, canonical errors, server errors, blocked rendering. Usually three to ten items. This is your real list.
  2. Attach a number to each. Sessions, revenue, or pages affected. Anything that converts the finding into a business fact.
  3. Assign one owner discipline per item. Watch the list split into parallel workstreams.
  4. Write acceptance criteria before anyone starts. One sentence each, objectively testable.
  5. Diary the verification. Put a date in the calendar to re-run the specific test. Not a general re-audit — the specific test.
  6. Delete the rest, for now. The remaining 190 items are not going anywhere. They will be caught on the next inspection, and the difference between fixing ten things and reading about two hundred is the entire ballgame.

The part nobody says out loud

An audit is cheap to produce and expensive to act on. That asymmetry is why the industry keeps producing them: the deliverable is profitable, the outcome is somebody else’s problem, and the failure is easy to attribute to client inaction.

The agencies that retain clients for years are not the ones with better crawlers. Everybody has the same crawlers. They are the ones who built a system that converts findings into scheduled, owned, verified work — and who can show a client in month six exactly which items were closed and how each one was proven.

That is not a tooling advantage. It is a format advantage, and it is available to anyone willing to stop shipping documents.