Technical SEO audit checklist: 55 checks in priority order

Why does the order of a technical SEO audit matter?

Because the checks are not independent. A crawl block invalidates everything downstream of it. If a template is serving noindex, then your title tags, your internal links, and your Core Web Vitals scores on those pages are all irrelevant until that one line is fixed.

This is the most common way I see audits waste budget. A team receives a spreadsheet with two hundred rows sorted by tool severity score, works top to bottom, and spends three weeks on image compression while a canonical conflict quietly keeps half the site out of the index.

So the tiers below are not a difficulty ranking. They are a dependency order.

• Tier 1, blocking. Can search engines and AI systems reach the page and keep it in the index? Nothing else counts until this passes.
• Tier 2, comprehension. Having reached the page, can they work out what it is about and how it relates to everything else?
• Tier 3, refinement. Is the experience good enough that it does not cost you rankings or conversions?

One more thing before the list. Assign an owner and a date to every item you flag. An audit that produces findings without owners produces nothing.

Tier 1: Can crawlers reach and render the page?

Start here every time. In my experience the majority of genuinely damaging findings in any audit sit in this section and the next one.

1. robots.txt allows your priority paths. Read the live file at /robots.txt rather than trusting the CMS setting. Confirm no Disallow rule catches a template, directory, or parameter you need crawled.
2. CSS and JavaScript are not blocked. Blocking these stops Google rendering the page as a user sees it, which can change how the content is assessed. Check with the URL Inspection tool's rendered screenshot.
3. AI crawler rules are a deliberate decision, bot by bot. Training crawlers and live retrieval crawlers do different jobs. Blocking retrieval bots removes you from the AI answers you presumably want to appear in. Decide per bot, write down why, and confirm the live file matches the decision.
4. Priority pages return 200. Crawl the site and filter for anything that is not a 200 on a URL you consider important. Pay particular attention to pages linked from navigation.
5. Primary content exists in the raw HTML. View source, or fetch the page with JavaScript disabled, and confirm the headline and body copy are present. Several AI retrieval systems do not execute JavaScript, so a client-rendered page can look empty to them even when Google renders it correctly.
6. No soft 404s. These are pages returning 200 while showing a "not found" or empty state. Google's Page Indexing report labels them directly.
7. Crawl budget is not draining into junk URLs. Look for faceted navigation, session parameters, infinite calendars, and search result pages being crawled. On small sites this rarely matters. On large ones it matters a lot.
8. Server logs confirm bots actually arrive. This is the check almost everyone skips. Logs are the only place you can prove which crawlers reached which pages and what status they received. Everything else is inference.

Tier 1: Is the right version of each page indexed?

Reachable and indexed are different states. A page can be perfectly crawlable and still be excluded.

9. Priority pages are indexed. Run them through URL Inspection in Search Console. Do not assume, and do not rely on a site: search, which is unreliable for this.
10. No stray noindex tags. Check both the meta robots tag and the X-Robots-Tag HTTP header. Staging directives surviving a launch is a genuinely common and expensive mistake.
11. Canonicals are self-referencing and correct. Every indexable page should declare itself canonical unless you have a specific reason otherwise.
12. Google's chosen canonical matches yours. URL Inspection shows both. When they disagree, Google is telling you it found the page too similar to another one, which is a content or template problem rather than a tag problem.
13. One live version of every URL. HTTP and HTTPS, www and non-www, trailing slash and not, uppercase and lowercase. Pick one of each pair, redirect the rest with a 301, and confirm the redirect actually fires.
14. The XML sitemap contains only canonical, indexable, 200-status URLs. No redirects, no 404s, no noindexed pages, no non-canonical variants. A sitemap full of noise reduces the trust placed in it.
15. The sitemap is submitted and lastmod values are honest. Resubmitting is idempotent, so it is safe to do after structural changes. Do not stamp every URL with today's date, because that pattern is easy to detect and easy to discount.

Tier 2: Can machines follow your site's shape?

Architecture and internal linking tell search engines and assistants which pages you consider important and how your topics connect. This is also the cheapest lever most sites have available.

