SEO for SaaS companies

The facts here come from Google Search Central: Understand JavaScript SEO basics, Block Search indexing with noindex, Introduction to robots.txt, Software App (SoftwareApplication) structured data, Spam policies for Google web search and Creating helpful, reliable, people-first content. Where we give our own advice, we say so. The general steps (titles, Search Console, links) are in our SEO basics for small business websites; this page covers only what is different for software.

The short answer

Make sure the marketing pages, pricing and public docs are in the HTML Google renders, at URLs it can crawl. Keep the app, the logged-in screens and the sign-up steps out of the index with noindex or a login, not with robots.txt alone. Write feature, integration and comparison pages only where you have something true and specific to say. Add SoftwareApplication structured data where it fits, and measure SEO by the trials and sign-ups it brings, not by traffic alone.

Marketing site and app: two different jobs

The marketing site (home, features, pricing, docs, blog) exists to be found and read. The app (dashboards, settings, customer data) exists to be used by people who are already signed in, and none of it belongs in search results. Our view: the cleanest set-up puts the app on its own subdomain or path with its own rules, for example app.example.com, so a mistake in one does not leak into the other. If both share one codebase, keep a list of public and private routes and check it after releases that add routes.

JavaScript rendering basics

Google says it processes JavaScript web apps in three main phases: crawling, rendering and indexing. Pages with a 200 status go into a rendering queue, where a headless Chromium runs the JavaScript once Google's resources allow, and Google uses the rendered HTML to index the page. That works, but Google adds that "server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript."

Three things from the same page matter most for SaaS sites. Links should be real <a href> links; injecting them with JavaScript is fine as long as they follow Google's crawlable-link markup. Routes should use the History API, not URL fragments (#/pricing), to load different content. And a single-page app that shows "not found" with a 200 status creates soft 404s; Google suggests a JavaScript redirect to a URL that returns 404, or adding a noindex robots meta tag to the error view. The details, including titles and canonicals set by JavaScript and testing with URL Inspection, are in our JavaScript SEO guide.

Keeping the app, sign-up and account pages out

A common mistake is to disallow /app/ in robots.txt and assume the job is done. Google's robots.txt guide says robots.txt is used mainly to avoid overloading a site with requests and "is not a mechanism for keeping a web page out of Google". A blocked URL can still be indexed if other pages link to it, shown without a description. To keep a page out, Google says to use noindex or password protection.

The two also clash: "For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file". If robots.txt blocks a page, Google never sees its noindex. In practice for SaaS (our view):

• Screens behind a login need nothing else: a crawler sees the login wall, not the data.
• Public steps of the funnel with no search value (sign-up form steps, onboarding, password reset, invite and email-confirmation links) get a noindex robots meta tag or an X-Robots-Tag header, and are not blocked in robots.txt.
• The main sign-up or "start free trial" page can stay indexable if people search for your brand plus "sign up"; it is a landing page, not app space.
• Shared links that open customer content without a login (public reports, shared boards) need noindex unless the customer chose to publish them.

How each method works, and how long a page takes to drop out, is in our guides to the noindex tag and robots.txt and XML sitemaps.

Documentation and help centre pages

Product docs can bring search visits the marketing pages never get, because people search for the exact task they are stuck on: "export invoices to CSV", "connect X to Slack". Our view: keep public docs on your own domain (a /docs/ or /help/ path, or a docs subdomain you verify in Search Console), as plain crawlable pages with one task per page and a clear title. If a help-desk tool puts articles behind a login, Google cannot read them; if it renders them only with JavaScript, check them with URL Inspection like any other JS page. Docs for features that no longer exist should redirect or return 404 rather than stay up and confuse readers.

Feature, integration and comparison pages

These pages are where SaaS SEO most often crosses Google's spam lines. Google's spam policies say "Scaled content abuse is when many pages are generated for the primary purpose of manipulating search rankings and not helping users", and "Doorway abuse is when sites or pages are created to rank for specific, similar search queries." Two hundred integration pages that differ only by the partner's name, or a "best X alternatives" page for every competitor with the same text swapped in, fit those descriptions.

Google's helpful content page gives a test to run on each one, including "Are you mainly summarizing what others have to say without adding much value?" and whether a reader will "leave feeling they've learned enough about a topic to help achieve their goal". It also says "SEO can be a helpful activity when it is applied to people-first content, rather than search engine-first content." Our view of what passes:

• Feature pages: one page per feature people actually search for, showing what it does with real screenshots and its limits.
• Integration pages: a page only where the integration does something specific worth explaining: what syncs, which way, set-up steps, plan requirements.
• Comparison pages: written from first-hand use of the other product, dated, accurate about where the competitor is stronger, and updated when either product changes.

More on both sides of the line: helpful content for business websites and Google's spam policies.

The pricing page

People search for "[product] pricing" before they buy, so the pricing page should be a normal, indexable page with the plans and prices in the HTML, not loaded only after a click, behind a form or inside an image. If the plan table comes from JavaScript, check in URL Inspection that the rendered HTML shows it. Our pricing pages guide covers how to present prices honestly.

SoftwareApplication structured data

Google supports SoftwareApplication markup, and also the MobileApplication and WebApplication types, for app details in search results. To be eligible for a rich result, the required properties are name, offers.price and a rating or review (aggregateRating or review); applicationCategory (for example BusinessApplication) and operatingSystem are recommended. Google says: "If the app is available without payment, set offers.price to 0". Ratings must follow Google's review snippet guidelines, so only mark up real reviews shown on the page; without a rating or review, the page is not eligible for the rich result. Format, testing and the general rules are in our structured data basics.

Counting trials and sign-ups

Search Console reports clicks and impressions, not sign-ups. Our view: mark the trial start, demo request and sign-up as key events in GA4 (see GA4 key events), link GA4 to Search Console, and look at which landing pages bring trials, not only visits. Docs pages are the exception: judge them on support load, not sign-ups. If you also run ads, the same events feed Google Ads for SaaS.

If your product site or app is still being built, our web app development service builds customer portals, internal tools and dashboards with React, Next.js and Node.js, and we plan the public and private routes from the start.

Frequently asked questions

Can Google index a SaaS site built with React or another JavaScript framework?

Yes. Google renders JavaScript pages with a headless Chromium before indexing them, but it still recommends server-side or pre-rendering because it is faster for users and crawlers and not all bots run JavaScript.

Should I block my app in robots.txt?

Not as the only measure. Google says robots.txt is not a mechanism for keeping a page out of Google; use a login or noindex, and do not block noindexed pages in robots.txt or Google cannot see the tag.

Are competitor comparison and alternatives pages allowed?

Yes, if each one is written to help someone choose and is accurate. Many near-identical pages made mainly to rank for similar searches can fall under Google's scaled content or doorway abuse policies.

Which structured data should a SaaS product use?

SoftwareApplication, or WebApplication for a browser-based product, with name, offers.price (0 if free) and a real rating or review for a rich result.