Drei Systeme, drei Logins, ein zerrissener Auftritt
Die Ausgangslage kenne ich aus fast jedem SaaS-Projekt: Die Marketing-Website lebt in Webflow oder einem anderen Baukasten, die Entwickler-Doku in GitBook oder ReadMe, der Blog in einem WordPress, das irgendwann einmal jemand aufgesetzt hat. Drei Logins, drei Designs, drei Rechnungen. Und niemand fühlt sich für das Ganze zuständig.
Wie es dazu kommt, ist nachvollziehbar: Jedes System war im Moment seiner Einführung die schnellste Lösung. Das Marketing wollte ohne Entwickler Seiten bauen, die Entwickler wollten Markdown schreiben, und der Blog lief eben dort, wo Blogs traditionell laufen. WordPress betreibt ausweislich W3Techs auch im September 2026 noch 40,2 Prozent aller Websites.
Die Rechnungen selbst sind dabei nicht das Problem. GitBook Premium kostet 65 US-Dollar pro Site und Monat plus 12 US-Dollar je zusätzlichem Bearbeiter, ReadMe Pro 250 US-Dollar monatlich; beide Preise gelten bei jährlicher Abrechnung (Stand September 2026). Das trägt jedes finanzierte SaaS. Der eigentliche Preis steht auf keiner Rechnung.
Er liegt im zerrissenen Auftritt: Die Doku auf docs.deinprodukt.de verlinkt nie in den Blog, der Blog nie in die Doku, und die Website kennt beide nicht. Der interne Link-Graph, der Suchmaschinen deine Themenautorität zeigt, existiert schlicht nicht. Und ein Interessent, der von der polierten Startseite in eine Doku mit veraltetem Logo wechselt, spürt den Bruch sofort.
Dieser Artikel gehört zu unserer Serie über die Anatomie einer B2B-SaaS-Website. Heute geht es um die Schicht darunter: die Content-Architektur, die entscheidet, ob dein Auftritt aus einem Guss ist oder aus drei.
Was zusammengehört: ein Content-Modell statt Seitenkopien
Zum Kern des Problems: Die drei Systeme speichern keine Inhalte, sie speichern Seiten. Ein Beispiel macht den Unterschied greifbar. Du launchst ein neues Feature, sagen wir einen Slack-Connector. Dafür entstehen ein Abschnitt auf der Integrationsseite, ein Doku-Kapitel, ein Blogartikel zur Ankündigung und ein Changelog-Eintrag: viermal dieselbe Information, von Hand in drei Systeme kopiert.
Ändert sich später der Name des Features oder ein Preis, beginnt die Suche: Welche der vier Stellen haben wir vergessen? Genau solche vergessenen Kopien erzeugen die veralteten Preise auf Landingpages und die toten Links in der Doku, über die sich deine Kunden beschweren.
Ein Content-Modell dreht das um. Du speicherst Inhalte als strukturierte Dokumente mit Feldern und Referenzen, nicht als fertige Seiten. Der Slack-Connector ist dann ein Dokument: Name, Beschreibung, Logo, Kategorie, Referenz auf sein Doku-Kapitel. Website, Doku und Blog sind nur noch drei Ausspielungen desselben Bestands.
Was das konkret bringt:
- Ein Link-Graph: Doku-Kapitel, Blogartikel und Landingpages referenzieren einander im Modell; das Frontend rendert daraus interne Links auf einer einzigen Domain.
- Ein Design-System: Alle drei Ausspielungen nutzen dieselben Komponenten; ein Redesign ist ein Frontend-Projekt, kein Dreifach-Projekt.
- Eine Preisquelle: Preise leben als strukturierte Daten und erscheinen auf der Pricing-Seite, in Vergleichstabellen und im Blog immer im selben Stand.
- Skalierende Seitentypen: 30 Integrations-Landingpages sind 30 Dokumente plus eine Vorlage, keine 30 von Hand gebauten Seiten.
Die technische Grundlage dafür ist ein Headless-CMS mit referenzfähigem Content-Modell. Wie so ein Content Lake grundsätzlich funktioniert, habe ich in Was ist Sanity? ausführlich beschrieben.
Was Entwickler-Doku wirklich braucht
Vorab eine Warnung: Die Doku ist der anspruchsvollste der drei Content-Typen. Website und Blog in ein CMS zu legen, ist Routine. Developer Docs stellen drei Anforderungen, an denen naive CMS-Setups regelmäßig scheitern. Wer sie kennt, kann sie einplanen.
Dazu kommt ihr Gewicht im Vertrieb: Entwickler prüfen die Doku, bevor sie eine Demo buchen. Öffentliche, indexierbare Doku-Seiten ranken außerdem für Long-Tail-Suchanfragen, die deine Marketing-Seiten nie abdecken. Jede dokumentierte Fehlermeldung, jeder Endpunkt ist eine potenzielle Einstiegsseite.
Versionierung: v2 dokumentieren, während v3 lebt
Sobald deine API in Version 3 läuft, aber zahlende Kunden noch gegen Version 2 entwickeln, brauchst du beide Doku-Stände parallel. Im Content-Modell löst du das mit einem Versions-Feld pro Kapitel und einem Versionsumschalter im Frontend. Wichtig ist die Abgrenzung: Versioniere nur die API-nahen Kapitel, nicht die halbe Doku. Jede versionierte Seite ist eine Seite, die du doppelt pflegst.
Code-Blöcke: mehr als graue Kästen
Entwickler beurteilen deine Doku nach den Code-Beispielen. Das heißt konkret: Syntax-Highlighting, Kopier-Button und dasselbe Beispiel in mehreren Sprachen als Tabs, etwa cURL, TypeScript und Python. In Sanitys Portable Text sind Code-Blöcke eigene strukturierte Blöcke mit Sprach-Attribut; wie sie aussehen, entscheidet dein Frontend.
Eine Ausnahme gehört von Anfang an definiert: Die API-Referenz selbst hat im CMS nichts verloren. Sie wird aus deiner OpenAPI-Spezifikation generiert, sonst lügt sie irgendwann. Von Hand gepflegte Endpunkt-Listen veralten mit dem ersten Release, das jemand unter Termindruck ausliefert.
Suche: ohne sie stirbt die Doku
Niemand liest Doku linear; wer den Fehlercode 429 sucht, will in Sekunden beim richtigen Kapitel sein. Der Standard dafür ist Algolia DocSearch: für technische Dokumentation kostenlos, im Einsatz bei über 9.000 Projekten von React bis Laravel. Liegt deine Doku strukturiert im CMS, hast du eine Alternative: eine eigene Suche über die Abfrage-API, die Überschriften und Code getrennt gewichtet.
Docs-as-Code oder CMS: die ehrliche Abwägung
Bevor du alles ins CMS ziehst, gehört ein Gegenentwurf ernsthaft geprüft: docs-as-code. Die Idee, geprägt von der Write-the-Docs-Community: Du behandelst Dokumentation wie Quellcode. Sie liegt als Markdown neben dem Code im Git-Repository, Änderungen laufen über Pull Requests, die CI baut daraus eine statische Site, etwa mit Docusaurus.
Ich sage es offen: Für reine Entwickler-Teams ist das oft die bessere Wahl. Die Doku ändert sich im selben Pull Request wie der Code, Reviews sind eingebaut, die Werkzeuge kosten nichts. Wer diesen Workflow lebt, sollte ihn nicht für ein Architektur-Ideal aufgeben.
Die Grenzen zeigen sich, sobald Nicht-Entwickler mitschreiben sollen. Support-Mitarbeiter, die erst Git und Pull Requests lernen müssen, schreiben keine Doku mehr. Es gibt keine Vorschau für Redakteure, keine Referenzen auf Preise oder Features, und der Blog im Marketing-System bleibt abgeschnitten. Die Übersicht:
| Kriterium | Docs-as-Code | Headless-CMS |
|---|---|---|
| Autoren | Entwickler mit Git | auch Support, Produkt, Marketing |
| Review | Pull Request | Workflow mit Vorschau im Studio |
| Versionierung | Git-Branches, eingebaut | Versions-Feld im Content-Modell |
| Wiederverwendung | Copy-Paste zwischen Dateien | Referenzen auf Features und Preise |
| Lizenzkosten | 0 Euro | Sanity: kostenlos bis 10.000 Dokumente |
| Link-Graph zur Website | getrennte Systeme | eine Domain, ein Graph |
Mein Rat ist deshalb häufig ein Hybrid: Die API-Referenz entsteht generiert aus der OpenAPI-Spezifikation, Guides, Tutorials und Konzept-Artikel leben im CMS, und beides rendert dasselbe Next.js-Frontend unter einer Domain. Die Grenze verläuft nicht zwischen den Werkzeugen, sondern zwischen den Autoren: Wer schreibt, bestimmt das System.
Wie wir es selbst machen: ein Content Lake für alles
Zum Beweis, dass ich hier nicht nur Theorie verkaufe: happycoding.agency läuft vollständig auf Sanity und Next.js, gehostet auf Vercel. Kein Baukasten, kein WordPress, kein separates Doku-Tool. Jede Landingpage, jeder Blogartikel, jede FAQ liegt als strukturiertes Dokument im selben Content Lake.
Konkret heißt das: Ein Blogartikel ist bei uns kein HTML-Klumpen, sondern ein Dokument mit getrennten Feldern für Fließtext, Kernaussagen, FAQ und Quellen. Das Frontend rendert daraus die Seite und zusätzlich strukturierte Daten als JSON-LD, etwa FAQPage und Article für Suchmaschinen. Kategorien sind Referenzen, aus denen Themenseiten automatisch entstehen.
Im Alltag ändert das die Arbeitsteilung: Ich schreibe Inhalte im Studio, ohne einen Entwickler zu brauchen; Layout-Änderungen sind Code und laufen über Git. Beide Seiten arbeiten in ihrem Werkzeug, keine blockiert die andere. Genau an dieser Trennung von Inhalt und Darstellung scheitern Baukästen und WordPress-Themes.
Denselben Mechanismus empfehle ich für SaaS-Inhalte, die aktuell bleiben müssen. Die Unterauftragsverarbeiter-Liste im Trust Center ist das Paradebeispiel: einmal als strukturierter Inhalt gepflegt, erscheint sie auf der Trust-Seite und im AVV-Anhang immer im selben Stand, statt in drei PDFs zu veralten.
Zu den Kosten: Der Sanity-Free-Plan trägt 20 Nutzer, 10.000 Dokumente und 250.000 API-Requests pro Monat; der Growth-Plan kostet 15 US-Dollar pro Nutzer und Monat (Stand September 2026). Unsere Site mit weit über 100 Blogartikeln läuft deutlich unterhalb dieser Grenzen. Meine Einschätzung aus den eigenen Projekten: Das Budget fließt in den Frontend-Bau, nicht in Lizenzen.
Wann getrennte Systeme trotzdem richtig sind
Zur ehrlichen Beratung gehört die Gegenliste: Es gibt Konstellationen, in denen ich dir von der Ein-CMS-Architektur abrate.
- Deine API-Referenz ist dein Produkt: Wenn die Entwickler-Doku dein wichtigster Vertriebskanal ist und ReadMes interaktiver API-Explorer genau dein Werkzeug, dann kauf das Spezialwerkzeug.
- Ein eingespielter docs-as-code-Prozess: Ein Team, das seit Jahren Doku per Pull Request mit CI-Checks pflegt, verliert durch eine Migration einen funktionierenden Prozess und gewinnt nur Architektur-Ästhetik.
- Open-Source-Projekte: Community-Beiträge kommen als Pull Requests; Docusaurus plus DocSearch ist hier der etablierte, kostenlose Standard.
- Kein Frontend-Besitzer: Ohne jemanden, der ein Next.js-Frontend baut und dauerhaft pflegt, ist Baukasten plus GitBook die ehrlichere Wahl als ein halbfertiger Eigenbau.
Der Merksatz dazu: Ein Content-Modell, das niemand pflegt, ist schlechter als drei Systeme, die laufen. Die Architektur muss zu deinem Team passen, nicht umgekehrt.
Nächste Schritte
Wenn dich das Drei-Systeme-Problem gerade selbst nervt, fang mit einer Inventur an: Notiere eine Woche lang jede Stelle, an der dieselbe Information doppelt gepflegt wird. Diese Liste ist dein Business Case, präziser als jede Grundsatzdiskussion über CMS-Anbieter.
Der zweite Schritt ist eine Autoren-Frage: Wer soll in zwölf Monaten Doku, Blog und Website pflegen? Schreiben ausschließlich Entwickler, spricht wenig gegen docs-as-code. Sollen Support, Produkt und Marketing mitschreiben, führt an einem Content-Modell kaum ein Weg vorbei.
Als Agentur für B2B-Websites bauen wir genau solche Architekturen: ein Content-Modell in Sanity, ein Next.js-Frontend für Website, Doku und Blog, Migration samt Weiterleitungen. Wenn du wissen willst, ob sich das für dein SaaS rechnet, buch dir ein kostenloses Erstgespräch: 30 Minuten, konkrete Einschätzung, keine Folien.
