How to Do SaaS Technical SEO: 10 Issues to Fix in Order

SaaS technical SEO is the process of fixing how a SaaS company’s website is built and set up so that it helps Google and AI tools find, read and store its pages, and helps those pages show up in search and AI answers.

Say you open an audit tool. You get a couple hundred warnings and a PageSpeed score sitting in the orange. Speed is the easiest number to move, so that’s usually where people start. But on a SaaS site, I’d fix speed last. If Google hasn’t indexed your important BOFU pages, it doesn’t matter how fast they load.

Most SaaS sites aren’t that big, either. You’re usually looking at around 500 to 700 pages at most, maybe more if you run programmatic pages. On a site that size, my rough estimate is that about 90% of the technical ranking gains come from crawlability and indexation. That’s why the indexing problems sit at the top of the list below and speed sits at the bottom.

The 10 SaaS Technical SEO Issues at a Glance

• Issue 1: Important pages like pricing and features aren’t in Google’s index, so they can’t rank.
• Issue 2: Logged-in app screens and staging sites show up in search as junk or duplicate results.
• Issue 3: Versioned docs, filter URLs and thin changelogs create duplicates that compete with the right page.
• Issue 4: Regional pages without correct hreflang tags get treated as duplicates, so the wrong country’s page shows up.
• Issue 5: Page content only loads through JavaScript, so Google sees it late and many AI crawlers miss it.
• Issue 6: Links your blog earns on a subdomain may not help your product pages as much as they would in a subfolder.
• Issue 7: Redirect chains, 404s and orphan pages waste link value and leave pages hard to find.
• Issue 8: Missing or wrong schema leaves search engines guessing what your product is.
• Issue 9: AI crawlers are blocked or can’t read your pages, so AI answers don’t cite you.
• Issue 10: Slow pages hurt users and conversions, but they matter least of the ten for rankings.

What Is SaaS Technical SEO?

SaaS technical SEO refers to the work on a software site’s infrastructure that lets search engines and AI systems crawl, render, index and understand its pages. It’s the part of SEO that deals with how your pages are built and served.

Now, for a SaaS site, that work mostly lands in five areas:

1. JavaScript rendering: a lot of SaaS marketing sites are built on React, Next.js or a similar framework. If your content only shows up after JavaScript runs, a crawler can end up looking at an almost empty page. (Issue 5)
2. Site architecture and subdomains: your marketing site, your app, your docs and your blog often live in different places. How you split them up, and how clear your URL structure is, decides what gets crawled and where the value of your links ends up. (Issues 2, 4, 6 and 7)
3. Crawl budget and auto-generated pages: filters, URL parameters, docs versions and changelogs can quietly turn into thousands of thin URLs. (Issue 3)
4. Page speed and Core Web Vitals: how fast your pages load, how quickly they respond, and whether things jump around while they load. (Issue 10)
5. Structured data: schema tells search engines what your product is, what it costs and who makes it. (Issue 8)

There’s one more thing that wasn’t on this list a few years ago. ChatGPT, Perplexity and Claude send their own crawlers, and many of them don’t run JavaScript at all. So whether those tools can read your pages is a technical question too.

And if you’re wondering where this sits next to the rest of SEO, here’s how I’d put it. SEO is the whole job: content, links, technical, all of it. Technical SEO is the foundation underneath, and it’s Step 2 of our 8-step SaaS SEO strategy . You can write the best comparison page in your category, and if Google never indexes it, nobody’s going to find it.

Why Is Technical SEO Different for SaaS?

Most websites only need their marketing pages crawled and indexed, whereas a SaaS site also has to manage a logged-in app, docs and changelogs on the same domain, and product releases that can change pages every week.

A SaaS site has everything any other site has. Blog posts, landing pages, a pricing page, maybe a few category pages. And JavaScript rendering isn’t a SaaS-only problem anymore, with so many sites now built on React or put together with AI site builders. What’s different is everything a SaaS company adds on top, like an app dashboard that ends up in Google, or an old v1 docs page outranking v3. Most technical SEO checklists don’t check for those, because they’re written to work for any website. Technical SEO for SaaS websites has to cover those extras too.

Here’s what a SaaS site adds on top of the usual:

Most of those extras show up in Issues 2 and 3. The last row is why the audit schedule further down has a check after every release.

