How to Do an SEO Audit of a Website: A 40-Minute Method That Finds the Expensive Problems First

An SEO audit is a diagnosis, and diagnoses have an order. You check whether the patient is breathing before you check their cholesterol. Most audits, human and automated, skip the order: they run every check they have, sort the results by whatever the tool thinks is severity, and produce a document long enough to justify the fee. The result is a list where "meta description 165 characters" sits three lines above "every page canonicalised to the homepage", and the reader cannot tell which one is why traffic halved.

This is the order. It is arranged so that each stage can invalidate the ones after it: there is no point auditing headings on pages Google cannot fetch. It takes about forty minutes on a site of a few hundred pages, most of which is the crawl running while you do the first two stages by hand.

Stage 0: What are you auditing, and why?

Ten minutes, before any tool. Answer three questions in writing:

1. What is the site for? A SaaS marketing site, a documentation site and a store have different failure modes, and an audit that does not know which it is looking at will weight things wrongly. On a docs site, orphaned pages are the main event; on a store, faceted URL explosion is.
2. What does "better" mean? More organic sessions to the pricing page is a different goal from more citations in AI answers, which is different again from a migration that must not lose rankings. Write down the goal, because every finding will be graded against it.
3. What changed recently? A redesign, a framework migration, a domain move, a new CMS. If something changed and traffic moved, the audit is really a diff, and you should be comparing before and after rather than auditing in a vacuum.

If you have Search Console access, open the Performance report and the Pages report now and leave them open. They are the only source of truth for what Google actually did with the site; everything else is a model.

Stage 1: Can it be crawled? (5 minutes)

Nothing else matters if this fails. Three checks, all from a terminal.

robots.txt.

curl -s https://example.com/robots.txt

Look for a Disallow: / under User-agent: *. It happens far more often than it should, usually left over from staging. Then look for what is specifically disallowed and ask whether each line is intentional. Then look at the AI crawler groups, because a rule that blocks OAI-SearchBot or PerplexityBot removes the site from every AI answer, and rules like that are frequently copied in without anyone deciding to. The crawler list and the safe configuration are here.

The response, as a crawler.

curl -sI -A "Googlebot" https://example.com/
curl -sI -A "Mozilla/5.0" https://example.com/

Both should return 200. A 403 or a challenge page for the first and a 200 for the second means a WAF is blocking crawlers, and the site may be invisible to search engines while looking fine in every browser. Check the X-Robots-Tag header in the same output; a noindex there is invisible in view-source and takes the site out of the index just as effectively as the meta tag.

The sitemap.

curl -s https://example.com/sitemap.xml | head -50

It should exist, parse, and contain the URLs you want indexed and nothing else. Common defects: it lists http URLs on an https site; every lastmod is today's date, which makes the field useless; it includes noindexed pages, redirecting pages and 404s. A sitemap is a hint to search engines about what you consider canonical, and a sitemap full of junk is a hint that you do not know.

Stage 2: Is it being indexed? (5 minutes)

Crawlable is not indexed. This stage is Search Console, and there is no substitute.

Pages report. Look at the excluded reasons and their counts:

• Crawled — currently not indexed. Google fetched it and decided not to keep it. On a small site this usually means thin or duplicate content. On a large site it can mean crawl budget is being spent on the wrong URLs.
• Duplicate without user-selected canonical / Duplicate, Google chose different canonical. Your canonical tags are wrong, missing, or disagreeing with your internal links and sitemap. This is the finding that most often explains a traffic drop after a migration.
• Excluded by 'noindex' tag. Fine if intentional. Check that the count is what you expect.
• Blocked by robots.txt. Cross-reference with Stage 1.
• Soft 404. Pages returning 200 with not-found content. Each one is a template bug.

URL Inspection on five pages: the homepage, a top-traffic page, a page that lost traffic, a page published in the last month, and a page you suspect is a duplicate. For each, compare "User-declared canonical" with "Google-selected canonical". Where they differ, you have found something the crawl in the next stage will explain.

Performance report, last 3 months vs previous 3 months, by page. Sort by click difference. The pages that lost the most are the pages to inspect first in Stage 4. This is the only step that tells you which findings actually matter for this site.

Stage 3: Crawl it (runs in the background)

Start a crawl of the whole site now, from the homepage, following links, with the sitemap as a second source. Let it run while you do the next stage. The crawl produces the two things a manual inspection cannot: a per-page list of every check, sortable by score, and cross-page findings that only exist in aggregate.

The cross-page findings to read when it finishes, in order:

