Technical SEO Checklist for 2026: What to Check, in Order

A technical SEO checklist is a list of site-level checks that confirm search engines can crawl your pages, index them, render them properly and serve them to users quickly and securely. The order matters more than the length. If Google can’t crawl a page, nothing else on the list helps, so work from crawling to indexing to rendering to speed, then structured data and AI crawler access. This 2026 version drops outdated advice like FID and Search Console geotargeting, and adds the reports that exist today.

I run some version of this list on every site we take on. On a small WordPress site it takes an afternoon. On a large store with filters and thousands of URLs, it can take a week, and the second half of the list matters far more.

What Changes the Checklist for Your Site?

The same 31 checks apply everywhere, but four variables decide which ones deserve your time first:

1. Size. Under roughly 1,000 URLs, crawl budget almost never matters. Above 10,000, it can.
2. Platform. WordPress and Shopify handle sitemaps and canonicals for you, mostly. Custom JavaScript builds handle almost nothing by default.
3. Languages and regions. One language, one market means you skip hreflang entirely.
4. Filters and parameters. Stores and listing sites with faceted navigation can generate near-infinite URL combinations.

My rule of thumb is simple. If a stage fails, stop and fix it before moving on. A beautiful Core Web Vitals score means nothing on a page Google never indexed, and I’ve lost count of the audits where someone spent weeks shaving milliseconds off a site that was quietly blocking its own blog folder.

Each stage below opens with the reason it matters, then the checks. The branches near the end form the advanced technical SEO checklist: the extra work for large stores, JavaScript apps and multilingual sites.

Stage 1: Can Google Crawl the Site?

Crawling is the gate. When I audit a site that “suddenly dropped,” the cause is often a single line in robots.txt or a firewall rule, not an algorithm update. Check this stage first, even on sites you think are fine.

If Crawl stats show Googlebot getting errors or timeouts, talk to your host before you touch anything else. If crawling looks healthy but new pages take weeks to appear, the problem is usually discovery, which means weak internal linking or a stale sitemap.

• robots.txt loads and doesn’t block important paths. Check it in the robots.txt report in Search Console, which replaced the old robots.txt Tester. Google ignores anything past the first 500 KiB of the file.
• XML sitemap exists, is referenced in robots.txt and submitted in Search Console. One sitemap file can hold up to 50,000 URLs or 50MB uncompressed, per Google’s sitemap documentation.
• The sitemap only lists canonical, indexable URLs that return 200. No redirects, no noindex pages.
• Your CDN or firewall isn’t blocking Googlebot. Security plugins and bot protection are the usual culprits.
• Crawl stats look normal. Open Settings, then Crawl stats, and look for spikes in server errors or response time.
• Important pages are within a few clicks of the homepage and have at least one internal link. Orphan pages get crawled rarely, if at all.

Stage 2: Is Google Indexing the Right Pages?

Indexing is where most of the confusion lives. A page can be crawlable and still never make it into the index, which is exactly why the Page indexing report in Search Console should be the first screen you check every month, not an afterthought.

• Page indexing report reviewed. Look at the “Why pages aren’t indexed” table and sort by count.
• Each page has one self-referencing canonical, or points to the true canonical if it’s a duplicate.
• No canonical chains or loops. Page A shouldn’t canonicalize to B, which canonicalizes to C.
• Noindex is only on pages you truly want hidden. Staging leftovers are common after a redesign.
• HTTP and www variants 301 to one version, in a single hop.
• Redirect chains are one hop at most, and old internal links point to final URLs.
• 4xx errors are fixed or redirected where a real replacement exists; 5xx errors are zero.

Not every excluded page is a problem. Tag archives, internal search results and thin filter pages should stay out of the index. What I look for is the mismatch: pages you care about sitting under “Crawled, currently not indexed” or “Discovered – currently not indexed,” or the count of indexed pages swinging hard from one month to the next. Those are signals worth chasing. A few hundred excluded feed URLs are not.

Stage 3: Can Google Render What Users See?

Google indexes the mobile version of your site. Its final move to mobile-first indexing meant sites still crawled by the desktop crawler switched to the mobile one after July 5, 2024.