16. Priority pages sit within three clicks of the homepage. Depth is a signal of importance. A revenue page buried five levels down is being described as unimportant.
17. No orphan pages. Compare your sitemap against your crawl. Any URL with zero internal links pointing to it is effectively invisible regardless of its quality.
18. Redirect chains collapsed to a single hop. Chains leak value and slow crawling. Point the original URL directly at the final destination.
19. No internal links to redirects or 404s. If you moved a page, update the links that point to it rather than leaning on the redirect permanently.
20. Anchor text is descriptive. "Read more" and "click here" tell machines nothing. Anchor text is one of the strongest relevance signals you fully control.
21. Breadcrumbs are present and marked up. They help users, they help crawlers understand hierarchy, and they can appear in results. See item 32 for the schema side.
22. URLs are readable and stable. Short, lowercase, hyphenated, no tracking cruft. Stability matters more than perfection, because moving a URL breaks any citation or link already pointing at it.

Tier 2: Is each page structured to be understood and quoted?

This is where technical SEO and AI search readiness overlap most. Retrieval systems pull passages rather than whole documents, so each section needs to make sense on its own.

23. Title tags are unique and front-loaded. One per page, distinct across the site, with the primary term early. Check for duplicates across templates, which is where they usually hide.
24. Meta descriptions are written, not templated. They do not affect ranking directly, but they affect click-through rate, which is often the cheapest available improvement on a page already ranking.
25. Exactly one H1 per page, matching search intent. Not the logo, not the tagline. The H1 should say what the page is.
26. Heading hierarchy is logical. H2s under the H1, H3s under H2s, no skipped levels, and no headings chosen for how big the font looks.
27. Headings phrased as questions where it fits naturally. This maps directly onto how people query assistants, and it gives retrieval systems a clean question and answer pair to lift.
28. Each section answers its question in the first two sentences. Do not bury the answer under three paragraphs of preamble. Answer first, then elaborate.
29. Real tables for comparisons, real lists for steps. Semantic markup is parsed far more reliably than a visual layout that only looks like a table.
30. Images have descriptive alt text. Accessibility first, image search second, and it gives text-based systems a description of content they cannot otherwise read.

Tier 2: Is your structured data accurate and consistent?

Schema does not make a page rank. It makes a page easier to interpret with confidence, and it reduces the chance a machine guesses wrong about who you are.

31. Organization or LocalBusiness schema on the homepage. Name, URL, logo, and sameAs links to your real profiles. For a local business add address, geo coordinates, and telephone.
32. BreadcrumbList schema on every subpage. Cheap to add, directly supports how your hierarchy is understood.
33. Article or BlogPosting schema on posts, with a linked author. Give the author entity a stable @id that resolves to a real author page, so your articles accumulate against one identity instead of a name string.
34. FAQPage schema only where FAQs are genuinely visible on the page. Marking up content a user cannot see is a guideline violation, and it is easy to detect.
35. Everything validates. Run the Rich Results Test for eligibility and the Schema.org validator for correctness. They catch different problems.
36. Schema facts match visible page facts. If your markup says you are open until 6pm and the page says 5pm, you have created a contradiction rather than a clarification. Audit for drift after any content edit.

Tier 3: Is the page fast enough?

Performance matters, with diminishing returns. Moving from poor to good is worth real effort. Chasing the last few points on an already fast site rarely changes business outcomes.

37. Largest Contentful Paint under 2.5 seconds. Use field data from the Core Web Vitals report rather than a single lab test, because lab conditions are not your users' conditions.
38. Cumulative Layout Shift under 0.1. Usually caused by images without dimensions, injected banners, or late-loading fonts.
39. Interaction to Next Paint under 200 milliseconds. Normally a JavaScript execution problem rather than a network one.
40. Images are modern format, correctly sized, and lazy-loaded below the fold. Serve WebP or AVIF, never scale a large image down in the browser, and always set explicit width and height.
41. Render-blocking resources minimized. Defer non-critical JavaScript, inline critical CSS, and preload the font files you actually use.
42. Caching and compression enabled. Sensible cache headers on static assets plus Brotli or gzip. Often a single configuration change.
43. Third-party scripts audited and justified. Tag managers accumulate. Every tag has a performance cost, and abandoned ones are pure loss.

Tier 3: Mobile, security, and hygiene

44. Mobile shows the same content and links as desktop. Indexing is mobile-first, so content hidden on mobile is content you have partly given up on. Collapsed accordions are fine, because the text is still in the HTML. Content removed entirely is not.
45. Tap targets and font sizes are usable. Test on a real device, not just a resized browser window.
46. HTTPS everywhere, with no mixed content. One insecure asset reference can trigger a browser warning on an otherwise secure page.
47. Certificate valid and not close to expiry. Set a calendar reminder. An expired certificate is a total outage.
48. The 404 page is useful and genuinely returns a 404 status. It should offer navigation and search rather than dead-ending, and it must not return 200.
49. hreflang is correct and reciprocal, if you run multiple languages or regions. Every version points at every other version including itself. Skip this entirely if you run a single-language site.

