The Technical SEO Audit Checklist for 2026

Every page you publish depends on a chain of machine decisions you never see: can the page be fetched, does it render into something readable, is it kept in the index, is it understood, and does it load fast enough to count. A technical audit checks each link in that chain. When one link is broken, everything published above it is quietly lost.

This checklist is the one we run at the start of every engagement. It is organised in the order that matters — crawlability before indexation, indexation before rendering, and so on — because a fault lower in the chain makes the checks above it meaningless. Each item states what to look at, what good looks like and how to confirm the fix. You can run the whole thing in a working week with free tools and a crawler.

Why a technical audit comes before content

It is tempting to start an organic programme by writing. Writing is visible, it feels productive and it is easy to buy. But content only counts if the systems that read it can reach it, render it, keep it and understand it. Those four conditions are technical, and they are checked by machines long before any human reads a word.

In the businesses we have worked with, the ceiling on organic growth was more often technical than editorial. Pages that were never indexed, pages that competed with their own duplicates, product listings that only existed in the browser after a script ran — none of these problems are solved by publishing more. They are solved by finding the fault, fixing it at the template level and proving the fix. The reasoning is set out in our essay on the commercial cost of technical debt; this guide is the practical version.

What you need before you start

A useful audit needs five sources of evidence. Tool brands do not matter much; what matters is that you have each kind of evidence and that you compare them. A crawler tells you what *could* be found; Search Console tells you what Google *did* with it; server logs tell you what bots *actually* requested.

You also need two lists from the business: the pages that make money (products, services, category pages, key landing pages) and the pages that are meant to be excluded (internal search, filters, admin, staging). Without those two lists you cannot tell a healthy exclusion from a damaging one.

1. Crawlability — can bots reach every page that matters?

Crawlability is whether a search engine can request your pages and receive them. It sounds trivial and is failed constantly, usually by a rule written for a different purpose: a robots directive from a staging environment, a firewall that challenges bots, or a navigation built entirely from JavaScript events.

• robots.txt exists, returns 200, and disallows only what should be disallowed. Check that it does not block CSS, JavaScript or image paths that pages need in order to render.
• XML sitemaps list only canonical, indexable, 200 URLs; are referenced in robots.txt; are under 50,000 URLs and 50 MB each; and carry accurate lastmod dates. A sitemap full of redirects or noindex pages teaches the crawler to distrust it.
• Status codes are honest: 200 for live pages, 301/308 for moved pages, 404 or 410 for gone pages. No soft 404s (a ‘not found’ message served with a 200).
• Redirect chains and loops are eliminated. One hop, not three. Chains waste crawl budget and leak link equity at every step.
• Bot protection (CDN firewalls, rate limiting, JavaScript challenges) allows verified search-engine crawlers. Check the logs for 403 and 429 responses to Googlebot and Bingbot.
• Internal links are real <a href> elements. Links that only work via onclick handlers or form submissions are invisible to crawlers.
• Crawl waste is under control: faceted navigation, calendar pages, session parameters and infinite scroll are not generating millions of near-identical URLs.

How to verify: compare the sitemap URL list with the crawler’s discovered URL list and with Search Console’s indexed URL list. The three sets should be nearly identical. Where they diverge, you have found either a crawl gap or crawl waste.

2. Indexation — is the right set of pages in the index?

Indexation is whether a crawled page is kept and made eligible to appear. The Search Console Pages report lists every reason a URL was excluded. Reading each reason and deciding whether it is healthy or harmful is the heart of the audit.

• Every money page returns 200, is indexable, declares a self-referencing canonical, and is the URL that internal links point to.
• No noindex on templates that serve valuable pages — check category, product, article and pagination templates individually.
• rel=canonical is absolute, points at a 200 URL, and is consistent between the HTML and any HTTP header.
• Parameterised, uppercase, trailing-slash and http versions all resolve to one canonical form with a single redirect.
• Pagination pages are crawlable and indexable (or deliberately noindexed with a stated reason), and page 2+ does not canonicalise to page 1.
• Search-engine-facing copies of the site (staging, preview, CDN test hostnames) are not indexable.

How to verify: URL-inspect ten money pages in Search Console. Each should show ‘URL is on Google’, the canonical you intended, and a recent crawl date. Then export the Pages report and classify every excluded URL as healthy, harmful or unknown.

3. Rendering — does the content exist after JavaScript runs?

Modern sites often deliver an empty shell and build the page in the browser. Search engines can execute JavaScript, but rendering is queued, costly and not guaranteed for every URL. Anything that matters — titles, headings, body copy, links, structured data, canonicals — should be present in the HTML the server sends.