How to Do Technical SEO for SaaS

To do technical SEO for SaaS, set up Search Console and a crawler, check that your key pages are indexed, clean up app, staging and duplicate URLs, fix rendering, redirects and schema, and leave speed for last.

If you’re starting from scratch, this is the order I’d work in:

1. Set up your tools: verify your site in Google Search Console and Bing Webmaster Tools, and run a first crawl with Screaming Frog or a site audit tool so you can see what’s there.
2. Check indexing first: open the Pages report and look at your product, pricing, comparison and integration pages before anything else, because a page Google hasn’t indexed can’t rank at all.
3. Clean up what shouldn’t be in Google: keep staging sites and logged-in app screens out of search, and point duplicate docs, filter URLs and old versions at the page you want to rank.
4. Fix how pages render and link: make sure your main content is in the HTML, fix 404s and redirect chains, link to orphan pages, and add schema to your product and pricing pages.
5. Check speed and keep checking: fix any Core Web Vitals failures, then put the audit schedule further down on your calendar so new releases don’t undo the work.

The 10 issues below go through each of these in detail, in the same order.

What Tools Do You Need?

You’ll need Google Search Console, a crawler like Screaming Frog, a site audit tool like Semrush or Ahrefs, PageSpeed Insights and Google’s Rich Results Test, and most of them are free.

Here’s what each one costs and what it’s for (prices checked in October 2026):

The 10 SaaS Technical SEO Issues, in the Order to Fix Them

The 10 SaaS technical SEO issues to fix, in order, are: important pages that aren’t indexed, crawlable app and staging URLs, duplicate docs and parameter URLs, regional pages with broken hreflang tags, content that only loads through JavaScript, a blog on a subdomain, redirect chains, 404s and orphan pages, missing or wrong schema, blocked AI crawlers, and slow pages.

The order inside each group isn’t strict, though. If you spot something big further down, like your robots.txt blocking GPTBot, go ahead and fix it. That’s a one-line change.

Here’s what fixing each one looks like, before we go through them one by one. Time to check is how long it takes to find the problem, and time to fix is the work after that.:

Issue 1: Important Pages Aren’t Indexed

If your key pages aren’t in Google’s index , they can’t rank for anything, and this is the most common SaaS technical SEO problem we find when we audit a site.

It’s also easy to miss. The page loads fine, it’s in your sitemap, and your team looks at it every day. Nobody thinks to ask whether Google actually kept it.

The quickest check is a site: search. Type site:yourdomain.com/your-page into Google, and if the page doesn’t come up, Google hasn’t indexed it. Treat that as a spot check, though. For the exact answer on one URL, paste it into URL Inspection in Search Console.

This is what you see when a page isn’t in the index. Google just says the search didn’t match any documents:

For the whole site, open Search Console, go to Pages, and scroll to “Why pages aren’t indexed.” This is what that looks like. Pages sits in the left sidebar under Indexing, and each row in the list is a reason, with the number of pages it affects on the right:

When traffic drops, I look at two of those rows first: “Crawled - currently not indexed” and “Discovered - currently not indexed.” If either one keeps climbing, that’s usually your answer. They mean different things, though, so they need different fixes:

Once you know which reason is behind it, start with your BOFU pages: pricing, features, comparisons and integrations. Those are the ones that bring in demos.

Issue 2: Logged-In App Screens and Staging Sites Are Crawlable

Screens that sit behind your login, and staging copies of your site, shouldn’t be in Google, because they show up as junk or duplicate results.

It helps to split your app URLs into two groups:

• Keep crawlable: your login page. People search “[your product] login” all the time, and for a lot of SaaS companies it’s one of their biggest branded searches. Public app pages that work as content, like shared templates, public profiles or an integrations directory, go here too.
• Keep out of Google: everything past the login. Dashboards, workspace URLs, settings, onboarding steps, password-reset links.

That second group is where things go wrong. When Googlebot follows a link to one of those pages, it usually gets bounced to the login page or lands on an empty shell. Some of them end up indexed anyway, as a pile of near-identical pages titled “Dashboard” or “Sign in.”

Staging is the other one. Staging and preview deploys often aren’t password-protected, so a single stray link or an early sitemap entry is enough for Google to find them. And then there’s a full copy of your marketing site competing with the real one.

