Technical SEO Checklist

A comprehensive technical SEO checklist covering crawlability, indexing, Core Web Vitals, structured data, sitemaps, robots.txt, canonicalization, HTTPS, and mobile SEO — organized by priority and site type.

First published: Jun 27, 2026 · Last updated: Jul 25, 2026 · Advanced
demand #5 in Tools#85 in Technical SEO#113 on the site
AIAuthored byAI v2
1 evidence signal on this page

A technical SEO checklist confirms the technical conditions a site must meet for search engines and AI answer engines to crawl, render, index, and serve its pages — Google's four load-bearing conditions are crawlable, indexable, understandable, renderable. It's the technical-only slice; the broader full-site version lives in the SEO Audit Checklist. Work it in priority order — crawlability, indexing, HTTPS, mobile parity, sitemaps, structured data, Core Web Vitals — and gate whole sections by site type: most small sites can skip crawl-budget engineering entirely, which Google confirms in its own docs. Two myths to kill on sight: robots.txt does not deindex a page, and structured data is not a ranking factor. Meeting the checklist is necessary but not sufficient — Google says indexing still isn't guaranteed.

TL;DR — Technical SEOTechnical SEO is the practice of making a site easy for search engines to crawl, render, index, and (now) be eligible for AI answers. It's the foundation that lets your content and links rank — not a ranking trick of its own. is the floor, not the ceiling: pages must be crawlable → indexable → understandable → renderable before content work can pay off. Run the checklist in priority order and gate sections by site type — most small sites can skip crawl budgetThe number of URLs an engine will crawl in a timeframe., faceted-nav control, log analysis, and JS-renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. engineering, which Google’s own crawl-budget doc confirms. Kill two myths on sight: robots.txt doesn’t deindexDeindexing means getting a URL to stop appearing in Google's search results. There's no single delete button — the right method depends on whether you own the page, whether removal is temporary or permanent, and whether the content should still exist., and structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. isn’t a ranking factor. Treat Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. as targets, not pass/fail gates — that’s Google’s own “strive to” language. And meeting every box still doesn’t guarantee indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed..

Evidence for this claim Google's minimum technical requirements include accessible Googlebot crawling, a successful HTTP response, and indexable content. Scope: Eligibility prerequisites, not a guarantee of indexing or ranking. Confidence: high · Verified: Google Search Essentials: Technical requirements Evidence for this claim Meeting technical requirements does not guarantee that Google will crawl, index, or serve a page. Scope: Google Search eligibility and selection behavior. Confidence: high · Verified: Google Search Essentials: Technical requirements

The mental model: four conditions

Google frames the whole of technical SEOTechnical SEO is the practice of making a site easy for search engines to crawl, render, index, and (now) be eligible for AI answers. It's the foundation that lets your content and links rank — not a ranking trick of its own. around four load-bearing conditions — a page has to be crawlable, indexable, understandable, and renderable. Its Search Essentials technical requirements boil that down to three minimums: “GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. isn’t blocked,” “The page works” (served with an HTTP 200 status), and “The page has indexable content.” Everything on this checklist is really in service of those.

The critical caveat, straight from the same doc: “Just because a page meets these requirements doesn’t mean that a page will be indexed; indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. isn’t guaranteed.” Technical SEO is a gate you have to pass through, not a lever that guarantees results. This is why I’ve always argued the technical checklist is the floor — you clear it so content and links can do their job, not instead of them.

Before you start: which sections even apply to you?

Every competing checklist organizes by topic and runs the whole thing on every site. That’s the wrong default. The better organizing axis is site type, because Google itself gates its most advanced guidance by site size. From the large-site crawl-budget guide: “If your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide.”

Google’s own (deliberately rough) thresholds for when crawl budgetThe number of URLs an engine will crawl in a timeframe. starts to matter:

  • Large sites — 1 million+ unique pages with content changing about weekly.
  • Medium-or-larger sites — 10,000+ unique pages with very rapidly changing (daily) content.
  • Sites with a big share of URLs stuck in Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.’s “Discovered - currently not indexed” state.

So here’s the split I’d actually run:

