Technical SEO Audit Checklist 2026: Everything You Need to Fix

AI search has not changed this. It has raised the stakes: if a crawler cannot reach, render and understand a page, then neither can an AI answer engine deciding whether to cite it.

This checklist covers 14 areas, ordered the way an audit actually runs: verify access first, then crawling, then indexation, then performance, then content signals, then the AI readiness layer, then monitoring. Each area explains what to check, how to check it, and what good looks like in 2026. Run it top to bottom on a site you control and you will surface problems worth months of fixing.

A note on scope: this is an audit checklist, not a rebuild plan. The 90-day rollout at the end converts findings into work, sized by team resources.

Key Takeaways

• Audit in the order engines do: robots.txt and server health, then crawlability, then indexation, then rendering, then performance, then content signals. Fixing in the wrong order wastes effort on pages engines cannot even reach.
• The 2026 performance gates are Core Web Vitals with INP replacing FID: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, Cumulative Layout Shift under 0.1.
• Mobile-first indexing means the mobile rendering is the only rendering that counts for ranking; audit there first.
• AI search readiness is a technical layer, not a content trick: server logs must show AI crawler visits, structured data must be complete and error-free, entities must be connected, and answers must be extractable.
• llms.txt is a low-cost pilot, not a standard; Google's own statements remain the source of truth for what affects ranking.
• An audit without a rollout plan is a document, not a project: end every audit with a 90-day schedule sized to your actual resources.

Preparation Before the Audit

Ten minutes of setup saves an hour of confusion later. Full access is the difference between an audit and a guess.

• Google Search Console and Bing Webmaster Tools verified. If GSC is unverified, verify via DNS. If analytics is the only data source available, expect a materially incomplete audit.
• A crawler ready. Screaming Frog with a paid licence for JavaScript rendering, or the free tier under 500 URLs for small sites. Cloudflare and AWS dashboards open for server-side checks.
• An export of the current state. Current sitemap, robots.txt copy, and a baseline of indexed pages from the GSC Coverage report, so every finding has a before.

Area 1: Robots.txt and Server Health

Before any crawler sees a page, the server decides whether to let it. Two file types decide this: the access rules and the response codes.

• Audit robots.txt against actual URLs. Parse the file and verify every rule against the URL list. Common findings: development sites blocked with the same robots.txt copied to production, and CSS or JavaScript directories disallowed, which breaks rendering even when pages crawl.
• Check server response codes on priority pages. 200 for money pages, 301 for permanent redirects, 404 for true dead ends, 410 for deliberately removed content, 503 for temporary outages. A 302 chain on a homepage is a finding, not a style choice.
• Review robots.txt naming and location. Lowercase name, single file, root directory, HTTPS served. Subdomain and protocol variations each need their own check; the file only governs the host and protocol it is served from.

Area 2: Crawlability

With access verified, can engines actually traverse the site?

• Crawl the full site and compare against the known URL list. Orphan pages, those with zero internal links but live in the sitemap or analytics, surface here.
• Audit the internal link graph. Broken links, redirect chains, and pages five or more clicks from the homepage. Information architecture is covered in Area 4; here the concern is mechanical reachability.
• Audit pagination, faceted navigation and parameter handling. E-commerce sites live or die here: facets that generate infinite URL spaces dilute crawl budget and create duplicate content at scale.

Area 3: Indexation and Coverage

Crawlable is not the same as indexed. This area reconciles what exists with what Google keeps.

• Reconcile the GSC Coverage report against the URL inventory. Every excluded URL should be excluded on purpose: noindexed, canonicalised elsewhere or retired with a 410.
• Audit canonical tags as a decision tree, one page at a time. Check duplicates and near-duplicates for self-referencing canonicals; parameter and faceted URLs for canonicals pointing to the base version; syndicated or republished content for canonicals pointing to the original; HTTP to HTTPS for full protocol consistency; print and mobile alternate URLs for canonicals to the primary; staging and test environments for removal from any public discovery.
• Review the noindex usage against a rule, not a reflex. The reflexive version of this advice, noindex anything with low traffic, quietly removes pages that attract links and serve top-of-funnel queries. The working rule: noindex pages with no search demand and no link value (internal search results, filtered views, thin utility pages), and fix or merge pages that have demand but underperform.

Area 4: Site Architecture and Navigation

Architecture is a crawl and comprehension asset: a logical hierarchy distributes authority and helps both classic crawlers and AI systems understand what the site is about.

• Map the hierarchy. The main navigation should mirror the most important sections, ideally within three clicks of the homepage for key pages.
• Audit breadcrumbs. Present on deep pages, marked up with BreadcrumbList schema, consistent with the URL structure.
• Check URL structure. Short, hyphenated, lowercase, descriptive. Changing URL structure mid-audit multiplies the redirect surface; log it as a finding and schedule it, do not improvise it.

Area 5: XML Sitemaps

• Every sitemap lists only indexable, canonical, 200-status URLs. No redirects, no 404s, no noindexed pages, no duplicated parameter variants.
• Sitemaps are referenced in robots.txt and submitted in both GSC and Bing Webmaster Tools. Check the last-modified dates are real dates, not deployment timestamps that reset on every build; engines use them for recrawl prioritisation.

Area 6: Mobile-First and Responsive Behaviour

Mobile-first indexing means the mobile rendering is the rendering. A desktop-only audit is half an audit.

