How do I do a technical SEO audit?

Work in dependency order rather than by category: indexability first, then crawlability, then canonicalization, then rendering, then performance and on-page structure. Fix each tier completely before moving on, because findings in later tiers are frequently symptoms of problems in earlier ones — and a page that cannot be indexed gains nothing from faster images.

What should a technical SEO audit check?

Robots meta tags and X-Robots-Tag headers, robots.txt rules, HTTP status codes and soft 404s, bot blocking, internal linking depth and orphaned pages, sitemap accuracy, redirect chains, crawl traps, hostname and protocol canonicalization, self-referencing canonicals, duplicate titles and descriptions, the gap between initial HTML and rendered DOM, Core Web Vitals from field data, heading structure, and structured data.

Why does the order of an audit matter?

Because later findings are often meaningless while earlier ones are broken. A site accidentally serving noindex on every product page will produce hundreds of true findings about thin content and slow images, none of which will change anything. Dependency order surfaces the one finding that matters in the first ten minutes instead of the last.

How often should I run a technical SEO audit?

A full audit annually, or after any migration, redesign or CMS change — those are when the high-consequence faults get introduced. Between full audits, monitor the Page indexing report monthly and watch for sudden changes in a status group, since a count that jumped last week points at a change you made last week.

What is the most common serious technical SEO problem?

Accidental de-indexing, usually from a staging configuration reaching production: a noindex tag, an X-Robots-Tag header, or an over-broad robots.txt Disallow. It is the most damaging because it is completely silent — the site looks perfect to every human who visits — and it is the reason indexability is the first tier of an audit rather than a later checklist item.

How do I present audit findings so they get fixed?

Group findings by cause rather than by page, so 4,000 pages missing a canonical is one template fix rather than 4,000 items. State the consequence of each finding, not just the fact of it. And give each recommendation a verification check with a realistic timeframe — days for a URL Inspection live test, weeks for the Page indexing report, a month for field performance data.

How to do a technical SEO audit

Five tiers, each of which makes the next one pointless if skipped — plus how to report findings so someone actually acts on them.

By Max8 min read

A technical SEO audit is a check that search engines can find, fetch, render, understand and prefer your pages — in that order. The order is the whole method. Most audits fail not because they miss a check but because they run the checks in an order where the findings cannot be acted on.

Why order beats coverage

Consider a site where every product page carries noindex from a staging config that shipped to production. A category-by-category audit turns up 340 findings: thin descriptions, missing alt text, slow images, no structured data. All true. All irrelevant, because none of those pages is in the index and none of the fixes changes that.

Dependency order surfaces the one finding that matters in the first ten minutes. That is the difference between an audit and an inventory.

The five tiers, and what each one makes pointless if skipped
Tier	The question	What is wasted if you skip it
1. Indexability	Can this page be in the index at all?	Everything. A noindex page ignores every other fix.
2. Crawlability	Can Google find and reach the page?	Content work on pages nothing links to.
3. Canonicalization	Which URL is the real one?	Optimizing a duplicate that will never be the indexed version.
4. Rendering	Does Google see the content you see?	Auditing content that is not in the rendered DOM.
5. Performance & structure	Is the page fast and legible?	Nothing — but it only pays once 1 to 4 hold.

Tier 1 — Indexability

Four things can keep a page out of the index outright, and all four are binary rather than a matter of degree.

Robots meta tags and X-Robots-Tag headers. Check both — the header is the one people forget, because it is invisible in the page source and set at the server or CDN. A noindex header on a page with no meta tag is a genuinely confusing bug.

robots.txt. Look for over-broad Disallow rules. A single stray line can remove a whole section, and the damage is silent.

HTTP status codes. Every page you want indexed must return 200. Check for soft 404s too — pages returning 200 while saying nothing was found.

Authentication and bot blocking. Verify a page is reachable without a session, and that your firewall or bot protection is not refusing Googlebot. Search Console’s live test is the authority here.

Tier 2 — Crawlability

Now that pages can be indexed, can Google reach them?

Internal linking. Every page you care about should be reachable from the homepage in three clicks or fewer, through real <a href> links. Orphaned pages — reachable only via the sitemap — get crawled but carry no signal of importance.

The sitemap. It should list exactly the canonical, indexable URLs. Redirects, 404s and noindex pages in a sitemap are contradictions, and they are the source of most “Submitted URL…” errors in Search Console.

Redirect chains. One hop maximum. Chains waste crawl and dilute the signals they pass.

Crawl traps. Calendars, filters and parameters that generate unbounded URLs. On a large site this is usually the dominant problem — crawl budget and faceted navigation covers it properly.

Tier 3 — Canonicalization

This tier decides which URL gets the credit, and it is where quiet, expensive mistakes live.

