Technical SEO audit checklist SaaS teams run in 2026

The technical SEO audit checklist SaaS teams run in 2026

A technical SEO audit checklist SaaS teams can run in a day covers seven systems, in impact order: crawlability and robots policy, indexation and canonicals, JavaScript rendering, Core Web Vitals, structured data, site architecture, and auth-wall hygiene. The order matters: a page that cannot be crawled earns nothing from speed work; a page that renders only after heavy client-side JavaScript earns nothing from schema. Each step names a tool and a pass condition.

The stakes are commercial. SEOmator's 2026 guide claims organic search drives 53% of SaaS website traffic, citing SeoProfy's 702% average SEO ROI for B2B SaaS — vendor figures, but showing how much pipeline rides on discoverability. Pew Research Center found in July 2025 that clicks on traditional results dropped to 8% when an AI summary appeared, from 15% without one. Citability is now technical scope, hence crawler policy is step one.

Step 1 — Crawlability and robots/AI-crawler policy

Start with robots.txt, the gate every other step depends on: one leftover Disallow: / from staging hides the entire site from Googlebot and from the crawlers that feed AI answer engines.

Google's robots.txt guide is explicit that the file manages crawl traffic, not indexation — noindex keeps pages out of search. The 2026 audit also declares AI-crawler policy: Google documents that AI Overviews and AI Mode need nothing beyond normal crawlability, indexation, and snippet eligibility, so blocking crawlers is a strategic call.

• Production robots.txt returns 200 with no staging-era Disallow: / — pass: curl -s https://yoursite.com/robots.txt shows only deliberate rules.
• Every Disallow rule has a named reason; marketing, docs, and blog paths stay open unless a written policy says otherwise (Tool: Screaming Frog robots report).
• AI-crawler directives are explicit, never wildcard: GPTBot, OAI-SearchBot, PerplexityBot, ClaudeBot, Google-Extended each allowed or blocked per citation strategy (Tool: robots.txt review plus server logs).
• XML sitemap referenced from robots.txt returns 200, holds only canonical URLs, stays under 50,000 URLs per file (Tool: Screaming Frog sitemap export).

Step 2 — Indexation and canonicals

Crawled is not indexed. Search Console's Page Indexing report shows which URLs Google indexed and why the rest are not — reconcile it against your sitemap first.

Google is clear that not every URL should be indexed: the target is 100% of canonical, revenue-bearing pages. Classic SaaS failures are a templated noindex shipped from staging, and a canonical tag pointing every feature page at /products/, collapsing hundreds of URLs into one.

• Indexed count tracks the sitemap's canonical URL count; a gap over ~30% gets investigated per URL class (Tool: Search Console Page Indexing report).
• No noindex on pricing, feature, docs, or blog templates — check every template's rendered HTML, not just the homepage (Tool: Screaming Frog custom extraction).
• Every page carries a self-referencing canonical unless consolidation is intentional, with canonical, hreflang, sitemap, and internal links agreeing (Tool: Sitebulb or Screaming Frog).
• "Crawled — currently not indexed" clusters usually mean duplication or thin content; fix by consolidation, not resubmission (Tool: Search Console plus URL Inspection).
• Removed pages return 404 or 410, not 200 with thin content — the latter are soft 404s (Tool: crawl status-code report).

Step 3 — JavaScript rendering: the SaaS failure mode

If View Source shows an empty shell and the pricing table appears only after JavaScript runs, every crawler that skips rendering indexes nothing — and several AI-answer crawlers execute less JavaScript than Googlebot. Rendering parity between initial HTML and the browser is the highest-value fix on this checklist.

Googlebot renders JavaScript in a delayed second wave, and server-side or static generation for indexable routes removes the dependency entirely — one reason SaaS marketing sites increasingly ship as static exports on edge CDNs.

• View Source on pricing, feature, and docs pages shows headings, body copy, and links before JavaScript runs (Tool: View Source versus the rendered DOM).
• URL Inspection's live test shows the rendered DOM Google indexes; missing content there is a bug, not a quirk (Tool: Search Console URL Inspection).
• Primary nav and footer links live in static HTML, not behind click handlers — crawl with JS off, then on; the delta is the finding (Tool: Screaming Frog).
• Tab, accordion, and comparison-table content is in the DOM at load; collapsed is fine, injected-on-click is not (Tool: Chrome DevTools Elements panel).
• Client-side routes return real HTTP statuses: a missing page returns 404, not 200 with an empty shell (Tool: curl -I on a bad URL).

Step 4 — Core Web Vitals: LCP, INP, CLS