• Content and links are the same on mobile and desktop. Hidden mobile menus are fine; missing content is not.
• Key content appears in the rendered HTML. Use URL Inspection, then “View crawled page,” to confirm text and links aren’t stuck behind JavaScript.
• Lazy-loaded content doesn’t need a scroll or click to load for Google to see it.
• CSS and JavaScript files aren’t blocked in robots.txt.

Note that the Mobile Usability report and the Mobile-Friendly Test were retired on December 1, 2023. Lighthouse in Chrome DevTools is now the practical replacement.

For most WordPress sites this stage passes without drama, because the HTML arrives fully built from the server. It’s the sites built as JavaScript apps, or themes that load product grids and reviews through scripts after the page loads, where I find content that users see and Google doesn’t.

Stage 4: Is the Page Experience Good Enough?

Core Web Vitals are now LCP, INP and CLS. Interaction to Next Paint replaced First Input Delay on March 12, 2024, so any checklist still telling you to optimize FID is out of date.

• LCP is 2.5 seconds or less for real users.
• INP is 200 milliseconds or less. This one catches heavy JavaScript, chat widgets and bloated page builders.
• CLS is 0.1 or less. Reserve space for images, ads and embeds.
• Measured at the 75th percentile of page loads, on mobile and desktop separately, which is how web.dev defines passing.
• The whole site runs on HTTPS with no mixed content. The HTTPS report in Search Console lists URLs that fall short.

How common is failing? The HTTP Archive’s 2025 Web Almanac found only 48% of mobile websites had good Core Web Vitals, against 56% on desktop. It also found images were the LCP element on 76% of mobile pages. So if your LCP is slow, look at the hero image first: its size, its format and whether it’s lazy-loaded when it shouldn’t be.

Honestly, I’d treat speed as a tiebreaker, not a magic lever. A fast page with thin content still loses. But a page that fails INP on mobile is a page real people abandon, and that’s reason enough to fix it.

Stage 5: Do Structure and Markup Help Google Understand Pages?

These are the on-page technical basics. They’re fast to fix in bulk with a crawler like Screaming Frog or Lumar (formerly DeepCrawl). I run a crawl, export the duplicate titles and missing descriptions, and fix them by template first, because one theme fix can repair 500 pages at once.

• Every indexable page has one unique title and meta description.
• One H1 per page, with H2 and H3 levels in order.
• Short, lowercase, hyphenated URLs without tracking parameters.
• Images have descriptive alt text, sensible file names and modern formats like WebP or AVIF.
• Structured data matches visible content and validates in the Rich Results Test. Article on posts, Organization on the homepage, BreadcrumbList sitewide, Product on product pages.

Two schema warnings. HowTo rich results no longer show in Google, so don’t spend time adding them. FAQ rich results stopped appearing in Google Search on May 7, 2026; existing FAQ markup does no harm, but adding more of it won’t earn a rich result.

I’d rather see three schema types done correctly than ten done badly. The most common error I find is markup that describes something the page doesn’t show, like review stars with no reviews on the page or a product price that changed months ago. Google’s guidance is clear that structured data should match visible content, and mismatches are how sites lose rich results they once had.

Stage 6: Are AI Crawlers Handled on Purpose?

This is the new part of any technical SEO checklist for 2026. For Google, the rule is simple: AI Overviews and AI Mode use the same Googlebot and the same index as normal Search. Google’s documentation on AI features and your website says a page only needs to be indexed and eligible for a snippet, and that you don’t need new machine-readable files or special markup.

• Don’t block Googlebot to “opt out” of AI Overviews. You’d drop out of Search too. Use nosnippet or max-snippet if you need to limit what’s shown.
• Decide on Google-Extended deliberately. It controls use of your content for Gemini training and grounding, and Google says it has no effect on Search rankings.
• Review other AI user agents such as GPTBot, OAI-SearchBot, ClaudeBot and PerplexityBot in robots.txt. Blocking a search-focused bot can remove you from that assistant’s answers.
• Check that bot protection isn’t blocking them by accident. I see this on Cloudflare sites more than anywhere else.

