SEO Audits
An audit that ends with a prioritised plan, not a two hundred page PDF
A fixed-scope diagnostic with a defined deliverable. We examine the site, the search demand around it and the competition, then hand over a ranked set of changes with the reasoning, the expected effect and enough detail for a developer to build from.
How it runs
Five stages, two to four weeks, a fixed deliverable
This is a productised piece of work rather than an open-ended investigation, so you know at the start what you are getting and when.
Scope and access
We agree the question the audit is answering — general diagnosis, pre-redesign protection, or a specific traffic loss — then collect access to analytics, Search Console, the CMS and, where they exist, server log files. Access is the usual bottleneck, so it goes first.
You get: Agreed scope statement and an access checklist
Collect and crawl
A full crawl at your site scale, rendered and unrendered so we can see what depends on JavaScript, plus index coverage data, performance field data, log file samples and historical search performance. Everything is gathered before anything is judged.
You get: Complete data set, retained and shared with you
Analyse
The part that is not automated. Manual review of your main templates, intent match on your commercial pages, cannibalisation across the site, competitive comparison on the searches that matter, and a timeline of site and market events where a decline needs explaining.
You get: Findings register with the evidence attached to each item
Prioritise
Every finding ranked by expected effect against the effort to implement it, with the reasoning stated. This is where four hundred issues become a list of six that matter, and where we say plainly which findings we think you should ignore.
You get: Ranked roadmap with the ordering rationale written out
Hand over properly
A working session with your marketing and development teams, recorded, where we walk through the findings and answer the questions that normally stall implementation. Written specifications go into whatever ticketing system you already use.
You get: Recorded handover session and sprint-ready specifications
Coverage
What gets examined
The list below is the standard scope. It expands for very large sites and narrows where a specific question makes parts of it irrelevant.
- Crawl accessibility: robots directives, canonicals, redirect chains, status codes and parameter handling
- Index coverage: what is indexed, what is excluded, and whether the exclusions were intended
- Rendering: what a crawler sees with and without JavaScript, and what depends on hydration
- Site architecture: depth, internal linking, orphaned pages and how authority moves through the site
- Template quality across the page types that carry commercial value
- Intent match: whether each commercial page answers the search it targets
- Cannibalisation: pages competing with each other for the same intent
- Search demand mapping and the gaps where no page exists at all
- Competitive comparison on the searches that lead to enquiries
- Core Web Vitals and field performance data by template
- Structured data validity and alignment with visible content
- International and location configuration where relevant
- Historical performance timeline against site changes, updates and market events
- Conversion and tracking accuracy, because a measurement fault can look exactly like a traffic fault
Which one you need
Three audits, three different questions
| Dimension | Technical audit | Full SEO audit | Traffic-loss diagnostic |
|---|---|---|---|
| The question it answers | Can search engines crawl, render and index this site properly? | Why is organic performance short of what this business should achieve? | What specifically caused the decline, and when? |
| Usual trigger | A replatform, a migration, or a site that has grown past its architecture. | A retainer decision, a new marketing lead, or a plateau nobody can explain. | A drop that shows in the reporting and has no agreed cause. |
| Heaviest work | Crawl, log file and rendering analysis at scale. | Demand mapping, intent match and competitive comparison. | Historical data reconstruction and event timeline correlation. |
| What you receive | Specifications for the development team, ranked by effect. | A full roadmap covering technical, content, architecture and authority. | A cause, the evidence for it, and a recovery sequence. |
| When it is the wrong choice | When the site is technically sound and the real gap is demand or authority. | When you already know the cause and just need it specified and fixed. | When the decline is explained by seasonality or a tracking change, which we check first. |
Afterwards
What happens once the document is delivered
Most audits fail at this point rather than in the analysis. The document is thorough, the recommendations are correct, and eighteen months later almost none of it has been implemented. That outcome is predictable enough that we design against it.
Three things make the difference. Findings written as buildable work rather than as observations, so a developer can pick one up without translating it first. A handover session with the people who will implement, because the questions that stall a rollout are almost always answered in the first hour. And a ranked list short enough to act on, which means being willing to tell you that three hundred of the four hundred findings are not worth your time.
After that the choice is yours. Your team implements it, another agency does, or we do. The audit is priced and scoped as a standalone piece of work, and we would rather it stood on its own merits than functioned as a sales document with a crawl report attached.
If you do continue with us, the audit becomes the first quarter of the plan rather than something to be redone. Nothing gets charged twice.
The deliverable
Four things you actually receive
The findings register
Every issue found, with severity, the evidence behind it, the number of URLs affected and a plain-language explanation of why it matters. This is the complete picture, including the items we go on to recommend ignoring.
The prioritised roadmap
The short version: what to do, in what order, and why that order. Ranked by expected effect against implementation effort, with the reasoning written out so you can disagree with it on the evidence rather than on trust.
The specifications
Each structural finding written as work: the template or component affected, what should change, acceptance criteria, a test to confirm it worked, and the consequence of skipping it. Delivered into whatever ticketing system your team already uses.
The handover session
A recorded working session with your marketing and development teams. Questions answered live, ownership agreed for the top items, and a shared understanding of what happens in the first sprint after we finish.
Questions
What people ask before commissioning an audit
How is this different from running a crawl ourselves?
A crawler tells you what is technically true about your site. It cannot tell you which of those four hundred findings is costing you money, which are irrelevant at your scale, and which are symptoms of a single underlying cause.
We use the same crawlers. The deliverable is the interpretation: the evidence for each finding, the reason it is ranked where it is, and what changes if you fix it. That judgement is the thing being bought.
What if the audit finds nothing seriously wrong?
Then we say so, and the audit turns to why performance is still short. Usually the answer is one of three things: the demand you are targeting is smaller than assumed, your pages do not match the intent behind the searches, or your competitors have authority you have not built.
That is a genuinely valuable finding, because it stops a technical project that would have produced nothing and moves the budget somewhere that might.
How is this different from your free audit?
The free version is an automated check plus a short review, useful for spotting whether anything obvious is broken and for deciding whether a full diagnosis is worth commissioning.
The paid audit involves log files, index coverage data, manual review of your key templates, competitive analysis, demand research and interviews with your team. It produces specifications rather than observations. They answer different questions and the free one is genuinely free.
Will our developers actually be able to use it?
That is the main thing we optimise the format for. Each structural finding is written against the template or component it affects, with acceptance criteria, a test to confirm it worked, and a plain statement of the consequence of not doing it.
We also offer a handover session with your development team rather than sending a document and hoping. Most of the questions that stall implementation get answered in that hour.
How long does an audit take?
Typically two to four weeks from receiving access, depending on the size of the site and how quickly access to analytics, Search Console and log files can be arranged. Access delays are the most common reason an audit runs long.
Large sites and traffic-loss diagnoses take longer because the historical data work is substantial. We will give you a date at the point of scoping rather than an estimate that moves.
Do we have to work with you afterwards?
No. The audit is a fixed-scope piece of work with a defined deliverable, and it is yours to implement with your own team, another agency, or us.
We would rather deliver something genuinely useful and be judged on it than produce a document designed to make a retainer feel unavoidable.
Tell us the question and we will scope the audit to it
A general diagnosis, a redesign you want to protect, or a drop nobody can explain are three different pieces of work. Tell us which one you have and we will confirm the scope, the timeline and the price before anything starts.
If we don't deliver the work we agreed to deliver for reasons within our control, you don't pay for the undelivered work. Read our guarantee
Related
Where to go next
- our free visibility checkA much shorter look, useful for deciding whether the full audit is worth it.
- technical remediation workWhere the structural findings get implemented.
- reasons organic traffic fallsThe causes we work through in a loss diagnosis.
- recovering traffic after a drop
- page experience and performance work
- an ongoing search programmeWhat an audit often leads into, though it does not have to.
Last updated · Reviewed by Zubair Afzal