Guides
What Is an SEO Audit and What Should It Include?
A plain-English guide to what an SEO audit is, the four layers it must cover, how to run one step by step, and how to turn the findings into a prioritised fix list.
Run a fresh DomainLens audit and use the report as your priority list.
What an SEO audit actually checks
An SEO audit is a structured review of everything that decides whether a search engine can crawl, index, understand, and rank your pages. It is not a single score, and it is not only about keywords. A good audit looks at the page the way Googlebot does: it requests the URL, follows the redirects, reads the rendered HTML, checks the directives that allow or block indexing, and measures how fast and stable the page feels to a real user.
The goal is to separate cosmetic issues from problems that genuinely cost you traffic. A missing meta description is worth noting; a noindex tag on a page you want ranked, or content that only appears after JavaScript runs, can quietly remove that page from search entirely. The audit exists to surface that difference before you spend engineering time on the wrong thing.
In practice, most indexing problems trace back to a handful of causes: the page is blocked, the canonical points somewhere else, the content is too thin or duplicated across templates, or the page is too slow and unstable to compete. An audit checks each of those layers in order.
The four layers every audit should cover
Work through these in order — there is no point optimising titles on a page Google cannot even crawl.
- Crawlability — can search engines reach the page at all? Check HTTP status codes, robots.txt rules, redirect chains, internal links that lead to the page, and whether the server responds reliably.
- Indexability — is the page allowed and chosen to be indexed? Check the robots meta tag, X-Robots-Tag header, the canonical URL, and whether the page is a near-duplicate of another template.
- On-page and content — does the page deserve to rank? Check the title tag, H1 and heading structure, the depth and uniqueness of the content, image alt text, and whether it matches what the searcher actually wants.
- Performance and Core Web Vitals — does the page experience hold up? Check LCP, INP, and CLS using real field data where possible, plus the server response time that everything else depends on.
How to run an SEO audit, step by step
- Collect a baseline: run an automated audit so you have a consistent snapshot of status codes, meta tags, indexability signals, and Core Web Vitals.
- Confirm the page is crawlable: fetch the URL as a bot and check the rendered HTML actually contains your content and links.
- Confirm it is indexable: verify the robots directives and the canonical agree that this is the URL you want ranked.
- Review the content against search intent: is it the page a searcher for this query would want, or thin filler that repeats across templates?
- Measure real performance: prefer field data (CrUX / Search Console) over a single lab score, and find the slowest real interactions.
- Turn findings into a prioritised list: for each issue record the affected URL pattern, current behaviour, expected behaviour, impact, and how you will validate the fix.
What belongs in a useful audit report
A report that is just a list of warnings is noise. A useful report ranks issues by how much they affect crawling, indexing, and rankings, and it gives each one enough context to act on.
- The exact URL or template the issue affects, not just a site-wide count.
- A severity that reflects search impact, so a blocked page outranks a missing favicon.
- Evidence: the current value, the expected value, and where it was observed.
- A concrete next action and a way to validate it once shipped.
Mistakes that make an SEO audit worthless
- Chasing a single tool score instead of fixing the issues that actually block indexing or rankings.
- Auditing the source HTML only, when the content and links exist after JavaScript renders — check the rendered DOM.
- Treating every warning as equal, which buries the few problems that genuinely cost traffic.
- Validating on a local build instead of the live production URL, where the real directives and performance apply.
- Running the audit once and never re-checking after the fix ships.
Where DomainLens fits
DomainLens runs the automated half of this workflow: it fetches the live page, reads the rendered HTML, and reports crawlability, indexability, on-page tags, and Core Web Vitals as a ranked list of issues rather than a wall of warnings. Use it to collect the baseline and to re-check a page after a fix ships.
It does not replace judgement. The audit tells you what is wrong; you still decide which fixes matter for the query intent and the business value of the page. Start with the issues that block indexing or affect the most valuable URLs, and validate each change against the production page once it is live.