Search Engineering

A technical SEO audit, delivered as something you can build from

Most audits are a document. What a team actually needs is a set of findings grouped by the fix that resolves them, ordered by evidence, and written in a form that can go into a tracker without being rewritten.

The problem

An audit that cannot be acted on has not been delivered

The familiar result is a long document: every issue found, each with a severity, each described in its own section. It is accurate and it is close to unusable — the findings are grouped by symptom rather than by cause, so one template change appears as forty entries, and there is no way to tell which of them matter. The document is then either ignored or worked through in the order it was written, which is not the order of impact.

A previous audit produced a document nobody worked through
Findings are listed per URL when the cause is per template
Severity ratings exist and nothing distinguishes the first ten items from the rest
The engineering team says the recommendations are not actionable as written
Issues were fixed and the reported problem did not change
Nobody can say which of the findings are worth doing first, or why
The audit predates a redesign and has not been revisited
An audit is required to satisfy someone — a client, an investor, a board — as well as to fix things

Who this is for

The people who usually bring us this problem

A team that has decided it needs an audit

You want to know what you will receive and in what form, before commissioning it.

A team whose previous audit was not acted on

The document exists and the work did not happen, and you need the output in a different shape.

An engineering team handed an audit to implement

You have been given the findings and need them grouped by cause rather than by symptom.

What it costs

What this costs while it goes unfixed

Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.

The unit of a useful finding is a cause, not a URL

One template defect produces thousands of affected URLs. Listing them individually turns a single one-line change into thousands of tracker items and hides the fact that it is one change. Grouping by the fix that resolves them is what makes an audit proportionate to the work it implies.

Severity without reasoning is a ranking nobody can challenge

A finding marked critical with no explanation of the evidence is an assertion. What makes an ordering usable is that it says why: what was measured, what it affects, what happens if it is left. An ordering that can be argued with is one that can be trusted.

Fixes are frequently coupled, and the audit has to say so

Redirect correctness and canonical correctness have to change together or the second undoes the first. An audit that lists them as independent items produces work that is partly wasted, and the waste is invisible because both items appear complete.

An audit is a snapshot and the site keeps moving

It describes the site on the day it ran. A redesign, a migration or a release after that can invalidate parts of it, and a finding acted on eighteen months later may be describing a template that no longer exists. The artefact carries its date for that reason, and the parts most likely to age are marked.

What we do about it

Capabilities

Each of these is work we carry out, not an area we advise on.

Scope definition against the reported problem

What is being established and why — a decline, a migration to plan, a growth constraint, or a general position. Scope follows the question, so an audit commissioned to explain a decline examines different things from one commissioned before a replatform.

Crawlability and rendering review

What a crawler can reach and what it receives: robots rules, status codes, redirect chains, rendering dependencies, and whether the content of each page type is present in the served HTML.

Indexation and duplication review

What is indexed against what the site intends to be indexed, where signals are divided across near-duplicates, and which of the canonical, robots and linking decisions disagree with each other.

URL and internal linking structure

The address estate and the link graph beneath it: every URL class, what generates it, whether the structure is coherent, and whether the pages that matter are reachable through paths a crawler will follow.

Template and page-type analysis

Findings grouped by the template that produces them, because that is both where the cause is and where the fix goes. This is the analysis that turns a list of thousands of URLs into a list of tens of changes.

Structured data and machine readability

What the site asserts about its content, whether those claims are supported by the pages, and whether the entities it describes are identified consistently enough to be understood as the same things.

Performance and reliability as they affect discovery

Response behaviour at the level that influences crawl: server response, error rates and the query cost behind each template. Included because a discovery problem is frequently a performance problem and is fixed in the code.

Findings as a prioritised backlog

The deliverable itself: findings grouped by cause, each with the evidence, the pages affected, the fix, the owner it belongs to and whether it blocks or is blocked by another item — written so it can go into an engineering tracker directly.

A separate position for whoever commissioned it

Where the audit is also needed to satisfy someone who will not read a tracker, the same findings are summarised in a short form: what is wrong, what it affects and what is being done. Produced from the same findings, so it cannot diverge from them.

How we work

Engineering methodology

The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.

Agree what the audit is for before starting
The question it answers determines its scope, its depth and which parts of the site matter. An audit run against a generic checklist answers a question nobody asked and omits the one they did.
Record a baseline first
Current indexation, crawl behaviour and per-page-type position, before any change. Findings are prioritised by evidence of impact, and without a baseline there is no evidence and the ordering is opinion.
Analyse by page type, not by URL
Findings are established per template and per URL class, which is where causes live. Per-URL analysis produces a longer document that is harder to act on, because it obscures how few changes are usually behind a large number of affected pages.
Attach evidence to every finding
What was measured, on how many pages, and what it affects. A finding without evidence cannot be prioritised and cannot be challenged, and one that cannot be challenged should not be acted on.
State dependencies between fixes
Which changes have to happen together, and which have to happen in an order. Findings treated as independent items are how a team implements two corrections where the second undoes the first.
Write for the person implementing it
The audience is the engineer who has not read the audit and does not have the context. Each item names the fix, the location and the reason, and where the correct behaviour is a judgement rather than a rule, the judgement is stated as one.
Date it, and say what will age
An audit is a snapshot. The parts most likely to be invalidated by a redesign, a migration or a release are marked, so a reader working from it later knows which findings to re-check rather than trusting all of them equally.

