Technical SEO Checklist

TL;DR — A technical SEO checklist is the list of technical boxes your site has to tick so search engines can find, read, and show your pages. Google’s short version: a page has to be crawlable, indexable, understandable, and renderable. Work the list in priority order, and skip the sections that don’t apply to your size of site — a 20-page brochure site does not need to worry about the same things a 500,000-product store does.

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: 2026-07-14 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: 2026-07-14 Google Search Essentials: Technical requirements

What this checklist is (and isn’t)

Technical SEO is the plumbing. Before your content can rank, search engines have to be able to reach your pages, download them, understand them, and file them away. A technical SEO checklist is just the ordered list of things that make that possible.

It is not the whole of SEO. It doesn’t cover writing good content, targeting the right keywords, or earning links. Those matter enormously — they’re just a different job. If you want the everything-at-once version, that’s a full SEO audit checklist, and it’s a separate, broader thing. This page stays technical.

The priority order

Do these roughly top to bottom. The higher up the list, the more it can quietly break everything below it.

1. Can search engines crawl your site? Check your robots.txt isn’t blocking pages you want found. Fix broken pages (404s) and server errors (5xx).
2. Can your pages be indexed? Make sure you’re not accidentally telling Google to noindex important pages, and that duplicate versions of a page point to one preferred version.
3. Is your site on HTTPS? The little padlock. It’s a baseline expectation now.
4. Does it work well on phones? Google indexes the mobile version of your site, so your phone version has to have the same content as your desktop version.
5. Do you have an XML sitemap? A simple list of your URLs you hand to Google and Bing so they don’t have to find everything by following links.
6. Is your structured data valid? Optional, but it can earn you richer-looking search results. (It won’t boost your rankings — more on that myth below.)
7. How’s your page speed? Google’s Core Web Vitals measure loading, response, and visual stability.

The two myths to know

• Blocking a page in robots.txt does not remove it from Google. It just stops Google reading it. To actually remove a page, let Google crawl it and add a noindex tag. (Blocking it in robots.txt and adding noindex is a classic trap — the bot can’t crawl the page, so it never sees the noindex.)
• Structured data is not a ranking boost. It can make your result look richer, which can help clicks — but adding schema doesn’t move you up the results.

Not everything applies to you

The single most useful thing about this checklist is knowing what to skip. If you run a small site, you can ignore crawl-budget management entirely — Google itself says most sites don’t need to think about it. Want the full picture, including who does need those advanced sections? Switch to the Advanced tab.

TL;DR — Technical SEO 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 budget, faceted-nav control, log analysis, and JS-rendering engineering, which Google’s own crawl-budget doc confirms. Kill two myths on sight: robots.txt doesn’t deindex, and structured data isn’t a ranking factor. Treat Core Web Vitals as targets, not pass/fail gates — that’s Google’s own “strive to” language. And meeting every box still doesn’t guarantee indexing.

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: 2026-07-14 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: 2026-07-14 Google Search Essentials: Technical requirements

The mental model: four conditions

Google frames the whole of technical SEO 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: “Googlebot 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; indexing 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 budget 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 Console’s “Discovered - currently not indexed” state.

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

Starter track — small / brochure / local-business sites (< ~10K URLs): crawlability sanity check, indexing/canonical sanity check, HTTPS, mobile parity, one XML sitemap, one round of Core Web Vitals, valid structured data where it earns a rich result. Skip crawl budget, faceted-nav control, log-file analysis, and JS-rendering 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) hreflang.

1. Crawlability

• robots.txt correctness. Confirm you aren’t disallowing anything you want indexed. Google: “A robots.txt file tells search engine crawlers 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 deindexing 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 crawling + 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 chains and loops. Collapse A→B→C→D down to A→D. Chains waste crawl and leak a little on every hop. The crawling and redirects material goes deeper here.

2. Indexability