Starter track — small / brochure / local-business sites (< ~10K URLs): crawlabilityCrawlability is how well search engine crawlers can discover, access, and fetch a site's pages. A crawlability issue is any technical condition — blocked access, broken links, server failures, or bloated URL inventory — that stops pages from reaching the index. sanity check, indexing/canonical sanity check, HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.', mobile parity, one XML sitemapAn XML sitemap is a UTF-8 file listing the canonical URLs on your site (with optional lastmod) so search engines can discover and prioritize them. It's a discovery and diagnostic aid, not a guarantee of indexing — and Google ignores its priority and changefreq tags., one round of Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data., valid structured data where it earns a rich result. Skip crawl budget, faceted-nav control, log-file analysis, and JS-renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. engineering entirely.

Advanced track — large / ecommerce / JS-heavy / enterprise sites: everything in the Starter track plus crawl-budget management, faceted-navigation control, JavaScript rendering audits, server-log analysis, and (if international) hreflangHreflang is an annotation (in HTML, HTTP headers, or XML sitemaps) that tells search engines which language and optional region a page targets, and which alternate versions exist. It only works when every page in the cluster references all the others..

1. Crawlability

  • robots.txt correctness. Confirm you aren’t disallowing anything you want indexed. Google: “A robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. file tells search engine crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. which URLs the crawler can access on your site. This is used mainly to avoid overloading your site with requests; it is not a mechanism for keeping a web page out of Google.” Use it to keep bots out of low-value spaces (internal search, infinite parameter combinations), not as a deindexingDeindexing means getting a URL to stop appearing in Google's search results. There's no single delete button — the right method depends on whether you own the page, whether removal is temporary or permanent, and whether the content should still exist. tool. This is the same territory the robots.txt deep dive covers in full.
  • The robots.txt + noindex contradiction trap. Do not block a URL in robots.txt and rely on a noindex on it. Google: “While Google won’t crawl or index the content blocked by a robots.txt file, we might still find and index a disallowed URL if it is linked from other places on the web.” The bot can’t crawl the page, so it never sees the noindex, and the URL can still surface bare in results. To remove a page: allow crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. + noindex, or password-protect it.
  • Crawl errors. Fix unexpected 4xx and 5xx. Google only indexes pages served with a 200, and “Client and server error pages aren’t indexed.”
  • Redirect chainsA → B → C instead of A → C. Each hop loses link equity and adds latency. and loops. Collapse A→B→C→D down to A→D. Chains waste crawl and leak a little on every hop. The crawling and redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. material goes deeper here.

2. Indexability

  • Index coverage. In Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance.’s Page Indexing reportThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason., reconcile what you want indexed against what actually is. Investigate large “Discovered/Crawled - currently not indexed” buckets.
  • CanonicalizationHow search engines pick one canonical URL among duplicates and consolidate signals onto it.. Point duplicate and near-duplicate URLs at one preferred version. Google calls rel="canonical" “a strong signal that the specified URL should become canonical” — a signal, not a directive it must obey. And crucially: “Don’t use the robots.txt file for canonicalization purposes.” Check you aren’t sending conflicting canonical signals across HTML tag, HTTP header, and sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. — the canonicalization deep dive walks through consolidating them.
  • Duplicate contentThe same or very similar primary content reachable at more than one URL. There's no general duplicate content penalty — the real costs are possible signal dilution, the wrong URL getting chosen, and less-efficient crawling.. Parameters, print versions, staging leaks, http/https and www/non-www splits all create duplicates. Pick one, canonicalize or redirect the rest.

3. HTTPS

Baseline, not optional. Serve the whole site over HTTPS, redirect http to https, and hunt down mixed contentMixed content is when a page served over HTTPS loads a sub-resource — a script, stylesheet, image, iframe, or similar — over insecure HTTP. Browsers' current taxonomy is upgradable versus blockable; active mixed content (scripts, styles, iframes) is blocked, and passive mixed content (images, audio, video) is warned about or increasingly auto-upgraded, with exceptions like CORS-enabled images and srcset/picture candidates that are blockable, not upgradable. (a secure page loading an insecure image, script, or stylesheet). Chris Green’s SEO in 2026 reality-check pegs HTTPS adoption at “91%+” — you don’t want to be in the trailing 9%.