Deliverables

What an engagement produces

Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.

The findings set

Findings grouped by the cause that resolves them, not by symptom or URL
Evidence for each: what was measured, across how many pages, with what effect
The pages and page types affected, by class rather than enumerated
Dependencies and required ordering between changes
Who each item belongs to: engineering, editorial, infrastructure or a vendor
Items that are judgements rather than defects, marked as such

The prioritisation

An order derived from evidence of impact, with the reasoning stated per item
Which findings block others, and which are cheap and independent
What is expected to change if the top items are done
What was found and deliberately not recommended, with the reason
The parts most likely to age, and what would invalidate them

The short form

A summary for whoever commissioned it: what is wrong, what it affects, what is being done
Derived from the same findings, so it cannot disagree with them
An explicit statement that no ranking, traffic or indexation outcome is guaranteed
The baseline the findings were assessed against

Under the hood

Architecture and technology

What the audit examines

Crawlability: robots rules, status codes, redirects, rendering dependencies
Indexation: coverage against intent, canonical agreement, near-duplicate sets
URL structure: every class, what generates it, whether the structure is coherent
Internal linking: what a crawler can reach, and by what path
Templates: the defects that affect every page of a type at once
Structured data: what the site asserts, and whether the pages support it
Performance and reliability at the level that influences crawl
Content accessibility: whether the content is in the served HTML

What the audit is not

A guarantee of rankings, traffic or indexation — none is offered or implied
An implementation engagement — the fixes are described, and doing them is separate
Content strategy, editorial direction or keyword planning
Link acquisition or off-site work of any kind
A substitute for a retainer: an audit describes the site as it was, not as it becomes

Related work

Where we have done this

Engagements where this capability was the substance of the work rather than a line item.

Fintech & capital markets

Search engineering at stockbroking scale

A stockbroking platform publishing at news velocity was losing search visibility to problems that had nothing to do with content quality. Two workstreams ran in parallel: sustaining a high-volume editorial output across business and market categories, and diagnosing the technical faults — a domain safety flag, recurring server errors, and a metadata defect on a templated page type — that were suppressing how much of that output search engines could actually reach.

225Msitewide impressions

All case studies →

Adjacent problems

If this is not quite your problem

These overlap at the edges. Sending you to the right page is more useful than having you work it out.

You want the discipline explained, not the deliverable

The umbrella page: what technical SEO covers and whether you need it.

Technical SEO

You want the findings implemented

Making the fixes at engineering standard, not handing over a description of them.

Technical SEO implementation

You want someone working continuously rather than once

Ongoing capacity instead of a project, and what a retainer does and does not include.

Technical SEO retainer

The specific problem is known

Coverage and crawl diagnosis when the question is already narrowed.

Crawl and indexation

Questions

Frequently asked

How is this different from your technical SEO page?

One answers what the discipline is; this answers what you receive if you commission it. The umbrella page explains the scope, how the work is approached and what the evidence looks like — it is there so a reader can decide whether any of this applies to them. This page is for someone who has decided, and it describes the artefact: how findings are grouped, how they are ordered, what form they take and what is not included. Three pages sit together here and the boundary is deliberate: this one for the diagnostic, implementation for making the fixes, and the retainer for ongoing work instead of a project.

What format is the deliverable in?

Findings grouped by the cause that resolves them, each carrying its evidence, the pages affected by class, the fix, and its dependencies — in a form that can be moved into a tracker without being rewritten. If a separate summary is needed for someone who will not read a tracker, that is produced from the same findings so the two cannot disagree. What it is not is a document organised by symptom, because a single template defect would then appear as thousands of entries and the one change that resolves them would be invisible.

Will the audit tell us our rankings will improve?

No, and nothing in it implies that. An audit establishes what is wrong, what is affected and what should change, ordered by the evidence available. It does not predict a position, a traffic level or an indexation outcome, because those are not determined by the audit — a search engine's evaluation of a site, a competitor's behaviour and demand for the subject all sit outside it. What the audit does is make the technical position legible and give the fixes an order. Claims about rankings attached to an audit are a different kind of document.

Do we need an audit, or could you just fix things?

It depends on whether the problem is established. If you know what is wrong and it needs implementing, an audit is overhead — go to implementation. If the position is unclear, or several things may be wrong and the order is not obvious, an audit is what stops the fixes being made in the wrong sequence, or made at all where they would not have helped. Where the question is already narrow, such as a coverage or a crawl problem, a scoped diagnosis is cheaper than a full audit and we will say so.

How long is an audit valid for?

It describes the site on the day it ran, and it carries that date. Some findings stay valid for a long time — a URL structure, a canonical rule, a missing page type — and others are invalidated by the next release: a template finding becomes moot the moment the template is replaced. The audit marks the findings most likely to age and what would invalidate them, so a reader picking it up months later knows which parts to re-check rather than treating the whole document as equally current.

Related capabilities and work

Bring us the problem you have not been able to fix

Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.

Discuss your engineering challenge View our work