Most "technical SEO checklist" posts are alphabetical, e-commerce-flavored, and treat all 40 items as equally urgent. They aren't. 96.55% of all web pages get zero organic traffic from Google (Ahrefs, 2023), and on a large B2B SaaS site a big share of that is technical: pages that never get crawled, pages stuck in "Crawled, currently not indexed," content hidden behind client-side JavaScript, thin programmatic pages eating crawl budget. This is the checklist sorted by what actually moves the needle, built for SaaS sites rather than online stores.

Key Takeaways - Only 43% of mobile origins pass all three Core Web Vitals (HTTP Archive, 2024). It's the norm to fail, not the exception. - Googlebot renders virtually all HTML it crawls, but the median delay between crawl and render is about 10 seconds, with the 99th percentile around 18 hours (Vercel/MERJ, 2024). Client-side-only pages can sit invisible for hours. - INP is the only Core Web Vital weakly correlated with ranking; the others "prevent losses but do not guarantee wins" (Semrush, 2024). Speed pays you back in conversions, not positions. - A 0.1-second mobile speed improvement lifted retail conversions 8.4% and average order value 9.2% in a Google/Deloitte study of 37 brands (web.dev, 2020).

What technical SEO actually is, and what it isn't

Technical SEO is the set of things that decide whether search engines can crawl, render, index, and trust your site, separate from your content (on-page SEO) and your backlinks (off-page). It splits into three buckets, and they don't carry equal weight:

• Indexability: can Google find the page, fetch it, render it, and decide to keep it? This is where rankings are won or lost, because a page that isn't indexed can't rank at all.

• Performance and Core Web Vitals: how fast and stable the page feels. A genuine business lever, but a weak ranking signal.

• Architecture and hygiene: site structure, internal linking, sitemaps, HTTPS, structured data, redirects. Mostly table stakes, with one exception worth real effort (structured data, below).

A checklist that treats "fix broken links" with the same urgency as "your new pages aren't getting indexed" is wasting your time. Sort by impact.

The fixes that move rankings vs the ones that are just hygiene

The single most useful thing you can do with a technical audit is rank the findings by expected impact, not by alphabet. Here's the order that holds up against the data.

Tier 0, indexability. If pages aren't indexed, nothing else matters. Googlebot does attempt to render essentially all HTML it crawls, including React Server Component streams (Vercel/MERJ, 2024), so "Google can't read JavaScript" is outdated. But the render queue has a tail: median crawl-to-render delay around 10 seconds, 90th percentile near 3 hours, 99th percentile near 18 hours, and URLs with query strings sit longer. A client-side-only marketing page can be functionally invisible for a while, and "Crawled, currently not indexed" in Search Console is Google telling you it saw the page and chose not to keep it.

Tier 1, performance as a conversion lever. Worth doing, but be honest about why. INP is the only Core Web Vital that shows even a weak correlation with SERP position, and Semrush's own conclusion is that Core Web Vitals "prevent losses but do not guarantee wins" (Semrush, 2024). The return on investment is on the revenue side: a 0.1-second mobile improvement moved retail conversions up 8.4% and AOV up 9.2% across 37 brands (web.dev, 2020); Vodafone reported 8% more sales from a 31% LCP improvement, and Tokopedia saw session duration rise 23% after cutting LCP 55% (web.dev, 2021).

Tier 2, architecture. Crawl budget allocation, internal linking, subdomain decisions. Matters most on big sites.

Tier 3, hygiene. HTTPS, sitemaps, redirect chains, canonical tags. Get them right once and stop thinking about them, with structured data as the one item that earns ongoing attention.

Indexability: is the page even in the index?

Start every technical audit with one question per important URL: is it indexed? Search Console's Page Indexing report and the URL Inspection tool answer it. Then triage like this:

1. Not in the index, and not crawled ("URL is unknown to Google"). Discovery problem. Check that the page is in your sitemap, that the sitemap was re-fetched recently, and that internal links point to it from pages Google already crawls.