1. Canonical clusters and duplicates. Groups of pages with identical titles, identical descriptions, identical H1s, or near-identical body text. These are the mechanical explanation for the "duplicate" exclusions in Stage 2.
2. Broken internal links. Any link to a URL that returned 4xx or 5xx. Each one is both a user-facing dead end and a wasted crawl.
3. Orphans and depth. Sitemap URLs with no internal links pointing at them, and pages more than three clicks from the homepage. Orphans get their own treatment; the short version is that each one is a page the site itself is not vouching for.
4. Indexability inconsistencies. Pages that are noindexed but in the sitemap; pages that canonicalise to a different URL but are linked as if they were primary; noindexed pages with lots of inbound links.
5. Thin pages. Under a couple of hundred words of actual content. Sort by inbound links: a thin page with many inbound links is a page that should be better; a thin page with none is a page that should probably not exist.

The site crawl on this site produces exactly this list, with each page's full audit one click away, and it follows links rather than only reading the sitemap, which is what makes the orphan report meaningful.

Stage 4: Audit the templates, not the pages (15 minutes)

While the crawl runs, audit five pages by hand, one per template: the homepage, a category or index page, a content page, a product or feature page, and one utility page (contact, pricing, a legal page). Almost every technical SEO defect lives in a layout, a component or a CMS setting; fixing it on the template fixes every page that uses it, and auditing fifty pages that share a template tells you the same thing fifty times.

For each page, run through the technical and meta checks in the 36-check list, in weight order:

• Weight 3 first: HTTPS with a single redirect from http, no noindex (tag or header), not disallowed in robots.txt, a final 200 status, a title of 30 to 60 characters that is unique to the page, and retrieval crawlers allowed. Any failure here is a template bug that is costing every page on that template.
• Then weight 2: a self-referencing canonical, a meta description of 70 to 160 characters, a viewport meta, a TTFB under 800 ms, one H1 that describes the page, enough content to be about something, and internal links in both directions. Read the canonical value, not just its presence; the classic failure is a canonical that is present on every page and points at the homepage on every page.
• Then the hygiene checks: charset, compression, lang attribute, alt text, heading levels, Open Graph. Real, worth fixing, rarely why traffic changed.

The one tool that helps most here is view-source: plus a search for <link rel="canonical", <meta name="robots", and <title>. The rendered DOM in DevTools is what the browser has after JavaScript; the source is what Googlebot's first pass and every AI retrieval bot sees. If a title or canonical only exists in the DOM and not in the source, that is a JavaScript rendering problem and a serious one.

Stage 5: Content and structure (the rest)

Only now, and only on the pages that matter: the top-traffic pages, the pages that lost traffic in Stage 2, and the pages that are supposed to rank for the goal in Stage 0.

For each: does the title match the query the page is supposed to win? Does the first paragraph answer it, or clear its throat? Is there structured data describing what the page is, and is it the right type? Does the page link to the three pages a reader would want next? Is it dated, and is the date honest?

This is the stage most audits start with, and it is last on purpose. Content changes on a page that is canonicalised to the homepage do nothing. Content changes on a page that Google has excluded as a duplicate do nothing. Content changes on a page that a WAF is hiding from Googlebot do nothing. Stages 1 to 4 are there so that the content work in Stage 5 is done on pages that can actually benefit from it.

What to skip

Things that appear in most audit reports and can safely be left out of yours:

• Keyword density. Not a thing since roughly 2011.
• Meta keywords. Ignored by every major engine for over fifteen years.
• Word count as a target. A floor, for detecting thin pages. Never a goal.
• Text-to-HTML ratio. A proxy for bloat that measures nothing useful directly.
• Domain authority and every other third-party authority score. Modelled numbers with no relationship to any ranking system. Useful for comparing two sites at a glance; useless as an audit finding.
• Lighthouse performance score as a target. Field data is what ranks; the lab score is a debugger.

Turning the audit into fixes

The audit's output should be a short list, ordered by weight times pages affected: "canonical template points at homepage, 340 pages" at the top, "favicon missing, 1 page" at the bottom. Each item names the template or setting to change, not the page. That is the document that gets things fixed, and it is usually under a page long.

If a developer or a coding agent is doing the fixing, the same list becomes the instructions: one finding, one file, one expected result, in severity order. How to write those instructions so an agent executes them rather than improvising is the companion piece. And if you want the single-page version of Stage 4 with the weights shown, the free audit here runs all 36 checks on any URL without an account, which is a reasonable way to see what the template audit looks like before doing it by hand.