To check, search Google for these, using whatever subdomains you actually run:

• site:app.yourdomain.com
• site:staging.yourdomain.com

Anything that shows up and isn’t meant to be public needs to go. On a site with this problem, the results look something like this. The login page belongs there, and the rest don’t:

Here’s how to clean it up:

• Staging and preview sites: put them behind a password. HTTP authentication keeps every crawler out.
• Logged-in paths: block them in robots.txt so crawlers stop requesting them.
• Pages that are already in Google: add a noindex tag and leave them crawlable until they drop out. If you block them in robots.txt first, Google can’t see the noindex, and they can stay in the index.
• Internal links into the app: check your marketing pages for links that point into the app and end up redirecting to the login. Point them at a public page instead.

Issue 3: Versioned Docs, Thin Changelogs and Parameter URLs Create Duplicates

Near-identical docs versions, filter URLs and one-line release notes create duplicate content that splits your rankings across copies of the same page, and Google can end up showing the wrong one.

In SaaS technical SEO, you’ll often hear this called a crawl budget problem. For most SaaS sites it isn’t one. Google says crawl budget is worth worrying about once you’re past about a million pages, or more than 10,000 pages that change every day. A SaaS site is usually a few hundred pages, and Google can crawl all of that. What actually costs you is the duplicates.

It usually shows up in one of three ways:

• Versioned docs: you’ve got /docs/v1/authentication, /docs/v2/authentication and /docs/v3/authentication, and they’re about 90% the same. Google might pick v1 as the main version because it’s older and has more links pointing to it. So someone searching for how to authenticate with your API lands on a page you deprecated a year ago.
• Filter and parameter URLs: say your integrations directory has 80 integrations, with filters for category and sort order. Every combination becomes its own URL. That’s hundreds of URLs showing the same 80 cards.
• Thin changelogs: one page per release, each saying something like “Fixed a bug in CSV export.” None of them will ever rank, and they pile up in “Crawled - currently not indexed,” where they bury the pages you actually care about.

Here’s the versioned docs problem in search results. It’s three copies of the same page, and the oldest one is on top:

To check, go back to that Search Console list and look at “Duplicate, Google chose different canonical than user,” “Duplicate without user-selected canonical” and “Crawled - currently not indexed.” If those rows are full of docs pages or URLs with question marks in them, this is your issue.

The fixes:

• Old docs versions: point their canonical tag at the current version.
• Filter and parameter URLs: add a canonical to the clean URL, or noindex them, and keep them out of your sitemap.
• Changelogs: roll release notes up into one page per month.
• Your XML sitemap: list only canonical, indexable pages that return a 200. And make sure it agrees with robots.txt, so you’re never listing a URL that robots.txt blocks.

Don’t noindex your docs to solve this, by the way. Docs pull in real search traffic. Give each docs section its own kind of query, like setup, troubleshooting or API reference, and keep the commercial keywords on your marketing pages.

How your pages are structured decides a lot of this. We had a client who wanted to go after specific B2B use cases with programmatic pages . We didn’t publish thousands at once. We built 100 first to test the setup, and Google struggled to index them. So we reworked the page architecture, and within a day the pages started getting indexed. Only after that did we scale up, step by step, to 50,000 pages.

Issue 4: Regional Pages Have Missing or Broken hreflang Tags

If you sell in more than one country, hreflang tags tell Google which version of a page to show in each region, and without them it can treat your regional pages as duplicates and show the wrong one.

This one only applies once you’ve got regional or translated pages. Say you have /pricing/ for the US, plus /uk/pricing/ and /au/pricing/. The copy is almost the same, and only the currency and a few details change. To Google, that looks a lot like three copies of one page. So it picks one, and a buyer in London lands on your US pricing in dollars, or your UK page never ranks at all.

hreflang tags sort that out. They sit in the <head> of each page and tell Google which versions exist and which audience each one is for. Here’s a real set from greytHR, an HR software company with India, Middle East and Indonesia versions of its HR software page:

The rules that trip most teams up:

• Return links: every version has to list all the others, and itself. If the UK page points to the US page but the US page doesn’t point back, Google can ignore the tags.
• Correct codes: use a language code with an optional region code, like en-gb or en-au. The UK’s region code is GB, so en-uk doesn’t work, and it’s one of the most common slips.
• x-default: mark one version as the fallback for everyone who doesn’t match a region.
• Canonicals: each regional page needs a canonical tag pointing to itself. If the UK page’s canonical points to the US page, it contradicts the hreflang tags, and Google usually goes with the canonical.

To check, run the hreflang report in a crawler like Screaming Frog or Sitebulb. It flags missing return links, invalid codes and regional pages whose canonical points somewhere else.

Issue 5: Page Content Only Loads Through JavaScript

If your page’s content only appears after JavaScript runs, Google has to render the page before it can see that content, and many AI crawlers won’t see it at all.

What actually happens is when a crawler asks for a page, the first thing it gets is the HTML your server sends back. On a lot of sites built with React or Vue, or put together with an AI site builder, that HTML is almost empty. It’s a shell with a script tag in it, and the headline, the copy and the pricing table all get filled in by JavaScript once the page loads in a browser.

As a visitor, you’d never notice, because the page looks fine. But Google has to put it in a rendering queue, run the JavaScript, and only then read what’s on it, which can hold up indexing, especially for newer pages with few links. And many AI crawlers, like the ones behind ChatGPT and Perplexity, don’t run JavaScript at all. To them, the page is blank.

Here’s the same page from both sides:

To check, right-click the page, choose View Page Source, and search for a sentence from your page. If it isn’t in the source, JavaScript is adding it. You can also open URL Inspection in Search Console and click View crawled page to see the HTML Google got, or load the page with JavaScript turned off. If the main content disappears, crawlers have the same problem.

The SaaS technical SEO fixes for this, from best to most basic:

1. Server-side rendering (SSR): the server builds the full HTML before sending it, so every crawler gets the complete page on the first request.
2. Static site generation (SSG): pages are built as finished HTML when you deploy. Next.js, Nuxt and SvelteKit all support this, and it works well for marketing pages that don’t change by the minute.
3. Prerendering: a service serves crawlers a ready-made HTML copy of each page. It’s less engineering work, but it’s one more system to maintain.

While you’re in there, check that robots.txt isn’t blocking your CSS or JavaScript files. The page still returns a 200, so uptime monitoring won’t flag it, but Google can’t render it properly.

The same thing can quietly break your tracking too. We had a client whose demo form was meant to load a /demo-submitted/ page, and that page view was what GA4 counted as the conversion. But JavaScript often just swapped the form for a “Demo scheduled with [Name] on [Date + Time]” message without loading a new page, so the conversion didn’t fire reliably. If your conversions depend on a thank-you page, fire a conversion event like generate_lead when the form succeeds, and compare a month of demo bookings in your CRM with GA4 to spot any gap.

Issue 6: The Blog Lives on a Subdomain

A blog on blog.yourdomain.com may not pass as much value to your product pages as one at yourdomain.com/blog, so a subfolder is the safer setup.

I’ll be honest, this one gets debated. Google has said it handles subdomains and subfolders about the same. But the safe assumption is that a subdomain can get treated more like a separate site, which means the links your blog earns may not clearly help your feature and pricing pages. With a subfolder, it’s all one site, and there’s no question about it.

Here’s the difference in the URL itself:

Usually the blog ended up on a subdomain because it was set up on a different CMS before anyone thought about SEO. You don’t have to rebuild anything to change that. A reverse proxy can serve the blog under a subfolder while the CMS behind it stays the same.

So is it worth moving? If the blog is big and already ranks well where it is, a move carries real risk: every URL changes, and every one of them needs a clean 301 redirect. If the blog is newer, or isn’t pulling much traffic yet, moving it into a subfolder sets you up better going forward.

The same thinking applies to public pages that live on your app subdomain, like integration pages or feature tours. If prospects are meant to find them through search, they belong on the main domain.

Issue 7: Redirect Chains, 404s and Orphan Pages

Redirect chains, broken internal links and pages with no internal links pointing to them waste crawls and link value, and they make important pages harder for Google to find.

404s are one of the SaaS technical SEO issues we find most often. Products get renamed, features get retired, pages get moved during a redesign, and the links pointing at the old URLs just stay where they were.

There are three things to look for:

• 404s from internal links: a link on your own site that points to a page that’s gone. It’s a dead end for visitors and for Googlebot, and one of the most common crawl errors . Fix the link, or 301 the old URL to the closest live page.
• Redirect chains: page A redirects to B, which redirects to C. SaaS sites build these up over years of rebrands and migrations. Point every redirect straight at the final URL.
• Orphan pages: pages with no internal links pointing to them. Think integration pages added during a launch, feature pages the product team built on their own, or old comparison pages. They’re often in the sitemap, but with nothing linking to them, Google tends to leave them sitting in “Discovered - currently not indexed.”

To check, run a crawler like Screaming Frog or Sitebulb over the site. Filter for 404s, redirects with two or more hops, and pages that have zero internal links pointing to them. Then put that last list next to the “Discovered - currently not indexed” URLs in Search Console. There’s usually a lot of overlap.

Here’s a real 404 in Screaming Frog. Set the Response Codes tab to Client Error (4xx), click the broken URL, and the Inlinks tab at the bottom lists every page still pointing to it:

That one’s only a missing image. On a site in worse shape, the same report shows actual blog posts or feature pages returning a 404, with several pages across the site still linking to each of them.

And across a whole crawl, the three problems look something like this:

Orphans get fixed with links from the pages most related to them. A feature page should get links from the blog posts and use-case pages that talk about that feature, and every important page should be reachable within about three clicks of the homepage.

Issue 8: Schema Is Missing or Doesn’t Match the Page

Schema markup describes a page to search engines in a format they can read directly, and without it they have to guess what your product is, what it costs and who makes it.

Missing product schema is another SaaS technical SEO gap we find all the time. The homepage might have Organization schema that the CMS added, and the blog has Article schema. But the product and pricing pages, the ones that actually describe what you sell, have nothing.

For a SaaS site, these are the types worth having:

Here’s what it looks like on a real SaaS site. greytHR’s HR software page carries SoftwareApplication schema in its code, with the product name, category, the platforms it runs on, and its review rating:

One rule with all of these: only mark up what’s actually on the page. A rating in your schema with no reviews on the page, or a price that doesn’t match your pricing page, can cost you rich results altogether. And FAQPage won’t get most sites the old FAQ dropdowns in Google anymore, but it still labels your questions and answers clearly for search engines and AI tools.

You probably don’t need a dedicated schema tool for any of this. WordPress and Webflow generate a lot of schema on their own, and for anything custom, ChatGPT or Claude can write the JSON-LD for you to paste into your CMS. Our free schema markup generator does the same for SoftwareApplication, Organization, FAQPage and Article: fill in the fields and copy the code. Whatever you use, run the page through Google’s Rich Results Test before you call it done.

Issue 9: AI Crawlers Are Blocked or Your Pages Aren’t Citation-Ready

AI tools like ChatGPT, Perplexity and Claude can only cite pages their crawlers are allowed to reach and able to read.

Allowing Googlebot doesn’t automatically let the others in. OpenAI’s GPTBot and OAI-SearchBot, Anthropic’s ClaudeBot and PerplexityBot each read your robots.txt separately. A lot of security tools and CDNs also block unfamiliar bots by default, so you can end up blocking them without anyone ever deciding to.

This is what a robots.txt looks like when it lets them in. Each company’s crawlers get their own lines:

If you’d rather not write those rules by hand, our free robots.txt generator lets you allow or block each AI crawler and gives you the file to upload.

Access is only half of it. Since many of these crawlers don’t run JavaScript, Issue 5 matters twice over here. If your answer only appears after a script loads, they never see it.

Then the page has to be easy to quote. That comes down to a few things:

• Direct answers first: put the answer at the top of each section, before the detail.
• Clear structure: use clear headings, short paragraphs, and tables wherever you’re comparing things.
• Author and date: keep an author name and an updated date on the page.
• llms.txt (optional): some sites also add an llms.txt file , which is a plain list of their key pages for AI tools. It won’t make up for any of the points above.

Issue 10: Slow Pages and Core Web Vitals

Core Web Vitals measure how fast your pages load, how quickly they respond and how stable they stay while loading, and they’re a ranking factor, but on a typical SaaS site they matter less than the other nine issues.

I don’t chase perfect PageSpeed scores. The pages ranking at the top for competitive SaaS keywords rarely score above 80, and in my experience getting a page from 65 to 92 won’t change where it ranks.