• Audit the mobile rendering of every template, not just the homepage. Same content, same structured data, same internal links as desktop, or the differences become the findings.
• Check tap targets, viewport configuration and interstitial behaviour. Intrusive interstitials are both a ranking consideration and an INP problem.

Area 7: Core Web Vitals and Page Experience

The 2026 thresholds, measured at the 75th percentile of real users in field data:

• Largest Contentful Paint under 2.5 seconds. Usually an image or font problem: preload the hero asset, compress, serve AVIF/WebP, lazy-load below the fold.
• Interaction to Next Paint under 200 milliseconds. INP replaced FID as the responsiveness metric. Find long tasks in the main thread, split them, defer non-interactive third-party scripts.
• Cumulative Layout Shift under 0.1. Reserve space for images and embeds with width and height attributes; never inject content above existing content on load.
• HTTPS everywhere, no mixed content. Certificate validity, HSTS where appropriate, and no insecure subresource calls.

Area 8: JavaScript Rendering

If content only exists after JavaScript executes, an audit must verify what crawlers actually receive.

• Compare the raw HTML against the rendered DOM for key templates using a rendering crawler or the URL Inspection tool. Missing content, links or schema in the raw HTML is a risk finding even when rendering works today.
• Budget JavaScript. Render-blocking scripts, hydration waterfalls and third-party tags are the usual INP culprits; the fix usually belongs to the developers, but the finding belongs to the audit.

Area 9: Structured Data

• Validate every template's markup with the Rich Results Test and the GSC Enhancements reports. Errors and warnings are findings with ticket-level specificity.
• Implement the types that match the business: Organization, WebSite with SearchAction, BreadcrumbList sitewide; Product with offers and Review on commerce pages; Article with author Person markup on the blog; LocalBusiness with matching NAP for physical locations; FAQPage where genuine FAQs exist. All marked-up facts must be visible on the page; schema is a description of the page, not a second channel for claims.

Area 10: Duplicate and Thin Content

• Parameter and faceted duplicates get canonical rules, not hope.Case and trailing-slash variants get 301s or consistent canonicals.
• Thin content gets a decision, not a delete reflex: consolidate overlapping pages, expand pages with demand, noindex utility pages without demand, and 410 the rest. The audit output is a content decision list with one row per URL.

Area 11: International and Multiregion

If the site serves multiple languages or regions, this area is where invisible ranking loss hides.

• Hreflang annotations are reciprocal and complete, including self-references and an xdefault, and every annotated URL returns 200.
• Language declarations, currency, and localised content actually match the target market; an hreflang tag on an untranslated page is a broken promise to users and engines alike.

Area 12: On-Page Content Signals

Technical SEO and content quality are not separate audits; the technical layer exists to make content legible.

• Titles and descriptions: unique, descriptive, matched to intent, without mass-produced boilerplate patterns that repeat across hundreds of pages.
• Heading hierarchy: one H1, logical order, no skipped levels used for styling. Headings are also the extractable structure AI systems rely on.
• Images:descriptive filenames, alt text that describes the image, AVIF/WebP delivery, and dimensions reserved in markup. Internal links use descriptive anchor text rather than "click here"; the anchor is a relevance signal for the page being linked to.

Area 13: AI Search Readiness

The newest layer of the audit, and the reason the 2026 checklist differs from the 2024 one. The rule of thumb: what helps a search crawler understand the site helps an answer engine cite it, with four additions.

• Check server logs for AI crawler visits (GPTBot, ClaudeBot, PerplexityBot and peers). If the site blocks them by default at the CDN or firewall layer, that is a deliberate business decision being made by accident. Unblock the ones you want reading your content; keep blocking the ones you do not.
• Audit entity coherence: the same organization, brand and author identities, described consistently in schema, on-page and across the web. This connects directly to the E-E-A-T work covered in a companion article in this series; the two audits share findings.
• Audit extractability: question-format headings, answer-first paragraphs under them, one idea per section. A passage that cannot stand alone cannot be cited.
• Pilot llms.txt if the use case fits (documentation, reference content, structured catalogues). Publish it, validate it, monitor logs for consumption. Treat it as an experiment with a clear date of review, not a ranking lever; the source of truth for ranking remains Google's own published guidance.

Area 14: Monitoring and Cadence

• GSC and Bing dashboards reviewed monthly; Core Web Vitals and log files trended, not snapshotted. A one-time audit decays; a monitoring cadence is what keeps the fix list at zero.
• Re-run the crawl after every major release, not quarterly. Most regressions (blocked directories, broken canonicals, missing schema) ship with deploys, not with time.
• Track the indexation count, crawl error count and CWV pass rate as the three headline numbers in whatever report leadership reads. Findings that are not trended do not get resourced.

The 90-Day Rollout

An audit is a list of findings; the rollout converts findings into a calendar. Size the plan to the team you actually have:

Table 2. Implementation plan by team resources

The sequencing inside each track follows the audit order: access and crawlability first, because nothing downstream matters if engines cannot reach the page; then performance; then the content and AI layers that presume the plumbing works.

The Audit Is the Easy Part

Nothing in these 14 areas is exotic. The work is discipline: run the checks in order, write every finding with a fix and an owner, and protect the calendar that turns the register into changes on the site.

The sites that win technical SEO in 2026 are not the ones with the longest checklists. They are the ones where the checklist runs on a cadence, where every finding becomes a ticket, and where an AI answer engine can reach, read and cite every page worth citing. If you want that register built and worked by a team that does this weekly, that is the technical SEO work we do at Grapes. Bring the site; the findings will come.