2. Crawled, currently not indexed. Quality or value problem. Google saw it and passed. Usual culprits: thin or near-duplicate content, programmatic pages with little unique value, content rendered only client-side, or a brand-new low-authority domain. This is the state that bites SaaS sites with large templated sections.

3. Indexed but not ranking. Now it's a content and authority problem, not a technical one.

Frameworks make a measurable difference here. In a controlled comparison of identical sites, a Next.js build scored 100% on Lighthouse SEO versus 88.8% for a client-side-rendered React build, with the gap widening on slower connections (Pati & Zaki / The Web Conf, 2025). If you're on a JS framework, the JavaScript SEO traps in React and Next.js sites are worth a close read. And one underrated indexability risk that's also a security risk: your robots.txt is publicly readable, and what you Disallow you also advertise.

Core Web Vitals: a conversion lever, not a ranking lever

Treat Core Web Vitals as a revenue and UX project that happens to be SEO-adjacent. Only 43% of mobile origins (and 54% of desktop) pass all three thresholds (HTTP Archive, 2024). Mobile INP "good" rates climbed to about 74% after INP became a Core Web Vital, CLS sits around 76%, and LCP is the laggard at roughly 52% on mobile. A page-level study of ~208,000 pages put LCP "good" at 53.8% and CLS "good" at 65.1% (Backlinko). So failing one of these is completely normal, which is exactly why fixing them is a differentiator on conversion, not on rank.

The thing to measure is field data (real Chrome users, in the Chrome UX Report), not just a Lighthouse lab score on a throttled phone. New, low-traffic SaaS sites often have no CrUX field data at all, which is itself a signal you don't have enough traffic yet for performance to be your bottleneck. For the SaaS-specific version of all this, see Core Web Vitals for B2B SaaS in 2026.

The SaaS-specific failure modes no generic checklist covers

This is where a SaaS site differs from a Shopify store, and where most checklists go quiet:

• App shell vs marketing site. Your /app (or app.yourdomain.com) is a single-page application behind a login. It should be noindex or robots-disallowed, and it should not be bleeding into the index alongside your marketing pages. Check that the boundary is clean.

• Programmatic and faceted pages. Integration directories, /templates, /vs-competitor comparison pages, location pages. These are great for coverage and terrible for crawl budget if 80% of them are near-duplicate. Decide which are indexable, canonicalize or noindex the rest, and don't link to the thin ones from your nav. The hub-and-spoke architecture for SaaS topic clusters and internal linking beyond the "related posts" widget are the right mental models.

• Subdomain sprawl. Docs on docs., blog on blog. or /blog, status page, help center, community forum. Each is a separate property in Google's eyes. Make the call deliberately, don't let it happen by accident.

• Staging leakage. A staging or preview subdomain that got crawled and indexed is a duplicate-content and a security problem at once. Search site:staging.yourdomain.com and site:preview. once a quarter.

• The noindex someone forgot to remove after launch. It happens more than anyone admits. Spot-check.

Structured data: the one hygiene item with real CTR data

Most checklists say "add schema" and move on. Here's why it earns ongoing attention: a Milestone Research analysis of 4.5 million queries found pages shown as rich results captured 58% CTR versus 41% for non-rich results, roughly a 40% relative uplift, with FAQ-rich results around 87 to 91% (Search Engine Journal, 2020). For a B2B SaaS site, the high-value markup is Organization, BreadcrumbList, FAQPage on resource pages, Product or SoftwareApplication on the product pages, and Article on the blog. Validate it, and re-validate after template changes, because a deploy that breaks your JSON-LD removes the rich result without telling you. Our schema markup cheat sheet for SaaS companies has copy-ready JSON-LD.

The HTTPS and security overlap

