A Complete Technical SEO Audit Checklist, Step by Step

the first time i ran a proper technical audit on a site i actually cared about, i found 4,000 urls nobody had asked for. filter pages, session ids, a whole calendar archive that looped forever. the site had been quietly leaking crawl budget for years and nobody noticed because traffic looked fine on the surface. that is the thing about technical seo. it rarely announces itself. it just sits there, taking a small bite out of everything else you do, until someone opens a crawl report at 7am with a cup of rooibos going cold next to the keyboard.

this guide is the checklist i wish i had then. it covers the stuff that actually decides whether search engines can find, render, index and rank your pages. it is not a list of every possible tweak, because nobody needs that. it is an order of operations. start with access, move to indexing, then speed, then architecture, then the messy structured data layer. and where a finding is worth more context, i will point you to the longer pieces on this site, including our broader walkthrough of site health and visibility.

Why the Basics Still Decide Everything

search has changed a lot in the last few years. ai overviews, answer engines, shopping carousels, video blocks. but the pipeline underneath has not changed much. a crawler has to reach a url, fetch it, render what is needed, decide whether it deserves to be indexed, and then rank it against everything else. if any stage breaks, the content above it is invisible no matter how good it is.

the reason technical audits keep getting skipped is that they feel boring. nobody screenshots a robots.txt file. but the sites that lose the most organic traffic after a migration or a redesign almost always lose it at one of these early stages. a staging directive gets copied to production. a noindex tag sits in a template. a canonical points at the homepage for every article. these are not subtle problems. they are just easy to miss when nobody is looking at the plumbing.

a technical audit is not a score. it is a list of places where the machine stopped understanding your site, ranked by how much traffic that stop is costing you.

so treat the checklist below as a diagnostic, not a trophy cabinet. fix the things that block access first, even if they are ugly. the speed tweaks can wait a week. the schema can wait a month.

Stage One: Access and Crawlability

start with what a crawler is allowed to touch. open your robots.txt file and read it like a stranger would. check that you are not disallowing directories that contain css, javascript or images needed for rendering. check for a stray disallow: / line, which sounds absurd until you see how often it survives a launch.

next, confirm that your xml sitemaps list only canonical, indexable, 200-status urls. a sitemap full of redirects and noindexed pages is a contradiction you are asking the crawler to resolve on its own. google's documentation sets the practical limits per sitemap at 50,000 urls or 50mb uncompressed, so large sites should use a sitemap index. then submit the sitemap through google search console and watch the coverage numbers over the next few crawl cycles rather than the day you upload it.

the most useful single check in this stage is a full crawl with a tool like screaming frog, sitebulb or an equivalent, configured to respect robots.txt the way a search engine would. compare what the crawler finds against what your sitemap claims exists. the gap between those two lists is where most crawl waste hides.

A Quick Access Checklist

• robots.txt does not block css, js or image paths needed for rendering
• no accidental site-wide noindex or x-robots-tag headers on live templates
• sitemap contains only indexable, canonical, 200-status urls
• sitemap is referenced in robots.txt and submitted in search console
• server returns consistent status codes, with no soft 404s on empty product or search pages
• internal links do not point at urls that redirect or return errors

Stage Two: Indexing, Canonicals and Duplication

once a page is reachable, the next question is whether search engines should keep it. this is where duplication does its damage. parameter urls, faceted navigation, printer-friendly versions, trailing slash variants, http and https pairs that both resolve, and www and non-www versions all compete for the same signal.

canonical tags are the usual fix, but they are a hint rather than a command. check that each canonical points at a live, indexable version of the same content, and that it is self-referencing on pages that have no duplicates. a common failure is a canonical chain, where page a points to b, and b points to c. another is a canonical pointing at a page that is itself noindexed, which sends mixed signals that the engine has to untangle.

redirects deserve their own pass. look for redirect chains longer than one hop, because each extra hop costs time and sometimes loses signal. look for redirect loops, which are rarer but catastrophic. and make sure permanent moves use 301s rather than 302s when the move is meant to be permanent. the audit should output a clean map: old url, final url, status code, and the date the change went live.

finally, check the index itself. run site: queries as a rough sanity check, but do not treat them as data. the coverage and indexing reports in search console are the real source. a growing count of "discovered, currently not indexed" urls usually means the engine has found your pages and decided they are not worth the storage yet. that is a quality and architecture signal, not a bug to patch with more sitemaps.

Stage Three: Core Web Vitals and Rendering

speed is no longer a tiebreaker you can ignore, but it is also not the magic lever some vendors pretend. google measures core web vitals through field data from real users, and the thresholds are specific. largest contentful paint should be under 2.5 seconds at the 75th percentile. interaction to next paint should be under 200 milliseconds. cumulative layout shift should be under 0.1. interaction to next paint replaced first input delay as the responsiveness metric in march 2024, which is still a common source of outdated audit advice.

