In short
SaaS SEO works best when the public site mirrors the product: feature, integration, use case, comparison and template pages that each answer a real buying question, served as plain HTML and kept separate from the logged-in app. Programmatic SEO builds many of those pages from a data source and a template, and it is legitimate as long as every page carries its own useful data. The moment pages exist only to catch keyword variations, the same method becomes what Google calls scaled content abuse or doorway abuse.
What Google officially says
Google has no separate rules for SaaS companies or for “programmatic” pages. The rules that matter are the general spam policies and the helpful content guidance. Two policies decide where the line is.
“Scaled content abuse is when many pages are generated for the primary purpose of manipulating search rankings and not helping users.”
Google Search Central — Spam policies for Google web search. Google continues: “This abusive practice is typically focused on creating large amounts of unoriginal content that provides little to no value to users, no matter how it's created.”“No matter how it's created” is the key phrase for programmatic work. A template filled from a database, a spreadsheet merged into HTML and text written by an AI model are all judged the same way: by the value of what ends up on the page. Google's examples include:
- “Using generative AI tools or other similar tools to generate many pages without adding value for users”
- “Scraping feeds, search results, or other content to generate many pages (including through automated transformations like synonymizing, translating, or other obfuscation techniques), where little value is provided to users”
- “Stitching or combining content from different web pages without adding value”
- “Creating multiple sites with the intent of hiding the scaled nature of the content”
- “Creating many pages where the content makes little or no sense to a reader but contains search keywords”
The instruction for site owners is short: “If you're hosting such content on your site, exclude it from Search.”
“Doorway abuse is when sites or pages are created to rank for specific, similar search queries.”
Google Search Central — Spam policies. “They lead users to intermediate pages that aren't as useful as the final destination.”Three of Google's doorway examples describe exactly what a careless programmatic project produces:
- “Having multiple domain names or pages targeted at specific regions or cities that funnel users to one page”
- “Generating pages to funnel visitors into the actual usable or relevant portion of a site”
- “Creating substantially similar pages that are closer to search results than a clearly defined, browseable hierarchy”
The helpful content guidance gives you the test to apply to each template. Two of its questions: “Does the content provide original information, reporting, research, or analysis?” and “Does the content provide substantial value when compared to other pages in search results?” It also lists warning signs, among them “Are you using extensive automation to produce content on many topics?” and “Does your content leave readers feeling like they need to search again to get better information from other sources?” And on the side of intent: “If you use automation, including AI-generation, to produce content for the primary purpose of manipulating search rankings, that's a violation of our spam policies.”
SaaS site architecture: marketing site, app, docs and blog
A typical SaaS company runs several sites under one brand, and each part has a different job in search. Getting the split right comes before any content work.
- Marketing site (
example.com): home, pricing, features, integrations, use cases, comparisons. These pages bring buyers and should all be indexed. - Docs and help center (
example.com/docs/ordocs.example.com): setup guides, API reference, troubleshooting, changelog. They rank for long, specific questions from people who already use or evaluate the product. - Blog (
example.com/blog/): guides, research and opinion for the problems your product solves. - Public templates and tools (
example.com/templates/,example.com/tools/): free things people can use without signing up. - The app (
app.example.com): everything behind login. It is for customers, not for search.
What stays out of the index
Dashboards, workspaces, settings, billing, invite and password-reset pages, internal search results and staging copies should never appear in Google. Logged-out requests to app URLs should get a login wall: Google's JavaScript guide recommends a meaningful status code, “like a 404 for a page that could not be found or a 401 code for pages behind a login.” Remember that robots.txt stops crawling, not indexing: a blocked URL that is linked from elsewhere can still show up as a bare URL. For pages that must not be indexed, a login wall or noindex is the reliable tool.
Publicly shared user content, such as public boards, forms or reports created by customers, is a deliberate decision. Keep it noindex by default. Index it only when it is genuinely useful to strangers, moderated, and the customer chose to make it public. Otherwise you publish thousands of thin or spammy pages under your domain that you did not write.
Subfolder or subdomain for docs and blog
Both work. Google's crawl budget guide notes that “https://www.example.com/ and https://code.example.com/ are treated as separate sites and have separate crawl budgets.” For most SaaS sites crawl budget is not the deciding factor; what matters more is that a subfolder keeps one navigation, one sitemap setup and one Search Console property, while a subdomain often means a separate CMS, separate templates and separate maintenance. If the docs live on a subdomain, add it to Search Console, link to it from the main navigation and link back from the docs to relevant feature pages.
App pages and JavaScript
Most SaaS products are single-page applications. Google describes the pattern: “Some JavaScript sites may use the app shell model where the initial HTML does not contain the actual content and Google needs to execute JavaScript before being able to see the actual page content that JavaScript generates.” For the app itself that is fine, because it is not meant to be indexed. The risk comes when the marketing site, docs or template gallery are built with the same front-end stack and inherit the app shell.
Rules for any public page that should rank:
- Render on the server or pre-render. “Keep in mind 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.” Pricing, features and integration pages should be complete in the HTML response.
- Use real links. “Google can only discover your links if they are <a> HTML elements with an href attribute.” Filters in a template gallery that change content on click without a link are invisible as navigation.
- Use the History API, not fragments. “For single-page applications with client-side routing, use the History API to implement routing between different views of your web app.” A URL like
/#/templates/okris one URL to Google. - Return honest status codes. A template or integration that no longer exists should not show an error message with a 200 status. That is a soft 404, and Google's crawl budget guide warns that “soft 404 pages will continue to be crawled, and waste your budget.”
- Do not start with noindex. “If you do want the page indexed, don't use a noindex tag in the original page code.” Removing it later with JavaScript may not work.
Rendering, hydration and testing are covered in depth in the lesson “JavaScript SEO and rendering”. Here the point is simpler: every page you want in search must work as HTML before any script runs.
Product-led page types
Product-led content means pages built around what the product actually does, for people who are close to a decision. Each type matches a different search intent and carries a different risk.
| Page type | Search intent | Example URL | Main risk |
|---|---|---|---|
| Feature | “Does the tool do X, and how?” | example.com/features/time-tracking/ | Marketing slogans with no screenshots, limits or plan details |
| Use case / industry | “Tool for my job or sector” | example.com/use-cases/agencies/ | The same text with the industry name swapped |
| Integration | “Does it connect with Y?” | example.com/integrations/slack/ | One sentence per app, hundreds of near-identical pages |
| X vs Y | Choosing between two products | example.com/compare/example-vs-rival/ | One-sided claims, outdated competitor prices |
| Alternatives to X | Unhappy with a product, looking around | example.com/alternatives/rival/ | A “list” that only recommends you |
| Template | “Give me a ready-made one” | example.com/templates/okr/ | Empty or duplicate templates, gallery pages with no content |
| Free tool | “Calculate / check / convert this” | example.com/tools/roi-calculator/ | Tool runs only in JavaScript with nothing else on the page |
| Glossary | “What does this term mean?” | example.com/glossary/burn-rate/ | Thousands of one-line definitions |
Feature pages
One page per feature that people actually search for. Show what it does, screenshots or a short video, how it works step by step, which plans include it and what its limits are. A feature page that only repeats the homepage pitch rarely ranks for anything.
Use case and industry pages
“Project management for agencies” and “project management for construction” are different questions only if the answers differ. A good use case page shows the workflow for that audience, the features they use most, a template they can start from and, ideally, a customer example. If the only difference between your industry pages is the industry name, you are close to Google's doorway example of “substantially similar pages”.
Integration pages
Integration pages are the classic programmatic page type for SaaS, and the easiest to get wrong. A useful one says what the integration does, which data syncs and in which direction, what triggers a sync, how to set it up, which plan it needs, what it cannot do, and links to the setup guide in the docs. “Example connects with Slack. Try it free.” repeated across 300 apps is not an integration page; it is a keyword list with a button.
Comparison and alternatives pages
These capture people at the moment of choosing, so they convert well and are tempting to exaggerate. The next section covers how to keep them honest.
Templates, free tools and glossary
These are top-of-funnel assets: people find them without knowing your brand, use them, and some of them come back. They are covered below as link and traffic assets.
Comparison and alternatives pages, done honestly
A comparison page is a claim about another company's product. Treat it like one. Readers check, competitors check, and an inaccurate page loses trust faster than it gains clicks.
- Date it. Show when the comparison was last checked, and recheck when either product changes pricing or plans.
- Show your criteria. List what you compared (price per seat, limits, integrations, support, data location) so readers can judge the comparison, not just the verdict.
- Say where the competitor wins. Every product is better for someone. A page that admits this is more believable on the points where you win.
- Source the facts. Link to the competitor's public pricing or docs for every number you state about them.
- No invented reviews or ratings. Use only real customer quotes and real, attributable scores.
- Alternatives pages list real alternatives. If your “Top 7 alternatives to Rival” page ranks only your own product in a useful way, readers leave and search again.
Google's thin affiliation policy describes what makes comparison-style content valuable: “Examples of good affiliate pages include offering additional information about price, original product reviews, rigorous testing and ratings, navigation of products or categories, and product comparisons.” The same standard is a good bar for your own comparison pages: original testing and real information, not a rewrite of two pricing pages.
Free tools, templates and glossaries as assets
A free tool is often the strongest SEO asset a SaaS site has. A calculator, checker, generator or converter answers a task directly, earns links from blogs and forums that recommend it, and puts your brand in front of people who will later search for it by name. Google counts tools as part of a page's main content: “Interactive features: Built-in functionality such as calculators, online tools, games, or search functionality.”
To make a tool page work in search:
- Keep a clear title, an explanation of what the tool does, how the result is calculated, worked examples and a short FAQ in the HTML around the tool. That text is what Google can read even if the tool itself runs in JavaScript.
- Make each tool a separate URL with its own title. One page with ten tools in tabs ranks for none of them well.
- Do not create a separate indexable URL for every possible input.
/tools/roi-calculator/?revenue=5000is a result, not a page.
Template galleries follow the same logic. Each template page should show a preview, explain who it is for and how to use it, and let people use it. Gallery and category pages need real content and real links to templates, and empty states (“No templates found”) should return 404 or carry noindex rather than be indexed.
A glossary works when it is tied to your product area: a definition, an example, how the concept shows up in practice, and a link to the feature or guide that helps. Thousands of one-line definitions copied from general knowledge add nothing a dictionary does not already offer.
How programmatic SEO works
Programmatic SEO means generating many pages from a structured data source with one template. In SaaS the common cases are integration pages, template galleries, “product for industry” pages, converters and data pages built from your own product data. It has three parts:
- Data source. A table where each row is a page and each column is a fact: an integrations database, a template library, public data you clean and enrich, or aggregated, anonymised data from your own product. The data decides whether pages can be different from each other.
- Template. The layout that turns one row into one page: title pattern, headings, sections that appear only when the data exists, related links, structured data.
- Unique value per page. The facts, examples and functions that exist on this page and nowhere else on your site. If you cannot point to them, the page should not exist.
A clean URL pattern follows from the data: /integrations/slack/, /templates/okr/, /tools/currency-converter/eur-usd/. One pattern per page type makes it easy to see each template's performance in Search Console later.
Word count is not the measure. Google says so directly: “Are you writing to a particular word count because you've heard or read that Google has a preferred word count? (No, we don't.)” Padding each page with generated paragraphs does not add value; it only adds text.
- Own data fieldsFacts specific to this row: what syncs, limits, prices, steps, numbers that differ from sibling pages.
- A real answerThe page fully answers the query in its title, without sending the reader elsewhere to finish.
- Something to doA working template, tool, setup button or interactive preview, not only text.
- Real examplesScreenshots, sample outputs or a customer example for this specific case.
- Questions from supportFAQ taken from real tickets or sales calls about this case.
- Links that helpTo the matching docs article, related pages from the same category and the parent hub.
- Accurate metadataA title and description written from the data, not a keyword pattern with a name swapped in.
- Checked by a personSomeone who knows the product reviewed the template and a sample of pages.
The quality gate before publishing
The most important decision in programmatic SEO is which rows not to publish. Build that decision into the pipeline, so a page is only generated when it clears thresholds you set per template.
What the checks mean in practice:
- Required fields complete. Decide which data fields a page cannot do without. An integration page without “what syncs” and setup steps is not finished; it is held back until the data exists.
- Unique facts above your threshold. Count the facts that differ from sibling pages. Set a minimum per template and test it on real rows. Rows below the line get enriched by a person or folded into a broader page such as the category hub.
- Real demand or user need. Either people search for it, or your users need it in navigation. A page with neither does not need to exist. A page users need but nobody searches for can stay, with
noindexand out of the sitemap. - Different enough from siblings. Compare each page with its closest neighbours in the same template. Near-duplicates, such as one template for 40 cities with the same text, are merged into one page, or the variants point a canonical to the main version.
For a variant you keep for users but not for search, put the directive in the server HTML:
<!-- held-back variant: usable, not indexed, not in the sitemap -->
<meta name="robots" content="noindex">Then launch in batches. Publish a first batch from the template, wait several weeks, and look at how many pages were indexed and whether they earn impressions. Expand when the batch performs; rework or prune the template when it does not. Publishing every row on day one hides the problem until it affects the whole site.
Where programmatic pages become scaled content abuse or doorways
The technology is the same on both sides of the line. The difference is whether each page helps the person who lands on it.
✓ Programmatic and useful
- Integration pages that each document a different connection: data, direction, setup, limits
- Template pages where each template is real and can be used
- Converter or calculator pages where each pair gives a different, correct result
- Data pages built from your own aggregated product data that nobody else has
- Docs pages generated from an API schema, one per endpoint
✕ Scaled content abuse or doorways
- “Best CRM for [city]” pages for hundreds of cities with the same text
- Integration pages for apps you do not actually connect with
- “[Rival] alternative” pages for every competitor, all with the same body
- Pages rewritten or translated from competitors' docs with no added value
- AI-written paragraphs added to empty rows just to reach a length
- Many thin pages whose only job is to push visitors to the signup page
The last item matches Google's doorway example of “Generating pages to funnel visitors into the actual usable or relevant portion of a site”. The city pages match “Having multiple domain names or pages targeted at specific regions or cities that funnel users to one page”. And sets of pages that differ only by a keyword fit “Creating substantially similar pages that are closer to search results than a clearly defined, browseable hierarchy”.
If you already have such pages, the policy's instruction is to exclude them from Search. In practice that means removing them, merging them into stronger pages, or adding noindex. Adding more generated text does not fix a page whose problem is that it should not exist. The wider question of AI-written content at scale is covered in the lesson “AI-assisted content without scaled content abuse”.
Internal linking and monitoring at scale
Linking generated pages
A page that exists only in a sitemap is hard for Google to value and impossible for users to find. Every generated page needs a place in the site's structure:
- A hub per page type:
/integrations/,/templates/,/compare/, with categories as real, crawlable links. - Breadcrumbs from each page to its category and hub.
- Related links chosen from the data: other integrations in the same category, templates for the same team, the matching docs article.
- Links from editorial pages: blog guides and feature pages that link to the most useful generated pages.
Keep the hierarchy browseable. That is the opposite of Google's description of doorways as pages “closer to search results than a clearly defined, browseable hierarchy”. How to plan hubs and depth is covered in the lesson “Internal linking and orphan pages”.
Crawling and duplicates
Large templates multiply URLs quickly: filters, sort orders, empty categories, parameters. Google's crawl budget guide is direct: “Eliminate duplicate content to focus crawling on unique content rather than unique URLs.” And: “If Google spends too much time crawling URLs that it shouldn't, Google's crawlers might not explore the rest of your site, or might not increase your crawl budget.” For Google Search, crawl resources take into account “popularity, overall user value, content uniqueness, and serving capacity.” Thin generated pages are not only an indexing problem; they slow down the discovery of your good pages.
Indexing ratio per template
“For Google Search, not every page that is crawled will necessarily be indexed.” Measure how many of each template's pages Google keeps:
- Create one XML sitemap per template, for example
sitemap-integrations.xmlandsitemap-templates.xml. - In the Page indexing report, filter by each sitemap. Indexed URLs divided by submitted URLs is that template's indexing ratio.
- Read the reasons for the rest. “Crawled - currently not indexed” and “Discovered - currently not indexed” on a large share of a template usually mean Google does not see enough value. “Duplicate without user-selected canonical” means pages look alike. Soft 404s often point to empty states.
- Compare templates. A template with a low ratio and no impressions is the first candidate for pruning or rework; a template with a high ratio and growing impressions is the one to expand.
- Watch the Performance report by URL pattern for clicks and impressions per template over time.
What each status means and how to fix it is explained in the lesson “Page indexing report: every status”.
Check how your templates are crawled
OurSEO Tools crawls up to 1,000 pages and records the status code, canonical, indexability and load time of every URL, so you can spot soft 404s, noindexed templates and duplicate pages in one run.
Common mistakes
- ✕Publishing every row on day oneThousands of pages go live before anyone knows whether the template works.
- ✕Swapping only the keywordIndustry, city or competitor pages with the same body and a different name.
- ✕Padding with generated textAdding paragraphs to reach a length instead of adding data or function.
- ✕Marketing pages inside the app shellPricing and features that only appear after JavaScript runs.
- ✕Indexable app and share URLsWorkspaces, settings or customer share links showing up in search.
- ✕Soft 404s on empty states“No results” pages returning 200 and getting crawled again and again.
- ✕Dishonest comparisonsOld competitor prices, invented ratings, alternatives pages that list only you.
- ✕Orphan generated pagesPages reachable only through the sitemap, with no hub or related links.
- ✕No per-template monitoringOne sitemap for everything, so nobody sees which template Google ignores.
FAQ
Is programmatic SEO against Google's guidelines?
No. Generating pages from data is a method, not a violation. It becomes scaled content abuse when pages are made “for the primary purpose of manipulating search rankings and not helping users”. Each page has to answer a real question with its own data.
How many programmatic pages should I launch at once?
Start with a batch that is big enough to measure but small enough to fix, then wait several weeks before expanding. The right size depends on your site, so there is no number that fits every case. What matters is that indexing and impressions per batch decide the next step.
Should comparison pages name competitors?
Yes, that is the point of the page. Keep every claim accurate and sourced, date the page, and say where the competitor is the better choice. Do not use invented reviews or ratings.
Should docs live on a subdomain or in a subfolder?
Either works. A subdomain is a separate site for crawling and in Search Console, so it needs its own setup and good links from the main site. A subfolder is easier to keep consistent. Choose by how your team maintains the docs.
Can I keep thin variants for users but not for Google?
Yes. Leave them crawlable, add noindex in the server HTML and keep them out of the sitemap. If many variants are near-duplicates of one main page, merging or a canonical is usually better.
Our app is a single-page application. Do we need to rebuild it?
Usually not the app itself, because it should not be indexed. What matters is that the public pages, such as pricing, features, integrations, templates and docs, are server-rendered or pre-rendered, use real links and return honest status codes.
Sources
- Google Search Central — Spam policies for Google web search
- Google Search Central — Creating helpful, reliable, people-first content
- Google Search Central — Understand JavaScript SEO basics
- Google Crawling Infrastructure — Crawl budget management
Quotes checked against the official pages on 30 October 2026.