An audit is a document, not an engagement
An audit produces one thing: a written diagnosis of what is preventing a site from being found, understood and ranked, ordered by what each problem is plausibly costing. It has a beginning and an end. You receive it, you own it, and you are under no obligation to buy anything else — including from the person who wrote it.
That framing matters commercially, because the audit is the most commonly mis-sold artifact in this field. It is frequently given away as a sales instrument, in which case it is not a diagnosis but a list of things a tool flagged, arranged to make a proposal look necessary. It is equally often confused with the work of fixing the findings, which is a separate engagement with a separate cost.
The test for a real one is whether a competent developer who has never met you could open it and start working. If a finding does not name the affected URLs, state the expected behavior, and explain how to test the result, it is an observation, not a finding.
What actually gets examined
The scope is largely settled and it is worth stating so you can compare quotes on like terms.
- Crawl controls —
robots.txtdirectives, meta robots tags, and anything blocking access to pages that should be reachable or exposing pages that should not be. - Status codes across the whole URL inventory —
200,301,302,304,404,410,429and5xx— plus redirect chains. Googlebot will follow up to ten hops, but Google advises redirecting to the final destination directly, so chains are a finding even when they resolve. - Canonicalization — whether
rel=canonicalagrees with internal linking, sitemaps and the redirect layer, or contradicts them. - Indexation — what is indexed that should not be, what is excluded that should not be, and soft 404s, which are pages returning success while showing nothing useful.
- Rendering — a diff of source HTML against rendered HTML, because content that only exists after JavaScript execution is content that depends on the render queue.
- Core Web Vitals field data at the 75th percentile of real page loads.
- XML sitemaps, including whether
<lastmod>is accurate rather than set to the build date. - Structured data validity, faceted and parameter URL inventory, internal link distribution, and
hreflangreturn-link integrity where more than one language or region exists.
Where the evidence comes from, and what each source cannot see
Four sources, each with a blind spot that the others cover.
A full crawl establishes what exists and how it responds, but only sees what is linked or listed. It cannot tell you what search engines are actually requesting.
Search Console is the only source that reports impressions and position at all. Its Crawl Stats report gives request volume, download size, average response time, host status across robots.txt fetch, DNS resolution and server connectivity, plus breakdowns by response code, file type, crawl purpose and Googlebot type. Google also states the report's limits: some requests might not be counted for various reasons, only your own property domain is included, and the example URLs shown are samples rather than complete lists.
Server log files are what close that gap. Complete per-URL request records, exact timestamps, true response codes as served, and full user-agent strings — which is now the only reliable way to separate Googlebot from the AI crawlers hitting the same site. Logs also show requests to URLs no report mentions.
Analytics supplies the commercial weighting: which templates and URL groups actually produce revenue, so findings can be ranked by consequence rather than by severity in the abstract.
How findings get ordered, and why that is the hard part
Producing a list of problems is not difficult. Any crawler will produce several hundred, most of which do not matter. The work is deciding which ones do.
Ranking uses three inputs together. Consequence — how much traffic or revenue passes through the affected pages, taken from analytics rather than from instinct. Confidence — whether the mechanism is documented by Google or inferred; a documented rule outranks a hypothesis. Cost to fix — a one-line server rule and a re-architecture are not comparable, even when they address the same symptom.
Findings that come out low get a second look before being dropped, because the alternative is a report that ranks the same top ten items for every site. And some findings are deliberately included as explicit non-issues. If crawl budget is not your constraint, saying so in writing is worth as much as any fix, because it stops you buying a project that would have changed nothing.
A report of forty items with no ordering is not an audit. It is the hard part transferred back to the buyer.
What lands on your desk at the end
A written document, structured to be used rather than admired:
- A short summary that states the diagnosis in plain terms — what is actually wrong, in a paragraph, without preamble.
- Findings in priority order. Each one names the problem, the affected URLs or URL patterns, the evidence, the expected behavior after the fix, and how to test it.
- A separate list of things that are fine, and things that were checked and found not to apply. This is the section that saves money.
- The raw data behind it — the crawl export, the URL inventory with response codes, and the Search Console and field-data extracts used, so nothing rests on my summary of it.
- A handover conversation with whoever will implement, because a document nobody can ask questions about gets half-implemented.
The document is yours. It goes to your developers, to another consultant, or to an agency you already work with, without restriction. An audit that only makes sense if its author does the follow-on work was written as a proposal.
Why a lot of buyers should stop here
This is the part most providers leave out, so it is worth being direct: for a large share of sites, the audit is the whole purchase.
If you have a development team who ships regularly and a marketer who can hold them to a list, you do not need anyone standing over the implementation. You need to know what to build. Once the document is in hand, the remaining work is project management you are already staffed for, and paying an external party to watch it happen is a cost with no matching benefit.
Stopping is also the right call when the audit's own conclusion is that the technical surface is sound. That happens more often than the market admits, particularly on small sites and on mainstream platforms in near-default configuration. In that situation the honest recommendation is that the constraint is content, positioning or demand — none of which a technical engagement addresses.
Where ongoing help is genuinely warranted is narrower than it is usually sold: when nobody internally can decide which of forty findings comes first, when the fixes are structural enough that a wrong implementation causes damage, or when the site changes fast enough that new problems appear faster than a one-time document can describe them.
What makes one audit cost more than another, and how long it takes
Two to four weeks from the point access is granted is normal, and the gating item is almost always access rather than analysis — log file extracts and Search Console permissions routinely take longer to arrive than the crawl takes to run.
Cost is driven by measurable properties of the site, not by how much you appear able to pay. Total URL count and the number of distinct templates. Whether server logs are obtainable at all, since some hosted platforms do not expose them. The number of languages and markets, because every additional locale multiplies hreflang validation. Whether the site is server-rendered or requires rendering analysis. Whether e-commerce faceted navigation is in play, which turns URL inventory into a substantial exercise on its own. And how many separate parties — hosting, platform, development, content — hold a piece of the answer.
An audit is bought as a fixed-scope project with a defined end, which is precisely why it is a low-risk way to evaluate whether you want to work with someone at all.
How you will know the audit was worth buying
Not by a traffic number in the following month, which no diagnosis can produce on its own. Three tests instead.
Did your developers act on it without needing to reinterpret it? If implementation stalled on questions the document should have answered, the specification failed regardless of whether the analysis was correct.
Did the instrumentation move after the fixes shipped? Response-code distribution in Crawl Stats, URLs changing state in the Page Indexing report, field data updating over the following weeks. These respond before rankings do and they are how causation gets established rather than assumed.
Did it change what you decided to spend money on? An audit that stops an unnecessary project — a crawl budget engagement for a site nowhere near the thresholds, a platform migration nobody needed, a link campaign aimed at a problem that turned out to be a canonical tag — has already paid for itself before a single fix ships.
Ranking movement, when it comes, follows recrawling and reassessment on a timeline nobody controls. Google's own documentation says some changes take effect in a few days while others could take several months, and declines to commit to any noticeable impact at all. That is the correct expectation to hold.
Frequently Asked Questions
How much does an SEO audit cost?
It is bought as a fixed-scope project, and the figure is driven by properties of the site rather than by the size of the business. The main drivers are total URL count and number of distinct templates, whether server log files can be obtained at all, how many languages and markets are involved, whether the site needs rendering analysis because content is assembled in JavaScript, and whether faceted navigation is generating parameterized URLs at scale. A small single-market site on a mainstream platform sits at the low end. A large multi-locale catalog with three vendors holding pieces of the stack sits at the other.How long does an SEO audit take?
Typically two to four weeks from the point access is granted, and access is usually the bottleneck rather than the analysis. Search Console permissions, analytics access and server log extracts often take longer to arrive than the crawl takes to run, so the clock effectively starts when the last of them lands. Large sites take longer because URL inventory and rendering checks scale with size. If a provider quotes a turnaround measured in days without having seen the site, they are describing a tool report rather than an audit.What is the difference between a free SEO audit and a paid one?
A free audit is nearly always a sales instrument: a crawler run against your domain, its default warnings exported, and the output arranged so that a proposal looks necessary. It has no access to your Search Console data, no analytics weighting, no server logs, and therefore no way to rank findings by what they actually cost you. A paid audit is defined by having those inputs and by the ordering work they enable. The useful question to ask any provider offering a free one is which data sources they will have access to before they write it.Can I give the audit to my own developers or another agency?
Yes, and it should be written to survive that. The document is yours outright, including the underlying crawl export, the URL inventory with response codes, and the data extracts behind each finding. A finding that names the affected URL patterns, states the expected behavior and describes the test can be handed to any competent developer without further explanation. If an audit only makes sense when its author implements it, it was written as a proposal rather than a diagnosis, and that is worth checking before you commission one.I already have an audit from an agency. Do I need another one?
Usually not, and getting a second opinion on the first one is cheaper than commissioning a replacement. The questions worth asking of the document you already hold: are the findings ranked by consequence to your revenue, or by a tool's severity label? Does each finding name affected URLs and a test? Does it say anywhere what is fine and what was checked and found not to apply? Does it recommend anything Google's own documentation contradicts, such as routine disavowing or a crawl budget project on a site well below the documented thresholds?How often should a site be audited?
Less often than it is sold. A full audit is warranted when something material changes — a platform move, a redesign, a migration, an unexplained traffic drop, a new market — or when the previous one has been implemented and the site has moved on. For a stable site of moderate size, that is rarely more than once a year and sometimes considerably less. Continuous monitoring of crawl and indexing reports is a different and much smaller activity, and it does not need a full diagnostic exercise attached to it every quarter.Is a tool report the same thing as an audit?
No. A crawler produces observations at volume — often several hundred, most of which do not matter for your site — with severity labels assigned by the tool's own defaults rather than by anything about your business. What it cannot do is weight findings by the revenue passing through the affected pages, reconcile crawl data against server logs and Search Console, distinguish a documented Google mechanism from a widely repeated assumption, or tell you which findings to ignore. The tool output is an input to an audit. On its own it is a list.Published