HTTPS is still a confirmed ranking signal, now folded into the page-experience signals inside Google's core systems rather than a standalone factor, and Google has said explicitly that dropping it from the named list doesn't mean it can be ignored (Google Search Central). The technical-SEO version of this is mundane (full-site HTTPS, HSTS, no mixed content, valid certificate chain), but it sits on the same audit as the security questions, which is the part most SEO checklists skip: exposed staging, leaked .env or .git, an over-permissive robots.txt Disallow list that doubles as a site map for an attacker. If you're auditing crawlability, you're already most of the way to auditing exposure. Mobile-first indexing is also now the default for 100% of sites (Google Search Central, 2024), so anything that exists only on the desktop layout effectively doesn't exist to Google; we've covered what mobile-first indexing actually means for a SaaS site in 2026 separately.

The prioritized checklist

Work top to bottom. Don't start at the bottom because it's easier.

P0, indexability - Pull the Page Indexing report; triage every "Crawled, currently not indexed" and "Discovered, not indexed" URL. - Confirm your sitemap is current and has been re-fetched by Google recently. - Render-test key pages (URL Inspection "View crawled page"); fix anything that's client-side-only. - Make sure /app, staging, and any preview subdomains are out of the index. - Audit noindex, robots.txt Disallow, and canonical tags for mistakes.

P1, performance (as conversion) - Get field-data Core Web Vitals (CrUX), not just Lighthouse. - Fix LCP first (it's the most-failed metric), then INP, then CLS. - Set a regression budget so a deploy can't quietly tank a metric.

P2, architecture - Decide your subdomain strategy on purpose. - Canonicalize or noindex thin programmatic pages; keep the strong ones in the nav. - Make sure important pages are linked from pages Google crawls often.

P3, hygiene - Full HTTPS, HSTS, no mixed content. - Clean up redirect chains and loops. - Add and validate structured data; re-validate after template changes. - Check for exposed .env, .git, directory listings, and an over-broad robots.txt.

Frequently Asked Questions

Do Core Web Vitals affect Google rankings?

Barely. INP is the only Core Web Vital that shows even a weak correlation with SERP position, and Semrush's own framing is that Core Web Vitals "prevent losses but do not guarantee wins" (Semrush, 2024). The real payoff is on conversions: a 0.1-second mobile speed improvement lifted retail conversions 8.4% in a Google/Deloitte study (web.dev, 2020). Fix them for revenue and UX, not for a ranking bump.

How do I know if Google has indexed my page?

Use Search Console's URL Inspection tool on the exact URL. It returns the coverage state: "Submitted and indexed" means you're in; "Crawled, currently not indexed" means Google saw it and passed (usually a quality or value issue); "URL is unknown to Google" means it was never crawled (a discovery issue). The Page Indexing report gives you the same states across the whole site.

Is technical SEO still worth it for a small SaaS site?

Yes, but the priorities flip. A small site rarely has a crawl-budget problem; it has a "Google decided this isn't worth indexing" problem. So on a small SaaS site, the technical work is mostly: make sure pages are actually indexable, not client-side-only, not accidentally noindex'd, and that the few pages you have are clearly more useful than the alternatives. Performance optimization is lower priority until you have enough traffic to have CrUX data.

What's the difference between technical SEO and on-page SEO?

Technical SEO is about whether search engines can crawl, render, index, and trust your site (indexability, performance, architecture, structured data, HTTPS). On-page SEO is about the content on a given page (the actual writing, headings, internal links, keyword targeting). Technical SEO decides whether the page gets a fair shot; on-page SEO decides whether it wins once it has one.

How often should I run a technical SEO audit?

A full audit once or twice a year, plus a standing rule that the indexability checks (Page Indexing report, render-testing key templates, structured-data validation) run after any significant deploy or template change. The most common way technical SEO breaks isn't neglect, it's a release that quietly introduced a noindex, a broken canonical, or client-side-only rendering on a page that used to be server-rendered.

The bottom line

Technical SEO isn't a 40-item list to grind through alphabetically. It's three buckets with very different stakes: indexability (where rankings are actually won), performance (a conversion lever wearing an SEO costume), and hygiene (do it once). For a B2B SaaS site, start with the Page Indexing report, find the pages Google saw and rejected, figure out why, and fix that before you touch anything else.