A technical SEO audit checks whether search engines can crawl your pages, index them, understand them, and trust them. That is the whole job. Everything else in this post is a way of testing one of those four things.
The reason most audits fail to produce results is not that they miss issues. It is that they list forty issues with no order, so a development team fixes the three easiest and the report gets filed. Run this in the order below, because each layer depends on the one above it.
Start With robots.txt, Because Everything Else Depends On It
Open yourdomain.com/robots.txt and read it. Not a tool's summary of it, the actual file.
What you are looking for: disallow rules blocking directories that contain pages you want ranked, wildcard patterns broader than whoever wrote them intended, and a sitemap directive that points somewhere real.
The failure I see most is a staging configuration shipped to production. A site launches with Disallow: / inherited from a development environment, and nobody notices for weeks because the site works perfectly for humans.
Check parameter blocking specifically. Blocking URL parameters in robots.txt is a common instinct and usually wrong, because a blocked URL cannot be crawled, so its canonical tag is never read, so the consolidation you wanted never happens. Let crawlers reach parameter URLs and let canonicals do the work, per the canonicalization guide.
Then Indexation, Which Is Where the Gap Usually Sits
Crawlable and indexed are different states. Search Console's page indexing report is the fastest way to see the difference, and the discrepancy between pages you have and pages Google has indexed is frequently larger than teams expect.
Work through the exclusion reasons rather than the total. Excluded by noindex tag on pages that should rank is a straightforward error. Duplicate without user-selected canonical means Google disagrees with your canonical choice, which is worth investigating rather than dismissing. Crawled but currently not indexed usually signals a quality assessment rather than a technical fault, and no amount of technical work fixes it.
Soft 404s deserve their own pass. A page returning a 200 status while saying nothing was found is worse than a clean 404, because it adds an empty page to the index rather than removing a URL from consideration. Test by requesting a URL you know does not exist and reading the status code rather than the page text, as covered in the status codes guide.
Site Architecture and Click Depth
The working consensus across technical audits is that pages sitting more than three or four clicks from the homepage receive noticeably less crawl attention and rank weaker. Depth is a proxy for how much internal signal a page receives.
Crawl your own site and pull the depth distribution. Pages at depth six or seven are usually there because the only route to them is paginated archive browsing, which is the discovery problem covered in the pagination guide.
Orphan pages are the sharper version of the same issue. Audits routinely find a substantial share of pages with zero internal links pointing in, meaning they exist in the sitemap and nowhere else. A sitemap gets a page discovered. It carries no signal about whether the page matters.
Fixing architecture is unusually cost effective because it requires no new content. Reorganising internal links changes rankings without writing a word, and the internal linking guide covers the structure worth aiming at.
Core Web Vitals, Read From Field Data
The three metrics and their thresholds have been stable since INP replaced FID in March 2024. Largest Contentful Paint under 2.5 seconds. Interaction to Next Paint under 200 milliseconds. Cumulative Layout Shift under 0.1.
Use Search Console's Core Web Vitals report, which reflects real visitors, rather than relying on lab tools alone. Lab scores routinely look acceptable while field data shows real users on real connections struggling, and the field data is what counts.
The usual causes are predictable. LCP failures trace to unoptimised images, slow server response, or render blocking resources. INP failures trace to heavy JavaScript occupying the main thread. CLS failures trace to images without explicit dimensions, late loading fonts, and content injected after initial render.
Fix images first because it is the cheapest intervention with the widest effect. Explicit width and height attributes, modern formats, and lazy loading below the fold resolve a meaningful share of both LCP and CLS problems in one pass.
My honest position on Core Web Vitals: they are a real ranking input and a modest one. A site failing all three thresholds should fix them. A site passing all three should not expect further optimisation to produce ranking movement, and time spent shaving another two hundred milliseconds is usually better spent on content or architecture.
Rendering, Which Breaks Silently
Use Search Console's URL Inspection tool on a JavaScript heavy page and compare the rendered HTML against what the server actually returns. Where content only appears after rendering, Google can usually handle it and other crawlers frequently cannot, per the rendering guide.
The faster manual version: load an important page with JavaScript disabled. Whatever remains is roughly what a non rendering crawler sees. Empty containers where your content should be is a finding, not a curiosity.
Duplicate Content and Canonicals
Every page should carry a self referencing canonical using an absolute URL, unless it deliberately points elsewhere. This is defensive rather than optional, because it prevents ambiguity before a duplicate exists.
Check for the specific failures: canonicals pointing at redirected URLs, canonicals pointing at noindexed pages, and pages where the canonical contradicts what the sitemap declares. Conflicting signals are worse than a missing one, because a crawler resolving contradictory instructions may honour neither.
Faceted navigation is where this compounds on ecommerce sites. Filter combinations multiply into thousands of near duplicate URLs, most of which should canonicalise to the unfiltered category rather than being indexed independently.
Redirects, Flattened
Chains accumulate across successive site changes. A 2023 migration mapped old to new, a 2026 migration mapped current to newer, and nobody went back to flatten the first map. Add HTTPS and trailing slash normalisation rules and four hops is achievable without anyone doing anything obviously wrong.
Google tolerates a few hops. Every hop is still a wasted request, and the tolerance is not unlimited. Flatten every chain so the original URL points directly at the final destination.
Then rewrite internal links to point at destinations rather than at redirected URLs. Leaving them is the most common post migration failure, and it forces every crawler through an unnecessary detour on every discovery pass indefinitely.
Structured Data
Schema adoption remains low enough across the web that implementing it properly is still a competitive advantage rather than table stakes, with recent analysis putting adoption among the top ten million sites at under a fifth.
Validate with the Rich Results Test and the Schema.org validator. Both are free and both confirm syntax rather than confirming a crawler received the markup, which is a separate check covered in the schema guide.
The error worth prioritising is schema that contradicts visible content. A price in markup that differs from the price on the page damages trust in your markup site wide, not just on that URL.
What This Audit Also Buys You
Every item above is a classic SEO requirement and every one of them independently determines whether AI systems can use your content. Crawl access, rendering, canonical clarity, and structured data are the same prerequisites for both, which is covered from the other direction throughout this blog.
That overlap is the practical argument for doing technical work properly rather than treating it as a separate AI project. There is no second infrastructure to build.
Cadence
A full audit once or twice a year suits most sites. Large sites publishing constantly benefit from continuous monitoring of index coverage rather than scheduled reviews.
Run an immediate targeted audit after any migration, redesign, platform change, or unexplained traffic drop. Those events break things in predictable ways and catching them within days rather than at the next scheduled review is the difference between an inconvenience and a quarter of lost traffic.
Verifying Crawler Access Specifically
The NotionCue AI Crawler Audit checks what specific crawlers receive from a URL rather than what a browser renders, which resolves the rendering and access questions in this checklist in one pass rather than requiring separate manual verification per page.
Start your free NotionCue trial and run it alongside your next technical audit. Crawl access is the layer everything else depends on and it is the layer most often assumed rather than checked.
If you do one thing from this checklist today, request a URL that does not exist on your site and check the status code. A 200 response means every deleted page you have ever had is being indexed as valid empty content.
Common Questions
How long does a technical SEO audit take?
A thorough audit on a mid sized site runs one to two days of analysis and typically surfaces between ten and thirty prioritised issues. The fix work is usually months rather than weeks, which is why prioritisation matters more than completeness.
Which issues should be fixed first?
Anything blocking crawl or indexation, because every other fix is worthless until pages can be reached and indexed. Architecture next, since it is cheap and moves rankings. Performance and schema after that.
Do technical fixes alone improve rankings?
Fixing technical problems removes ceilings rather than creating growth. A site with excellent technical health and weak content will not rank. A site with strong content and a crawl blocker will not rank either, and that one is fixable in an afternoon.