SaaS SEO Audit

TL;DR — A SaaS SEO audit is the process of reviewing your software site to find and fix what’s hurting your search performance — on a schedule, with a way to decide what to fix first. It’s different from a checklist: a checklist is the list of things to look at; the audit is you actually looking, on a cadence, and then ranking what you found. The SaaS-specific part is that you’re auditing three things at once — a marketing site, help docs, and an app — and making sure the app and signup pages aren’t accidentally in Google.

Evidence for this claim Google renders JavaScript with a web rendering service, but server-side or pre-rendered content remains a useful reliability strategy. Scope: Google JavaScript SEO guidance; rendering behavior is not SaaS-specific. Confidence: high · Verified: 2026-07-14 Google Search Central: JavaScript SEO basics Evidence for this claim Core Web Vitals assessment is based on real-user field data rather than a single lab run. Scope: Core Web Vitals measurement; lab tools remain useful for diagnosis. Confidence: high · Verified: 2026-07-14 web.dev: Web Vitals

What a SaaS SEO audit actually is

A lot of people think an “audit” means running a crawler and handing over everything it flags. It doesn’t. A crawler prints a list; an audit is a person deciding which items on that list actually matter for your site and fixing those first.

The sibling SaaS SEO checklist covers what to check — free tools, pricing pages, comparison pages, integration pages, docs, JavaScript rendering, which funnel pages to keep out of Google. This page is about how you run the review using that list:

1. Pick a cadence. Light, automatic monitoring all the time (crawl errors, Core Web Vitals, indexing changes), plus a bigger, thorough audit every few months.
2. Decide what to crawl — and what not to. Your marketing site is the target. Your help docs get their own attention. Your app, dashboard, and signup pages should be confirmed to be out of Google, not crawled by accident.
3. Check indexation. Are more pages in Google than you expected? That’s “indexation bloat,” and it usually means thin or duplicate pages are diluting your site.
4. Check speed the right way. Use real-visitor speed data, not one test run on your fast laptop — SaaS sites are usually built with JavaScript, which makes the difference bigger than most people realize.
5. Compare yourself to competitors. Specifically, look at their “us vs. them” comparison pages and their integration pages, and see what you’re missing.
6. Rank what you found. Fix the high-impact, low-effort things first. Don’t hand anyone a giant report of everything — nobody reads those.

Want the practitioner version — with the exact tools, the three-number indexation check, and the prioritization frameworks — switch to the Advanced tab.

TL;DR — An audit is a process, not a longer checklist. Google’s Martin Splitt: a technical audit “can use checklists and guidelines to do so, but it needs experience and expertise to adapt these guidelines and checklists to the site you audit.” Run it on a cadence appropriate to release frequency and risk. Scope the crawl by property — marketing site, docs, and app surfaces — and confirm app/trial/dashboard URLs aren’t crawled and indexed by accident. Check indexation bloat by reconciling submitted vs. crawled vs. indexed. Prioritize Core Web Vitals with field data, split by page template, because lab tools mislead on a hydration-heavy stack. Verify JS rendering with URL Inspection / Rich Results and account for the render-queue delay. Start the content gap analysis from competitors’ comparison and integration pages, not a keyword list. Then prioritize with an Impact/Effort Matrix and/or severity tiers, and cap the report at a short, prioritized set the team can implement.

Evidence for this claim Google renders JavaScript with a web rendering service, but server-side or pre-rendered content remains a useful reliability strategy. Scope: Google JavaScript SEO guidance; rendering behavior is not SaaS-specific. Confidence: high · Verified: 2026-07-14 Google Search Central: JavaScript SEO basics Evidence for this claim Core Web Vitals assessment is based on real-user field data rather than a single lab run. Scope: Core Web Vitals measurement; lab tools remain useful for diagnosis. Confidence: high · Verified: 2026-07-14 web.dev: Web Vitals

An audit is a process, not a longer checklist

I’ll open the way I open every audit conversation, because the misconception is that persistent: a good SaaS SEO audit is not “run Screaming Frog, export everything it flags, send it over.” That’s a crawler report. An audit is what a human does with it.

Google’s Martin Splitt put the distinction cleanly in his 2025 Search Central lightning talk on audit methodology. A technical audit, he said, “should make sure no technical issues prevent or interfere with crawling or indexing. It can use checklists and guidelines to do so, but it needs experience and expertise to adapt these guidelines and checklists to the site you audit” (as covered by Search Engine Journal). That last clause is the whole job. The checklist is the input; the adaptation to your specific site is the audit. And he’s blunt about the tooling trap, too: “Please, please don’t follow your tools blindly. Make sure your findings are meaningful for the website in question and take the time to prioritize them for maximum impact” (SEJ coverage).