Verification: how do you know the audit worked?

This section is what separates an audit from a document. Findings that are never verified tend to quietly not get fixed.

50. Search Console is verified at the right property level, and Manual Actions is clean. Check Security and Manual Actions before you attribute a traffic problem to anything technical. A manual action changes the entire diagnosis.
51. Analytics is collecting cleanly. Confirm the tag fires once per page, that internal and staging traffic is filtered out, and that preview or proxy hostnames are not inflating your session counts.
52. Capture a baseline before you change anything. Impressions, clicks, average position, indexed page count, and Core Web Vitals. Without a before, you cannot demonstrate an after.
53. Re-crawl and re-inspect after the fixes ship. Confirm the change is live in production, not just merged. Request indexing on genuinely important changed pages.
54. Track AI crawler hits over time. Once retrieval bots are allowed, logs will show whether they are actually fetching your priority pages. This is currently the most direct evidence available that your content is reachable by AI systems.
55. Every finding has one owner and one date. Severity without ownership is just commentary.

What tools do you need for a technical SEO audit?

Fewer than most people assume. The free ones do most of the work.

Job	Tool	Cost
Index status, canonicals, crawl errors, manual actions	Google Search Console	Free
Rendering check and live page fetch	URL Inspection, inside Search Console	Free
Core Web Vitals field data	Search Console, PageSpeed Insights	Free
Schema validation	Rich Results Test, Schema.org validator	Free
Site-wide crawl for status codes, depth, duplication	Screaming Frog, Sitebulb, or similar	Free tier
Traffic, engagement, and channel behavior	GA4	Free
Crawler verification	Server or CDN access logs	Free
Competitive and keyword context	Semrush or equivalent	Paid

The one that is hardest to obtain and most valuable is log access. If you can get it, take it.

How long should a technical SEO audit take?

For a small business site of up to roughly fifty pages, Tier 1 is a couple of focused hours and the full checklist is about a day. For a few hundred pages, expect two to three days. For a large ecommerce or multi-language site, the crawl alone can run overnight and the analysis is a week or more.

What takes longer than the audit is the remediation, which is why sequencing matters. If you only have a day, do Tier 1 and stop. You will find more value in those fifteen checks than in the remaining forty combined.

If you would rather not run this yourself, that sequencing is exactly what I do inside a website audit, delivered as a prioritized plan with owners rather than a raw tool export. For the reasoning behind the AI-search items above, see technical SEO for AI search and what an SEO audit for AI search includes.

Technical SEO audit checklist FAQ

What is a technical SEO audit?

A technical SEO audit is a structured review of whether search engines and AI systems can crawl, render, index, and understand your site. It covers crawl access, indexation, architecture, page structure, structured data, performance, and measurement. It does not assess content quality or backlinks, which are separate pieces of work.

How often should you run a technical SEO audit?

A full audit once or twice a year suits most sites, plus a Tier 1 check after any migration, redesign, CMS change, or template update. Between audits, monitoring the Page Indexing and Core Web Vitals reports in Search Console catches most new problems as they appear.

What should you fix first in a technical SEO audit?

Anything that stops a page being reached or indexed. That means robots.txt blocks, stray noindex tags, canonical conflicts, rendering failures, and non-200 status codes on important pages. Fix those before touching titles, descriptions, schema, or performance, because work done on an unreachable page is wasted.

Can you do a technical SEO audit for free?

Mostly, yes. Google Search Console, URL Inspection, PageSpeed Insights, the Rich Results Test, and GA4 are all free and cover the majority of this checklist. A paid crawler saves significant time on larger sites, and server log access is the one genuinely hard thing to obtain.

Does a technical SEO audit help with AI search visibility?

Yes, because AI systems have to fetch and parse a page before they can summarize or cite it. Crawl blocks, rendering problems, and indexation issues remove a page from AI answers the same way they remove it from rankings. The items that matter most for AI retrieval are raw-HTML availability, deliberate AI crawler rules, passage-level page structure, and URL stability.

What is the difference between a technical SEO audit and an SEO audit?

A technical SEO audit looks at whether your site can be crawled, rendered, indexed, and understood. A broader SEO audit adds content quality, keyword targeting, competitive position, and off-site authority. The technical work comes first, because content and link improvements cannot pay off on pages that machines cannot reach.