• Compare the raw HTML (view source) with the rendered DOM (developer tools) for each template. Main content, navigation links and metadata should be in both.
• Server-side rendering, static generation or pre-rendering is in place for indexable templates. Client-only rendering is reserved for interactive, non-indexable states.
• Canonicals, noindex and hreflang are not injected by client-side scripts that can fail or run late.
• JavaScript errors in the console do not prevent the main content from rendering.
• Lazy-loaded content that should be indexed (product grids, article bodies) loads without user interaction.
• Search Console’s URL Inspection Test live URL shows the rendered HTML with the content present and no blocked resources.

4. Architecture and internal links

Architecture decides where crawl attention and authority go. A page that is four clicks deep with one incoming link will be crawled rarely and ranked weakly, whatever its content. The audit asks whether the structure of the site reflects the structure of the business — the argument made in The Architecture of Organic Growth.

Click depth

• Money pages are reachable within three clicks of the home page. Use the crawler’s depth report and sort by commercial value.
• Category and hub pages link to everything beneath them without relying on ‘load more’ interactions.

Orphans and dead ends

• No indexable page has zero internal links pointing at it (compare sitemap URLs with the crawl).
• No indexable page has zero outgoing internal links.
• Broken internal links (404) and links to redirects are fixed at source, not just tolerated.

Faceted navigation and filters

• Filter combinations that have search demand are indexable, static URLs with unique content; everything else is canonicalised, noindexed or kept out of the crawl.
• Sort orders, view modes and session parameters never create indexable URLs.

Anchor text and link placement

• Anchor text describes the destination (‘technical SEO services’, not ‘click here’).
• Key pages receive links from body copy, not only from navigation and footers.
• Breadcrumbs are present, consistent with the hierarchy, and marked up with BreadcrumbList.

5. Performance and Core Web Vitals

Performance is a ranking signal, a conversion factor and a crawl-efficiency factor. Google assesses it with three Core Web Vitals, measured on real users over the previous 28 days. Lab tools help you find causes; only field data tells you whether you pass.

• The Search Console Core Web Vitals report shows no ‘Poor’ URL groups on mobile for money templates.
• The LCP element is server-rendered, not lazy-loaded, and its image is sized, compressed and preloaded where appropriate.
• Fonts are subset, limited to the weights actually used, and loaded with font-display: swap or an equivalent that avoids invisible text.
• Third-party scripts (tags, chat widgets, consent tools) are loaded after the main content, and each one has an owner who can justify it.
• Images and embeds carry explicit dimensions so nothing shifts when they load.
• Long JavaScript tasks are split or deferred; total blocking time on the main templates is under control.
• Caching headers and a CDN serve static assets; HTML responds quickly (server response time under roughly 600 ms is a reasonable target).

6. Structured data and entity clarity

Structured data tells machines what a page *is* — an organisation, a product, an article, a set of questions — and connects it to entities elsewhere. It earns rich results in search and, increasingly, it helps answer engines parse and attribute your content, which we cover in How to Get Cited by AI Answer Engines.

• An Organization (or the relevant subtype) is declared once, site-wide, with a stable @id, name, logo, URL and sameAs links to the profiles that describe the company elsewhere.
• Each template declares the type that matches its content: Product with offers and availability, Article with author and dates, Service, FAQPage, BreadcrumbList.
• Every property in the markup is visible on the page. Marking up content the user cannot see is a spam-policy risk.
• Markup validates in the Rich Results Test and the Schema Markup Validator with no errors; warnings are reviewed, not ignored.
• Search Console’s enhancement reports show no invalid items for the templates that matter.
• Names, addresses, product names and prices in the markup match the visible page and the rest of the web.

7. International and language versions

If you serve more than one language or market, the audit must check that each version is discoverable, distinguishable and correctly related. Hreflang faults are common because they are easy to get half right.

• Each language or market version lives at its own crawlable URL (subdirectory, subdomain or ccTLD) — never behind a cookie, IP detection or a JavaScript switch alone.
• hreflang annotations are reciprocal (every version lists every other version, including itself) and use valid language-region codes.
• An x-default is declared for the fallback or language-selector page.
• Hreflang targets are canonical, indexable 200 URLs — not redirects, not noindexed pages.
• Automatic redirection by IP or browser language does not prevent crawlers from reaching every version.
• Content is genuinely localised for the market, not machine-translated word for word; search demand and terminology differ by country.

8. Security, redirects and hygiene

• The whole site is served over HTTPS, http:// redirects to https:// in one hop, and there is no mixed content.
• One hostname is canonical (www or not); the other redirects permanently.
• Security headers are set (Strict-Transport-Security, Content-Security-Policy or at least X-Content-Type-Options and Referrer-Policy).
• Titles are unique and descriptive per page; meta descriptions exist for money pages; no template leaves them empty.
• One <h1> per page that describes the page; headings form a sensible outline.
• Images have descriptive alt text where they carry meaning.
• Custom 404 page returns a real 404 status and links back into the site.
• Legacy URLs from previous designs or domains still redirect to their current equivalents.
• No accidental indexable duplicates of the site (mirrors, CDN hostnames, print versions, AMP leftovers).

