If you've ever stared at flat organic traffic wondering why your content isn't performing, the answer is probably not your content.

SaaS companies have a structural disadvantage when it comes to technical SEO. Most are built on JavaScript-heavy frameworks like React, Next.js, or Angular. They accumulate pages fast — feature pages, integration pages, docs, changelogs, use-case landing pages, pricing tiers. And their marketing teams, rightly focused on content and backlinks, often don't notice the technical debt building up underneath until rankings have already stalled.

The frustrating part is that technical SEO problems are largely invisible in standard reporting. Traffic looks flat, so you publish more content. Rankings slip, so you chase more links. Meanwhile the actual bottleneck sits in your rendering pipeline, your crawl configuration, or your site architecture.

This checklist covers every area worth auditing for SaaS teams — in order of priority.

Before You Start: Tools You'll Need

You don't need a huge stack to do a solid technical audit. The essentials are Google Search Console (free, non-negotiable), Screaming Frog for crawl analysis, Google PageSpeed Insights for performance, and Ahrefs or Semrush for backlink and indexation health. For larger sites, server log analysis tools like Botify or Lumar add meaningful signal about what crawlers are actually doing on your site day to day.

1. Crawlability and Indexation

This is where most audits should start. If Google can't crawl and index your pages properly, nothing else matters.

Check your robots.txt file

Open your robots.txt file and read every rule. The two most common mistakes SaaS teams make here are blocking important pages accidentally — often after a site migration or dev deployment — and blocking AI crawlers like GPTBot, ClaudeBot, and PerplexityBot, which matters increasingly for AI search visibility.

Make sure you're not blocking any CSS or JavaScript files Google needs to render your pages. Blocking render resources is one of the fastest ways to tank your technical health without realising it.

Audit your XML sitemap

Your sitemap should include every page you want indexed and nothing you don't. Pull your sitemap into Screaming Frog and cross-reference it against your actual indexed pages in Search Console.

Common issues: pages in the sitemap that are noindexed, redirected URLs still included, or important pages missing entirely. Fix all three.

Use the URL Inspection Tool in Search Console

Pick a handful of your most important pages — pricing, key feature pages, high-intent landing pages — and run them through the URL Inspection Tool. Check whether Google has indexed them, when they were last crawled, and crucially, what the crawled page actually looks like. If the rendered HTML looks different from what you see in a browser, you have a rendering problem.

Check for crawl budget waste

For sites with more than a few hundred pages, crawl budget starts to matter. Since May 2025, Google has implemented dynamic crawl budgeting, meaning your daily crawl allocation fluctuates based on server response times, content freshness, and technical health.

Common crawl budget killers on SaaS sites: parameter URLs from faceted navigation or filters, thin utility pages like account settings and login screens, paginated doc pages without proper canonical handling, and old redirect chains left over from migrations.

Use Search Console's coverage report and server logs to identify which URLs Googlebot is spending time on that it shouldn't.

2. JavaScript Rendering

This is the issue that catches most SaaS teams off guard and is worth spending real time on.

Most SaaS products are built on JavaScript frameworks that render content client-side. That's great for user experience and terrible for search engine crawlers. When Googlebot visits a client-side rendered page, it often receives a nearly empty HTML shell — and has to put that page in a rendering queue to execute the JavaScript later. That queue introduces delays, and if your scripts are complex or error-prone, rendering fails silently.

How to check if you have a rendering problem

Right-click on one of your key pages and select View Page Source. If the source code is mostly empty and doesn't contain the main text of your page, Google is probably struggling with it.

Then run the same page through Search Console's URL Inspection Tool and click "View Crawled Page." Compare what Google saw to what you see in a browser. Any significant difference is a problem.

The fix

The gold standard is server-side rendering (SSR) or static site generation (SSG) for all revenue-influencing pages. This means your pricing page, feature pages, key landing pages, and product overviews should return fully-formed HTML in the initial response — no JavaScript execution required.

The tradeoff between rich app experience and crawlable content can usually be resolved at the page level. Keep complex, interactive app functionality client-side rendered where it genuinely needs to be. Put everything that needs to rank on SSR or SSG.

3. Site Architecture

SaaS sites accumulate structure problems in ways that blogs and ecommerce stores rarely do. Pages start competing with each other. Crawl paths get messy. Content that should build domain authority becomes a liability instead.