Here’s an example. Search “project management tools”, one of the most competitive searches in SaaS, and Wrike’s guide comes up first:

Now run that same page through PageSpeed Insights on mobile. It scores 63 for performance, well short of the green zone, and it’s still ranking first:

That doesn’t mean speed doesn’t matter. Slow pages lose people before they ever see your demo button. So fix the failures, and then stop there. These are Google’s thresholds:

If you still see First Input Delay (FID) in older guides, that’s the metric INP replaced as a Core Web Vital in March 2024.

Check the mobile numbers first. Google uses mobile-first indexing, which means it crawls and ranks the mobile version of your pages, so that’s the version that has to hold up. Make sure your mobile pages carry the same content as desktop, too.

Once your pages are in the green, your time is better spent on the issues above.

On SaaS marketing sites, the usual failures are big hero images that aren’t in WebP, chat widgets and analytics or A/B testing scripts loading before the content, and layout shifts from fonts or banners that load late. Most engineering teams can fix the critical ones in a sprint.

How to Do a Technical SEO Audit for SaaS

To do a technical SEO audit for SaaS, check the pages that changed after every release, review indexing, duplicates, broken links and Core Web Vitals every month, and run a full technical SEO audit of all 10 issues every quarter.

A SaaS site changes all the time. Someone ships a new page template, a noindex tag from staging slips into production, or a page gets renamed and the old URL starts throwing 404s. One audit a year won’t catch any of that, so each issue gets its own rhythm. Here’s how often I’d check each one, and how:

Where Should You Start for Your Setup?

Where you start with technical SEO for SaaS depends on what your site is built on and what’s happening right now, but if traffic just dropped, start with indexing.

A migration is the one case where I’d change the order. Anything that’s going to break tends to break on launch day, so check rendering, duplicates and redirects on staging before you switch over.

How PipeRocket Handles SaaS Technical SEO

At PipeRocket, we fix SaaS technical SEO in this same order: indexing first, speed last, with conversion tracking checked along the way so the demos SEO brings in actually get counted. If you want a second pair of eyes on your site, take a look at our technical SEO services or talk to us .

Frequently Asked Questions

What is SaaS technical SEO?

SaaS technical SEO is the process of optimizing a software website’s infrastructure so search engines and AI systems can crawl, render, index and understand its pages. On most SaaS sites, that covers indexing, app and staging URLs, duplicate and regional pages, JavaScript, schema and page speed.

What is the difference between SEO and technical SEO?

SEO covers everything that helps a site rank, including content and links, whereas technical SEO is the part that makes sure search engines can crawl, render and index the site in the first place. Without the technical side working, the content and links have nothing to stand on.

Does using a JavaScript framework hurt SEO?

Not on its own. Sites built on React, Next.js or Vue rank fine when the content is in the HTML the server sends, through server-side rendering or static generation. It becomes a problem when content only loads in the browser, because Google has to render the page first and many AI crawlers don’t render JavaScript at all.

How often should a SaaS site run a technical SEO audit?

Run a full technical SEO audit every quarter, check Search Console every month, and do a quick check after every product release. Releases are when most technical SEO problems get introduced on a SaaS site.

How long does it take to see results from technical SEO fixes?

Small fixes, like removing a stray noindex tag or unblocking a page in robots.txt, can show up within days to a few weeks, once Google recrawls the pages. Bigger changes, like moving to server-side rendering or migrating a blog into a subfolder, usually take one to three months to settle. Requesting indexing in Search Console can speed up the first recrawl of your most important pages.

Should a SaaS blog be on a subdomain or a subfolder?

A subfolder, like yourdomain.com/blog, is the safer choice, because the blog and your product pages sit on one site and share its authority. Google says it can handle both. But if you’re setting up a blog now, the subdomain has no upside, and moving an established subdomain blog needs a careful 301 redirect plan.

Kamaraj Mathiarasan (Kim) Co-Founder, PipeRocket Digital

Kim is a dedicated SEO expert with over 15 years of experience helping B2B SaaS companies scale their organic presence. As Co-Founder of PipeRocket Digital, he focuses on high-impact SEO strategies, comprehensive content marketing, and revenue-focused optimization. Passionate about driving measurable growth, he builds scalable systems that turn organic traffic into meaningful pipeline.

View full profile