Skip to content
Guide · Reviewed August 2026

Technical SEO audit checklist: 40 evidence-backed checks

Audit the path from discovery to indexing, performance, and AI access—then turn verified findings into a remediation plan instead of exporting an undifferentiated warning list.

How to use this checklist

Start with a representative sample: the homepage, each indexable template, recent pages, high-impression pages, and URLs from every important Search Console exclusion group. Record the tested URL, evidence, owner, severity, and retest date. A crawler export is evidence to investigate, not a remediation plan by itself.

Google’s technical requirements provide the baseline: Googlebot must not be blocked, the page must return a successful HTTP response, and the page must contain indexable content. This checklist expands that baseline into reproducible checks. You can also run the MarqOps technical audit for a fast first pass, then verify consequential findings manually.

Discovery and crawl (1–5)

  1. Verify robots.txt availability. Fetch /robots.txt on every production host and confirm it returns a usable file rather than an error, redirect loop, or environment-specific block.
  2. Test important paths against robots rules. Check representative pages and required assets. A robots.txt block controls crawling; it is not a reliable way to remove an already known URL from search.
  3. Validate XML sitemaps. Include canonical, indexable URLs that return 200 responses. Remove redirects, errors, duplicate variants, and deliberately noindexed pages.
  4. Compare sitemap URLs with discovered URLs. Investigate important pages missing from the sitemap and sitemap entries that have no internal links. Sitemap inclusion is a discovery hint, not an indexing guarantee.
  5. Review Crawl Stats in context. Look for host availability failures, response-code shifts, unexpected file types, or abrupt changes. Crawl volume alone is not a success metric.

Rendering and responses (6–10)

  1. Confirm final HTTP status codes. Important pages should resolve without redirect chains to a successful response. Retired pages should use an intentional redirect or a genuine 404/410.
  2. Compare raw HTML with the rendered page. Make sure primary copy, headings, links, canonicals, and robots directives remain available after JavaScript rendering.
  3. Test JavaScript routing and errors. Client-side routes need distinct URLs, useful HTML, working browser history, and correct error responses—not a 200-status shell for missing content.
  4. Check resource access. Do not block scripts, styles, or APIs required to render meaningful content. Reproduce the page with a crawler-compatible user agent when evidence points to rendering differences.
  5. Verify environment parity. Production must not inherit staging noindex rules, authentication, restrictive headers, placeholder canonicals, or preview-domain links.

Indexing and canonicals (11–15)

  1. Inspect Page indexing groups. Sample URLs from every material reason, not just the total. Separate intentional exclusions from unexpected discovery, crawl, canonical, and quality outcomes.
  2. Verify indexability signals together. Check robots meta, X-Robots-Tag, status code, authentication, canonical, and rendered content. Conflicting signals slow diagnosis.
  3. Use self-referencing canonicals on unique pages. Canonicals should be absolute, production-host URLs and should agree with internal links, redirects, hreflang, and sitemaps.
  4. Consolidate duplicates deliberately. Redirect obsolete URLs when users no longer need them. When variants must remain accessible, choose a canonical and align other signals with it.
  5. Inspect unexpected Google-selected canonicals. Compare content similarity, internal linking, redirects, sitemap membership, and template signals before assuming Google ignored the tag arbitrarily.
  1. Map priority pages to navigation paths. Every commercial and pillar page should be reachable through crawlable HTML links from relevant hubs, not only through search, scripts, or a sitemap.
  2. Find orphan and weakly linked pages. Combine crawler data, sitemap data, analytics landing pages, and Search Console URLs. Add links where they help a reader continue a task.
  3. Use descriptive anchor text. Make the destination understandable without stuffing exact-match phrases into every link.
  4. Repair broken internal destinations. Update links to their final canonical URLs and remove chains. Validate links in navigation, content, breadcrumbs, cards, and structured data.
  5. Control faceted and parameter paths. Decide which combinations deserve standalone search pages, then align crawl rules, canonicals, internal links, and sitemap inclusion with that decision.

Search presentation and content (21–25)

  1. Write distinct, descriptive titles. Match the page’s main purpose and avoid boilerplate or truncated phrases. Google publishes no universal title character limit and may generate a different title link.
  2. Write useful meta descriptions. Summarize the page in complete language. Treat the description as a candidate snippet, not a ranking guarantee.
  3. Align headings with visible content. Use a clear primary heading and a logical hierarchy. One H1 can aid consistency, but one H1 is not a Google requirement.
  4. Resolve intent overlap. When multiple pages compete for the same task without distinct value, choose a primary page, merge useful material, redirect obsolete URLs, and update internal links.
  5. Audit claims and freshness. Replace unsupported statistics, stale product details, and invented thresholds with current primary sources. Add author, publication, and review information where readers need accountability.