the audit approach here has two layers. first, pull the field data from search console and the chrome user experience report to see which url groups are failing in the real world. second, run lab tests on representative templates to diagnose why. a product template that fails lcp because of an unoptimised hero image is a very different job from a blog template that fails cls because an ad slot loads late.

rendering is the quieter problem. if your content depends on client-side javascript, check what the crawler sees before and after rendering. compare the raw html with the rendered dom. if the headings, body copy, internal links or structured data only appear after rendering, you are relying on the engine's second wave of processing, which is generally reliable but not instant. for critical content, server-side rendering or static generation removes that dependency entirely.

What to Measure, and Where

1. pull 28-day field data for each major template from search console's core web vitals report
2. run lab audits on the slowest template in each group and record the largest single bottleneck
3. compare raw html against rendered output for three representative urls per template
4. log third-party scripts and remove any that do not earn their load cost
5. retest after each release, not once at the start of the project

Stage Four: Architecture, Internal Links and Crawl Depth

architecture is where technical seo meets content strategy, and it is where audits tend to get the most interesting. a flat site where important pages sit three or four clicks from the homepage will struggle, no matter how fast it loads. a deep site where a hundred thousand urls hang off a single pagination chain is asking the crawler to give up.

measure click depth from the homepage for every indexable url. most sites have a cluster of valuable pages that sit deeper than they should, usually because they were added through a campaign and never linked from the main navigation or hub pages. fix that with contextual internal links from relevant, already-authoritative pages. anchor text should describe the destination in plain language, not stuff a keyword in every link.

orphan pages are the other classic finding. these are urls that exist in the sitemap or analytics but have no internal links pointing at them. log file analysis, if you can access server logs, is the cleanest way to see what crawlers actually request versus what you think they request. it often reveals that googlebot is spending serious time on archive pages, parameter urls or old faceted combinations that nobody wanted indexed.

for editorial sites, this is also where cross-linking earns its keep. when we audit content libraries, related guides matter. the same logic applies to any site with a lot of similar intent. if you are auditing a publication, the companion pieces such as this look at common mistakes in audit checklists are worth linking from the most relevant hubs, because those links tell both readers and crawlers where the topic clusters live.

Stage Five: Structured Data and On-Page Technical Signals

structured data is the layer where people most often over-invest for the wrong reasons. schema markup helps engines understand entities, page types and eligibility for rich results. it does not, by itself, make a weak page rank. the audit question is simple: does the markup match the visible content, is it valid, and does the page qualify for the rich result type it claims?

run the rich results test and the schema validator on representative templates. check for mismatches, such as product markup on pages without visible prices or faq markup on pages with no visible questions. google has tightened enforcement around misleading markup over the years, and the penalty risk is real even when the intent was innocent.

on-page technical signals are the last stop. check title tags and meta descriptions for duplication across templates, missing or multiple h1 elements, hreflang annotations that point at non-reciprocal pairs, and open graph tags that break social previews. none of these are dramatic on their own. together they describe whether a page has been built carefully or assembled from a theme and forgotten.

if you can explain every piece of structured data on a page to a human editor, and they agree it describes what is visibly there, you are probably safe. if you cannot, the markup is working against you.

What Changed in 2026, and What to Watch

the biggest shift in the last year has been the growing share of search surfaces that summarise rather than list. reports suggest click-through patterns have moved noticeably on informational queries where ai-generated summaries appear, while transactional and local queries have held up better. for technical audits, this changes priorities in two ways. first, being crawlable and well structured matters more, because summarisation systems depend on clean, accessible source content. second, the value of being the page that answers a specific question clearly, with unambiguous headings and direct statements, has gone up.

the second change is the rise of log-based and server-side monitoring as standard practice rather than an enterprise luxury. more teams now track crawler behaviour continuously, which means audit findings can be verified in weeks rather than quarters. the third is the normalisation of javascript-heavy frameworks, which has made rendering checks a permanent part of the audit rather than a one-off investigation.

industry commentary on these shifts is still evolving, and i would be cautious about any vendor who claims a precise percentage impact from a single fix. the honest position is that technical health is a prerequisite, not a guarantee. you can have a perfect site and still lose to a better answer. you cannot have a broken site and expect the better answer to be seen at all.

A Practical Order of Operations

if you only have one afternoon, do these things in this order. confirm robots.txt and sitemap health. check the index coverage report for a sudden drop or spike. run a crawl and compare it to the sitemap. look at the top ten templates by traffic and check their status codes, canonicals and render output. then check field core web vitals for those templates. everything else can wait for the second pass.

if you have a week, add click depth analysis, log file review, redirect mapping and structured data validation. write the findings in a format a developer can act on without a meeting. every finding should name the url pattern, the evidence, the expected fix and the traffic at risk. audits that read like essays get filed. audits that read like tickets get done.

and set a schedule. technical seo is not a project you finish. it is a maintenance habit, closer to checking the library calendar for due dates than to a one-time renovation. the sites that stay healthy are the ones where someone looks at the crawl report every month, even when nothing looks wrong. that is usually when the quiet problems are easiest to catch.