Skip to content

checklist

SEO audit: what to check, in what order

Irfan6 min read

What order should an SEO audit follow?

An SEO audit should follow dependency order, not importance order. Check whether pages can be reached, then whether they can be indexed, then whether they are understood, then whether they compete. Each stage is meaningless until the one before it passes: optimising a title tag on a page blocked from indexing changes nothing, and most audits waste effort by starting with on-page factors.

Most SEO audit templates are organised by category — technical, on-page, content, off-page. That produces a long list of findings with no ordering, where a missing meta description sits beside a directive blocking half the site.

This is ordered by dependency. Each stage only matters if the one before it passed. Work down; the first stage that fails is your finding, and everything below it is noise until that is fixed.


Stage 1 — Can search engines reach the pages?

Nothing below matters until this passes.

  • robots.txt fetches and returns 200. A 5xx here can suspend crawling entirely; a 404 is safer than an error
  • No Disallow blocking pages you want indexed. Check the specific paths, not just the file — a broad rule catches more than intended
  • AI crawlers explicitly permitted or refused, deliberately. GPTBot, ClaudeBot, PerplexityBot, Google-Extended. Either answer is defensible; not having decided is not
  • XML sitemap exists, returns 200, is valid. Referenced in robots.txt
  • Sitemap URLs match canonical URLs exactly — including the trailing slash. A mismatch points every entry at a redirect
  • Every important page reachable within three clicks of the homepage
  • Navigation present in server-rendered HTML. Fetch the page and search the raw response for a nav link. A menu that only exists after JavaScript runs is invisible to several crawlers
  • No orphan pages — every page has at least one inbound internal link
  • Server returns 200 for a browser-like request. Some hosts challenge non-browser clients with a 403 carrying noindex. Test with a real User-Agent, or you will diagnose a catastrophe that does not exist

Stage 2 — Can the pages be indexed?

Reachable and indexable are different things, and this is where most real damage hides.

  • No unintended noindex in meta tags or X-Robots-Tag headers. Check the headers, not just the HTML — a header-level noindex is invisible in view-source
  • Search Console indexing report reviewed by reason, not just total count
  • Indexed page count roughly matches published page count. A widening gap is the finding
  • Canonical tags self-reference on pages that should be indexed
  • Canonical matches the served URL character for character, trailing slash included
  • No canonical pointing at a redirect or a 404
  • One URL per page. Check for the same content at www and apex, http and https, with and without trailing slash, and with tracking parameters
  • Pagination pages self-canonical, not canonicalised to page one — otherwise deep content is declared not to exist
  • No crawlable faceted filters generating near-duplicate URLs at scale
  • Redirect chains flattened. A → B → C should be A → C
  • No redirect loops
  • 404s return 404, not 200 with an error page. Soft 404s waste crawl budget and can be indexed

Stage 3 — Can the content be understood?

Now on-page factors start to matter.

  • Exactly one <h1> per page
  • Heading levels do not skip. h1 → h3 breaks the structural signal
  • Title unique across the site, under about 60 characters
  • Meta description unique, roughly 140–160 characters
  • No two pages targeting the same primary keyword. The cheapest cannibalisation check there is
  • Structured data present and valid for the page type
  • FAQ schema matches visible text word for word. Schema-only FAQs are a manual-action risk
  • Breadcrumb schema matches the visible trail and the URL depth
  • Organization entity referenced by @id, not redefined per page
  • Images have meaningful alt text. Not the filename, not empty on content-bearing images
  • Internal links use descriptive anchor text, not "click here" or a bare URL
  • Language declared with a valid lang attribute
  • Open Graph and Twitter tags complete, with an image that resolves

Stage 4 — Can the page compete?

Everything above is hygiene. This stage decides outcomes.

  • Search intent matches the page type. A commercial query answered with a blog post loses to a service page, and vice versa
  • Content answers the query in the opening paragraph. Answer first, then elaborate
  • Content is genuinely more useful than what currently ranks. If it is not, no technical work will fix that
  • No thin pages. Pages that exist only to hold a keyword now cost more than they earn
  • Every page has three or more inbound internal links, excluding navigation and footer
  • Money pages supported by informational content on the same topic
  • No page competing with a page it should support
  • Publish and update dates visible and honest. A date the content does not justify is a small lie search engines are increasingly able to detect

Stage 5 — Experience and performance

Last, deliberately. This affects close contests, not whether you are in one.

  • Core Web Vitals assessed on field data in Search Console, not lab scores
  • LCP under 2.5s at the 75th percentile
  • CLS under 0.1
  • INP under 200ms
  • Usable on a 320px viewport
  • Tap targets adequately sized and spaced
  • HTTPS everywhere, no mixed content
  • HTML Cache-Control shorter than the deploy cadence. A long s-maxage on HTML means visitors keep seeing a build you replaced
  • Static assets content-hashed and immutable, and old builds retained long enough that cached HTML referencing them does not 404

Those last two are worth checking together rather than separately. We hit exactly that combination on this site — a one-year s-maxage on HTML kept serving a build whose JavaScript chunks had already been deleted, and the write-up of what went wrong and how it was diagnosed covers the commands that finally separated the two problems.

Most teams get through the audit and stall at the point where findings become changes to the site — which is

the remediation work that follows an audit.


How to run it

Test the deployed site, not a dev server. Half of these checks concern headers, caching, redirects and host behaviour that a local server does not have.

Send browser-like headers. A bare curl can be challenged by a WAF and report a broken site that is fine for real visitors.

Cache-bust while diagnosing — then check without. Cache-busting shows you the origin. Checking clean shows you what visitors actually receive. Only checking one of the two is how a stale build serves for a week while every test reports green.

Stop at the first failing stage. Fix, re-crawl, continue. An audit that reports two hundred findings across five stages has not been prioritised; it has been transcribed.

Scoring the findings

Order by dependency stage first, then by blast radius:

PriorityDescription
CriticalStage 1–2 failure affecting multiple pages — blocked, unindexable, or duplicated
HighStage 1–2 affecting single pages, or Stage 3 affecting a template
MediumStage 3 on single pages, Stage 4 findings
LowStage 5 where thresholds already pass

A finding affecting a template is a different class from one affecting a page. One robots directive can outweigh every other item on this list combined, and a category-ordered audit will bury it at position 47.

Working through this list?

Most teams get through the audit and stall on the remediation. That is the part we usually take on.

Key takeaways

  • Audit in dependency order — reachable, then indexable, then understandable, then competitive.
  • A finding at an early stage invalidates everything after it. Fix and re-crawl before continuing.
  • Most audit templates are ordered by category, which is why they produce long lists of low-value fixes.
  • Test against the deployed site with browser-like headers; dev servers and bare curl both lie.
  • Stop at the first stage that fails. That is the finding.
FAQ

Questions about this

Because a failure at an early stage makes later findings meaningless. If a page is blocked in robots.txt, its title tag is irrelevant. Category-ordered templates produce a hundred findings of undifferentiated priority, and the one that matters gets the same weight as a missing meta description.

Related services

More on SEO

TopicsSEO auditTechnical SEOIndexingCrawl budget
Chat with us