• Index coverage. In Search Console’s Page Indexing report, reconcile what you want indexed against what actually is. Investigate large “Discovered/Crawled - currently not indexed” buckets.
• Canonicalization. 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 sitemap — the canonicalization deep dive walks through consolidating them.
• Duplicate content. 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 content (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 indexing: “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 description 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 tags 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 text 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.”
• IndexNow. 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 results.”
• 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-LD 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:

• LCP — “strive to have LCP occur within the first 2.5 seconds of the page starting to load.”
• INP — “strive to have an INP of less than 200 milliseconds.”
• CLS — “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 Vitals are a tiebreaker among relevant results, not an override of relevance. Measure with real-user (CrUX/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 traps, 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 SEO territory.
• Faceted navigation 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 GEO/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.

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 Checklist, a separate, wider thing. Don’t try to make this one page do both jobs.

AI summary

A condensed take on the Advanced version:

• Technical SEO = the floor. Google’s four conditions: crawlable, indexable, understandable, renderable. Meeting them is necessary but not sufficient — “indexing isn’t guaranteed.”
• Gate by site type, not just topic. Most small sites can skip crawl budget, faceted-nav control, log analysis, and JS-rendering engineering. Google’s own thresholds: 1M+ pages changing weekly, or 10K+ changing daily, or lots of “Discovered - currently not indexed.”
• Priority order: crawlability (robots.txt, 4xx/5xx, redirect chains) → indexing (coverage, canonicalization, duplicates) → HTTPS + mixed content → mobile-first parity → XML sitemap + IndexNow → structured data → Core Web Vitals.
• Two myths to kill: robots.txt does not deindex (blocked-but-linked URLs can still appear bare); structured data is not a ranking factor (rich-result eligibility only).
• CWV are targets, not gates — Google’s “strive to” language: LCP < 2.5s, INP < 200ms, CLS < 0.1. And “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.”
• Mobile-first parity: same content, titles/meta, structured data, robots meta tags, and alt text across mobile and desktop; don’t lazy-load primary content on interaction.
• Prioritize by impact (solve the client’s actual pain point; 80/20). A checklist gets you “okay”; topical depth wins.
• Full-site version (technical + content + links) = the separate SEO Audit Checklist.

Official documentation

Primary-source documentation from the search engines.

Google

• Google Search technical requirements — the crawlable/works/indexable minimums, and the “indexing isn’t guaranteed” caveat.
• Introduction to robots.txt — what robots.txt does and doesn’t do.
• Build and submit a sitemap — formats, the 50MB/50,000-URL limit, and referencing it in robots.txt.
• Consolidate duplicate URLs — canonicalization signals and “don’t use robots.txt for canonicalization.”
• Intro to structured data markup — rich results, and the JSON-LD recommendation.
• Understanding Core Web Vitals — the “strive to” LCP/INP/CLS targets.
• Page experience in Google Search results — relevance vs. page experience.
• Mobile-first indexing best practices — the mobile/desktop parity requirements.
• Optimize your crawl budget — who actually needs crawl-budget management, with thresholds (formerly titled “Large site owner’s guide to managing crawl budget”; the doc moved under Google’s Crawling Infrastructure docs).

Bing / Microsoft

• Keeping Content Discoverable with Sitemaps in AI-Powered Search — Bing’s July 2025 sitemap + IndexNow guidance.
• Bing Webmaster Guidelines — crawling, indexing, ranking, and quality (cite by reference; the page is JS-rendered).

Quotes from the source

On-the-record statements from Google and Bing. Where a link is a deep link, it jumps to the quoted passage on the source page.

Google — the minimum requirements

• “Client and server error pages aren’t indexed.” — Google Search Central, Google Search technical requirements. Jump to quote
• “Just because a page meets these requirements doesn’t mean that a page will be indexed; indexing isn’t guaranteed.” Jump to quote

Google — robots.txt and canonicalization

• “A robots.txt file tells search engine crawlers 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.” Jump to quote
• “rel=“canonical” link annotations are a strong signal that the specified URL should become canonical… Don’t use the robots.txt file for canonicalization purposes.” — Google, Consolidate duplicate URLs. Read the doc

Google — structured data and Core Web Vitals

• “Adding structured data can enable search results that are more engaging to users… which are called rich results.” — Google, Intro to structured data markup. Read the doc
• “In general, Google recommends using JSON-LD 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.” Read the doc
• “strive to have LCP occur within the first 2.5 seconds”; “strive to have an INP of less than 200 milliseconds”; “strive to have a CLS score of less than 0.1.” — Google, Understanding Core Web Vitals. Read the doc
• “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” — Google, Page experience. Read the doc

Google — mobile-first indexing

• “Google uses the mobile version of a site’s content, crawled with the smartphone agent, for indexing and ranking.” — Google, Mobile-first indexing best practices. Read the doc

Google — crawl budget (who needs it)

• “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, Optimize your crawl budget. Jump to quote

Bing — sitemaps and IndexNow (July 2025)

• “XML remains the preferred format for sitemaps.” / “The lastmod field in your sitemap remains a key signal, helping Bing prioritize URLs for recrawling.” — Fabrice Canel & Krishna Madhavan, Bing Webmaster Blog. Read the post

Patrick Stox — how to prioritize an audit

• “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.” — Patrick Stox, quoted in Ahrefs’ Free SEO Audit Template. Jump to quote

Which checklist should I actually run?

Don’t run the same 90-item list on every site. Start here.

Q1. How many URLs does your site have, and how fast does content change?

• Under ~10,000 URLs, changing occasionally → run the Starter track and stop: crawlability sanity check, indexing/canonical sanity check, HTTPS, mobile parity, one XML sitemap, one round of Core Web Vitals, valid structured data where it earns a rich result. Skip crawl budget, faceted-nav control, log analysis, and JS-rendering engineering. Go to Q3.
• 10,000+ URLs changing daily, or 1M+ changing weekly, or lots of “Discovered - currently not indexed” → run the Advanced track (Starter + crawl budget + faceted nav + JS rendering + logs). Go to Q2.

Q2. Is the site JavaScript-heavy or international?

• JS-heavy (SPA, client-rendered content/links) → add a rendering audit: confirm critical content and <a href> links exist in the rendered HTML. This is the item most likely to be silently costing you indexing.
• Genuinely multi-region / multi-language → add hreflang, done properly, in its own workstream. If you’re not truly international, skip it.
• Neither → proceed to Q3.

Q3. What did the audit surface — and what should you fix first?

• A crawl/index blocker (robots.txt disallow on important pages, mass noindex, wrong canonical, site-wide 5xx) → fix first, always. These gate everything below.
• Lots of medium issues, limited time → apply the 80/20: fix the ~20% that moves the needle, and if it’s a client, fix the specific pain point they came to you with first. Don’t hand over 90 undifferentiated line items.
• Only cosmetic/edge issues left → you’ve cleared the floor. Stop optimizing plumbing and go do content and links.

Q4. Do you actually want the full-site version?

• Yes — technical + content + on-page + links → this technical checklist isn’t it. Run the broader SEO Audit Checklist instead; this page is technical-only by design.
• No — just the technical floor → you’re on the right page.

One-line version: small + stable → Starter track only; big/JS/international → add the advanced sections; then fix crawl/index blockers first and prioritize the rest by impact.

The technical SEO checklist

Two tracks. Run the Starter track on any site; add the Advanced items only if you cleared the site-type gate (10K+ URLs changing daily, 1M+ weekly, or JS-heavy/international).

Starter track — every site

Crawlability

• robots.txt doesn’t disallow anything you want indexed (and does block low-value spaces like internal search).
• No important URL is blocked in robots.txt and relying on a noindex (the trap).
• Unexpected 4xx/5xx fixed; important pages return 200.
• Redirect chains/loops collapsed to a single hop.

Indexability

• Page Indexing report reconciled — what you want indexed actually is.
• Canonicals point to one preferred version; no conflicting signals across HTML tag, HTTP header, and sitemap.
• http→https and www/non-www consolidated to one version.

HTTPS

• Whole site on HTTPS; http redirects to https.
• No mixed content (secure page loading insecure assets).

Mobile

• Mobile version has the same content, titles/meta, structured data, robots meta tags, and alt text as desktop.
• Primary content isn’t lazy-loaded on user interaction.

Sitemaps

• XML sitemap lists only canonical, indexable URLs; accurate lastmod; under 50MB/50,000 URLs per file.
• Sitemap submitted in Search Console and Bing Webmaster Tools, and referenced in robots.txt.

Structured data

• Schema (JSON-LD) valid in the Rich Results Test, and only used where it earns a rich result.

Core Web Vitals

• LCP, INP, CLS reviewed on field/CrUX data against Google’s targets (2.5s / 200ms / 0.1) — treated as targets, not pass/fail gates.

Advanced track — large / ecommerce / JS-heavy / international only

• Crawl budget reviewed (only if past Google’s thresholds); waste removed (parameters, facets, traps, duplicates).
• JS rendering audited — critical content and <a href> links present in rendered HTML.
• Faceted navigation: decided which combinations are crawlable/indexable.
• Server logs analyzed for crawl waste and uncrawled important URLs.
• IndexNow wired up for real-time change submission to Bing and participating engines.
• hreflang correct and reciprocal (only if genuinely multi-region/multilingual).
• AI-crawler access explicitly decided in robots.txt.

The mental models

1. The four conditions — crawlable → indexable → understandable → renderable. Every technical item serves one of these. When a page isn’t performing, find which condition it’s failing before you touch anything: is it even crawlable? Indexable? Understood? Rendered?

2. Floor, not ceiling. Technical SEO clears the floor so content and links can do their work. “Indexing isn’t guaranteed” even when you pass — so don’t treat a green technical audit as “SEO done.”

3. Gate by site type. The single most useful move: decide up front which sections don’t apply. Small/stable site → Starter track, skip the advanced plumbing. Large/JS/international → add it. Google gates its own crawl-budget guidance this way; you should too.

4. Signals vs. directives. Know which controls Google must obey and which are merely strong signals. noindex is a directive; rel=canonical is “a strong signal” Google can override; CWV targets are “strive to” goals, not gates. Mislabeling a signal as a guarantee is where most bad advice comes from.

5. Impact over completeness (80/20). A 90-item checklist is a menu, not a to-do list. Fix the ~20% that moves the needle, solve the actual pain point first, and stop optimizing plumbing once the floor is clear.

6. This is the technical slice. Crawl/index/render/serve mechanics live here; content quality, keyword targeting, and links live in the broader SEO Audit Checklist. Keep the boundary clean so neither job gets half-done.

Technical SEO — quick-reference

What each control does

Core Web Vitals targets (Google’s “strive to” numbers)

Crawl-budget “do I care?” thresholds (Google’s own, deliberately rough)

• ~1M+ pages changing about weekly → yes.
• 10K+ pages changing daily → yes.
• Big “Discovered - currently not indexed” bucket → yes.
• Otherwise → “you don’t need to read this guide.”

Fast facts

• Sitemap limit: 50 MB / 50,000 URLs per file; XML preferred; reference it in robots.txt.
• Structured data: rich results, not rankings. JSON-LD recommended.
• IndexNow: Bing/Yandex/others — not Google. Google indexes the mobile version.
• Mobile parity: same content, titles/meta, structured data, robots meta tags, alt text.

Myths and mistakes to avoid

The traps that come up most — several are widely-repeated myths worth correcting:

• “Blocking a URL in robots.txt keeps it out of Google.” No. Google: “it is not a mechanism for keeping a web page out of Google.” A disallowed URL can still be indexed (bare, no snippet) if it’s linked externally. Use noindex or password protection.
• “Block it in robots.txt and noindex it for extra safety.” The single most common self-inflicted wound. If the URL is blocked, Googlebot never crawls it, so it never sees the noindex — and the URL can still surface bare. Pick one: allow crawl + noindex, or disallow (accepting it may still appear).
• “Adding schema boosts rankings.” No. Google frames structured data purely as rich-result eligibility and machine understanding — not a ranking signal. Sell it as richer results, not higher positions.
• “Passing Core Web Vitals beats a more relevant competitor.” No. “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” CWV is a tiebreaker-ish signal, not an override of relevance.
• “CWV thresholds are hard pass/fail gates.” Google’s own word is “strive to” — they’re targets. Chasing a perfect lab score at the expense of everything else is misspent effort.
• “Crawl budget matters for every site.” No. Google gates its own guide to 1M+ pages (weekly changes) or 10K+ (daily). Most sites are told outright “you don’t need to read this guide.” Don’t burn a small-site engagement on crawl-budget theater.
• “rel=canonical is a directive Google must obey.” No — it’s “a strong signal.” Google can and does pick a different canonical when other signals conflict. Reduce conflicting signals rather than assuming the tag wins.
• “A green technical audit means SEO is done.” No. “Indexing isn’t guaranteed” even when you pass. Technical SEO is the floor; content and links still have to show up.
• “Run the same 90-item list on every site.” The differentiator is knowing what to skip. Gate sections by site type, and prioritize by impact, or you’ll drown clients in irrelevant line items.

SOP: run a technical SEO checklist (recurring)

A repeatable pass. Roughly 60–90 minutes for a small site; a day-plus for large/JS-heavy. Run it quarterly, or after any big migration, redesign, or CMS change.

1. Confirm the site type and pick a track. Count URLs (Search Console → Pages, or a crawl) and note how fast content changes. Under ~10K and stable → Starter track only. Over the thresholds, or JS-heavy/international → add the Advanced sections. This decides what you skip.
2. Crawl the site with Screaming Frog, Ahrefs Site Audit, or similar. Capture status codes, redirect chains, blocked URLs, canonicals, indexability, and depth.
3. Check robots.txt first. Fetch /robots.txt, confirm nothing important is disallowed, and check for the disallow-plus-noindex trap. Confirm the Sitemap: line is present.
4. Reconcile indexing. In Search Console’s Page Indexing report, compare what’s indexed to what you want indexed. Investigate large “Discovered/Crawled - currently not indexed” and “Duplicate” buckets.
5. Verify HTTPS and mobile parity. Confirm site-wide HTTPS with no mixed content. Then compare the mobile-rendered page to desktop for content, titles/meta, structured data, robots meta tags, and alt text (Google indexes the mobile version).
6. Validate sitemaps and structured data. Confirm the XML sitemap lists only canonical, indexable URLs with accurate lastmod; run key templates through the Rich Results Test.
7. Pull Core Web Vitals from field data. Use the CrUX/field report in Search Console or PageSpeed Insights — not just lab scores — and compare against the 2.5s / 200ms / 0.1 targets.
8. (Advanced track) Analyze logs and crawl budget. Read server logs for crawl waste and uncrawled important URLs; audit JS rendering and faceted-nav combinations.
9. Prioritize the findings by impact, not count. Put crawl/index blockers at the top; apply 80/20 to the rest; if it’s a client, lead with their actual pain point.
10. Log a baseline and re-check next cycle. Record the state so next quarter’s pass measures progress, not a fresh start.

Ready-to-use AI prompts

Copy-paste starting points for triaging a technical SEO checklist with an LLM. Always verify LLM output against primary docs and your own crawl data — treat these as drafting aids, not sources of truth.

Pick the right track for a site

I run a website with about [N] URLs, and content changes roughly [how often]. It’s built on [CMS/framework], is [single-language / multi-region], and is [static / JavaScript-rendered]. Based on Google’s own site-size thresholds for crawl budget, tell me which sections of a technical SEO checklist genuinely apply to me and which I can safely skip. Be explicit about what to skip and why.

Triage a crawl export by impact

Here is a CSV export from a site crawl [paste columns: URL, status code, indexability, canonical, redirect chain, robots.txt status]. Group the issues into (1) crawl/index blockers to fix first, (2) medium-impact fixes, (3) cosmetic/low-impact. For each group, explain the SEO consequence in one sentence. Do not tell me to “fix everything” — rank by impact.

Explain a specific indexing status

A batch of my URLs shows “[exact Search Console status, e.g. Discovered - currently not indexed]”. Explain the likely causes in priority order, how to diagnose each, and the concrete fix. Flag anything that is a symptom of crawl budget vs. a per-page problem.

Sanity-check for the robots.txt + noindex trap

Here is my robots.txt [paste] and a list of URLs I’m trying to keep out of Google [paste]. For each URL, tell me whether my current setup will actually keep it out of the index or fall into the “blocked in robots.txt but still indexable via links” trap, and give the correct fix (allow-crawl + noindex, or password protection).

Draft a prioritized remediation plan

Turn these confirmed technical findings [paste] into a prioritized remediation plan for a developer: blockers first, then impact-ranked, each with the specific change to make and a one-line rationale. The client’s stated pain point is [X] — surface fixes related to that first.

Tools for working the technical SEO checklist

Start with focused tests for the failure you are checking. A single all-in-one score often hides the difference between crawl access, response behavior, index signals, rendering, and field performance.

Patrick’s free tools

• Google Index Checker checks observable status, redirect, noindex, and canonical blockers, then points you to URL Inspection for Google’s actual indexed state.
• robots.txt Tester tests URLs against bot rules and shows the winning allow or disallow rule. Use it before changing crawl controls.
• XML Sitemap Validator checks sitemap syntax, URL inventory, and file problems before you submit the file.
• Canonicalization Checker compares HTML and HTTP canonical signals and tests the target URL for conflicts.
• Bulk HTTP Status Code Checker checks status codes, destinations, chains, and loops across a URL set.
• Schema Markup Validator validates structured data syntax and Google rich-result requirements before release.
• Render Gap compares initial HTML with rendered output for JavaScript-dependent content, links, canonicals, and robots directives.
• Core Web Vitals Checker separates available field data from a current performance check so you do not mistake one lab run for user data.
• Mobile-Friendly Tester checks viewport, responsive layout, tap targets, and related mobile implementation signals.
• Log File Analyzer turns server logs into evidence of what search bots actually fetched, which is most useful on large sites.

Search-engine tools

• Google Search Console provides Page Indexing, URL Inspection, Crawl Stats, Sitemaps, Core Web Vitals, rich-result reports, manual actions, and security issues.
• Bing Webmaster Tools adds Bing’s first-party index and performance views, IndexNow, Site Explorer, Site Scan, and Crawl Control.

Crawlers and browser tools

• Ahrefs Site Audit or Screaming Frog SEO Spider is the scalable layer for crawling templates, status codes, directives, internal links, and structured data.
• Chrome DevTools exposes the network response, rendered DOM, console errors, and performance trace for individual pages.
• PageSpeed Insights and CrUX provide Google’s lab and field performance views; use field data for the standing user-experience baseline when it is available.

Test yourself: Technical SEO Checklist

Five quick questions on what belongs on a technical SEO checklist and how to prioritize it. Pick an answer for each, then check.

Resources worth your time

My related writing

• The Beginner’s Guide to Technical SEO — the bigger picture this checklist sits inside.
• SEO Audit Template — my 80/20, impact-first framing, and the “solve their actual pain point” advice; also the closest thing to the broader full-site audit.
• The Story of Blocking 2 High-Ranking Pages With Robots.txt — my first-party experiment on what robots.txt blocking actually does.
• Indexed, though blocked by robots.txt — the mechanism behind the disallow-plus-noindex trap.
• Robots.txt and SEO: Everything You Need to Know.

My speaking

• How Search Works (SlideShare) — my walkthrough of crawling, rendering, indexing, and ranking, which is the pipeline this whole checklist is protecting.

My published work worth citing

• Web Almanac 2021 — SEO chapter — I was lead author; the source for cross-signal canonical-conflict rates across the real web.
• Rankable Ep. 65 — Ranking Technical SEO Priorities (iPullRank) — me on how to prioritize technical issues on a roadmap, which is exactly this checklist’s organizing principle.

From around the industry

• Google Search technical requirements — the definitive statement of the minimums, and the “indexing isn’t guaranteed” caveat.
• Optimize your crawl budget (Google) — the source for the site-size gate (page renamed from “Large site owner’s guide to managing crawl budget” and moved under Crawling Infrastructure).
• Keeping Content Discoverable with Sitemaps in AI-Powered Search (Bing) — the sitemap + IndexNow guidance most Google-only checklists skip.
• SEO in 2026: Higher standards, AI influence, and a web still catching up (Chris Green, Search Engine Land) — a reality-check on where sites actually stand (HTTPS 91%+, robots.txt as a “policy surface”).
• Web Almanac 2022 — SEO chapter (HTTP Archive) — canonicalization-method and schema-adoption data across the web.
• Technical SEO Checklist: The Complete Guide (DebugBear) — a strong performance-leaning take on the same territory.
• Technical SEO checklist (90+ points) (Kristina Azarenko) — a thorough, prioritization-minded alternative checklist.

Stats worth citing

• HTTPS adoption ~91%+. Where sites actually stand on the HTTPS baseline heading into 2026 (HTTP Archive data, via Chris Green). Source
• Canonical adoption rose from 65% (2024) to 67%+ (2025). Coverage of the canonical tag is climbing but far from universal. Source
• ~67% of images lack a loading attribute; 91%+ of iframes lack one. Low-hanging performance wins most sites still leave on the table. Source
• Conflicting canonical signals appeared on ~0.3–0.4% of pages. Small but real — a reason larger sites should check for cross-signal canonical conflicts (Web Almanac 2021 SEO chapter, which I led). Source
• Sitemap file limit: 50 MB / 50,000 URLs per file — the hard ceiling to split large sitemaps against (Google). Source

Technical SEO Checklist

A technical SEO checklist is a prioritized list of the technical conditions a site must satisfy — crawlable, indexable, understandable, renderable — so search engines and AI answer engines can access and serve its pages. It's the technical-only slice of a full SEO audit.

Related: Crawling, Indexing, Canonicalization

Technical SEO Checklist

A technical SEO checklist is a prioritized, ordered list of the technical conditions a website must meet so search engines — and increasingly AI/answer engines — can crawl, render, index, and serve its pages. Google collapses the whole thing to four load-bearing conditions: pages must be crawlable, indexable, understandable, and renderable.

It’s deliberately narrow. A technical checklist covers crawlability, indexing, HTTPS, mobile-first parity, sitemaps, structured data, Core Web Vitals, canonicalization, and (for big sites) crawl budget — but not on-page content quality, keyword targeting, or link building. That broader “everything” version is a full SEO audit; the technical checklist is the technical-only floor beneath it.

Two things people get wrong about it:

• Meeting the checklist is necessary but not sufficient. Google is explicit: “Just because a page meets these requirements doesn’t mean that a page will be indexed; indexing isn’t guaranteed.” Technical SEO is the floor, not the ceiling.
• Not every item applies to every site. Google itself gates its crawl-budget guidance to very large or fast-changing sites — most small sites can skip whole sections. The best checklists are split by site type, not run identically for a 20-page brochure site and a 500K-SKU store.

Related: Crawling, Indexing, Canonicalization

Changelog