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 foundA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore.. 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 crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. and handing over everything it flags. It doesn’t. A crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. 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 renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM., 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 VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data., indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. 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 pagesThe same or very similar primary content reachable at more than one URL. There's no general duplicate content penalty — the real costs are possible signal dilution, the wrong URL getting chosen, and less-efficient crawling. 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 indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. by accident. Check indexation bloat by reconciling submitted vs. crawled vs. indexed. Prioritize Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. with field data, split by page template, because lab tools mislead on a hydrationTurning HTML, CSS, and JavaScript into the final visual page and DOM.-heavy stack. Verify JS renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. with URL Inspection / Rich ResultsRich results (formerly 'rich snippets') are enhanced search listings — stars, images, prices, breadcrumbs, video thumbnails, and more — that Google and Bing build from structured data. They're a display feature, not a ranking factor, and eligibility never guarantees they'll show. 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 crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. 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 crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. or indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.. 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 VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. 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 crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. 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 CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms. 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 ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. property with its own crawl budgetThe number of URLs an engine will crawl in a timeframe. (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 reportA Google Search Console report (under Settings) that shows how Google has crawled your site over the last 90 days — total requests, download size, and average response time, broken down by response code, file type, Googlebot type, and purpose. It's only available for root-level properties (a Domain property or a URL-prefix property verified at the site's root). — 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.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. 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.

TIP Scope the marketing, docs, and app surfaces before reading crawl findings

This raw-HTML baseline exposes coverage and repeatable template issues. It does not evaluate rendered JavaScript or prove that the authenticated app is excluded from search.

Run a bounded SaaS crawl with my free Scout Site Audit Free Free

1. Run separate representative scopes for the marketing site and docs, and confirm the app boundary deliberately.
2. Group metadata and indexability findings by template instead of copying every URL into the audit.
3. Verify app exclusion, rendered output, and GSC state separately before prioritizing the queue.

Tap to enlarge

The report scores 82 out of 100, crawls 24 of 31 discovered URLs, calls the crawl partial, reports two missing-title warnings, and says rendered JavaScript and AI checks were not evaluated.

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 sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing.(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 paginationPagination splits a large set of content — product listings, blog archives, search results — across multiple sequentially numbered URLs. For SEO, each paginated page should be crawlable, indexable, and self-canonical; Google no longer uses rel=prev/next, but Bing still does. 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 VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors. 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 LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. occur within the first 2.5 seconds,” “strive to have an INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. of less than 200 milliseconds,” and “strive to have a CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. 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 InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. or LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 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 dataPerformance metrics captured from real users, not lab tests. 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, CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.).

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 ResultsRich results (formerly 'rich snippets') are enhanced search listings — stars, images, prices, breadcrumbs, video thumbnails, and more — that Google and Bing build from structured data. They're a display feature, not a ranking factor, and eligibility never guarantees they'll show. 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 linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them.)?

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 → indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. → rank pipeline, audited across three properties.
• Cadence: continuous light automated monitoring (crawl errors, CWVGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data., 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 budgetThe number of URLs an engine will crawl in a timeframe., 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 reportThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason.). Chase unexplained gaps; 404/index dips after a content prune are expected, not a crisis.
• Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data.: 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 renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM.: verify with URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. / Rich ResultsRich results (formerly 'rich snippets') are enhanced search listings — stars, images, prices, breadcrumbs, video thumbnails, and more — that Google and Bing build from structured data. They're a display feature, not a ranking factor, and eligibility never guarantees they'll show. 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 LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good./INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good./CLS metricCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. definitions and thresholds behind the performance step, and the Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. CWVGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. report you pull field dataPerformance metrics captured from real users, not lab tests. 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 inventoryCrawl demand is the 'want' side of crawl budget — how much a search engine wants to crawl a site or URL, driven by popularity, staleness, and perceived inventory (plus temporary spikes from site moves). It's distinct from crawl rate/capacity, the 'can' side.” and why undirected crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. 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 renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM.-verification tools (URL Inspection, Rich ResultsRich results (formerly 'rich snippets') are enhanced search listings — stars, images, prices, breadcrumbs, video thumbnails, and more — that Google and Bing build from structured data. They're a display feature, not a ranking factor, and eligibility never guarantees they'll show. 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 crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. or indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.. 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 crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. detail.” (Crawl Stats reportA Google Search Console report (under Settings) that shows how Google has crawled your site over the last 90 days — total requests, download size, and average response time, broken down by response code, file type, Googlebot type, and purpose. It's only available for root-level properties (a Domain property or a URL-prefix property verified at the site's root).) Jump to quote

Google — Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. thresholds

• “Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. 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 LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. occur within the first 2.5 seconds of the page starting to load” · “strive to have an INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. of less than 200 milliseconds” · “strive to have a CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. score of less than 0.1” Jump to quote

Google — lab vs. field dataPerformance metrics captured from real users, not lab tests. (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 renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. checks

• “To make sure that Google can still see your content after it’s rendered, use the Rich ResultsRich results (formerly 'rich snippets') are enhanced search listings — stars, images, prices, breadcrumbs, video thumbnails, and more — that Google and Bing build from structured data. They're a display feature, not a ranking factor, and eligibility never guarantees they'll show. Test or the URL Inspection ToolA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. 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 InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version., field-data by template, indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.-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 → CWVGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. → 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 linkAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them. 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 indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.?” 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 crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. 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 budgetThe number of URLs an engine will crawl in a timeframe.; the app gets confirmed excluded, not ignored.

3. The three-number reconciliation. Submitted (sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing.) → Crawled → IndexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.. 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 dataPerformance metrics captured from real users, not lab tests. 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 CWVGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. 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-indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. by accident (verify Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.’s indexed-URL list, don’t assume config).

Indexation

• Three numbers reconciled: sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing.-submitted vs. crawled vs. indexed.
• Page Indexing reportThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason. 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 VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. (JS stack)

• Field dataPerformance metrics captured from real users, not lab tests. (Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. CWV / CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.) 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 renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM.

• Rendered DOM checked (URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. / Rich ResultsRich results (formerly 'rich snippets') are enhanced search listings — stars, images, prices, breadcrumbs, video thumbnails, and more — that Google and Bing build from structured data. They're a display feature, not a ranking factor, and eligibility never guarantees they'll show.) 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 VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. thresholds (measure with field dataPerformance metrics captured from real users, not lab tests., 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 ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. — the backbone: Page Indexing reportThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason. (three-number reconciliation, bloat, wrong exclusions), Core Web Vitals reportThe Google Search Console report (under Experience) that shows how your indexed URLs perform on the Core Web Vitals — LCP, INP, and CLS — using real-user field data from CrUX, grouped by device, status, and clusters of similar-performing URLs. (field dataPerformance metrics captured from real users, not lab tests., by page type), URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. (rendered DOM per URL), Crawl StatsA Google Search Console report (under Settings) that shows how Google has crawled your site over the last 90 days — total requests, download size, and average response time, broken down by response code, file type, Googlebot type, and purpose. It's only available for root-level properties (a Domain property or a URL-prefix property verified at the site's root). (response codes, crawl purpose), and a separate property per subdomain (marketing, docs, app).
• Bing Webmaster ToolsMicrosoft's free portal for monitoring and improving how a site appears in Bing search — the peer to Google Search Console, plus IndexNow instant indexing, richer backlink data, and keyword volumes. Because Bing's index also feeds Microsoft Copilot, it doubles as a window into AI-search visibility. — 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 crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. (Ahrefs Site Audit / Screaming Frog) — scope a crawl by property/path to segment marketing vs. docs vs. app, surface noindex tags, robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. blocks, redirect chainsA → B → C instead of A → C. Each hop loses link equity and adds latency., thin programmatic pages, and orphaned integration/tool pages.
• PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. / LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. — lab tools for reproducing and debugging a CWV problem the field data already flagged — not for prioritizing on their own.
• CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. (Chrome UX Report) — field data at the origin/URL level to corroborate GSC’s Core Web Vitals reportThe Google Search Console report (under Experience) that shows how your indexed URLs perform on the Core Web Vitals — LCP, INP, and CLS — using real-user field data from CrUX, grouped by device, status, and clusters of similar-performing URLs..
• Rich ResultsRich results (formerly 'rich snippets') are enhanced search listings — stars, images, prices, breadcrumbs, video thumbnails, and more — that Google and Bing build from structured data. They're a display feature, not a ranking factor, and eligibility never guarantees they'll show. Test — the second renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM.-verification tool Google names; confirm the rendered HTML matches what should rank.
• Server log file analysisLog file analysis is reading a web server's raw access logs to see exactly which URLs search engine crawlers actually requested, when, how often, and what status code they got. Unlike crawl tools or Search Console, logs are the unsampled, ground-truth record of what really happened. — 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 indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.:

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 ToolA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. 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 ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. 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 sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing.-submitted URLs observed in crawl data or server logsLog file analysis is reading a web server's raw access logs to see exactly which URLs search engine crawlers actually requested, when, how often, and what status code they got. Unlike crawl tools or Search Console, logs are the unsampled, ground-truth record of what really happened., segmented by property and template. What it tells you: Whether intended inventory is discoverable and receiving crawl attention. How to pull it: Join current sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. URLs to Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. Crawl StatsA Google Search Console report (under Settings) that shows how Google has crawled your site over the last 90 days — total requests, download size, and average response time, broken down by response code, file type, Googlebot type, and purpose. It's only available for root-level properties (a Domain property or a URL-prefix property verified at the site's root). where usable and, preferably, botA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. log records. Benchmark / realistic range: Establish a baseline by template and update frequency; a universal ratio would ignore site size, crawl demandCrawl demand is the 'want' side of crawl budget — how much a search engine wants to crawl a site or URL, driven by popularity, staleness, and perceived inventory (plus temporary spikes from site moves). It's distinct from crawl rate/capacity, the 'can' side., 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 indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., with Page IndexingThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason. 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 crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index./log cohorts with Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.’s Page IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. 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 bloatAn SEO term for when a search engine has indexed a lot of low-value, thin, or duplicate URLs that don't serve search demand. It's a quality and crawl-efficiency problem, not a penalty.. How to pull it: Maintain the approved path inventory and compare it with Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. 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 LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good., 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 reportThe Google Search Console report (under Experience) that shows how your indexed URLs perform on the Core Web Vitals — LCP, INP, and CLS — using real-user field data from CrUX, grouped by device, status, and clusters of similar-performing URLs. and CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. field dataPerformance metrics captured from real users, not lab tests.; 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 indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., 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 CMSsA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms. and less understood by SEOs.”
• JavaScript SEO Issues & Best Practices — the renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. side you’re verifying: real links, History API, server-side renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM., 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 LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good./INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good./CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. thresholds and the Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. CWVGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. report you pull field dataPerformance metrics captured from real users, not lab tests. 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 inventoryCrawl demand is the 'want' side of crawl budget — how much a search engine wants to crawl a site or URL, driven by popularity, staleness, and perceived inventory (plus temporary spikes from site moves). It's distinct from crawl rate/capacity, the 'can' side.” 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 indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. 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 sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing.-submitted vs. crawled vs. indexed counts, test Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. with field dataPerformance metrics captured from real users, not lab tests. (not one lab run) split by page template, verify JavaScript renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. with the URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. and Rich ResultsRich results (formerly 'rich snippets') are enhanced search listings — stars, images, prices, breadcrumbs, video thumbnails, and more — that Google and Bing build from structured data. They're a display feature, not a ranking factor, and eligibility never guarantees they'll show. 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