Core Web Vitals are field metrics scored at the 75th percentile of real loads: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1, per Google. SEOmator's guide cites HTTP Archive's 2025 Web Almanac finding that only 48% of mobile sites pass all three — clearing the bar puts a SaaS site ahead of most of the mobile web.

INP replaced FID in March 2024 and is where SaaS bleeds: chat widgets, A/B scripts, and tag managers block the main thread. LCP is usually the unoptimized hero screenshot; CLS is usually injected banners and embeds without reserved space.

• Field LCP at or under 2.5s on mobile: identify the LCP element, preload it if an image, serve AVIF/WebP at responsive sizes (Tool: PageSpeed Insights / CrUX).
• Field INP at or under 200ms: profile long tasks over 50ms and defer third-party widgets (Tool: PageSpeed Insights field data plus a DevTools performance trace).
• CLS at or under 0.1: explicit width/height on images and iframes, no late-injected promo bars (Tool: PageSpeed Insights).
• Field data monitored continuously — a deploy that regresses INP on the pricing page is a revenue event (Tool: Search Console Core Web Vitals report plus web-vitals RUM).

Step 5 — Structured data as AI-citation infrastructure

Structured data tells Google and AI answer engines what a page is. Google's documentation makes the verified claim: markup helps Google understand content and enables rich results, with JSON-LD the recommended format. Digital Applied and RivuletIQ extend the argument in their 2026 checklists — clean, specific schema is the disambiguation layer AI engines use to choose citations — a vendor position, but consistent with how retrieval systems resolve entities.

Either way the audit actions are identical: valid JSON-LD that matches visible content, using the most specific schema.org type available.

• JSON-LD validates with zero errors on every template; Google recommends JSON-LD over Microdata and RDFa (Tool: Rich Results Test).
• SoftwareApplication on product pages, Organization with sameAs on the homepage, BreadcrumbList on deep pages, Article or BlogPosting with ISO 8601 dates (Tool: Schema.org validator).
• Markup matches visible content exactly — marking up content users never see violates Google's structured data guidelines (Tool: side-by-side review of markup and rendered page).
• FAQ blocks use clean question-and-answer headings that humans and extraction pipelines can lift; add FAQPage schema only where Google still grants FAQ rich results (Tool: Rich Results Test).

Step 6 — Site architecture and crawl depth

Crawl depth and internal linking decide how much crawl budget and link equity reach the pages that earn pipeline: every revenue page within three clicks of the homepage and holding at least one internal link from an already-indexed page.

• Pricing, feature, and top comparison pages are reachable within three hops of the homepage (Tool: Screaming Frog crawl-depth report).
• Zero orphan pages: every indexable URL gets at least one internal link from another indexable page (Tool: Screaming Frog orphans export).
• Redirect chains capped at one hop: every retired URL 301s directly to its final destination (Tool: crawl redirects report).

Step 7 — Auth walls, dynamic URLs, deploy regressions

SaaS-specific surface area closes the list: app paths that must never be indexed, session and filter parameters that must never multiply URLs, and the deploy pipeline that can silently regress every step above.

• App, dashboard, and admin paths are disallowed in robots.txt; login pages that legitimately appear in search carry noindex (Tool: robots.txt review plus a site: query).
• Session IDs and tracking parameters never appear in internal links; parameterized variants canonicalize to the clean URL (Tool: crawl URL-parameter report).
• Staging and preview environments are password-protected at the server level — robots.txt alone does not guarantee exclusion (Tool: incognito fetch of the staging host).
• Public marketing pages serve full content without session cookies; personalization must not gate crawlable text behind a login or A/B bucket (Tool: curl with no cookies).
• Every deploy touching templates, routing, or head tags runs an automated crawl diff so regressions surface in CI, not weeks later in Search Console (Tool: scheduled Screaming Frog or Sitebulb comparison).

How this applies at Kiwi

We run this checklist as an evidence-led audit: crawl data, Search Console exports, field Core Web Vitals, and log evidence first, conclusions second. Every finding arrives with the artifact behind it, a pass condition, and an impact ranking — and with no ranking guarantees, because anyone offering them is not reading the data. Enquiries get a senior review within 24 hours, and there are no junior hand-offs at any stage.

If the audit surfaces work worth doing, we scope it as fixed milestones with written scope; kickoff typically happens within 5 business days, and you keep 100% of the code and IP at handoff. We take on only two or three new builds per month, so an engagement gets senior attention rather than a slot in a queue. Send us your site and whatever Search Console access you can share; we will tell you what the checklist finds.