Keep important pages within three clicks of the homepage

Every page that needs to rank should be reachable in three clicks or fewer from your homepage. Pages buried deeper than that get crawled less frequently and accumulate less internal link equity.

Structure your site around what your buyer is trying to do — not how your internal team organises features. A pricing tier page should link to relevant use-case pages. A use-case page should link to the relevant integration pages and case studies. The paths should mirror the buyer journey.

Watch for keyword cannibalisation

SaaS sites generate a lot of similar pages — feature variants, use-case pages targeting overlapping queries, blog posts covering the same topic at different depths. When multiple pages target the same intent, Google gets confused about which one to rank and typically ranks none of them well.

Use Screaming Frog or Ahrefs to identify pages targeting similar terms. Consolidate where it makes sense, and use canonical tags to indicate the preferred version where consolidation isn't possible.

Handle documentation carefully

Docs are a crawl budget problem waiting to happen on most SaaS sites. Version history pages, API reference pages, and help articles can number in the thousands and eat significant crawl allocation without contributing much to rankings.

Apply noindex to doc pages that don't serve organic search intent. Use clear URL separation between documentation and commercial content so search engines can understand the hierarchy. Internal linking from docs to commercial pages is fine and useful — the opposite direction is where you need to be thoughtful.

4. Core Web Vitals and Page Speed

Google's page experience signals are now baked into rankings, and SaaS sites tend to struggle with them more than most due to heavy JavaScript execution, third-party scripts, and API-dependent content.

The three metrics to focus on:

LCP (Largest Contentful Paint) — how fast the main content of a page loads. Target under 2.5 seconds. Common fixes: optimise and lazy-load images, reduce render-blocking JavaScript, improve server response time.

INP (Interaction to Next Paint) — replaced FID in 2024, measures how quickly the page responds to user interaction. SaaS sites with heavy client-side state management often fail this. Deferring non-essential scripts and reducing main thread work are the main levers.

CLS (Cumulative Layout Shift) — visual stability as the page loads. Caused by images without defined dimensions, late-loading fonts, or ads and embeds injecting content above existing elements. Set explicit width and height on all images and iframes.

Run PageSpeed Insights and Search Console's Core Web Vitals report together. PageSpeed gives you lab scores and specific recommendations. Search Console gives you field data — real user experience across your actual traffic. Both matter, and they often tell different stories.

5. On-Page Technical Signals

Title tags and meta descriptions

Every indexable page needs a unique, descriptive title tag. Duplicates confuse search engines and waste ranking potential. Run your full site through Screaming Frog and filter for duplicate or missing titles — on larger SaaS sites this is almost always an issue somewhere.

Meta descriptions don't directly affect rankings but they affect click-through rate. Missing or duplicate meta descriptions should be filled in, especially on your highest-traffic pages.

Canonical tags

Canonical tags tell Google which version of a page to index when duplicates exist. Common misuses on SaaS sites: self-referencing canonicals pointing to the wrong URL version (http vs https, trailing slash vs no trailing slash), canonical chains where page A canonicals to page B which canonicals to page C, and incorrect canonicals introduced by CMS templates applied at scale.

Check your canonical configuration carefully on filtered pages, paginated pages, and any pages with URL parameters.

Structured data and schema markup

Schema markup doesn't directly boost rankings, but it significantly improves how your content is understood and displayed. More importantly in 2025, Microsoft's Fabrice Canel confirmed at SMX Munich that schema markup helps LLMs understand content — making structured data relevant not just for traditional search but for AI citation as well.

For SaaS, the most relevant schema types are Article for blog content, FAQ for support and product pages, SoftwareApplication for product pages, and BreadcrumbList for site hierarchy. Use Google's Rich Results Test to validate your implementation.

Internal linking

Internal links distribute authority across your site and signal to search engines which pages matter most. Your most commercially important pages — pricing, key feature pages, conversion-focused landing pages — should receive the most internal links from elsewhere on your site.

Check for orphan pages (no internal links pointing to them), and make sure anchor text is descriptive and contextual rather than generic "click here" links.

6. HTTPS and Security

This one should be table stakes by now, but it still trips up SaaS sites during migrations and subdomain expansions.