Prioritising: what to fix first

Crawlers produce long lists. The audit’s job is to turn the list into a short, ordered backlog. Rank each finding by the number of pages it affects, the commercial value of those pages and the effort to fix it. Template-level faults on money pages come first; page-level warnings on utility pages come last or never.

1. 01

   Day 1 — Evidence

   Export the Search Console Pages, Sitemaps and Core Web Vitals reports. Run a full crawl with JavaScript rendering enabled. Pull the last 30 days of bot requests from the logs.

2. 02

   Day 2 — Crawlability and indexation

   Classify every excluded URL. URL-inspect the top money pages. Check robots.txt, sitemaps, canonicals and status codes against the checklist above.

3. 03

   Day 3 — Rendering and architecture

   Compare raw and rendered HTML per template. Map click depth, orphans and internal link counts for money pages.

4. 04

   Day 4 — Performance, structured data and international

   Review field data by template. Validate markup. Check hreflang reciprocity if applicable.

5. 05

   Day 5 — Backlog and proof plan

   Write the prioritised backlog. For each item, state the template, the fix, the owner and the evidence that will prove it worked.

How often to audit

A full audit belongs at the start of an engagement, before any migration or redesign, and annually thereafter. Between full audits, a lighter monitor is enough: the Search Console Pages and Core Web Vitals reports reviewed monthly, a crawl of the money templates after every release, and an alert on any change to robots.txt, sitemaps or the noindex state of key templates.

The most damaging technical faults we see are introduced by releases — a rebuilt template, a new framework version, a plugin update — rather than by slow decay. Treating a technical check as part of the release process costs a few minutes and prevents most of them. If you are planning a replatform, read Website Migration Without Losing Organic Traffic before you start.

The bottom line

• A technical audit checks the chain of machine decisions between your codebase and the index: fetch, render, keep, understand, load. Work through it in that order.
• Start from Search Console’s Pages report and classify every exclusion as healthy or harmful before running anything else.
• Fix at the template level, prioritise by pages affected × commercial value, and record the evidence that will prove each fix.
• Pass Core Web Vitals on field data, by template, on mobile.
• Re-run the full audit before any migration and once a year; monitor monthly and after every release in between.

Frequently asked questions

How long does a technical SEO audit take?

For a site of a few hundred to a few thousand pages, a thorough audit takes about a working week using the day-by-day plan above. Very large sites (hundreds of thousands of URLs) take longer because crawl waste and log analysis dominate, but the method is the same.

Which free tools are enough to run this audit?

Google Search Console, Bing Webmaster Tools, PageSpeed Insights, the Rich Results Test and a browser’s developer tools cover most of it. A crawler with a free tier (Screaming Frog crawls 500 URLs free) covers the rest for small sites. Server logs come from your hosting or CDN.

How do I know if a fix worked?

Define the proof before you make the change. For indexation faults, use URL Inspection and the Pages report after a recrawl. For rendering, compare raw and rendered HTML again. For performance, watch the 28-day field data for the affected template. For architecture, re-crawl and compare depth and link counts.

Should I request indexing for every page after fixing something?

No. Manual indexing requests are rate-limited and are best reserved for a small number of high-value new or changed pages. For everything else, an accurate sitemap with updated lastmod dates and good internal links is faster and more reliable.

Does a technical audit cover content quality?

Only at the edges — thin or duplicate pages show up as indexation faults. Content quality, intent match and information architecture are a separate review; our Content & Information Architecture work covers that side.

What is the single most common expensive fault?

A noindex or a wrong canonical on a template that also serves money pages, usually left over from a staging environment or a redesign. It is invisible to users, easy to introduce, and it removes whole sections of a site from search at once.

How this guide was put together

• The checklist is the one used at the start of Lucidens engagements, refined across ground-up builds and existing sites. Thresholds and exclusion reasons are taken from Google’s public documentation, linked below.
• The example in the rendering section is anonymised from practice; it describes a pattern, not a named client result.

Sources

1. Google Search Central — Robots.txt introduction and guide
2. Google Search Central — Consolidate duplicate URLs (canonicalisation)
3. Google Search Central — JavaScript SEO basics
4. Google Search Central — Page indexing report
5. Google Search Central — Core Web Vitals and Google Search results
6. web.dev — Web Vitals
7. Google Search Central — Managing multi-regional and multilingual sites
8. Google Search Central — Structured data general guidelines
9. Lucidens — Technical SEO service