My version of the same point, from What is an Enterprise SEO Audit & How To Do One: “SEO checklists are impractical at scale. It’s a waste of time to check every little thing on every page because there’s simply no ROI in doing so, and no one is going to read your 200-page SEO audit.” Everything below is written to avoid producing that 200-page report.

The standard disclaimer I attach to all of this: it’s my understanding of how these systems work and how I’d approach the problem, not a guarantee — search engines change constantly, so verify against the primary docs in the Official Docs and Quotes tabs. And as with the checklist article: there’s no SaaS algorithm. The crawl → render → index → rank pipeline is identical to a recipe blog’s. What’s SaaS-specific here is the scope (three properties instead of one) and a couple of failure modes, not a special ranking system.

Cadence: continuous monitoring + a full periodic pass

There’s no Google- or Bing-mandated audit frequency, so this is practitioner consensus, not doctrine. The model that works for SaaS has two speeds:

• Continuous, light, automated monitoring — crawl-error alerts, Core Web Vitals regressions, and indexation deltas, ideally tied to deploys. SaaS ships fast, and a bad deploy can noindex a template or break rendering across a whole page type overnight. You want to catch that in days, not at the next quarterly review.
• A full, comprehensive pass on a slower cycle. In my enterprise-audit work I note that comprehensive audits “may occur every few months or yearly” (source). For a growing SaaS site I’d land on quarterly-to-semiannual, and scale that with how fast you ship new integration and comparison pages and how large your docs have grown — a company minting hundreds of programmatic pages a quarter needs the full pass more often than a five-page marketing site does.

The industry-common shorthand you’ll see repeated across competitor guides is “full audit quarterly, lighter monthly checks.” That’s a reasonable default; just don’t treat it as a rule handed down from a search engine. It isn’t one.

Scoping the crawl: marketing site, docs, and confirming the app is excluded

Here’s the SaaS-specific step almost no generic audit guide names as a discrete step: decide what you’re crawling before you crawl it, and segment by property. A SaaS brand is usually three sites wearing one logo — www (marketing), docs. (docs), and app. (the product) — and auditing them as one undifferentiated blob is how you either miss problems or drown in noise.

Segment first. In my audit process I lean on a site-structure view to slice the site “by specific pages, sections of a site, different languages or regions, or a specific CMS or JavaScript framework” before crawling — the SaaS translation is: crawl the marketing site as its own scope, treat the docs subdomain as its own property, and explicitly check what the app is doing.

• Marketing site — the primary target. This is where the audit’s weight goes: comparison pages, pricing, free tools, integration pages, the blog.
• Docs — its own crawl-budget property. If docs live on a subdomain, it’s a separate Search Console property with its own crawl budget (the checklist article covers the subdomain-vs-subfolder decision itself — I won’t re-litigate it here). The auditing point is: crawl it separately so a bloated, thousands-of-pages docs tree doesn’t distort the marketing site’s numbers. Note Google’s own scoping hint for the Crawl Stats report — it’s “aimed at advanced users” and “if you have a site with fewer than a thousand pages, you should not need to use this report” (Search Console Help). A standalone SaaS marketing site is often under a thousand URLs; it’s the docs and a growing integration library that push the total past the point where crawl budget starts to matter.
• App / trial / dashboard — confirm exclusion, don’t assume it. This is the distinct audit action: don’t just trust that noindex and robots.txt are configured right (that’s the checklist’s job) — verify during the audit that /app/, /dashboard/, /signup/, and post-login URLs aren’t being crawled and indexed by accident. Scope a crawl at those paths and check Search Console’s indexed-URL list for anything under them that shouldn’t be there. “Ignoring the app” and “confirming the app is correctly excluded” are not the same thing — the audit does the latter.

Checking indexation for bloat

Indexation bloat is when Google has more pages of yours indexed than should be — thin, duplicate, or unintentionally-crawlable URLs diluting the index. The audit check is a three-number reconciliation:

1. URLs submitted in your sitemap(s).
2. URLs Google actually crawled.
3. URLs actually indexed — from Search Console’s Page Indexing report, which splits your URLs into “indexed” and “not indexed” with a reason for each exclusion.

Big, unexplained gaps between those three numbers are the signal to chase. In my audit method I flag that a typical site has some pages indexed that shouldn’t be, and plenty of pages noindexed that should be indexed — so you check both directions: a pricing or comparison page wrongly excluded, and /app/ or filtered doc-search URLs wrongly included.

The word doing the work above is unexplained. Splitt’s framing is exactly right for SaaS, which sunsets old comparison and integration pages constantly: “A high number of 404s, for instance, is expected if you removed a lot of content recently. That’s not a problem… But if you have an unexplained rise in 404 responses, though, that’s something you want to point out and investigate” (SEJ coverage). A dip in indexed pages right after you pruned a hundred dead integration pages is a success, not a crisis. The audit’s job is spotting the deviation you can’t explain.

