SERVICE / 02
SEO Audit
An SEO audit should tell you what to do on Monday. Mine covers technical health, content, authority and measurement, then ranks every finding by impact and effort so your developers and writers get a sequenced plan rather than a list of everything that is slightly wrong.
On this page
I have read a lot of SEO audits written by other people. The pattern is consistent: a tool export dressed up as analysis, a hundred pages of "issues" with no sense of which ones matter, and a team that reads the executive summary, feels bad, and changes nothing. The audit was technically correct and practically useless.
The audit I deliver is a different kind of document. It is shorter, it is ordered, and every item in it is written so that a specific person can act on it.
An audit is a plan, not a report
The purpose of an SEO audit is to answer one question: given everything that could be improved on this site, what should we do first, and why? Everything else is supporting evidence.
That framing changes the output. Instead of listing every page with a missing meta description, I ask whether meta descriptions are constraining anything on this site at all. Usually they are not. Instead of flagging "duplicate content" from a tool, I trace where the duplication comes from, whether Google is actually confused by it, and what the one template or canonical change is that would resolve it everywhere. The Technical SEO Audit Framework on this site is the method I use; the audit is that method applied to your site with your data.
If a finding cannot be turned into a ticket, it does not belong in the audit.
It also changes how I spend time. A crawl takes an afternoon. Understanding why it looks the way it does takes most of the engagement. The value is in the interpretation, not the data collection.
Who needs an audit
Sites where organic has stalled or dropped
Traffic was growing and stopped, or fell after a release, a migration or a core update. You want to know what changed and what to fix first, not a list of everything that could be better.
Teams about to invest in SEO
Before you commission a content programme or a link campaign, you want to know whether the site can actually support it. Pouring content into a site with indexing problems is the most common way to waste a quarter.
Companies planning a migration or rebuild
An audit before the build documents what currently earns traffic and why, so the new site preserves it. This is cheaper than a recovery audit afterwards.
Leadership seeking a second opinion
You have an agency or an in-house team and want an independent read. I audit the site, not the people, and I keep it fair.
Large, templated sites
Marketplaces, listings, e-commerce, publishers. Problems live in templates and multiply across thousands of URLs. One finding can be worth more than a hundred page-level fixes.
What I audit
Four areas, because organic performance is constrained by whichever one is weakest. A fast, crawlable site with no content worth ranking fails. A great content library behind a rendering problem fails. The audit looks at all four and tells you where the binding constraint is right now.
Technical
Can Google find, fetch, render and index the pages that matter, and is it spending its crawl on them rather than on junk? I look at crawlability and indexability, robots and sitemap hygiene, canonicalisation, redirect chains, JavaScript rendering, site architecture, internal linking, structured data, Core Web Vitals and, where I have logs, what Googlebot actually does on the site versus what the crawl tool assumes.
Content
Does the site have pages that match how people search, at every stage of intent, and are those pages good enough to win? This is a search-intent analysis more than a word-count exercise: which queries have no page, which have three competing pages, which pages are thin, outdated or cannibalising each other, and where the site's topical coverage has gaps that competitors have filled.
Authority
Where does the site's link equity come from, where does it go, and is it pointing at the pages that need it? I look at the external link profile for risk and concentration, and much harder at internal distribution, because on most sites the biggest authority problem is that the homepage hoards it and the money pages starve.
Measurement
Can you tell whether any of this is working? Analytics configuration, Search Console property setup, conversion tracking for organic, and whether the reporting the team sees actually reflects business outcomes. An audit that improves the site but leaves you unable to measure it has failed on its own terms. I have written about why rankings are the wrong primary metric.
How findings are prioritised
Every finding gets two scores: impact and effort. Impact is my estimate of how much organic performance is constrained by this issue, grounded in how many pages or how much traffic it touches. Effort is a realistic read of what it takes to fix, including who has to do it and what they have to change.
| Quadrant | What it means | What I recommend |
|---|---|---|
| High impact, low effort | A template change, a robots rule, a canonical fix that affects thousands of URLs | Do first. These are usually the first two sprints. |
| High impact, high effort | Architecture changes, rendering strategy, content consolidation across a section | Plan properly. Sequence into the roadmap with dependencies made explicit. |
| Low impact, low effort | Page-level tidying, minor metadata, small schema additions | Batch into a maintenance ticket. Do not let these crowd out real work. |
| Low impact, high effort | Things tools flag loudly that do not move anything on this site | Explicitly deprioritise, in writing, so nobody reopens them later. |
The last row matters more than it looks. A good audit removes items from the team's backlog as well as adding them. If a previous report told you to fix four hundred "low word count" pages and I think that is irrelevant, I say so and explain why.
Prioritisation also accounts for dependencies. There is no point briefing content for a section that is not indexed, or building links to pages that redirect three times. The strategy work that follows an audit turns these dependencies into a calendar.
What the deliverable looks like
A diagnosis summary
Two to three pages, written for decision-makers: what is constraining organic performance, what we should do about it, and what we should expect. No tool screenshots.
A prioritised findings register
Every finding with evidence, affected URLs or templates, impact and effort scores, owner and recommended sequence. Delivered as a spreadsheet, because that is what gets used.
Implementation specifications
For each high-priority item, a ticket-ready description: what to change, where, how to test it on staging, and how to verify it in production. Developers should not need to ask what I meant.
A ninety-day sequence
The order in which to ship the top items, with dependencies. This is the bridge between the audit and a working roadmap.
A measurement baseline
The pages, queries and segments we expect to move, recorded now so that later comparison is honest.
A walkthrough
A recorded or live session with the people who will implement. The audit is not delivered until the team understands it.
The audit process
Scoping
What does the site do, what has changed recently, what is the business worried about. This shapes which of the four areas gets the most depth. A publisher's audit and a SaaS audit look different.
Access and data collection
Search Console, analytics, CMS, staging and server logs where available. A full crawl, a rendered crawl where JavaScript is involved, and a log sample to see what Googlebot actually requests.
Analysis
Reading the data together rather than separately. Crawl findings are checked against index status and logs. Content gaps are checked against query data. Authority flow is mapped against the pages that matter commercially.
Prioritisation and specification
Findings scored, sequenced, and written up so that each one can be picked up as a ticket or a brief. Low-value items are explicitly parked.
Walkthrough and handover
I present the audit to the people who will act on it and answer questions. The register and specifications become theirs to work from.
What happens after the audit
An audit by itself changes nothing. The most common failure mode is that it gets delivered, discussed, and then sits in a shared drive while the team returns to its existing backlog. I try to prevent that in two ways.
First, the deliverable is shaped so the first few items are easy to start: specified, sprint-sized, and high enough impact that the team sees movement early. Second, I offer implementation support afterwards, as a short advisory engagement to review what ships or as embedded technical SEO work for the larger items. Some clients run with the audit entirely in-house, and the document is built to survive that.
Examples
Technical SEO audit and content architecture (Rahul Verma, Finance) — diagnostic audit that found binding crawl and topical constraints, leading to 8k to 45k monthly visit growth.
Indexing orphan pages experiment — the SEO Lab test that informs how I diagnose orphaned URLs and crawl equity in audits.
I audit sites for companies across India and abroad, with much of the in-person work in Delhi and Mumbai.
Frequently asked questions
How long does an SEO audit take?
Typically a few weeks from access to walkthrough, depending on the size of the site and whether server logs and a rendered crawl are involved. A small SaaS marketing site is quicker than a marketplace with a million URLs. I give a specific estimate after scoping.
Is this a technical SEO audit or a full SEO audit?
Both, in proportion. Every audit covers technical, content, authority and measurement, but the depth in each area depends on where the problems are. If scoping shows the issue is clearly technical, the audit goes deep there and lighter elsewhere, and I will tell you that upfront.
Do you use automated audit tools?
Yes, for data collection: crawlers, log analysers, Search Console exports, performance tooling. The analysis and prioritisation is manual, because tools cannot tell you which of their thousand flags matters on your site. The deliverable is never a tool export.
Will the audit tell us why traffic dropped?
Usually, yes. Drops have causes that leave evidence: a deploy date, a redirect change, a rendering shift, a set of pages that fell out of the index. I correlate timing against technical changes and known Google updates and give you the most likely explanation with the evidence behind it. Occasionally the honest answer is "several things compounded", and I say that.
Can our developers implement the audit without you?
That is the goal. Specifications are written so that a competent developer or writer can act on them without me. Many clients do exactly that. If you want review of what ships, or help with the larger items, I offer that separately.
Get an audit you will actually use
If you want to know what is really constraining your organic performance and what to do about it first, send me the site and a sentence or two about what is bothering you. I will tell you what kind of audit it needs, what access I would want, and what the deliverable will look like.
Work with me
Want an audit your team will actually use?
Send me the site and a sentence about what is bothering you. I will tell you what kind of audit it needs and what it will take.
Request an Audit Read the audit framework