Make sure every page on your site is served over HTTPS, not just the homepage or the checkout flow. Check for mixed content warnings — pages served over HTTPS that load resources (images, scripts, stylesheets) over HTTP. Browsers flag these prominently and they can suppress security indicators that affect user trust and conversion.

Verify your SSL certificate is valid and renewing correctly. An expired certificate won't just hurt rankings — it'll kill conversions entirely.

7. Mobile Optimisation

Google uses mobile-first indexing, which means it crawls and indexes your mobile version of the page as the primary version. For SaaS companies whose buyers work primarily on desktop, this still matters because it's what Google sees.

Run your key pages through Google's Mobile-Friendly Test and PageSpeed Insights mobile scores. Pay attention to tap target sizes (buttons and links should be easy to tap without zooming), font readability, and content that might collapse or break on smaller viewports.

8. The New One: AI Crawler Access

This didn't exist as a serious concern two years ago. It does now.

AI crawlers — GPTBot from OpenAI, ClaudeBot from Anthropic, PerplexityBot, Google-Extended for Gemini training — are now a meaningful percentage of total crawler traffic. AI crawlers have expanded from 5% to 30% of total crawler traffic since 2024, and blocking them means your content doesn't end up in training data or real-time retrieval for AI search.

Check your robots.txt and make sure you're not blocking these user agents unless you have a specific legal or content reason to do so.

Also worth adding in 2026: an llms.txt file. Modelled on robots.txt, llms.txt is a new standard that provides AI systems with curated guidance about your site's most important content. It's not yet universal, but early adoption positions your site well as AI crawlers become more selective about what they index.

How Often Should You Run This Audit?

A full audit — covering all of the above — makes sense quarterly for most SaaS teams. Monthly is better if your team is shipping fast and the site is changing frequently.

Crawl health and Core Web Vitals should be monitored continuously via Search Console dashboards rather than treated as point-in-time checks. Set up email alerts for coverage drops, manual actions, or significant performance changes so problems surface immediately rather than after they've compounded.

The teams that win in technical SEO are the ones who treat it as ongoing infrastructure work rather than a periodic project. Most issues caught early cost an hour to fix. The same issues caught after six months of compounding often require weeks of remediation and months of ranking recovery.

The status means Google crawled the URL but has not included it in its index. It does not identify a single cause or promise that indexing will happen later. Google’s explanation of the status also says the unchanged URL does not need to be resubmitted for crawling.

For a business, the practical question is whether important pages are being missed. An excluded service page deserves a different response from an RSS feed. This guide walks through a diagnosis you can use before assigning development or content work, with a simple way to record the evidence behind each decision.

First, separate crawling from indexing

Crawling is Google retrieving a page. Indexing is processing its content and deciding what to keep in the search index. Google describes these as separate stages; a successful crawl does not guarantee inclusion or rankings.

“Discovered — currently not indexed” is a different starting point: Google knows the URL but has not crawled it yet. Do not treat both labels as the same problem. If the page has already been crawled, repeatedly telling Google that it exists will not explain the indexing decision.

Start with one important URL and one comparable indexed page from the same section of your site. Comparing like with like is more useful than investigating a service page, a tag archive and a tracking URL as if they were equivalent.

1. Decide whether this URL belongs in search

Ask what a person would gain by landing on this page directly from Google. A product page with useful specifications, an original tutorial or a service page explaining a distinct offering may have a clear purpose. A print view that repeats an article usually does not need its own search listing.

Write down the intended outcome before touching any settings: index this page, consolidate it with a better version, or deliberately keep it out of search. The goal is not to make the excluded-page count reach zero.

Do not remove pagination or navigation pages simply because they are not indexed. They may still help users and crawlers reach deeper content. And if you discover confidential material, handle access control separately: Google’s guidance on controlling shared content distinguishes password protection from search-indexing controls. Robots.txt is not a privacy barrier.

Use the sequence to choose an investigation, not to assume that every excluded page needs the same fix. This is an original explanatory diagram, not a Search Console screenshot.

2. Check the individual URL and the timing

Open URL Inspection for the exact address. Record its reported indexing state and last crawl, then compare the crawl with your latest meaningful change. If you fixed the page yesterday but the reported crawl happened before that, you are looking at evidence of the old version.