Google’s own crawl-budget doc names the root cause on the crawl side: “Without guidance from you, Google tries to crawl all or most of the URLs that it knows about on your site” (Optimize your crawl budget). On a SaaS site the “perceived inventory” it’s talking about is filtered doc-search URLs, tag and pagination variants on the blog, and templated integration pages that went thin — exactly the stuff an indexation-bloat pass exists to find.

Core Web Vitals on a JavaScript-rendered stack

Core Web Vitals is, per Google, “a set of metrics that measure real-world user experience for loading performance, interactivity, and visual stability of the page” (Google Search Central), with the familiar thresholds — “strive to have LCP occur within the first 2.5 seconds,” “strive to have an INP of less than 200 milliseconds,” and “strive to have a CLS score of less than 0.1” (same doc). Those numbers aren’t the SaaS-specific part. How you measure them is.

The trap on a JavaScript-heavy SaaS marketing site — React, Next.js, Vue — is trusting a single lab run (one PageSpeed Insights or Lighthouse test). A lab test often reflects a warm cache, a fast machine, and a fully-hydrated app shell — the experience a developer sees locally — not the cold, render-blocking-JavaScript experience a first-time trial visitor on a slower connection actually gets. Google’s own lab-vs-field guidance is explicit about which to trust: “As a general rule, if you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts” (web.dev). Lab data still earns its keep — it’s how you reproduce and debug a problem — which is why the same doc concludes “both lab data and field data are important parts of effective performance measurement” (web.dev). For prioritizing the audit, though, you lead with field data (Search Console’s Core Web Vitals report, CrUX).

The second SaaS-specific move: split field data by page template, not site-wide average. A comparison page with an embedded interactive calculator or a giant feature table carries a very different CWV profile than a plain blog post on the same domain. A site-wide average hides the exact template that’s failing. Group by page type, and the audit tells you which template to fix.

JavaScript rendering checks as an audit step

The checklist article covers the fixes for JS rendering (real <a href> links, server-side rendering, History API routing). The audit’s job is the method — actually opening the tools and looking. Google names the two: “To make sure that Google can still see your content after it’s rendered, use the Rich Results Test or the URL Inspection Tool and look at the rendered HTML” (JavaScript SEO basics). Compare the rendered DOM against view-source, per template, and confirm the content that should rank — headlines, prices, body copy, comparison tables — is actually present after render.

One thing that saves you from a false alarm: the render queue. Google warns “the page may stay on this queue for a few seconds, but it can take longer than that” (JavaScript SEO basics). When you’re auditing a freshly-published batch of integration pages, distinguish “this page is a genuine rendering failure” from “this page is just still waiting in the render queue.” Flagging the second as a bug wastes everyone’s time.

Content and competitive gap analysis: start from comparison and integration pages

Competitor benchmarking in most audits means a generic keyword gap or referring-domain diff. For SaaS, the higher-leverage version is structural and bottom-funnel. Rather than starting from a keyword list, I start from my competitors’ top-performing pages and work backward — a habit I describe in my enterprise SEO audit process. Applied to SaaS, that means pulling up your top two or three competitors’ comparison (“alternatives to X”) pages and their integration / marketplace directories, then diffing them against yours:

• Which integrations do they have landing pages for that you don’t (even though you support the integration)?
• Which “X vs. Y” and “alternatives to” pages exist for them and not for you?
• Where do you both have a page but theirs is winning — and is it a content-depth gap or a technical one (rendering, thin template, missing internal links)?

This is deliberately narrower than “run the Content Gap tool.” Those bottom-funnel page types are where SaaS deals actually get won, and they’re the exact page types the checklist article named as SaaS’s differentiators — so the gap analysis targets them specifically rather than chasing top-funnel keyword volume.

Prioritizing findings

This is where audits succeed or fail, and it’s the step tools can’t do for you. Two complementary frameworks:

1. Impact/Effort Matrix. Sort every finding into the quadrant grid. As I put it in my enterprise SEO strategies piece: “Anything high-impact and low-effort is a quick win, so tackle those tasks first.” On a SaaS audit the quick wins are often a stray noindex on a comparison page, a broken internal link to a pricing page, or a missing render on one template — high impact, low effort.

2. Severity tiers. Bing bakes this into its own audit tool, which is a clean model to borrow. In Bing’s Site Scan, “issues detected during the scan are grouped into three categories and listed in order of severity”: Errors are “the most critical and should be addressed first,” Warnings “may impact SEO health, but are considered medium in terms of severity,” and Notices are “low priority and should be addressed only after resolving errors and warnings” (via Search Engine Journal).

