If what you were handed is a list of issues sorted by severity, with a count next to each, you were handed a crawl report. It may have cost you two thousand pounds and it may have a cover page with your logo on it. It is still a crawl report.
I am not being sniffy about tools. I use them on every job and the good ones are excellent. The distinction I care about is narrower and it decides whether the document is worth anything: a crawl tells you what is on the site. An audit tells you which of those things is the reason you are not ranking.
Those are different claims and only one of them requires somebody to take a risk.
Three things a crawl cannot do
It cannot tell you whether a page should exist. A crawler will report a thin page. It has no opinion on whether the page was a mistake, and “improve this page” and “delete this page” are both correct answers to the same row depending on a judgement no tool makes.
It cannot connect two findings. On one site I audited, the crawl reported 8,317 orphan pages and, separately, 8,317 pages with a missing or http canonical. Two rows, two counts, one page-set, one template. Read as a list it is two projects. Read as a diagnosis it is one cause and one fix.
It cannot tell you what the business needs. A tool will flag a missing H1 on a legal disclaimer and a missing H1 on the main service page with the same severity. Only one of those matters and the tool has no way to know which.
The volume problem is real and measurable. WebAIM’s automated crawl of the top million home pages averaged 56.1 detected errors per page. Meanwhile the 2025 Web Almanac found 86.6% of mobile home pages pass Lighthouse’s descriptive-link-text audit, so the same tooling that hands you fifty-six problems per page will also tell you your link text is fine when every link on the site comes from the menu. Loud where it should be quiet, silent where it should not.
What I think the difference actually is
An audit commits to a cause.
That is the whole of it. A crawl report lists everything that is true. An audit says: of all these true things, this is the one costing you, and here is why I think so. That sentence can be wrong, which is exactly why most deliverables avoid writing it. A list of four hundred issues cannot be wrong. It also cannot be acted on.
The test I would apply to any document you have paid for: does it name a cause, and would the author look foolish if that cause turned out to be something else? If nobody has taken that risk, nobody has done the diagnosis.
What should be in it that a tool cannot produce
- Somebody opened the site. On a laptop and on a phone. A surprising share of problems are visible in the first four seconds and invisible to a crawler, which does not care that the home page describes a mood rather than a business.
- Search Console, read properly. Not exported. Read. Which queries have impressions and no clicks, what the average position column actually says, whether the pages you care about are in the index at all.
- A comparison against the two or three businesses beating you. Sometimes the honest finding is that the site is fine and simply outgunned, and that finding is worth more than forty rows of fixes.
- A prioritised three. Not sixty. Three, named, with who does each one.
- Things you should not bother with. An audit that recommends everything has not made any decisions. The items I explicitly rule out are usually the most useful page in the document, because they are the ones saving you money.
Why so many deliverables are crawl reports
Because they are safe and they look substantial. Four hundred rows feels like value. Three findings and a paragraph explaining what you should ignore feels thin, right up until you try to implement either one.
There is also a straightforward incentive problem: a list of four hundred items can be produced in an afternoon and defended forever. A diagnosis takes a day of reading and can be proved wrong in six weeks.
The short version
- A crawl says what is on the site. An audit says what is costing you.
- A crawl cannot judge whether a page should exist, and improve/delete are both valid answers to the same row.
- It cannot connect findings. Matching counts mean one cause; the tool cannot see that.
- The test: does the document name a cause the author could be wrong about?
- It should include somebody actually opening the site, on a phone.
- It should tell you what not to do. That page is usually the most valuable one.
If a site should be ranking and it isn’t, that’s the work I do. What I check first is the sequence I run before any tool is involved. If you want somebody to name the cause rather than list the symptoms, that’s what an SEO audit is for.
