Technical SEO Audit Checklist 2026: Crawling, Indexing and Speed

What a Technical SEO Audit Covers in 2026

A technical SEO audit is a planned check of everything that stops search engines from finding, understanding and ranking your pages. It looks at how the site is built, not at the quality of your writing. This technical SEO audit checklist is the order I follow myself.

The basics haven’t changed much, but some details have. Google moved its crawler documentation to a new crawling hub in late 2025. It made its file size limits clearer in early 2026, and it removed FAQ rich results in May 2026.

Work through the audit in this order, because each layer depends on the one before it:

1. Crawling: can Googlebot reach the URL?
2. Rendering: can it see the content once JavaScript runs?
3. Indexing: does Google choose to store the page, and under which URL?
4. Experience: is the page fast, stable, secure and mobile friendly?
5. Enhancements: structured data, hreflang and other signals.

If rankings dropped suddenly, first rule out an algorithm change. My guide to Google core updates in 2026 lists the dates.

The Technical SEO Audit Checklist (With Priorities)

Use this table as your main checklist. High priority items can block indexing or lose traffic across the whole site. Low priority items are fine-tuning.

Crawling: robots.txt, Sitemaps and Crawl Budget

Crawling is the first gate. If Googlebot can’t fetch a URL, nothing else in the audit matters for that page. Check robots.txt, your sitemaps and how Google spends its crawl.

robots.txt

• Check the file loads at /robots.txt on every host and protocol you use.
• Make sure you aren’t blocking CSS, JavaScript or image folders that pages need to render.
• Remember that robots.txt controls crawling, not indexing. A blocked URL can still be indexed from links, just without its content.
• Google’s crawling documentation changelog shows the robots.txt spec was updated in October 2026. It now recommends percent-encoding in rule paths, so check any rules that contain special characters.

XML Sitemaps

• List only canonical URLs that return 200 and are meant to be indexed.
• Keep lastmod honest. Google uses it when it is accurate over time.
• Submit sitemaps in Search Console and compare submitted and indexed counts for each sitemap. I like to split sitemaps by template, because it makes gaps easy to spot.

Crawl Budget Basics

Crawl budget is how much crawling Google is willing to do on your site. Most sites don’t need to worry about it. In my experience, it only becomes a real issue for very large sites, or sites with many auto-made URLs from filters and parameters.

• Open the Crawl stats report in Search Console and look at response codes, file types and host status.
• Look for crawl wasted on filter navigation, session IDs, internal search results and endless calendars.

Also note Googlebot’s size limit. According to Google’s Googlebot documentation, it fetches the first 2 MB of a supported file (64 MB for PDFs), measured uncompressed. Content past that point may not be indexed.

Indexing: The Page Indexing Report, Canonicals and Noindex

Indexing is where you find out which pages Google actually stores and why it skipped the rest. The Page indexing report in Search Console is your main source. When I audit a site, this is the report I open first.

Reading the Page Indexing Report

Don’t aim for 100% indexed. Many excluded URLs are fine, such as redirects or alternate pages with a proper canonical. Focus on reasons that affect pages you care about:

• Crawled – currently not indexed: Google fetched the page but chose not to index it. This often points to quality or duplication.
• Discovered – currently not indexed: Google knows the URL but hasn’t crawled it yet. This can point to weak internal linking or crawl limits.
• Duplicate without user-selected canonical: you haven’t set a canonical, so Google picked one.
• Duplicate, Google chose different canonical than user: Google disagrees with your canonical tag.
• Excluded by ‘noindex’ tag and Blocked by robots.txt: check these are on purpose.
• Soft 404: the page returns 200 but looks empty or like an error.

Canonicals and Duplicates

A canonical tag is a line of code that tells Google which version of a page is the main one.

• Give each indexable page a self-referencing canonical with a full HTTPS URL.
• Make canonicals, internal links, sitemaps and redirects agree on one version.
• Merge near-duplicates such as print versions, tracking parameters and trailing-slash versions.
• Use URL Inspection to compare “user-declared canonical” with “Google-selected canonical”.

Noindex

Crawl the site and export every URL with a noindex meta tag or X-Robots-Tag header. Staging settings left on after a launch are a classic cause of sudden traffic loss. I see this one more often than I’d like.

Also, never block a noindexed page in robots.txt. Google has to crawl the page to see the noindex.

Rendering and JavaScript SEO

If your site relies on JavaScript, you must check that Google sees the same content and links that users see. Google renders pages with a headless Chromium (a browser with no screen). But rendering can be delayed and things can break. My guide to JavaScript SEO covers the common mistakes.

Google’s JavaScript SEO basics guide sets out the main rules. Check these points on each key template:

• Run URL Inspection, then “Test live URL”, and view the rendered HTML and screenshot.
• Check that the main content, headings and internal links appear in the rendered HTML.
• Use real <a href> links. Links that only work through click handlers may not be followed.
• Don’t put noindex in the original HTML and hope JavaScript removes it. Google may skip rendering once it sees noindex.
• Set canonicals in the HTML. If JavaScript changes a canonical, it should match the original, not contradict it.
• In single-page apps, return real 404 status codes for missing content, or add noindex to error views, to avoid soft 404s.

Server-side rendering or pre-rendering is still the safest choice for important content, and it’s what I recommend. It also helps crawlers that don’t run JavaScript, which matters if you want visibility in AI search tools. See my guide on getting cited in AI Overviews and ChatGPT search.

Site Structure and Internal Links

Good structure helps search engines find pages and understand which ones matter most. Aim for a shallow, logical structure with strong internal links to your most important pages.