One hostname, one protocol. http/https and www/non-www should all resolve to one canonical form in a single redirect.

Self-referencing canonicals. Every indexable page should declare itself canonical. The classic disaster is a template with a hardcoded canonical pointing at the homepage on every page — the site looks perfect and tells Google it has one page.

Signal agreement. Canonical tags are hints weighed against internal links, sitemap entries and redirects. If those point elsewhere, Google overrides the tag — which is exactly what “Google chose different canonical than user” means in the Page indexing report.

Duplicate titles and descriptions. Not a canonical problem in themselves, but a reliable symptom of one, and the cheapest way to find duplicate templates at scale.

Tier 4 — Rendering

Compare the initial HTML against the rendered DOM. If your content, navigation, canonical or structured data only exists after JavaScript runs, it depends on a rendering queue that is neither immediate nor guaranteed. Use Search Console’s “View crawled page” rather than your browser — JavaScript SEO and rendering explains why the difference matters and how the failures present.

Tier 5 — Performance and structure

Only now is this worth measuring, and only with field data first.

Core Web Vitals — LCP, INP and CLS at the 75th percentile, from real users. Test the templates that receive search traffic, not the homepage. Diagnosing slow page speed covers the method; a slow server needs a separate approach.

On-page structure — one <h1> per page, a heading hierarchy that does not skip levels, descriptive alt text, unique titles under about 60 characters and descriptions under about 160.

Structured data — Organization and WebSite once, BreadcrumbList everywhere, Article or Product where they apply. See what is schema markup, and note two types not to bother with: HowTo, whose rich results Google removed in 2023, and FAQPage, retired for all sites in May 2026.

HTTPS and mixed content — a valid certificate, no HTTP subresources on HTTPS pages.

Reporting it so someone acts on it

An audit that lists 200 findings gets read once and filed. Three things make the difference.

Group by cause, not by page. “All 4,000 product pages lack a canonical, one template change” is one finding, not 4,000.

State the consequence. Not “missing meta description” but “Google is generating snippets for these pages, so you have no control over how they appear.” Findings without stated consequences get deprioritized, correctly.

Say how you would know it failed. Every recommendation should come with the check that proves it worked and a realistic timeframe — days for the URL Inspection live test, weeks for the Page indexing report, a month for field performance data.

Running the first three tiers now

Our free site check covers most of tiers 1 to 3 across your pages in one pass — indexability, status codes, canonical coherence, duplicate titles and descriptions, sitemap and robots.txt problems — which is the part of an audit that is mechanical and the part where the highest-consequence findings hide. For individual checks, the indexability checker, robots.txt checker and duplicate content checker map onto tiers 1 to 3 directly. If your site runs to tens of thousands of URLs, auditing a large website covers the sampling and prioritization this method needs at that scale.

Frequently asked questions

How do I do a technical SEO audit?: Work in dependency order rather than by category: indexability first, then crawlability, then canonicalization, then rendering, then performance and on-page structure. Fix each tier completely before moving on, because findings in later tiers are frequently symptoms of problems in earlier ones — and a page that cannot be indexed gains nothing from faster images.
What should a technical SEO audit check?: Robots meta tags and X-Robots-Tag headers, robots.txt rules, HTTP status codes and soft 404s, bot blocking, internal linking depth and orphaned pages, sitemap accuracy, redirect chains, crawl traps, hostname and protocol canonicalization, self-referencing canonicals, duplicate titles and descriptions, the gap between initial HTML and rendered DOM, Core Web Vitals from field data, heading structure, and structured data.
Why does the order of an audit matter?: Because later findings are often meaningless while earlier ones are broken. A site accidentally serving noindex on every product page will produce hundreds of true findings about thin content and slow images, none of which will change anything. Dependency order surfaces the one finding that matters in the first ten minutes instead of the last.
How often should I run a technical SEO audit?: A full audit annually, or after any migration, redesign or CMS change — those are when the high-consequence faults get introduced. Between full audits, monitor the Page indexing report monthly and watch for sudden changes in a status group, since a count that jumped last week points at a change you made last week.
What is the most common serious technical SEO problem?: Accidental de-indexing, usually from a staging configuration reaching production: a noindex tag, an X-Robots-Tag header, or an over-broad robots.txt Disallow. It is the most damaging because it is completely silent — the site looks perfect to every human who visits — and it is the reason indexability is the first tier of an audit rather than a later checklist item.
How do I present audit findings so they get fixed?: Group findings by cause rather than by page, so 4,000 pages missing a canonical is one template fix rather than 4,000 items. State the consequence of each finding, not just the fact of it. And give each recommendation a verification check with a realistic timeframe — days for a URL Inspection live test, weeks for the Page indexing report, a month for field performance data.