Loading…

The audit is a list, and lists decay

The standard engagement produces a spreadsheet. Two hundred rows, colour-coded by severity, each one a defect: thin pages, missing canonicals, orphaned URLs, bloated title tags. The team works the list. Six months later someone runs the crawler again and gets a new list, roughly the same length, with different rows in it.

This is not a failure of execution. It is what a list does. A defect list describes the state of the site on the day it was generated, and a site that is still shipping starts diverging from that description immediately. You are paying to describe entropy, then paying again to describe it once more after it has re-accumulated.

The question worth asking is not “what is broken”. It is “what keeps producing the same breakages”. Those are different investigations and they produce very different deliverables.

Defects are downstream of decisions

Take orphaned pages. An audit records that forty URLs have no internal links pointing at them. The fix is to add links. The cause is that nobody owns the internal link graph, so every new page arrives with whatever links its author happened to think of, and pages published in a hurry arrive with none.

Fix the forty and you have bought yourself until the next hurried publish. Assign ownership of the link graph, define which template each content type uses, and specify where its links come from, and orphans stop being generated. One is a repair. The other is a change to the system that produced the fault.

The same holds for thin content, for duplicate titles, for the slow drift of a taxonomy nobody is governing. Each shows up in an audit as a symptom. Each is produced by an unmade decision somewhere upstream in how the site is allowed to grow.

What to build instead

An architecture deliverable answers a small number of durable questions, and it answers them in a form your team can apply without you in the room:

• Which content types exist, and what is each one for. Not a wish list, a closed set. If a brief does not fit one of them, that is a signal, not an exception.
• How pages of each type link to each other, specified as a rule rather than a habit. “Every tool page links to its category hub and to three sibling tools” is a rule. “Link to relevant pages” is a habit.
• Where authority is meant to accumulate, and which pages are deliberately not competing for it.
• What must be true before a page is allowed to publish. A quality bar, written down, applied by the person publishing rather than by an auditor six months later.

None of that shows up as a row in a crawler report. All of it determines how many rows the next crawler report will have.

For what that architecture looks like sequenced across a year rather than described in the abstract, see the quarter-by-quarter operating plan.

The honest case for auditing anyway

There is a real place for the defect list. If a site has never been looked at, the audit tells you which failures are severe enough to be blocking, and some of those are genuinely urgent: a noindex left on a template, a canonical pointing at staging, a redirect chain eating crawl budget. Fix those immediately and without ceremony.

The mistake is treating that clean-up as the strategy. Clearing a backlog gets the site back to zero. It does not decide what the site becomes. If the engagement ends when the spreadsheet is green, you have bought a return to baseline at consultant rates.

A reasonable split: spend the first few weeks clearing blocking defects, and spend the rest defining the rules that stop them recurring. The output your team should still be using in eighteen months is the second thing, not the first.

One caveat on judging any of this: the defects you closed will not show up cleanly in your reporting, for reasons covered in how to measure organic when attribution is already broken.