Next, run a live test to check present access. Inspect the returned HTML and screenshot where available. Does the main content appear? Is it replaced by a login screen, an empty application shell or an error message?

The distinction matters: the stored inspection result describes Google’s known version, while the live test checks the current page. A successful live test does not prove indexing, and it does not resolve every issue, including Google’s canonical choice.

A site: search can be a useful extra observation, but do not use its result count as your inventory. Google explains that site searches do not return every indexed URL. Keep the exact URL and the inspection evidence together rather than switching between slightly different addresses.

3. Rule out a delivery or rendering problem

A page that looks fine in your logged-in browser can behave differently for a crawler. Check the public version, its HTTP response, the main content and any resources needed to display it. A 200 response is only a starting point: Google can receive a successful response without indexing the content.

Look for a concrete discrepancy you can reproduce. For example, the desktop page might show a detailed guide while the mobile layout displays only a loading message. Or a security layer might occasionally replace the page with a challenge. Record what was returned and when; a single successful test does not explain an intermittent failure.

For JavaScript sites, compare the initial HTML with the rendered result. Google uses rendered HTML when processing JavaScript pages, so check that the useful content and links survive rendering. Do not assume that a missing paragraph means all JavaScript must be removed.

Also check for an accidental noindex directive or a newly introduced robots rule. These have their own reporting categories when Google detects them. Finding one now is evidence about the live page, not proof that it caused the earlier “Crawled — currently not indexed” label.

4. Check for competing versions of the page

Compare the URL with similar pages on your site. Common examples include a tracking-parameter version, two guides answering the same question, or several location pages whose only difference is the place name.

Where the information is available, compare your declared canonical with Google’s selected canonical. Then review redirects, sitemap entries and internal links for conflicting preferences. If your links point to one version and the canonical points to another, make the intended destination consistent.

Google’s canonicalization guidance treats canonical annotations as signals, not commands. Use them for duplicate or substantially similar pages. Pointing every excluded URL at the homepage does not repair a collection of distinct pages.

If two articles solve the same reader problem, decide whether they should become one stronger resource. If they serve different needs, make that difference clear in the actual content, examples and navigation. A new title alone will not create a distinct purpose.

5. Look at usefulness and internal discovery together

Once the page can be delivered correctly, read it as someone arriving with the query you want it to answer. Can that person finish the task? What can they learn here that the neighboring pages do not already explain?

For a service page, useful additions might be the work included, the inputs needed, the deliverables and who the service suits. For a tutorial, the missing piece might be a working example or an explanation of a failure case. Those are editorial decisions based on the reader’s task, not a target word count. Google’s people-first content guidance explicitly rejects the idea of a preferred word count.

Then follow the path a reader would take to reach the page. Is it linked from a relevant category, a related guide or the service overview? Add a descriptive link where it genuinely helps the next step. A sitemap can support discovery, but it does not guarantee crawling or indexing.

When many important pages share the same symptom, investigate the template or section before commissioning dozens of separate rewrites. Dixika’s guide to choosing a technical SEO audit service explains how to turn that investigation into a scope, implementation tickets and acceptance criteria.

Turn the diagnosis into one clear next action

The examples below are illustrative, not client cases or measured indexing results. They show how evidence changes the next action.

For your own worksheet, keep one row per URL with the intended outcome, reported status, last crawl, live-test observation, proposed change, owner and follow-up result. Include a link to the evidence. “Improve quality” is difficult to assign; “replace the empty template with the complete tutorial and verify the rendered HTML” gives a developer something testable.

After a meaningful change, you can request a recrawl for a small number of URLs. For many changed pages, use the sitemap approach described in that guidance. Repeated requests for the same URL do not make crawling faster, and neither method guarantees indexing.

Separate two milestones: your fix working on the live page, and Google reassessing that page later. A rising indexed count is encouraging, but check whether the important URLs are included and whether they begin receiving relevant search impressions and clicks. Do not declare success because a URL moved to a different exclusion category.

If the investigation spans several templates, a migration or inconsistent canonical signals, contact Dixika with a sample of affected URLs. Include what changed, what Search Console reports and which pages matter commercially. That gives the review a useful starting point: resolving a specific obstacle between your content and the people searching for it.