Eine Seite je Integration: warum dein SaaS viele Landingpages braucht
«Wir brauchen eine Landingpage je Integration und Branche, aber ich will keine 50 Copy-Paste-Seiten pflegen.» Dieser Satz fasst einen echten Zielkonflikt zusammen: Spezifische Seiten gewinnen spezifische Suchanfragen, aber naive Skalierung produziert Content-Chaos und Google-Ärger. Dieser Artikel gehört zu unserer Serie über die Anatomie einer B2B-SaaS-Website und löst den Konflikt auf: mit einem Content-Modell statt einem Kopierbefehl.
Warum überhaupt viele Seiten? Weil niemand nach deiner Produktkategorie sucht, sondern nach seinem Fall. Google bezifferte bereits 2017, dass 15 Prozent aller täglichen Suchanfragen noch nie zuvor gestellt wurden. Die Nachfrage ist also breiter und spezifischer, als eine Startseite je abbilden kann. Drei Achsen liefern die Fälle:
- Integrationen: Suchanfragen wie «X + HubSpot» stellen Leute, die beide Werkzeuge schon nutzen oder gerade auswählen. Eine Integrations-Landingpage muss nur eine Frage beantworten: Was geht damit konkret, und wie richte ich es ein?
- Branchen und Personas: «Zeiterfassung für Steuerberater» ist eine andere Suche als «Zeiterfassung», mit anderem Wettbewerb und anderen Einwänden. Die Branchenseite spricht Mandate, Fristen und DATEV an, nicht abstrakte Features.
- Use Cases: «Urlaubsanträge digital genehmigen» sucht jemand mit einem Prozessproblem, der deine Produktkategorie womöglich gar nicht kennt. Die Use-Case-Seite holt ihn beim Problem ab und führt zum Produkt.
Dazu kommt ein Wettbewerbsargument: Auf den Kopfbegriff «Zeiterfassung» bieten Marktführer mit sechsstelligen Content-Budgets. Auf «Zeiterfassung für Steuerberater» konkurrierst du oft nur mit dünnen Verzeichnisseiten. Die spezifische Seite ist also nicht nur die relevantere Antwort, sondern häufig auch die schneller erreichbare Position.
Deine Startseite kann nicht dreißig solcher Fragen gleichzeitig beantworten; eine Seite je Fall kann es. Genau hier beginnt aber das Risiko, um das es im nächsten Abschnitt geht: Aus «eine Seite je Fall» wird schnell «fünfzigmal dieselbe Seite».
Der falsche Weg: 50 Kopien und ein Suchen-und-Ersetzen
Der naheliegende Weg sieht so aus: Du duplizierst die beste Seite, tauschst «Steuerberater» gegen «Architekten» und bist in einer Woche bei 50 Landingpages. Jede Seite hat denselben Aufbau, dieselben Argumente, dasselbe Zitat. Nur ein Wort rotiert.
Aus Nutzersicht ist das Ergebnis Thin Content: Die Seite verspricht eine Antwort für Architekten und liefert die Generik der Startseite. Wer über eine spezifische Suche kommt und Austauschbares findet, ist mit einem Klick wieder weg. Das Ranking-Risiko ist also nur die halbe Rechnung; die andere Hälfte ist verschenkte Conversion.
Google führt für dieses Muster seit März 2024 eine eigene Spam-Kategorie: skalierten Content-Missbrauch (scaled content abuse). Gemeint sind viele Seiten, die primär für Rankings statt für Menschen erstellt werden. Ausdrücklich egal ist dabei, ob die Kopien von Hand, per KI oder gemischt entstehen.
Die Ansage war keine Drohkulisse: Google erwartete vom März-Update 2024 und den vorangegangenen Maßnahmen zusammen 40 Prozent weniger minderwertigen, unoriginellen Content in den Suchergebnissen. Nach Abschluss des Rollouts im April 2024 meldete Google sogar 45 Prozent.
Dazu kommt eine ältere Kategorie, die auf Kopier-Landingpages fast wörtlich passt: Brückenseiten (doorway pages). Das sind viele beinahe identische Seiten für ähnliche Suchanfragen, die Besucher nur zur eigentlichen Zielseite durchreichen, etwa Stadt- oder Regionenvarianten ohne eigenen Inhalt.
Den Selbsttest liefert Googles Leitfaden für hilfreiche Inhalte gleich mit. Zwei seiner Prüffragen genügen: Bietet die Seite substanziellen Mehrwert im Vergleich zu anderen Seiten in den Suchergebnissen? Und ist der Inhalt in erster Linie dafür gemacht, Besucher aus Suchmaschinen anzuziehen? Wenn sich deine 50 Seiten nur durch ein Branchenwort unterscheiden, kennst du die Antworten.
Google zählt nicht deine Seiten. Google prüft, ob jede einzelne eine eigene Antwort gibt.
Der richtige Weg: ein Content-Modell statt 50 Dokumente
Der Ausweg ist kein Schreibtrick, sondern ein Architekturwechsel: Behandle Landingpages nicht als Dokumente, sondern als strukturierte Datensätze. Statt 50 Seiten in einem Editor zu pflegen, definierst du einmal eine Landingpage-Vorlage und füllst je Use Case nur noch die Felder, die sich wirklich unterscheiden. Genau für dieses Muster wurden Headless-CMS gebaut.
Die Vorlage: Struktur einmal bauen
Im CMS legst du einen Seitentyp «Use-Case-Seite» an, mit festen Abschnitten: Nutzenversprechen, Problembeschreibung, Lösung im Kontext, Beleg, FAQ, CTA. Das Frontend rendert alle Seiten aus dieser einen Vorlage. Änderst du Design oder Abschnittsfolge, änderst du sie einmal und nicht fünfzigmal; das ist der Unterschied zwischen Skalieren und Kopieren.
Zur Vorlage gehört auch die Routenstruktur: /integrationen/hubspot, /branchen/steuerberater, /use-cases/urlaubsantraege. Solche sprechenden Pfade machen die Achsen für Nutzer und Suchmaschinen lesbar und geben dir je Achse eine Übersichtsseite, die intern auf alle Einzelseiten verlinkt.
Denk die Vorlage bis in die Metadaten durch: Seitentitel und Beschreibung entstehen aus den Feldern («X für Steuerberater: Fristen halten mit 300 Mandaten»), die FAQ liefert die strukturierten Daten gleich mit. Auch das ist ein Vorteil des Modells: SEO-Handwerk wird einmal definiert statt fünfzigmal erinnert.
Wie ein solches Content-Modell praktisch aussieht, haben wir am Beispiel unseres eigenen Werkzeugs beschrieben: Was ist Sanity? Wir bauen Kundenprojekte und die eigene Website nach diesem Muster: Sanity hält die strukturierten Inhalte, Next.js rendert daraus die Seiten.
Die Felder: was sich je Seite wirklich unterscheidet
Die Vorlage verhindert Chaos, die Felder verhindern Thin Content. Für jeden Inhalt gilt die Prüffrage: Könnte er wortgleich auf einer anderen Seite stehen? Wenn ja, gehört er in die Vorlage; wenn nein, ist er ein Feld. So sieht das am Beispiel «X für Steuerberater» aus:
| Feld | Warum es je Seite echt sein muss | Beispiel «X für Steuerberater» |
|---|---|---|
| Nutzenversprechen | benennt das Problem des Falls, nicht das Produkt | «Fristen halten, auch mit 300 Mandaten» |
| Screenshot oder Workflow | zeigt genau diesen Fall im Produkt | der DATEV-Export im Bild, kein generisches Dashboard |
| Beleg | Zitat oder Zahl aus genau diesem Segment | eine namentlich genannte Kanzlei statt «über 1.000 Kunden» |
| FAQ | beantwortet die Einwände dieses Falls | «Ist der Export GoBD-konform?» |
Der Substanz-Test vor dem Veröffentlichen
Meine Faustregel aus Projekten, ausdrücklich eine Einschätzung und keine Studie: Jede Seite braucht mindestens drei Elemente, die auf keiner anderen Seite stehen könnten. Bekommst du für eine Branche weder Screenshot noch Beleg noch eigene FAQ zusammen, ist die Seite nicht reif. Dann fehlt nicht Text, sondern Substanz, und die schreibt dir kein Werkzeug herbei.
Das Ende jeder Landingpage ist dagegen gemeinsam: der Übergang in Trial oder Demo. Diese Strecke baust du einmal sauber und hängst alle Use-Case-Seiten daran an; wie, steht in unserem Artikel über die Trial-Conversion-Strecke.
Programmatic SEO: wann es trägt, wann es Spam ist
Zum Begriff: Programmatic SEO heißt, Landingpages aus einer Datenbank zu generieren, statt sie einzeln zu schreiben. Eine Vorlage, tausend Datensätze, tausend Seiten. Technisch ist das die konsequente Fortsetzung des Content-Modells; inhaltlich steht und fällt es mit einer Frage: Woher kommen die Daten?
Es trägt, wenn hinter jeder Seite ein echter Datensatz steht. Das Lehrbuchbeispiel ist Zapier: eine Seite je App-Paar, gefüllt mit den tatsächlichen Triggern und Aktionen beider Werkzeuge. Der Suchende bekommt auf jeder dieser Seiten eine Antwort, die so nirgendwo sonst steht, obwohl kein Mensch sie einzeln geschrieben hat.
Es ist Spam, wenn die «Datenbank» nur eine Wortliste ist: 500 Städte, 200 Branchen, derselbe Text mit rotierender Variable. Das ist exakt die Definition von skaliertem Content-Missbrauch aus dem vorigen Abschnitt, nur mit Skript statt Copy-Paste. Die Erzeugungsmethode ändert an Googles Bewertung nichts.
Dazwischen liegt ein ehrlicher Mittelweg, den ich häufig empfehle: das Gerüst aus Daten, die Substanz von Hand. Die Integrationsseite zieht Name, Logo und Feldzuordnungen aus deinem Integrationskatalog; Anwendungsbeispiel, Einrichtungsanleitung und FAQ schreibt ein Mensch, der die Integration wirklich bedient hat. So skalierst du die Struktur, ohne die Antwort zu verwässern.
Meine Einschätzung für B2B-SaaS im DACH-Raum: Den meisten fehlt schlicht die Datenbasis für 500 echte Antworten. Dann schlagen 10 bis 30 kuratierte Seiten jede generierte Masse. Programmatic SEO ist ein Werkzeug für Datenbesitzer, nicht für Textvervielfältiger; prüfe zuerst, zu welcher Gruppe du gehörst.
Priorisierung: mit welchen fünf Seiten du anfängst
Vorab ein Rat gegen den Vollausbau-Reflex: Baue nicht die komplette Matrix aus Integrationen mal Branchen, sondern die fünf Seiten mit belegter Nachfrage. Die Belege hast du meist schon im Haus, an vier Stellen:
- Search Console: Suchanfragen, für die deine Website schon Impressionen sammelt, ohne eine passende Seite zu haben. Das ist unbediente Nachfrage mit Beweis.
- Vertriebsgespräche: die Integration, nach der in jeder zweiten Demo gefragt wird. Was im Gespräch wiederkehrt, wird auch gesucht.
- Support und Onboarding: Use Cases, die Bestandskunden bereits leben. Dort liegen deine Screenshots, Zahlen und Zitate schon bereit, also die Substanz je Seite.
- SERP-Stichprobe: Google die Kandidaten selbst und sieh nach, was rankt. Dünne Verzeichnisse und Foren auf Seite eins sind eine Einladung; fünf Konkurrenten mit starken Spezialseiten sind ein Warnsignal.
Dann das Verfahren: fünf Seiten mit voller Substanz bauen, 90 Tage messen, danach entscheiden. Miss je Seite drei Dinge: Impressionen und Klicks in der Search Console sowie Trial- oder Demo-Klicks als Event. Erst wenn die erste Welle Nachfrage zeigt, verdient die Idee die Seiten sechs bis zwanzig.
Plane außerdem die Pflege gleich mit ein: Jede Landingpage zeigt Screenshots, Preise oder Integrationsdetails, die veralten. Ein festes Jahres-Review je Welle gehört deshalb in den Kalender, bevor die erste Seite live geht. Ungepflegte Seiten sind das zweite Gesicht von Content-Chaos, nur zeitversetzt.
So wird aus dem Bauchgefühl «wir brauchen 50 Landingpages» ein Programm mit Belegpflicht: jede Welle eine Wette, jede Messung eine Entscheidung.
Nächste Schritte
Wenn du Landingpages erstellen willst, starte nicht im Texteditor, sondern beim Modell: Liste deine drei Achsen auf (Integrationen, Branchen, Use Cases), sammle Nachfrage-Belege aus Search Console und Vertrieb und definiere die Felder deiner Vorlage. Erst dann wird geschrieben, und zwar für fünf Seiten statt für fünfzig.
Wenn du dir dabei Unterstützung wünschst: Als Website-Agentur für B2B- und SaaS-Unternehmen baue ich Landingpage-Systeme mit Next.js, Sanity und Vercel, vom Content-Modell bis zur Messung. Buch dir ein kostenloses Erstgespräch: Wir gehen deine Seiten-Liste gemeinsam durch und legen die ersten fünf fest.
