A SaaS site is one of the harder things to keep indexed. The marketing pages, the docs, the app itself, and often a changelog and a template library all sit under one brand, built by people shipping features on a weekly cadence. Search engines see the leftovers. This guide covers what technical SEO for SaaS involves, the failures that show up again and again in software companies, and the order to fix them in.
What technical SEO for SaaS covers
Technical SEO is the work that lets a search engine reach your pages, render them, index them, and understand how they relate to each other. It sits underneath everything else. You can publish good content for a year and get very little back if the template it lives on blocks indexing or renders empty without JavaScript.
For a software company the scope is wider than a normal site. You are usually managing a marketing site, a documentation set, a blog, a set of programmatic pages for integrations or comparisons, and a logged in application that should never appear in search at all. Each of those has different crawl rules, and they tend to be owned by different people.
The content side of this is a separate discipline. If you want the wider picture of keywords, content, and pipeline, our guide to SEO for SaaS covers the strategy layer that sits on top of the work below.
Why SaaS sites break differently
The framework renders on the client
Most SaaS marketing sites are built on a JavaScript framework. When content and links only appear after client side rendering, a crawler can see a shell with almost nothing in it. Google can render JavaScript, but it does so on a delay and not always completely, and several AI crawlers do far less rendering than Google does.
The app and the marketing site share a brand
Logged in screens, account pages, password resets, and API endpoints get crawled more often than teams expect. They add nothing to search and they eat crawl attention. Staging environments are the same story. A forgotten staging subdomain with no authentication will get indexed and will compete with the real site.
Templates create pages faster than anyone reviews them
One integration template with three hundred records becomes three hundred URLs on the day it ships. If the template is thin, you have published three hundred weak pages at once. Filters and search parameters do the same thing quietly, generating near duplicate URLs that nobody planned.
Settle subdomain versus subfolder first
Decide where the blog, the docs, and any resource library live before you build them. A subfolder such as yoursite.com/blog keeps everything on one hostname, which is the simpler setup and the one most SaaS teams should pick. A subdomain such as blog.yoursite.com is treated more independently by search engines and needs its own momentum.
The reason this matters early is that changing it later means a full migration. If your blog already sits on a subdomain and it performs well, moving it is a project with real risk. If you are choosing now, choose the subfolder.
Docs are the common exception. Many documentation platforms only support a subdomain. That is usually fine, because documentation ranks on its own product terms, but watch for docs pages outranking marketing pages for terms you want to sell on.
Crawling and indexation
Start by finding out what is actually indexed. In Google Search Console, open the Pages report and read the reasons under Not indexed. Then run a site: query and look for anything you do not recognise.
The usual fixes for a SaaS site:
- Block the application. Logged in routes, account settings, and internal search results should not be in the index. Use noindex on pages that get crawled and robots.txt for whole directories that never need to be read.
- Password protect staging. Do not rely on noindex or robots.txt alone for staging environments, because a link from anywhere can still surface them.
- Keep the sitemap honest. It should list canonical, indexable URLs only. Sitemaps full of redirects, 404s, and noindexed pages train crawlers to trust the file less.
- Check that robots.txt is not blocking your CSS and JavaScript. If it is, the rendered page a crawler sees will be broken.
- Watch parameter URLs. Sort orders, filters, and tracking parameters can multiply a small page set into thousands of near duplicates.
Crawl budget is worth attention in proportion to your size. Google has said that sites with relatively few pages that change infrequently do not usually need to worry about it. A five hundred page marketing site does not have a crawl budget problem. A site with fifty thousand programmatic URLs does.
Canonicals and duplicate URLs
Every indexable page should carry a self referencing canonical tag. That single habit prevents a large share of duplicate content problems, because it tells search engines which version is the real one when parameters or trailing slashes create variants.
Common canonical mistakes in SaaS sites:
- A template that hard codes one canonical across every generated page, so three hundred integration pages all point at the first one.
- Canonicals pointing at a staging or preview hostname after a deploy.
- Canonicals that point at a URL which then redirects, which weakens the signal.
- Paginated pages canonicalising to page one, which hides the deeper content entirely.
Check canonicals per template rather than per page. If one integration page has the wrong canonical, all of them almost certainly do.
JavaScript rendering
Test what a crawler sees rather than what your browser shows you. Use the URL Inspection tool in Search Console and read the rendered HTML, or load the page with JavaScript disabled.
You are looking for three things. Does the main body copy appear in the HTML. Do internal links appear as real anchor tags with href attributes. Does the canonical tag and title appear before rendering.
Navigation is the part that most often fails. A menu built from click handlers instead of anchor tags gives crawlers no path through the site. The links look identical to a user and are invisible to a crawler.
If key content only exists after rendering, server side rendering or static generation for the marketing pages is the durable fix. Most modern frameworks support this. The application itself can stay client rendered, because it should not be indexed anyway.
Core Web Vitals and speed
Core Web Vitals measure loading, responsiveness, and visual stability, with Interaction to Next Paint covering responsiveness. Treat them as a user experience problem that also happens to be a ranking signal. A pricing page that shifts under a visitor's cursor costs you trials directly, before any ranking effect.
On SaaS marketing sites the recurring causes are large uncompressed hero images, embedded demo videos loading on page load, font files blocking render, and analytics and chat widgets stacking up in the head. Chat widgets and session recorders are usually the biggest single win, because they are easy to defer and nobody notices.
Structured data for software companies
Structured data does not lift rankings on its own. It makes your pages easier to parse, which matters more now that AI systems read pages to answer questions.
The types worth implementing on a SaaS site are SoftwareApplication on the product and pricing pages, Organization on the homepage with your real company details, BreadcrumbList across the site, Article on blog posts, and FAQPage where you have genuine questions and answers on the page. Mark up only what a visitor can actually see. Schema describing content that is not on the page is a violation, and it is the sort of thing that gets flagged in bulk.
Internal links and architecture
Internal links decide which pages get crawled often and which ones get forgotten. On a SaaS site the pattern that works is a small number of hub pages for each theme, with supporting content linking up to them and across to close neighbours.
The pages that usually end up orphaned are programmatic ones. If your integration pages are only reachable from a paginated directory buried in the footer, the ones deep in the list may never be crawled properly. Link them from relevant blog posts and from each other.
Use descriptive anchor text that says what the destination is about. Anchors like "learn more" and "click here" pass no meaning.
International SaaS sites
If you serve several languages, hreflang annotations tell search engines which version belongs to which audience. The rules are strict. Every version must reference every other version including itself, the language and region codes must be valid, and the URLs must be absolute.
Machine translating your marketing site into eight languages and publishing all of it is usually a mistake. Translate the pages that earn it, keep them maintained, and expand from there.
Redirects and migrations
SaaS companies rebrand, reposition, and replatform more often than most businesses. Every one of those is a migration.
Before you move anything, crawl the current site and export the full URL list with its titles and status codes. After the move, crawl again and compare. Map every old URL to the closest new one with a 301, avoid chains of more than one hop, and never redirect everything to the homepage. Bulk redirects to a homepage are treated as soft 404s and lose whatever the old page had earned.
Keep the redirects in place permanently. Removing them a year later to tidy the config file undoes the work.
Technical SEO for AI search
A growing share of research now happens inside ChatGPT, Perplexity, Gemini, and AI Overviews. These systems have their own crawlers, and most of them render JavaScript far less thoroughly than Google. A site that only works after client side rendering can be readable to Google and close to invisible to an AI crawler.
What helps is unglamorous. Serve real HTML. Use a clear heading hierarchy so sections can be extracted on their own. Answer the question near the top of the section rather than after four paragraphs of preamble. Keep the facts a model would want to quote, such as pricing, integrations, and limits, in text rather than inside an image or a script.
Check your robots.txt and your firewall rules to see whether you are blocking AI crawlers. Some teams block them deliberately and that is a valid choice, but many are blocking them by accident through a bot filtering rule nobody reviewed.
The audit sequence
Run these in order. Each step tends to explain the results of the next.
- Read the Search Console Pages report and write down the top three reasons pages are not indexed.
- Crawl the site and export status codes, titles, canonicals, and indexability by template.
- Load your five highest value pages with JavaScript disabled and note what disappears.
- Check the sitemap against the crawl and remove anything that redirects, 404s, or is noindexed.
- Test your main templates for a self referencing canonical, not just individual pages.
- Look for staging, preview, and app URLs in the index and shut them out.
- Review Core Web Vitals on the pricing, homepage, and top blog templates.
- Map the internal links into your programmatic page set and fix the orphans.
Prioritise by revenue rather than by severity score. A medium issue on the pricing page matters more than a critical one on a blog post from 2021. Auditing tools cannot make that call for you, because they do not know which pages drive trials.
Keeping it fixed without a technical SEO on staff
Most of the list above is a one time cleanup. The part that never ends is everything downstream: research, publishing on a schedule, internal linking as the site grows, backlinks, and staying visible in AI answers. That is the work that quietly stops when a quarter gets busy.
Distribb runs that side on autopilot. You connect your site and it handles keyword research, writes the articles, publishes them, builds backlinks, and works on your visibility in AI search without anyone driving it. Approvals are available if you want them and are not required for it to keep running. Pro is $97 a month. Accelerator is $495 a month and includes a human reviewing every piece before it goes out.
It is a platform rather than a bespoke creative agency, so it will not invent a brand campaign for you. Template rendering and routing fixes still ship in your own codebase, because that is where they live. Everything after that runs without you. If you want the specifics for software companies, see what Distribb runs for SaaS companies.
If you would rather hand the whole thing to people, we compared the options in our roundup of SaaS SEO agencies.
FAQ
What is technical SEO for SaaS?
It is the work that lets search engines crawl, render, index, and understand a software company's website. It covers JavaScript rendering, duplicate URLs, canonicals, sitemaps, redirects, internal links, structured data, and page speed. SaaS sites need extra care because templates generate many similar pages and the logged in application sits on the same domain as the marketing site.
How often should a SaaS company run a technical audit?
A full audit twice a year is enough for most SaaS sites, with a shorter check after any migration, redesign, or framework upgrade. Search Console should be checked monthly, because indexation problems usually appear there first.
Does JavaScript hurt SaaS SEO?
JavaScript causes problems when important content or links only appear after client side rendering. Google can render JavaScript but does it on a delay, and several AI crawlers do much less rendering. Server side rendering or static generation for marketing pages removes the risk.
Should the blog be on a subdomain or a subfolder?
A subfolder is the better default because it keeps everything on one hostname. Subdomains are treated more independently and have to build their own momentum. If your blog already sits on a subdomain and performs well, moving it is a migration with real risk and is not always worth doing.
Can technical SEO alone grow SaaS traffic?
Technical SEO removes the things blocking growth rather than creating demand. Fixing indexation on pages that already deserve to rank can produce a fast lift. After that, growth comes from content, internal links, and authority. Both halves are needed, and technical work is the one that has to come first.
Which tools do I need?
Google Search Console is essential and free, because it is the only first party view of how Google treats your site. Add one crawler, such as Screaming Frog or Sitebulb, for template level inspection. PageSpeed Insights covers Core Web Vitals. Anything beyond that is optional until the basics are in place.