One page per integration: why your SaaS needs many landing pages
“We need a landing page for every integration and every industry, but I don't want to maintain 50 copy-paste pages.” That sentence captures a real conflict: specific pages win specific searches, but naive scaling produces content chaos and trouble with Google. This article is part of our series on the anatomy of a B2B SaaS website and resolves the conflict: with a content model instead of a copy command.
Why many pages in the first place? Because nobody searches for your product category; people search for their own case. Google put a number on this back in 2017: “15% of searches we see every day are new.” Demand is broader and more specific than any homepage can ever cover. Three axes supply the cases:
- Integrations: searches like “X + HubSpot” come from people who already use both tools or are choosing them right now. An integration landing page has to answer just one question: what exactly does the combination do, and how do I set it up?
- Industries and personas: “time tracking for tax accountants” is a different search than “time tracking,” with different competition and different objections. The industry page speaks to client engagements, deadlines, and DATEV, not abstract features.
- Use cases: “approve vacation requests digitally” is searched by someone with a process problem who may not even know your product category exists. The use case page meets them at the problem and leads them to the product.
Add a competitive argument: on the head term “time tracking,” market leaders bid with six-figure content budgets. On “time tracking for tax accountants,” you often compete only with thin directory pages. The specific page is not just the more relevant answer; it is frequently also the position you can reach faster.
Your homepage cannot answer thirty such questions at once; one page per case can. But this is exactly where the risk begins that the next section covers: “one page per case” quickly turns into “the same page fifty times.”
The wrong way: 50 copies and a find-and-replace
The obvious route looks like this: you duplicate your best page, swap “tax accountants” for “architects,” and reach 50 landing pages within a week. Every page has the same structure, the same arguments, the same quote. Only one word rotates.
From the user's perspective, the result is thin content: the page promises an answer for architects and delivers the generic copy of your homepage. Anyone who arrives via a specific search and finds interchangeable text is gone with one click. So the ranking risk is only half the bill; the other half is wasted conversion.
Since March 2024, Google has run a dedicated spam category for this pattern: scaled content abuse. It targets, in Google's words, “many pages generated for the primary purpose of manipulating search rankings and not helping users.” And Google states explicitly that the policy applies “whether automation, humans or a combination are involved.”
The announcement was no empty threat: Google expected the March 2024 update, combined with its previous efforts, to “reduce low-quality, unoriginal content in search results by 40%.” After completing the rollout in April 2024, Google even reported 45 percent.
On top of that comes an older category that fits copy-paste landing pages almost word for word: doorway pages. Google defines them as pages “created to rank for specific, similar search queries” that “lead users to intermediate pages that aren't as useful as the final destination,” such as city or region variants without content of their own.
Google's guidance on helpful content supplies the self-test. Two of its questions are enough: “Does the content provide substantial value when compared to other pages in search results?” And: “Is the content primarily made to attract visits from search engines?” If your 50 pages differ only by an industry word, you already know the answers.
Google doesn't count your pages. Google checks whether each one gives its own answer.
The right way: one content model instead of 50 documents
The way out is not a writing trick but a change of architecture: treat landing pages not as documents but as structured records. Instead of maintaining 50 pages in an editor, you define one landing page template once and, per use case, fill in only the fields that genuinely differ. Headless CMSs were built for exactly this pattern.
The template: build the structure once
In the CMS, you create a page type called “use case page” with fixed sections: value proposition, problem description, solution in context, proof, FAQ, CTA. The frontend renders every page from this one template. If you change the design or the section order, you change it once and not fifty times; that is the difference between scaling and copying.
The template includes the route structure: /integrations/hubspot, /industries/tax-accountants, /use-cases/vacation-requests. Readable paths like these make the axes legible for users and search engines, and they give you one overview page per axis that links internally to every individual page.
Think the template through to the metadata: page title and description are built from the fields (“X for tax accountants: meet deadlines with 300 clients”), and the FAQ delivers the structured data along the way. That too is an advantage of the model: SEO craft is defined once instead of remembered fifty times.
We build client projects and our own website on exactly this pattern: Sanity holds the structured content, Next.js renders the pages from it.
The fields: what genuinely differs per page
The template prevents chaos; the fields prevent thin content. For every piece of content, ask one test question: could it appear word for word on another page? If yes, it belongs in the template; if no, it is a field. Here is what that looks like for “X for tax accountants”:
| Field | Why it has to be real on every page | Example “X for tax accountants” |
|---|---|---|
| Value proposition | names the problem of this case, not the product | “Meet deadlines, even with 300 clients” |
| Screenshot or workflow | shows exactly this case inside the product | the DATEV export in the image, not a generic dashboard |
| Proof | a quote or number from exactly this segment | a tax firm named by name instead of “over 1,000 customers” |
| FAQ | answers the objections of this case | “Is the export GoBD-compliant?” |
The substance test before publishing
My rule of thumb from projects, explicitly a judgment call and not a study: every page needs at least three elements that could not appear on any other page. If you cannot pull together a screenshot, a proof point, or a dedicated FAQ for an industry, the page is not ready. What is missing then is not text but substance, and no tool writes substance into existence.
The end of every landing page, by contrast, is shared: the transition into trial or demo. You build that path cleanly once and attach every use case page to it; how, is covered in our article on the free-trial conversion path.
Programmatic SEO: when it works, when it's spam
A definition first: programmatic SEO means generating landing pages from a database instead of writing them one by one. One template, a thousand records, a thousand pages. Technically, it is the logical continuation of the content model; editorially, it stands or falls with one question: where does the data come from?
It works when a real record sits behind every page. The textbook example is Zapier: one page per app pair, filled with the actual triggers and actions of both tools. On each of these pages, the searcher gets an answer that exists nowhere else, even though no human wrote it individually.
It is spam when the “database” is just a word list: 500 cities, 200 industries, the same text with a rotating variable. That is precisely the definition of scaled content abuse from the previous section, only with a script instead of copy-paste. The generation method changes nothing about Google's verdict.
In between lies an honest middle path that I often recommend: the skeleton from data, the substance by hand. The integration page pulls name, logo, and field mappings from your integration catalog; the usage example, setup guide, and FAQ are written by a person who has actually operated the integration. That way you scale the structure without watering down the answer.
My assessment for B2B SaaS in the DACH region: most companies simply lack the data for 500 real answers. In that case, 10 to 30 curated pages beat any generated mass. Programmatic SEO is a tool for data owners, not for text multipliers; check first which group you belong to.
Prioritization: which five pages to start with
First, a word against the build-it-all reflex: don't build the full matrix of integrations times industries, build the five pages with proven demand. The proof is usually already in the building, in four places:
- Search Console: queries for which your website already collects impressions without having a matching page. That is unserved demand with evidence attached.
- Sales calls: the integration that comes up in every second demo. What recurs in conversation is also being searched for.
- Support and onboarding: use cases your existing customers already live. That is where your screenshots, numbers, and quotes already sit, meaning the substance for each page.
- A SERP spot check: google the candidates yourself and look at what ranks. Thin directories and forums on page one are an invitation; five competitors with strong dedicated pages are a warning sign.
Then the procedure: build five pages with full substance, measure for 90 days, then decide. Measure three things per page: impressions and clicks in Search Console, plus trial or demo clicks as an event. Only when the first wave shows demand does the idea earn pages six to twenty.
Also plan the maintenance from the start: every landing page shows screenshots, prices, or integration details that go stale. A fixed annual review per wave belongs in the calendar before the first page goes live. Unmaintained pages are the second face of content chaos, just time-shifted.
That turns the gut feeling of “we need 50 landing pages” into a program with a burden of proof: every wave a bet, every measurement a decision.
Next steps
If you want to create landing pages, don't start in the text editor, start with the model: list your three axes (integrations, industries, use cases), collect demand evidence from Search Console and sales, and define the fields of your template. Only then does the writing begin, and it begins with five pages instead of fifty.
If you'd like support along the way: as a website agency for B2B and SaaS companies, I build landing page systems with Next.js, Sanity, and Vercel, from content model to measurement. Book a free intro call: we'll go through your page list together and pick the first five.