4. Mobile SEO

Google uses mobile-first indexingGoogle's practice of using the mobile version of a page's content — crawled by Googlebot smartphone — for indexing and ranking. It is not a separate index and not a ranking boost.: “Google uses the mobile version of a site’s content, crawled with the smartphone agent, for indexing and ranking.” The parity checklist, straight from Google’s mobile-first doc:

  • “Make sure that your mobile site contains the same content as your desktop site.”
  • “Make sure that the title element and the meta descriptionThe meta description is an HTML head tag — `<meta name=\"description\" content=\"…\">` — that suggests a short summary of the page for the search snippet. It's not a Google ranking factor, and Google rewrites it the majority of the time, but a good one can still lift click-through. are equivalent across both versions of your site.”
  • “Make sure that your mobile and desktop sites have the same structured data.”
  • “Use the same robots meta tagsThe robots meta tag is an HTML element in a page's head — <meta name=\"robots\" content=\"noindex\"> — that tells search engines how to index and serve that page. It's crawl-then-obey: a page blocked in robots.txt is never fetched, so the tag is never seen. on the mobile and desktop site.”
  • “Don’t lazy-load primary content upon user interaction.”
  • “Make sure that the mobile site has the same alt textAlt text is the value of the `alt` attribute on an HTML `<img>` element — a short text substitute chosen for the image's purpose and context, not a literal description of what it shows. It makes images accessible to screen-reader users and helps search engines understand images, mainly for image search. for images as the desktop site.”

The most common failure is a stripped-down mobile template that quietly drops content, links, or structured data present on desktop — Google indexes the thinner version.