Then cap the deliverable. From my audit reporting advice: “I highly recommend focusing on a few key issues and not a massive report of everything you looked at… I’ve found reporting on 5-10 main issues or opportunities will be better received and the changes are more likely to be implemented” (enterprise SEO audit). That reframes “we found 40 issues” from a boast into a prioritization problem: the audit isn’t done when you’ve found 40 things, it’s done when you’ve decided which 5–10 to ship. An audit that recommends fixing everything has failed at prioritization, not succeeded at thoroughness.

Putting it together: a repeatable audit cadence

The whole loop for a growing SaaS site: continuous automated monitoring catches regressions between passes; a quarterly-to-semiannual full audit scopes the crawl by property (marketing / docs / confirm-app-excluded), reconciles submitted-vs-crawled-vs- indexed to catch bloat, prioritizes CWV from field data split by template, verifies JS rendering with the render queue in mind, diffs your comparison and integration coverage against competitors, and ships a prioritized 5–10-item report rather than a 200-page one. No SaaS algorithm — just the normal pipeline, audited across three properties, with the discipline to fix what matters instead of everything you found.

AI summary

A condensed take on the Advanced version:

• An audit is a process, not a longer checklist. Splitt: a technical audit can use checklists “but it needs experience and expertise to adapt these guidelines and checklists to the site you audit.” Patrick: “no one is going to read your 200-page SEO audit.” No SaaS algorithm — same crawl → render → index → rank pipeline, audited across three properties.
• Cadence: continuous light automated monitoring (crawl errors, CWV, indexation deltas, ideally tied to deploys) + a full pass quarterly-to-semiannual, scaled to how fast you ship integration/comparison pages.
• Scope the crawl by property: marketing site (primary), docs (own crawl budget, crawl separately), and confirm app/trial/dashboard URLs aren’t crawled and indexed by accident — verify, don’t assume.
• Indexation bloat = three-number reconciliation: submitted vs. crawled vs. indexed (Page Indexing report). Chase unexplained gaps; 404/index dips after a content prune are expected, not a crisis.
• Core Web Vitals: prioritize with field data, not one lab run (lab reflects a warm-cache dev machine, not a first-time JS-rendered visit). Split by page template.
• JS rendering: verify with URL Inspection / Rich Results against the rendered DOM; account for the render-queue delay before calling a fresh page broken.
• Content gap analysis: start from competitors’ comparison and integration pages, not a generic keyword list.
• Prioritize: Impact/Effort Matrix + severity tiers (Bing’s Error/Warning/Notice model); cap the report at 5–10 issues.

Official documentation

The primary sources behind the audit steps. A SaaS site is governed by these the same as any other site.

Google

• Understand Core Web Vitals and Search Console reports — the LCP/INP/CLS metric definitions and thresholds behind the performance step, and the Search Console CWV report you pull field data from.
• Lab data vs. field data (web.dev) — why field data drives prioritization and lab data drives debugging; the core doc for the JS-stack CWV section.
• Optimize your crawl budget — “perceived inventory” and why undirected crawling accumulates the URLs an indexation-bloat pass exists to find.
• Page indexing report — the indexed vs. not-indexed breakdown for the three-number reconciliation.
• Crawl Stats report — crawl requests by response, file type, and purpose; note its own “advanced users / a thousand pages” scoping caveat.
• Understand JavaScript SEO basics — the two rendering-verification tools (URL Inspection, Rich Results Test) and the render-queue delay.

Bing / Microsoft

• Site Scan — Bing Webmaster Tools Help — Bing’s free on-demand technical audit tool, with the Error/Warning/Notice severity model borrowed in the prioritization section.
• Keeping content discoverable with sitemaps in AI-powered search (July 2025) — accurate lastmod so a re-crawl audit can distinguish genuinely-updated from stale pages.

Quotes from the source

On-the-record statements from Google, Bing, and Patrick Stox. Each link deep-links to the quoted passage on the source page where the source page supports a text fragment.

Google — what a technical audit is for (Martin Splitt, Search Central, 2025)

• “A technical audit, in my opinion, should make sure no technical issues prevent or interfere with crawling or indexing. It can use checklists and guidelines to do so, but it needs experience and expertise to adapt these guidelines and checklists to the site you audit.” Read the coverage (SEJ)
• “Please, please don’t follow your tools blindly. Make sure your findings are meaningful for the website in question and take the time to prioritize them for maximum impact.” Read the coverage (SEJ)
• “A high number of 404s, for instance, is expected if you removed a lot of content recently. That’s not a problem… But if you have an unexplained rise in 404 responses, though, that’s something you want to point out and investigate…” Read the coverage (SEJ)

Google — indexation and crawl mechanics

• “Without guidance from you, Google tries to crawl all or most of the URLs that it knows about on your site.” Jump to quote
• “This report is aimed at advanced users. If you have a site with fewer than a thousand pages, you should not need to use this report or worry about this level of crawling detail.” (Crawl Stats report) Jump to quote

Google — Core Web Vitals thresholds

