Technical SEO Audit: The Complete Checklist and Method

A technical SEO audit checks that a search engine can access your pages, understand them and serve them fast. It judges neither your content nor your authority: it makes sure the rest of the work pays off. It is the audit that should come first, because a technical problem cancels out everything that comes after it.

Here is the checklist I use, in the order I work through it, with the free tool for each check, what deserves your time and what can wait.

What is a technical SEO audit?

It is the diagnosis of the part of SEO that depends neither on what you write nor on who talks about you. It answers three questions in this order: can a search engine access your pages, can it understand them and place them in relation to each other, can it serve them fast enough for the visitor to stay.

The distinction from a content audit and an authority audit is not academic, it is operational. A technical audit is fixed with a developer and verified objectively. A content audit is fixed with a writer and judged by results. Mixing the two produces a forty-page document nobody acts on. The technical audit is therefore one block of a full SEO audit, and I walked through an SEO audit report example part by part.

Why do a technical SEO audit?

For a simple reason that is often learned too late: technical problems cancel out the rest of the work. An excellent article on a non-indexed page earns nothing. An editorial overhaul on a site where half the pages cannibalize each other earns nothing either. These are multiplications by zero, and no content budget makes up for them.

The second reason is financial. Technical fixes are finite: one developer, a few days, a verifiable result. Content is an ongoing investment. Starting with the technical side sets a performance floor before you open the tap on recurring spend.

On the sites I audit, the gap between potential and results comes down, in most cases, to three technical problems, not thirty. The work is mostly about finding them.

Technical SEO audit checklist: the 30 points

Four blocks, in this order. The order matters: each block conditions the next one. In parentheses, the free tool used for the check. Points marked as blockers come before everything else.

1. Access and indexing: 10 points

This is where the most expensive problems, and the easiest to miss, are found. Read the Search Console Page indexing report in full: excluded pages tell you more than valid pages, because every exclusion reason reflects a decision, yours or Google's.

1. No strategic page appears among the non-indexed pages, and every exclusion reason is explained (Search Console, Page indexing).
2. robots.txt does not block any useful section, nor the CSS and JavaScript files needed for rendering (Search Console, robots.txt report). Blocker.
3. No page meant to be indexed carries a noindex tag or an X-Robots-Tag header (crawler). Blocker.
4. Every page meant to be indexed has a self-referencing canonical; no canonical points to the homepage or to an error page (crawler).
5. The XML sitemap contains only URLs returning a 200 code, indexable and canonical, and it is submitted in Search Console.
6. The site responds over HTTPS on a single version of the domain; the other versions 301-redirect.
7. No internal link points to a page returning a 4xx or 5xx error (crawler).
8. Every redirect leads straight to its final destination, in a single hop (crawler).
9. The main content is in the raw HTML, without JavaScript execution (browser, view page source).
10. The AI crawlers you want to let in (OAI-SearchBot, GPTBot, ClaudeBot) are not blocked by mistake in robots.txt.

Point 9 matters twice as much since answer engines arrived. Google executes JavaScript, with a delay. AI crawlers are less patient: according to an analysis published by Vercel in late 2024, none of the major AI crawlers, including GPTBot and ClaudeBot, executed the JavaScript of the pages they visited. Text loaded by a script is therefore likely to be invisible to them.

2. Structure and internal linking: 7 points

Once pages are accessible, the question becomes: does the search engine understand how they are organized? Internal linking is the most underused lever in technical SEO. It costs nothing, it can be fixed without a developer in most cases, and it redistributes the authority you already have toward the pages that need it.

11. Strategic pages are three clicks or fewer from the homepage (crawler, click depth).
12. No important page is orphaned, without an internal link pointing to it (crawler cross-checked with the sitemap and Search Console). Blocker.
13. URL parameters (sorting, filters, campaign tracking) do not create thousands of crawlable addresses (crawler).
14. Paginated pages are reachable through real links and do not duplicate the introductory text.
15. No two pages target the same query (Search Console: filter by query, then the Pages tab).
16. Internal links are real HTML links, with descriptive anchors.
17. The breadcrumb is present and marked up.

3. Performance and rendering: 7 points

Core Web Vitals measure three things: how fast the main content displays (LCP), how responsive the page is to interactions (INP) and visual stability while loading (CLS). I will be honest about their weight: when content quality is very uneven, performance does not turn anything around. When content is comparable, it breaks the tie. And above all, it directly affects conversion, regardless of any ranking. That is the argument that unlocks budgets, not the SEO argument.

18. LCP under 2.5 seconds on real-user data (PageSpeed Insights, Search Console Core Web Vitals report).
19. INP under 200 milliseconds.
20. CLS under 0.1.
21. Images in AVIF or WebP, at the displayed size, with width and height declared.
22. Third-party scripts (chat, ads, tracking) are deferred.
23. The mobile version has the same content and links as the desktop version, since Google indexes the mobile version.
24. The server responds fast and without 5xx errors (Search Console, Settings, Crawl stats).

Look at real-user data rather than lab tests. A synthetic test on a perfect connection says little about what your visitors experience on mobile over a patchy 4G connection.

4. Markup and structured data: 6 points

These are fundamentals, they can be checked in bulk with a crawler, and getting them wrong costs more than it seems on large catalogs.

25. Every page has a unique title tag.
26. Every page has a hand-written meta description.
27. A single H1 per page, and a heading hierarchy with no skipped levels.
28. Meaningful images have an alt attribute.
29. Structured data is valid and describes the visible content (Rich Results Test).
30. hreflang tags are reciprocal, if the site exists in several languages.