My take: most small businesses should allow the search-focused AI bots and make a conscious call on the training bots. Blocking everything feels safe, but it quietly removes you from the places a growing share of people now ask questions. If you’re unsure, write down what you decided and why, then revisit it every 6 months.

Branch: Large Stores and Faceted Navigation

If your site has thousands of product and filter URLs, the priorities shift. Crawl budget becomes real. Canonicalize or noindex thin filter combinations, keep parameter URLs out of the sitemap, and watch Crawl stats for Google spending its time on URLs you don’t care about. Stages 1 and 2 are where a store’s traffic is won or lost.

The test I use is blunt. Pick a filter combination, say color plus size plus price range, and ask whether anyone would ever search for that exact page. If yes, like “black running shoes size 10,” give it a clean URL (my URL structure rules apply), a unique title and a place in the sitemap. If no, keep it crawlable for users but out of the index. Out-of-stock products are the other store problem: if an item is coming back, keep the page live with a clear stock message; if it’s gone for good and a close replacement exists, redirect to it.

Branch: JavaScript Apps and Multilingual Sites

On a React, Vue or Angular site, Stage 3 jumps to first place. Server-side rendering or static generation removes most of the risk. For sites in several languages, hreflang tags must be reciprocal and use valid ISO codes. The old International Targeting report is gone from Search Console, and country targeting there is no longer supported, so hreflang and clear URL structures are what’s left.

For JavaScript sites, the quick check takes two minutes. Open URL Inspection, run a live test, and compare the rendered HTML with what you see in the browser. If your product descriptions, prices or internal links are missing from the rendered version, Google is indexing a thinner page than your visitors get. That gap explains more “why won’t this rank” questions than any keyword issue I come across.

For multilingual sites, I also check that each language version is a real translation, not a machine-translated copy with the old language’s title tags still in place. Hreflang can’t rescue a page that reads badly in its own language.

Edge Cases I See in Audits

These don’t fit neatly into a stage, but they turn up often enough that I check for them on every site.

• Staging sites indexed. Password-protect staging; noindex alone isn’t enough if links leak.
• Sitemap lastmod faked. Google ignores priority and changefreq, and only trusts lastmod when it’s consistently accurate.
• Soft 404s. Empty category pages returning 200 often get flagged. Add products or return a real 404.
• Plugins fighting plugins. Two SEO plugins outputting two canonicals is more common than you’d think.

Where to Start, by Site Type

How Often Should You Run This Technical SEO Checklist?

I check Search Console’s Page indexing and Core Web Vitals reports monthly and run a full crawl quarterly. After any migration, redesign or major plugin change, run the whole list within a week. Those are the moments sites break, and it’s why tested plugin updates get their own line in my WordPress maintenance cost breakdown.

If you want a second pair of eyes, our technical SEO service starts with a free audit, and we quote after we’ve seen the site. For local businesses, pair this with our local SEO checklist, since the local signals sit on top of a sound technical base.

Frequently Asked Questions

What Is the Most Important Item on a Technical SEO Checklist?

Crawl access. If robots.txt, a firewall or a server error blocks Googlebot, every other fix is wasted. Check the robots.txt report and Crawl stats in Search Console before anything else.

Is FID Still a Core Web Vital?

No. Google replaced First Input Delay with Interaction to Next Paint on March 12, 2024. INP measures responsiveness across all interactions on a page, not just the first one, and 200 milliseconds or less counts as good.

How Often Should I Update My XML Sitemap?

Automatically, whenever pages are added, removed or meaningfully changed. Most CMS plugins do this for you. Keep lastmod accurate, because Google only trusts it when it’s reliable, and it ignores priority and changefreq.

Do I Need an llms.txt File for AI Search?

Not for Google. Google says you don’t need new AI text files or special markup to appear in AI Overviews or AI Mode. Whether to publish one for other AI tools is a business choice, not a technical requirement, and my guide to whether your site needs an llms.txt file covers when that choice is worth 20 minutes.

Last updated: September 2026 by Mizanur Rahman