• “Core Web Vitals is a set of metrics that measure real-world user experience for loading performance, interactivity, and visual stability of the page.” Jump to quote
• “strive to have LCP occur within the first 2.5 seconds of the page starting to load” · “strive to have an INP of less than 200 milliseconds” · “strive to have a CLS score of less than 0.1” Jump to quote

Google — lab vs. field data (web.dev)

• “As a general rule, if you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” Jump to quote
• “Overall, both lab data and field data are important parts of effective performance measurement.” Jump to quote

Google — JavaScript rendering checks

• “To make sure that Google can still see your content after it’s rendered, use the Rich Results Test or the URL Inspection Tool and look at the rendered HTML.” Jump to quote
• “The page may stay on this queue for a few seconds, but it can take longer than that.” Jump to quote

Bing — Site Scan severity tiers

• “Issues detected during the scan are grouped into three categories and listed in order of severity.” — Errors are “the most critical and should be addressed first,” Warnings “may impact SEO health, but are considered medium in terms of severity,” and Notices are “low priority and should be addressed only after resolving errors and warnings.” Read the coverage (SEJ)

Patrick Stox — audit process and prioritization

• “SEO checklists are impractical at scale. It’s a waste of time to check every little thing on every page because there’s simply no ROI in doing so, and no one is going to read your 200-page SEO audit.” Jump to quote
• “I highly recommend focusing on a few key issues and not a massive report of everything you looked at… I’ve found reporting on 5-10 main issues or opportunities will be better received and the changes are more likely to be implemented.” Jump to quote
• “These audits may occur every few months or yearly…” Jump to quote
• “Anything high-impact and low-effort is a quick win, so tackle those tasks first.” Jump to quote

Which audit should you run right now?

Two decisions come up at the start of almost every SaaS audit: how big a pass this is, and how you’ll rank whatever you find.

A. Full audit, or a light monitoring check?

Q1. Did something specific break or drop — a traffic dip, a deploy, a template change?

• Yes → run a targeted check on the affected property/template, not a full audit. Reproduce it (URL Inspection, field-data by template, indexed-URL list) and fix the one thing. Stop here.
• No → continue.

Q2. Has it been a quarter (or your chosen full-pass interval), or did you ship a large batch of new integration/comparison pages since the last full audit?

• Yes → run the full comprehensive pass (scope → indexation → CWV → JS render → gap analysis → prioritize).
• No → stay on continuous light monitoring (crawl errors, CWV regressions, indexation deltas). A full audit on a site that hasn’t changed is mostly re-confirming what you already know.

B. You’ve got a pile of findings — how do you rank them?

Q1. Does the finding stop a page from being crawled, rendered, or indexed at all?

• Yes → it’s an Error tier (Bing’s model) — most critical, address first. Examples: a comparison page wrongly noindexed, a template that renders empty, the app accidentally indexed.
• No → continue.

Q2. Is it high-impact and low-effort?

• Yes → quick win — do it now regardless of tier. A broken internal link to pricing, a stray canonical, one missing render fix.
• No → continue.

Q3. Does it plausibly move rankings/conversions, at reasonable effort?

• Yes → Warning tier / medium priority — schedule it.
• No / cosmetic / low-confidence → Notice tier — only after errors and warnings, and honestly, maybe never.

The one-line version: decide the size of the pass by what changed, and rank findings by “does it block indexing?” then “is it a quick win?” — and cap what you actually report at 5–10 items.

The mental models

1. Checklist vs. audit. A checklist is what to check; an audit is checking it, on a cadence, adapted to this site, with a prioritization step at the end. If your “audit” is a crawler export, you have a checklist result, not an audit.

2. Three properties, one brand. A SaaS site is marketing + docs + app. Scope the crawl by property before you run it. The marketing site is the target; docs get their own crawl budget; the app gets confirmed excluded, not ignored.

3. The three-number reconciliation. Submitted (sitemap) → Crawled → Indexed. Bloat and coverage problems both hide in the gaps between those three numbers — and only the unexplained gaps are bugs. A dip you can explain (you pruned dead pages) is a success.

4. Field data prioritizes; lab data debugs. On a JS-heavy stack, lead prioritization with field data (real visitors), because a lab run reflects a warm-cache dev machine. Then use lab tools to reproduce and fix. Split both by page template — never trust a site-wide CWV average.

5. Two prioritization lenses that stack. Severity tier (does it block crawl/render/index?) tells you what’s an emergency. Impact/Effort quadrant tells you what’s a quick win. Use both, then cap the report at 5–10 items. Completeness is not the goal; the right 5–10 is.

6. “No site is perfect” is the professional standard. An audit that recommends fixing everything failed at prioritization. Finding 40 issues isn’t the finish line — deciding which handful to ship is.

The audit-process checklist

This isn’t the SaaS page-type checklist (that’s the sibling article) — it’s the sequence for running a full audit pass.