5. Sitemaps and discovery

  • XML sitemap hygiene. Use absolute, canonical URLs; stay under the 50 MB / 50,000-URL per-file limit; list only indexable, canonical URLs; keep lastmod accurate. Reference it in robots.txt (Sitemap: https://example.com/sitemap.xml) so engines discover it automatically. Full treatment in the XML sitemaps material.
  • Bing still cares. From Bing’s July 2025 guidance: “Sitemaps remain a foundational signal for ensuring comprehensive URL coverage across your site,” “XML remains the preferred format for sitemaps,” and “The lastmod field in your sitemap remains a key signal, helping Bing prioritize URLs for recrawling.”
  • IndexNowIndexNow is an open push protocol that lets you instantly tell participating search engines (Bing, Yandex, Naver, Seznam, and Yep) which URLs you've added, changed, or removed via a simple HTTP request — and one submission is shared across all of them. Google does not use it.. Most Google-centric checklists omit it, but it’s a live, free, one-line win: Bing’s advice is to “Use IndexNow for real-time URL submission, instantly notifying Bing and participating search engines” when content changes. It complements sitemaps rather than replacing them. (Note: Google does not use IndexNow for general pages.)

6. Structured data

  • What it does: earns rich-result eligibility and helps machines (and LLMs) understand your page. “Adding structured data can enable search results that are more engaging to users… which are called rich resultsRich results (formerly 'rich snippets') are enhanced search listings — stars, images, prices, breadcrumbs, video thumbnails, and more — that Google and Bing build from structured data. They're a display feature, not a ranking factor, and eligibility never guarantees they'll show..”
  • What it does not do: boost rankings. Google’s docs frame schema strictly as rich-result eligibility and machine understanding — not a ranking signal. Do not sell it, or budget for it, as a ranking play.
  • Format: “In general, Google recommends using JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. for structured data if your site’s setup allows it, as it’s the easiest solution for website owners to implement and maintain at scale.” Validate with the Rich Results Test. The structured data material covers the specific types worth implementing.

7. Core Web Vitals and page experience

Targets, not gates — Google’s actual wording is “strive to,” which most checklists overstate as hard pass/fail cutoffs:

  • LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. — “strive to have LCP occur within the first 2.5 seconds of the page starting to load.”
  • INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. — “strive to have an INP of less than 200 milliseconds.”
  • CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. — “strive to have a CLS score of less than 0.1.”

And the relationship to ranking, which people badly over-weight: “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” Good Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors. are a tiebreaker among relevant results, not an override of relevance. Measure with real-user (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program./field) data, not just lab scores.

8. Advanced additions (large / ecommerce / JS-heavy only)

  • Crawl budget. Only if you cleared Google’s thresholds above. Capacity + demand; you gain budget by removing waste (parameter explosions, faceted-nav combinations, spider trapsA spider trap (also called a crawler trap) is a site structure that generates an effectively infinite number of URLs — from faceted filters, calendars, session IDs, or redirect loops — so crawlers waste their budget on low-value, near-duplicate pages instead of your real content., duplicate URLs) far more than by trying to make Google crawl “more.” See the crawl budget deep dive.
  • JavaScript rendering. Confirm critical content and links exist in the rendered HTML and are reachable via real <a href> links, not click-only navigation. This is JavaScript SEOMaking sure search engines can crawl, render, and index content that depends on JavaScript. territory.
  • Faceted navigationFaceted navigation (faceted search, product filtering) lets visitors refine a list of products or content by attribute — price, color, size, brand, rating. The SEO problem: each filter combination can spawn a distinct crawlable URL, turning a small catalog into millions of near-duplicate pages that waste crawl budget and dilute ranking signals. control. Decide which filter/sort combinations are crawlable/indexable and control the rest.
  • Log-file analysis. The ground truth for what bots actually fetch, how often, and what status codes they hit.
  • hreflang — only if you’re genuinely multi-regional/multilingual. That’s a big enough topic to live in its own international-SEO material; don’t bolt it on half-done.

9. AI / LLM crawler access (short, scoped)

Two table-stakes items in 2026, and no more — the deep GEOGenerative Engine Optimization — visibility inside AI answer engines./AEO work lives in the AI-search material, not here:

  • Decide AI-crawler access in robots.txt. Explicitly allow or disallow the AI user-agents you care about (training vs. AI-search vs. user-triggered fetchers are different bots). Chris Green’s framing: “Robots.txt is no longer just crawl housekeeping. It’s becoming a policy surface.”
  • Structured data doubles as machine context for LLMs — a bonus reason to get your schema valid, not a new workstream.

10. How to prioritize what you find

This is where most checklists fail: they hand you 90 items with no weighting. Don’t fix everything — fix what moves the needle. My buddy Patrick’s advice on client audits, which I keep coming back to: “If clients are coming to you asking for an audit, they already have a pain point. Talk to them. Solve that one thing and they’ll be happy with the audit.” The same SEO Audit Template frames it as “sweating the small stuff rarely does much for your rankings” — better to spend “80% of your time fixing the 20% of things that matter.”

And zoom out on the whole exercise: a checklist gets you to okay. Google’s John Mueller has repeatedly made the point that fundamentals alone get you fine-but-not-great results — real dominance comes from topical depth and authority, not from ticking every technical box. The checklist clears the floor; content and links build the house.

TIP Turn the checklist into a scoped crawl with visible blind spots

This raw-HTML baseline helps find repeatable technical patterns. It does not evaluate rendered JavaScript, Search Console index state, or AI visibility.

Run the checklist’s crawl layer with my free Scout Site Audit Free Free

  1. Crawl the site or a representative section and note the discovered-versus-crawled scope.
  2. Group issues by detector and affected template instead of treating every URL as a separate task.
  3. Validate the highest-impact patterns in rendered pages and Search Console before shipping the fix.
A useful checklist result states what was checked and what was not, then gives you a pattern to verify.

The sample report has an 82 out of 100 raw-HTML score. It crawled 24 of 31 discovered URLs, labels the crawl partial, reports two missing-title warnings across 24 checked pages, and says rendered JavaScript and AI checks were not evaluated.

Want the full-site version?

This page is technical-only by design. If you want the broader audit — technical plus on-page, content, and off-page — that’s the SEO Audit ChecklistAn SEO audit checklist is the structured set of things you review across a site's technical health, on-page elements, content quality, and off-page authority — used to produce a short, prioritized action plan, not an exhaustive 100–200 item inventory., a separate, wider thing. Don’t try to make this one page do both jobs.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.