• Keep important pages within about three clicks of the homepage.
• Find orphan pages (pages no other page links to) by comparing your crawl with sitemap URLs, analytics landing pages and log files.
• Check that breadcrumbs, pagination and filter navigation create crawlable paths without endless URL combinations.
• Fix internal links that point to redirects or 404s, so link value goes straight to the final URL.

Internal links are the part of link value you fully control. For external links, see link building that still works.

Core Web Vitals: Current Thresholds

Core Web Vitals measure loading, responsiveness and visual stability using real user data. The thresholds haven’t changed since INP replaced FID in March 2024.

web.dev’s guides to LCP and INP say to judge each metric at the 75th percentile of page loads, separately for mobile and desktop.

How to Audit Them

1. Open the Core Web Vitals report in Search Console to find failing URL groups.
2. Test a sample URL from each group in PageSpeed Insights. It shows field data from the Chrome UX Report when available.
3. Use Lighthouse or Chrome DevTools to find the causes in a lab test.

Common Fixes

• LCP: preload or prioritise the main image, cut server response time, remove render-blocking files.
• INP: break up long JavaScript tasks, cut third-party scripts, avoid heavy work in event handlers.
• CLS: set width and height on images and embeds, reserve space for ads, avoid adding content above existing content.

Mobile-First Indexing and HTTPS

Google indexes most sites using the mobile version of their pages, and HTTPS is a basic must for every site. I check both together because they affect every URL.

Mobile Parity

• Crawl the site with a smartphone user agent and compare it with a desktop crawl.
• Check that the mobile version has the same main content, headings, internal links, structured data and meta tags.
• Make sure content hidden behind tabs or accordions still loads in the HTML, not only after a tap.

HTTPS

• Every HTTP URL should redirect to its HTTPS version in a single 301 hop.
• Update canonicals, sitemaps, hreflang and internal links to use HTTPS URLs directly.

Structured Data Validation

Structured data helps search engines understand your content and can make pages eligible for rich results. Your audit should check that the markup is valid, matches what users see and targets features Google still supports.

• Test key templates in Google’s Rich Results Test and the Schema.org Markup Validator.
• Review the rich result reports in Search Console for errors and warnings.
• Check markup describes visible content. Hidden or misleading markup can lead to a manual action.

Google has been simplifying results since 2025 and has dropped several rich result types. Google’s FAQPage documentation says that, as of 7 May 2026, FAQ rich results no longer appear in Google Search. The FAQ report and Rich Results Test support were removed from Search Console afterwards. This follows an earlier cut in 2023, when Google limited FAQ and How-To rich results.

You don’t have to delete FAQ markup, but don’t report FAQ rich results as an opportunity. Local businesses should pair LocalBusiness markup with a strong profile; see my Google Business Profile checklist.

Hreflang for International Sites

hreflang tells Google which language or regional version of a page to show each user. If you only serve one language and market, you can skip this section.

Check these points against Google’s localized versions guide:

• Every version lists itself and all its alternates.
• Links go both ways. If page A points to page B, B must point back to A. Missing return links are the hreflang error I find most often.
• Language codes use ISO 639-1, with optional ISO 3166-1 Alpha 2 region codes, such as en-gb.
• Every hreflang URL is canonical, indexable and returns 200.
• An x-default value is set for a language selector or fallback page where useful.

Redirects, 404s and Server Log Files

Redirect and error checks keep link value flowing and stop users hitting dead ends. Log files then show what search engine bots actually do on your server.

Redirects and 404s

• Use 301 or 308 for permanent moves, and 302 or 307 only for temporary ones.
• Flatten redirect chains so each old URL goes straight to its final page.
• Let truly removed pages return 404 or 410. Redirecting everything to the homepage tends to be treated as a soft 404.
• Redirect deleted pages that have backlinks or traffic to the closest relevant page.

Log File Analysis

Server logs show every request Googlebot makes, while Search Console only shows a sample. They’re most useful on large or complex sites. My log file analysis guide for beginners covers the setup.

• Verify Googlebot hits using reverse DNS or Google’s published IP ranges, because user agents are easy to fake.
• Compare crawled URLs with your sitemap to find ignored sections and wasted crawl.
• Note other bots, including AI crawlers, and decide whether your robots.txt rules for them match your goals.

Tools for a Technical SEO Audit

You can run a solid audit with free Google tools plus one desktop crawler. That’s honestly all I need for most sites.

• Google Search Console: Page indexing, URL Inspection, Sitemaps, Crawl stats, Core Web Vitals, robots.txt and rich result reports.
• Bing Webmaster Tools: a second view of crawling and indexing, plus Site Scan and IndexNow support.
• PageSpeed Insights, Lighthouse and Chrome DevTools: field and lab performance data.
• Rich Results Test and Schema Markup Validator: structured data checks.
• A site crawler such as Screaming Frog SEO Spider or Sitebulb: status codes, canonicals, directives, internal links, hreflang and JavaScript rendering.
• A log analyser: Screaming Frog Log File Analyser, or your own scripts and server dashboards.

Next Steps

1. Run a full crawl and export Search Console’s Page indexing, Crawl stats and Core Web Vitals data.
2. Fill in the checklist table above and mark each issue High, Medium or Low.
3. Fix crawling and indexing blockers first, then rendering, then performance and markup.
4. Check your fixes in Search Console and request recrawls for key URLs.
5. Schedule a lighter monthly check, and a full audit after every redesign, migration or platform change.

If you only remember one thing from this technical SEO audit checklist, make it the order: I’d always fix what stops Google reaching and indexing pages before anything else.