Before you crawl — scope

• Full pass or targeted check decided (nothing broke → light monitoring, not a full audit).
• Crawl segmented by property: marketing site, docs subdomain, app.
• Marketing site set as the primary crawl scope.
• Docs crawled separately so its size doesn’t distort marketing-site numbers.
• App / trial / dashboard paths explicitly checked — not crawled-and-indexed by accident (verify Search Console’s indexed-URL list, don’t assume config).

Indexation

• Three numbers reconciled: sitemap-submitted vs. crawled vs. indexed.
• Page Indexing report reasons reviewed — expected exclusions vs. mistakes.
• Both directions checked: ranking pages wrongly excluded, junk pages wrongly included.
• 404 / indexed-count spikes classified as expected (recent prune) or unexplained (investigate).

Core Web Vitals (JS stack)

• Field data (Search Console CWV / CrUX) used to prioritize — not a single lab run.
• Results split by page template (comparison/interactive vs. plain content).
• Lab tools used only to reproduce/debug the field-data failures.

JavaScript rendering

• Rendered DOM checked (URL Inspection / Rich Results) against view-source, per template.
• Content that should rank confirmed present after render.
• Render-queue delay accounted for before flagging a fresh page as broken.

Competitive gap analysis

• Top competitors’ comparison (“alternatives to”) pages diffed against yours.
• Competitors’ integration/marketplace directories diffed against yours.
• Started from competitors’ top pages, not a generic keyword list.

Prioritize & report

• Every finding sorted by severity tier (Error/Warning/Notice).
• Impact/Effort quadrant applied; quick wins pulled forward.
• Deliverable capped at ~5–10 issues, not a full dump.

SaaS SEO audit — cheat sheet

What to crawl, and how to treat it

The three-number indexation check

Only unexplained gaps are bugs. A drop after pruning dead pages is a win.

Core Web Vitals thresholds (measure with field data, split by template)

Prioritization — two stacked lenses

Then cap the report at 5–10 issues. A 200-page audit nobody reads is a failure mode, not thoroughness.

Cadence

• Continuous: crawl errors, CWV regressions, indexation deltas (tie to deploys).
• Full pass: quarterly-to-semiannual, faster if you ship many integration/comparison pages.

Tools for running the audit

• Google Search Console — the backbone: Page Indexing report (three-number reconciliation, bloat, wrong exclusions), Core Web Vitals report (field data, by page type), URL Inspection (rendered DOM per URL), Crawl Stats (response codes, crawl purpose), and a separate property per subdomain (marketing, docs, app).
• Bing Webmaster Tools — Site Scan — Bing’s free on-demand technical audit, with a built-in Error/Warning/Notice severity model you can borrow for prioritization even if you don’t act on every Bing-specific finding.
• A crawler (Ahrefs Site Audit / Screaming Frog) — scope a crawl by property/path to segment marketing vs. docs vs. app, surface noindex tags, robots.txt blocks, redirect chains, thin programmatic pages, and orphaned integration/tool pages.
• PageSpeed Insights / Lighthouse — lab tools for reproducing and debugging a CWV problem the field data already flagged — not for prioritizing on their own.
• CrUX (Chrome UX Report) — field data at the origin/URL level to corroborate GSC’s Core Web Vitals report.
• Rich Results Test — the second rendering-verification tool Google names; confirm the rendered HTML matches what should rank.
• Server log file analysis — ground truth for what bots actually crawled across properties, and where crawl is being wasted on app/parameter/filtered-doc URLs.
• Content Gap / competitor tooling (Ahrefs et al.) — but pointed at competitors’ comparison and integration pages first, not a generic keyword list.

Snippets for the audit

These are inspection helpers, not automation — run them in your browser’s DevTools console on a rendered page, or against a crawl export.

Confirm nav/cross-links are real <a href> links (DevTools console)

JS-rendered SaaS sites often “link” with onClick handlers Google can’t follow. Count real anchors vs. clickable non-anchors on the page:

// Real, crawlable links on this page
const anchors = [...document.querySelectorAll('a[href]')]
  .map(a => a.getAttribute('href'))
  .filter(h => h && !h.startsWith('#') && !h.startsWith('javascript:'));
console.log('Real <a href> links:', anchors.length);

// Suspicious: clickable elements that are NOT anchors (likely JS-only navigation)
const fakeNav = [...document.querySelectorAll('[onclick], [role="link"]')]
  .filter(el => el.tagName !== 'A');
console.log('Non-anchor clickable elements (audit these):', fakeNav.length, fakeNav);

Spot app/dashboard paths in the rendered page’s own links

Quick check that the marketing page isn’t leaking crawl paths into /app/, /signup/, or /dashboard/ that should stay out of the index:

const leaky = [...document.querySelectorAll('a[href]')]
  .map(a => a.getAttribute('href'))
  .filter(h => /\/(app|dashboard|signup|account|login)(\/|$|\?)/i.test(h || ''));
console.log('Links into app/auth paths (confirm these are intended):', leaky);

Compare rendered content vs. raw HTML (is content JS-injected?)

If a template’s key content only exists after render, that’s the app-shell risk. Rough signal — compare the raw HTML length to the rendered DOM length:

// Run in console: rendered DOM text length right now
console.log('Rendered text length:', document.body.innerText.length);
// Then compare against "View Source" / fetch of the raw HTML for the same URL:
fetch(location.href).then(r => r.text()).then(html => {
  const raw = new DOMParser().parseFromString(html, 'text/html');
  console.log('Raw HTML text length:', raw.body ? raw.body.innerText.length : 0);
});
// A large gap (rendered ≫ raw) means content is JS-injected — verify Google renders it
// via the URL Inspection Tool, don't trust this heuristic alone.

Regex for finding app/auth URLs in a crawl export

Filter a Screaming Frog / crawl CSV of indexed URLs for paths that shouldn’t be indexed:

/(app|dashboard|signup|account|login|onboarding|billing)(/|$|\?)

Remember: these snippets surface candidates. Confirm the real rendered state in the URL Inspection Tool before you record a finding — the render queue means a page can look “broken” locally while Google renders it fine.

Audit mistakes that create noise instead of decisions

Call a crawler export an audit

A tool can enumerate response codes, directives, and links; it cannot decide which findings matter for this SaaS site’s goals and architecture. Segment the properties, investigate the causes, prioritize by impact and effort, and attach an owner before calling the work an audit.

Follow every tool warning blindly

Generic scoring systems cannot know whether a 404 follows an intentional integration-page prune or an accidental routing regression. Classify expected versus unexplained changes and preserve the evidence behind the judgment.

Ignore the app instead of confirming its exclusion

The logged-in product may not need SEO, but trial, signup, dashboard, and share URLs can leak into the crawlable surface. Test those paths and Search Console coverage explicitly; “we do not audit the app” is not proof that it is excluded.

Treat one site-wide score as the result

Marketing, docs, and app surfaces have different responsibilities, while comparison, blog, and interactive templates have different performance profiles. Report by property and template so a large clean section does not hide a broken high-value cohort.

Report everything you found

A long issue inventory transfers prioritization work to the reader and reduces the chance anything ships. Lead with the small set of highest-impact, actionable findings; keep supporting observations in evidence, not in the executive queue.

Classify crawl and indexation changes

Classify each URL or template change as expected, unexplained, or needs evidence.
Use the crawl export, sitemap status, Page Indexing reason, release notes, and content
retirement log I provide. For every row return:
1. Classification
2. Evidence supporting it
3. The missing evidence, if any
4. Whether it blocks crawl, rendering, indexing, or none
5. The next concrete check and owner

Examples of expected changes can include intentionally retired integration pages.
Do not assume every 404 or index-count drop is a defect, and do not excuse an unexplained
change without evidence.

Audit inputs:
[PASTE CSV + RELEASE/PRUNE LOG]

Turn findings into a focused audit queue

Prioritize these SaaS SEO audit findings using both severity and impact/effort.
Separate the marketing site, docs, and app/trial surface. Return no more than 10
recommended actions, each with: affected cohort, evidence, SEO stage affected,
impact rationale, effort/dependency notes, owner, and a pass/fail verification step.

Do not rank an item highly only because a tool labels it an error. Do not invent traffic,
revenue, engineering effort, or affected URL counts. Put unsupported claims in a
"needs evidence" section rather than the action queue.

Findings:
[PASTE EXPORT AND CONTEXT]

Submitted-to-crawled coverage

Metric: The share and count of sitemap-submitted URLs observed in crawl data or server logs, segmented by property and template. What it tells you: Whether intended inventory is discoverable and receiving crawl attention. How to pull it: Join current sitemap URLs to Search Console Crawl Stats where usable and, preferably, bot log records. Benchmark / realistic range: Establish a baseline by template and update frequency; a universal ratio would ignore site size, crawl demand, and intentional low-cadence pages. Cadence: Monitor monthly and around major releases; review the trend in each full audit.

Crawled-to-indexed reconciliation

Metric: The gap between URLs crawled and URLs indexed, with Page Indexing reasons and expected exclusions separated. What it tells you: Whether crawl is reaching useful pages that Google can index, or spending on duplicates, junk paths, and intentional exclusions. How to pull it: Reconcile crawler/log cohorts with Google Search Console’s Page Indexing export. Benchmark / realistic range: Use the site’s documented intended-index inventory; the target is explained exclusions, not 100% indexation. Cadence: Monthly as a leading health check and quarterly-to-semiannually in the full audit.