Structured data (26–30)

  1. Validate syntax and eligibility. Test representative templates with Google’s supported validation tools and fix parsing errors before warning-level enhancements.
  2. Match markup to visible content. Structured data must describe the page users can see. Do not mark up reviews, FAQs, products, or organizations that the page does not actually present.
  3. Use the most specific supported type. Add only properties you can support accurately; valid markup makes a page eligible for a feature but does not guarantee display.
  4. Keep entity identifiers consistent. Use canonical production URLs for @id, publisher, breadcrumbs, images, and the main entity. Avoid splitting one organization across www and non-www identities.
  5. Monitor enhancements after deployment. Compare validation, Search Console reports, and rendered JSON-LD. Retest when a shared template changes.

Performance and mobile (31–35)

  1. Measure all three Core Web Vitals. Use field data for LCP, INP, and CLS when available; use lab tools to reproduce and diagnose individual pages.
  2. Segment by template and device. A sitewide average can hide a slow article template, mobile navigation delay, or layout shift limited to one component.
  3. Trace the actual LCP element. Optimize the responsible image, text, server response, or render dependency based on the trace rather than applying a universal preload fix.
  4. Diagnose interaction latency. Find long tasks and event handlers behind poor INP, then reduce main-thread work and verify the interaction again.
  5. Test mobile usability and overflow. Check responsive layout, tap targets, text, dialogs, sticky elements, navigation, forms, and horizontal scrolling on real viewport sizes.

AI access and monitoring (36–40)

  1. Apply normal Google Search eligibility first. Google says AI Overviews and AI Mode use the same foundational requirements; no special schema or AI text file is required.
  2. Choose AI crawler access intentionally. Review current operator documentation and distinguish search discovery, model training, and user-triggered retrieval before editing access controls.
  3. Verify bots at the edge. Check CDN, firewall, bot management, and server logs in addition to robots.txt. A permitted crawler can still be blocked elsewhere.
  4. Make important answers extractable and sourced. Use clear sections, direct explanations, stable URLs, and primary citations. Do not manufacture FAQ blocks solely to trigger a search feature.
  5. Monitor outcomes, not folklore. Track indexed pages, impressions, clicks, conversions, crawl failures, and cited referral traffic. Record the deployment date so changes can be evaluated against a baseline.

Turn findings into a remediation plan

Score each verified issue by impact, confidence, effort, and affected template. A practical order is:

  1. Access and indexability blockers affecting important URLs.
  2. Duplicate signals, broken paths, and template defects that multiply across the site.
  3. Internal linking and content consolidation for pages already earning impressions or serving commercial intent.
  4. Performance and enhancement work supported by field data or a reproducible user problem.

Deploy the smallest coherent batch, retest the affected templates, and annotate the release. Use the SEO audit workflow to assign findings, and pair this checklist with the GEO guide when evaluating search and AI visibility together.

FAQ

What is a technical SEO audit?

A technical SEO audit checks whether search engines can discover, fetch, render, understand, and index the URLs you want people to find. It also verifies performance, structured data, internal links, and measurement so fixes can be prioritized with evidence.

How long should a technical SEO audit take?

There is no universal duration. A small site may need a focused review, while a large or JavaScript-heavy site can require log analysis, template sampling, and repeated validation. Scope the work by templates, traffic, risk, and the number of indexable URLs.

Does Google require one H1 or a specific title length?

No. One clear primary heading is useful for readers, but one H1 is not a Google requirement. Google also publishes no universal character limit for title links. Write concise, descriptive titles and verify how they appear in actual search results.

Will FAQ schema or an llms.txt file make a page eligible for AI answers?

No. Google says the normal Search technical requirements apply to its AI features and that no special schema or AI text file is required. Structured data should describe visible content and use only supported types when relevant.

Should every AI crawler be allowed?

Not automatically. AI search, training, and user-triggered retrieval can use different bots. Decide which uses serve your business, confirm each operator’s current documentation, and test access rules before changing robots.txt or edge controls.

Sources and verification

Material factual claims were checked against the primary or official sources below in August 2026. Platform behavior can change, so recheck the linked documentation before changing access controls or measurement.

Related

Inspect the reporting workflow before signup

Open the interactive sample to inspect evidence receipts, approvals, and the client-facing report. No account or client data is required.

Explore the sample report