Structured data does not push a page up, but it explicitly tells a machine what it is looking at: an article, its author, its date, a product and its price. Do not always expect a rich result from it: since August 2023, Google only shows FAQ rich results for well-known, authoritative government and health websites. Markup is still useful for understanding the page, by Google as well as by answer engines.

Now tick the problems you found. The tool re-ranks them by real impact, which is almost never the order of the report your crawler gave you.

Which tools do you need for a technical SEO audit?

Three tools are enough, and they all have a free version. The full list, with the limits of each free version, is in my comparison of free SEO audit tools.

Search Console is the only source that tells you what Google really sees of your site, and no paid tool replaces it. The crawler produces the exhaustive view Search Console does not give: depth, redirects, duplication, broken links. PageSpeed Insights measures Core Web Vitals on real visits over the last 28 days.

The move that pays off most is in none of the three: it is the cross-check. Export the pages crawled by the crawler, export the pages that get impressions in Search Console, and compare the two lists. Whatever is in the first and not in the second is your debt: pages that consume crawl budget and earn nothing.

Can AI do a technical SEO audit?

Not on its own. An assistant like ChatGPT or Claude can see neither your Search Console nor all of your pages, and it does not crawl a site reliably. It does, however, read an export very well: give it a crawl file and it pulls out a first list of problems grouped by template, in a few minutes. The Screaming Frog MCP goes further by connecting Claude directly to your crawls.

Prioritizing and verifying remain human work. A model can get the cause of an exclusion wrong or suggest a fix that breaks something else. I use it to save time on data collection, never to decide the order of fixes.

How to prioritize the fixes

An audit is useless if it produces a list. It is useful when it produces an order.

My prioritization rule fits in one sentence: rank by number of URLs affected multiplied by severity, never by the severity shown in the tool. A crawler flags a missing tag on one page in red and a wrong canonical on eight hundred pages in orange. The second problem is worth a hundred times the first.

Next, record your baseline before fixing anything: rankings, indexed pages, impressions. Without that starting point, you will not be able to prove any result, and it is the first question you will be asked.

Finally, work in batches rather than problem by problem. Fixing eight hundred tags in one pass costs barely more than fixing ten, and leaves a clear mark on the graphs three to six weeks later.

Once the technical side is clean, the next project is editorial: that is where the rest is decided, and I describe it in my SEO content strategy method.

The six technical problems I find most often

After enough audits, the same causes keep coming back. Here they are, with what triggers them, because recognizing the pattern saves hours.

The canonical that points to the homepage. A developer puts a global canonical tag in the template, without a variable. Every page then declares the homepage as its reference version. The site loses most of its indexing at once, and nothing in the interface shows it. It is the most brutal problem I come across, and the quietest.

The block inherited from staging. A robots.txt file written to keep a test environment out of the index goes to production with everything else. The site is live, good-looking, and invisible. The check takes ten seconds and nobody does it.

Poorly handled pagination. On a catalog, pages two, three and beyond often contain the same introductory text. Depending on how they are declared, they cannibalize each other or waste crawl budget for nothing.

URL parameters. Filters, sorting, campaign tracking: each combination creates a different address for identical content. An online store quickly reaches tens of thousands of URLs that dilute everything.

Cascading redirects. One redesign redirects A to B, another B to C, a third C to D. Each hop slows crawling and loses a little of the value passed on. A redirect should always point straight to the final destination.

Content loaded after the fact. When the main text only appears after a script runs, the search engine sometimes sees an empty page, and AI crawlers usually do. The test is simple: view the raw source of the page and look for your text. If it is not there, you have found your problem.

The special case of a migration

It is the moment when the most things break, and the one where a technical audit makes the biggest difference. I handle it in three stages.

Before. Record the exact state of the current site: full list of URLs, rankings, indexed pages, pages that get traffic. Without this inventory, you will not know what you lost, and you will not be able to recover it. This snapshot is the most important deliverable of the whole migration.

During. Build the redirect plan URL by URL, not with a global rule. A generic rule that sends an entire old folder to a new category page destroys the value each page has built up. Every old address should point to its closest equivalent, with a single permanent redirect.

After. For six weeks, monitor crawl errors, newly excluded pages and the rankings of the twenty most strategic pages. Migration problems rarely show up on day one: they surface once the search engine has finished recrawling, often three to four weeks later.

A traffic dip after a migration is normal for a few weeks. A dip that has not recovered after two months is a technical problem, almost never a content problem.

How often should you do a technical SEO audit?

Twice a year on a stable site, once a quarter on a site that publishes a lot or changes technically. And always after a redesign, a migration or a platform change, because those are the three moments when the most things break without anyone noticing.

Between two full audits, a 20-minute monthly check is enough: new crawl errors, newly excluded pages, performance drops. That regular check is what keeps you from discovering, six months later, a problem that has been there for five.

Technical audit alone or full SEO audit?

A technical audit is enough when the doubt is about indexing, a migration or speed. If the site is technically sound and traffic is flat, the problem is elsewhere: content, competition or authority, and a full audit will tell you which. For a business that lives on local customers, add the Google Business Profile side with my local SEO audit checklist.

If you would rather delegate, what drives the price of an SEO audit is detailed in a dedicated article. My SEO audit covers this technical block, with an action plan ranked by impact, quoted on request.

Written by

Anthony Courtin

SEO, GEO & AI automation consultant

I help small businesses and independent professionals with their visibility (Google, ChatGPT, Perplexity) and with the real-world use of AI at work. I work on-site with companies to train teams and rethink processes. Everything I write here, I use in client work.

Follow me on LinkedIn My YouTube channel (in French)