Unintended indexed app-surface URLs

Metric: Count of indexed /app/, /dashboard/, /signup/, trial, and share-page URLs that policy says should be private or excluded. What it tells you: Whether the product surface is leaking into search and creating index bloat. How to pull it: Maintain the approved path inventory and compare it with Search Console Page Indexing exports and targeted site queries/URL inspections. Benchmark / realistic range: Zero for cohorts explicitly designated private or excluded; document intentional public share pages separately. Cadence: Check after routing/indexation releases and monthly.

Field Core Web Vitals pass rate by template

Metric: The proportion of URL groups with good field LCP, INP, and CLS, segmented by comparison, pricing, tools, docs, and content templates. What it tells you: Whether real visitors receive acceptable loading, interaction, and visual stability on the templates that matter. How to pull it: Use Search Console’s Core Web Vitals report and CrUX field data; use lab tests only to diagnose. Benchmark / realistic range: Good field thresholds are LCP within 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1; compare like templates rather than a site-wide average. Cadence: Monitor monthly and after frontend releases, with quarterly trend review.

Resources worth your time

My related writing

• What is an Enterprise SEO Audit & How To Do One — my full audit process: scoping and segmenting before you crawl, checking indexing, starting content research from competitors’ top pages, and the “5-10 main issues, not a 200-page report” reporting discipline. The parent for this article’s methodology.
• Enterprise SEO Strategies For Maximum Growth — where the Impact/Effort Matrix (“high-impact and low-effort is a quick win”) comes from, plus the broader scale-and-prioritization framing.
• Unlocking Growth Through Enterprise SaaS SEO — my SaaS guide on the page types you’re auditing (product-led, comparison, integration) and why SaaS JS frameworks are “relatively newer than CMSs and less understood by SEOs.”
• JavaScript SEO Issues & Best Practices — the rendering side you’re verifying: real links, History API, server-side rendering, and the render-queue delay.

My speaking

• What I learned from auditing over 1,000,000 websites (Tech SEO Connect) — the throughline behind this whole article at scale: the most common issues weren’t the most important ones, and no major site is technically perfect. My standing disclaimer applies — this is my understanding, not gospel.

From around the industry

• Google Warns Against Relying On SEO Audit Tool Scores — Search Engine Journal — the coverage of Martin Splitt’s 2025 Search Central talk on audit methodology; the checklist-vs-audit and “don’t follow your tools blindly” framing.
• Understand Core Web Vitals and Search Console reports — Google Search Central — the LCP/INP/CLS thresholds and the Search Console CWV report you pull field data from.
• Lab data vs. field data — web.dev — why field data drives prioritization on a JS-heavy stack.
• Understand JavaScript SEO basics — Google Search Central — the two rendering-verification tools and the render-queue delay.
• Optimize your crawl budget — Google Search Central — “perceived inventory” and the crawl side of indexation bloat.
• Bing ‘Site Scan’ Tool Audits Sites For Technical SEO Issues — Search Engine Journal — the Error/Warning/Notice severity model borrowed in the prioritization section.

Test yourself: SaaS SEO Audit

Five questions on how to run a SaaS SEO audit — the process, not the checklist. Pick an answer for each, then check.

SaaS SEO Audit

A SaaS SEO audit is the recurring process of reviewing a software company's marketing site — plus, deliberately, its docs and app surfaces — to find what's blocking crawling and indexing, wasting index budget, hurting Core Web Vitals on a JavaScript-heavy stack, and losing ground to competitors' comparison and integration pages, then prioritizing the findings by business impact rather than by raw issue count.

SaaS SEO Audit

A SaaS SEO audit is a process, not a longer checklist. A checklist tells you what to check; an audit is the recurring practice of checking it on a cadence and deciding what to fix first. As Google’s Martin Splitt frames a technical audit, it “can use checklists and guidelines to do so, but it needs experience and expertise to adapt these guidelines and checklists to the site you audit” — the audit is that adaptation, applied to your specific SaaS site.

What makes it SaaS-specific is the three-property structure most software companies have: a marketing site, an app, and documentation, often on separate subdomains. A real audit scopes those before it crawls — confirming the app, trial, and dashboard URLs are handled deliberately (not crawled and indexed by accident), treating a docs subdomain as its own crawl-budget property, and pointing the crawl at the marketing site as the primary target.

The core steps: scope the crawl (segment marketing site vs. docs vs. app), check indexation for bloat by reconciling sitemap-submitted vs. crawled vs. indexed counts, test Core Web Vitals with field data (not one lab run) split by page template, verify JavaScript rendering with the URL Inspection and Rich Results tools, run a content/competitive gap analysis against competitors’ comparison and integration pages, and prioritize everything with a named framework — an Impact/Effort Matrix or severity tiers — capping the deliverable at the handful of issues that actually matter.

Changelog