Lerne, wie du eine SaaS-Website planst, baust und launcht, die Marketing-Seiten und Dokumentation vereint: klare Struktur, SEO, Performance und einfache Aktualisierungen.
Eine SaaS-Website, die Marketing-Seiten und Dokumentation kombiniert, hat zwei Aufgaben: neue Besucher überzeugen und bestehenden Nutzern zum Erfolg verhelfen. Wenn du sie als „eine Seite mit nur einem Zweck“ behandelst, optimierst du meist nur eine Seite — die andere wird stillschweigend schlechter funktionieren.
Marketing-Seiten sollten einen Besucher zu einem klaren nächsten Schritt führen: Trial starten, Demo buchen oder Preise ansehen. Die Dokumentation sollte nach der Anmeldung Reibung verringern: Fragen schnell beantworten, beim Setup leiten und Integrationsarbeiten freimachen.
Schreibe einen Ein-Satz-Ziel, das du in jedem Planungstreffen wiederholen kannst, zum Beispiel:
„Qualified Prospects konvertieren und gleichzeitig Kunden ermöglichen, Support selbst zu erledigen.“
Die meisten SaaS-Seiten bedienen mehrere Zielgruppen mit unterschiedlicher Absicht:
Wenn du das Publikum für eine Seite nicht benennen kannst, wird der Text vage.
Ergebnisse halten dein Team auf Verhalten fokussiert, nicht auf Seitenanzahlen:
Wähle eine kleine Menge Metriken, die du monatlich prüfen willst: Marketing-Konversionsrate, Aktivierungsrate, Nutzung der Docs-Suche, häufige fehlgeschlagene Suchanfragen und Support-Ticket-Volumen nach Thema.
Entscheide, wer schreibt, reviewt und veröffentlicht Marketing- und Docs-Inhalte. Klare Ownership verhindert veraltete Docs und inkonsistente Produktkommunikation — und macht Releases reibungsloser, wenn mehrere Teams gleichzeitig Änderungen brauchen.
Informationsarchitektur bestimmt, wie beide Nutzerreisen offensichtlich wirken — ohne die Header-Navigation in eine Sammelstelle zu verwandeln.
Die meisten Teams kommen mit einer Handvoll Top-Level-Bereiche für „Marketing + Docs“ aus:
Halte die globale Navigation auf das fokussiert, was ein Erstbesucher erwartet. Alles Andere (Security, Status, Changelog, Partner, Rechtliches) kann im Footer oder im jeweiligen Bereich liegen.
Für die meisten SaaS-Produkte ist Hosting der Dokumentation unter /docs die einfachste Wahl.
Docs unter /docs (gleiche Domain)
Docs auf einer Subdomain (z. B. docs.deinedomain)
Wenn du bereits weißt, dass deine Docs sehr umfangreich sind und von einem separaten Team/Tooling gepflegt werden, kann eine Subdomain sinnvoll sein. Andernfalls ist /docs meist die stabile Default-Wahl.
Denk in häufigen Pfaden und stell sicher, dass URLs und Navigation sie unterstützen.
Beispiel Marketing-Reise:
Beispiel Support-Reise:
Navigation hat Rollen:
URLs sind Versprechen. Änderungen später brechen Lesezeichen, eingehende Links und Vertrauen.
Eine praktische Herangehensweise:
Wenn du umstrukturieren musst, plane Redirects von Anfang an. Saubere Architektur plus stabile URLs macht die SaaS-Website einfacher zu navigieren, zu warten und zu erweitern.
Wenn du eine SaaS-Seite baust, die verkaufen und Nutzer unterstützen soll, ist der schnellste Weg, ein kleines Set an Seiten zu veröffentlichen, die drei Fragen beantworten: Was ist das? Kann ich dem vertrauen? Was mache ich als Nächstes?
Beginne mit den Essentials, die Besucher erwarten und auf die das Team häufig verweist:
Halte jede Seite auf eine einzelne Entscheidung fokussiert. Du kannst später erweitern.
Vor dem Trial suchen Nutzer nach Nachweisen. Füge früh leichte Vertrauenssignale hinzu:
Sobald die Kernseiten stehen, ergänze Seiten, die deiner Sales-Strategie entsprechen:
Diese Seiten sollten Reibung entfernen: klare Formfelder, Erwartungen („wir antworten innerhalb 1 Werktag“) und nächste Schritte.
Deine Dokumentation sollte neuen Nutzern helfen, schnell erfolgreich zu werden:
Füge diese hinzu, wenn das Grundgerüst stabil ist: changelog (/changelog), optional roadmap, about und careers. Sie helfen bei Transparenz, Recruiting und Vertrauen — ohne den Launch zu blockieren.
Dein Tech-Stack sollte dazu passen, wie oft Inhalte wechseln, wer sie veröffentlicht und ob die Seite sich wie eine App verhalten muss. Für die meisten SaaS-Teams ist das Sweetspot eine Marketing-Seite + Docs, die schnell, einfach zu aktualisieren ist und nicht für jede Textänderung Entwickler benötigt.
Ein SSG (z. B. Next.js static export, Astro, Docusaurus, Hugo) baut Seiten im Voraus. Das passt gut, wenn Marketingseiten und Docs vorhersehbar sind.
Verwende statische Ansätze, wenn du willst:
Es ist auch ein sauberer Weg, Docs in Markdown zu halten und dennoch Suche und versionierte Inhalte zu unterstützen.
Ein server-gerenderter Aufbau (oder eine vollständige App) lohnt sich, wenn die Website sich wie eine Produkt-Erfahrung verhalten muss.
Wähle das, wenn du brauchst:
Du kannst trotzdem die meisten Marketing-Seiten statisch generieren und nur die wirklich dynamischen Teile serverseitig rendern.
Ein CMS-getriebener Ansatz funktioniert gut, wenn Nicht-Techniker häufig veröffentlichen und strukturierte Inhalte (Preis-Tiers, Kundenstories, Vergleichstabellen) konsistent benötigen.
Markdown/MDX ist ideal für Docs: schnell zu schreiben, einfach in Git zu reviewen und gut für Versionierung. CMS-Felder sind nützlich für strukturierte Marketing-Inhalte, wo Konsistenz wichtig ist.
Richte drei Umgebungen von Anfang an ein:
Dieser Workflow macht Publishings sicher, auch wenn Marketing und Docs wöchentlich Änderungen veröffentlichen.
Wenn du noch schneller starten willst, können Plattformen wie Koder.ai helfen, die initiale Marketing- + Docs-Erfahrung per einfachem Chat zu prototypen — und dann den Source-Code für eine traditionelle Pipeline zu exportieren, sobald Struktur, Navigation und Kernseiten validiert sind.
Gutes Design für eine SaaS-Site hat eine gespaltene Persönlichkeit: Marketing-Seiten überzeugen und leiten zum nächsten Schritt, Docs reduzieren Reibung und helfen Nutzern, schnell Erfolg zu haben. Die Kunst ist, beides wie ein Produkt wirken zu lassen.
Definiere bevor du Seiten baust ein kleines Designsystem: Typografieskala, Farbpalette, Abstandsregeln und ein paar Kernkomponenten (Buttons, Alerts, Cards, Tabs). Das verhindert, dass Marketing-Seiten „designed“ wirken, während Docs „default“ bleiben.
Ein praktischer Ansatz: 2–3 Schriftgrößen für Body + Headings, eine primäre Markenfarbe und eine neutrale Skala für Ränder/Hintergründe. Standardisiere Abstände (z. B. 8px-Schritte), damit Layouts auf Landing Pages und in Docs konsistent sind.
Erstelle wiederverwendbare Seitenabschnitte, die wie Bausteine zusammengesetzt werden können:
Wenn diese Abschnitte Spacing, Typografie und Button-Stile teilen, wirkt die Site kohärent, während Inhalte wachsen.
Docs-UX ist größtenteils Lesbarkeit. Nutze klare Überschriftenhierarchie, großzügige Zeilenhöhe und eine Content-Breite, die lange Sätze und breite Codeblöcke unterstützt. Erlaube Codeblöcken horizontales Scrollen statt unleserliches Wrappen. Halte Seiten scanbar mit kurzen Intros, „Before you start“-Hinweisen und Callouts für Warnungen.
Behandle Accessibility als Baseline:
Auf Mobilgeräten teste früh zwei Dinge: die Top-Navigation und die Docs-Sidebar. Wenn eine davon schwer zu öffnen/zu verstehen ist, springen Nutzer ab — besonders wenn sie schnell ein Problem lösen wollen.
Gute SaaS-Seiten beschreiben ein Produkt nicht nur — sie führen Leser von Neugier zu Vertrauen. Dieser Pfad entsteht durch klares Messaging, einfache Texte und absichtliche Calls-to-Action (CTAs), die zur Nutzerabsicht auf jeder Seite passen.
Bevor du schreibst, bestimme Erfolg pro Seite. Gib jeder wichtigen Seite einen primären CTA (Hauptaktion) und einen sekundären CTA (niedrigere Commitment-Stufe).
Beispiele:
Halte CTAs in Wortwahl und Platzierung konsistent, damit Besucher die Seite nicht auf jeder Seite neu erlernen müssen.
Beginne mit dem Outcome, das dem Kunden wichtig ist, und erkläre dann, wie du es lieferst. Ersetze vage Aussagen („dein Workflow optimieren") durch konkrete Ergebnisse („Onboarding-Zeit von Tagen auf Stunden reduzieren").
Vermeide Jargon wenn möglich. Wenn Fachbegriffe nötig sind, definiere sie einfach. Kurze Sätze gewinnen — besonders für Überschriften, Subheads und Button-Text.
Füge Proof nahe Entscheidungspunkten hinzu (Features, Pricing, Signup). Verwende Zahlen nur, wenn du sie verifizieren kannst, und zeige Kontext:
Balanceiere Metriken mit menschlichem Proof: Zitate, Mini-Case-Studies und reale Workflow-Beispiele.
Unklare Preisblöcke verhindern Signups. Liste Plan-Namen, Kern-Limits, Add-ons und was passiert, wenn ein Nutzer ein Limit überschreitet. Füge ein FAQ hinzu, das Einwände beantwortet (Security, Billing, Kündigung, Support).
Wenn du ein Feature beschreibst, verlinke direkt zur relevantesten Anleitung: „See how it works" → /docs/getting-started oder /docs/integrations/slack. Das stärkt Vertrauen und reduziert Pre-Sales-Fragen — und hält den Leser im Conversion-Pfad.
Gute Docs wirken „offensichtlich" nutzbar. Das Geheimnis ist eine vorhersehbare Struktur und Navigation, die auf jeder Seite zwei Fragen beantwortet: Wo bin ich? und Was sollte ich als Nächstes lesen?
Baue eine Docs-Sidebar mit wenigen Kategorien, beschriftet in klarer Sprache. Organisiere nach Aufgaben und Ergebnissen, nicht nach internen Teambezeichnungen.
Gängige Top-Level-Kategorien:
Halte Labels konsistent mit der Produktterminologie. Wenn die UI „Workspaces" sagt, nenne sie nicht in den Docs „Projects".
Auf längeren Seiten ein Inhaltsverzeichnis nahe dem Anfang einfügen, damit Leser direkt springen können. Füge Next/Previous-Links am Ende hinzu, um einen flüssigen Lesepfad zu fördern — besonders bei Setup- und Onboarding-Sequenzen.
Konsistenz ist ein Feature. Nutze eine einzige Guide-Vorlage wie:
Problem → Steps → Expected result → Troubleshooting
Dieses Muster hilft beim schnellen Scannen und erleichtert es dem Team, neue Artikel ohne Neuentwicklung der Struktur zu schreiben.
Füge auf jeder Seite leichte Feedback-Optionen ein: ein „War das hilfreich?"-Steuerelement und einen klaren Link zum Support (z. B. /contact oder /support). Feedback hält die Docs an echten Fragen ausgerichtet und gibt verärgerten Lesern eine schnelle Ausweichmöglichkeit, ohne lange nach Hilfe zu suchen.
Eine SaaS-Site ändert sich ständig: Preisänderungen, neue Features, Docs-Fixes und Produktankündigungen. Ziel ist, Updates für Menschen einfach zu machen und gleichzeitig die Site vorhersehbar zu halten — Navigation, Suche und SEO sollen stabil bleiben.
Behandle jeden Seitentyp als strukturierten Inhalt. Wenn du Markdown/MDX verwendest, definiere konsistente Frontmatter-Felder, damit Seiten gelistet, durchsucht und korrekt dargestellt werden können.
Gängige Felder:
title (was in der Seitenüberschrift steht)description (Meta + Karten)tags oder category (Gruppierung und Filterung)last_updated (Vertrauenssignal für Docs)sidebar_position (Docs-Reihenfolge)Konsistenz verhindert „mystery pages“, die nicht im Menü erscheinen oder in Listings falsch gerendert werden.
Eine leichte Pipeline reduziert Fehler:
Draft → Review → Publish
Drafts können in einem Branch (Git) oder in einem Headless-CMS erstellt werden. Reviews sollten Klarheit, Korrektheit und ob Links/CTAs noch auf die richtigen Ziele zeigen (z. B. /pricing oder /docs) prüfen.
Vermeide Freigaben anhand eingefügter Texte oder Screenshots. Nutze Preview-Links, damit Reviewer die Seite im Kontext sehen (Navigation, Mobile-Layout und Cross-Links).
Typische Optionen:
Schreib Entscheidungen einmal nieder: Tone of Voice, Überschriftenstruktur, Code-/Beispielkonventionen und wie Screenshots erstellt/aktualisiert werden. Das lässt Docs kohärent wirken, auch wenn viele beitragen.
Definiere Ownership:
Wähle außerdem einen Schiedsrichter für gemeinsame Seiten (Startseite, Navigation-Labels), damit Änderungen nicht blockieren.
SEO wird einfacher, wenn Marketing-Seiten und Docs auf einer Domain leben: Du kannst Autorität aufbauen, interne Links teilen und Signale nicht über Subdomains zersplittern.
Beginne mit Basics auf jeder indexierbaren Seite:
Erstelle eine einfache Regel: immer relative Pfade verwenden (z. B. /pricing, /docs/api/auth). Das hält Umgebungen konsistent und reduziert kaputte Links.
Das größte Risiko bei kombinierten Sites ist das Wiederholen derselben Erklärung an mehreren Stellen (z. B. „Wie SSO funktioniert" auf einer Feature-Seite und in den Docs).
Wenn Überschneidungen unvermeidbar sind:
Füge Schema nur ein, wenn es korrekt ist:
Baue Cluster, in denen Blogposts breite Fragen beantworten und Leser zum nächsten Schritt führen:
Diese Struktur hilft Rankings und Konversionen — ohne Docs wie Sales-Copy klingen zu lassen.
Eine SaaS-Site mit Marketing und Docs muss sofort und verlässlich wirken. Kleine Rückschritte (schweres Script, neue Schrift, große Screenshots) summieren sich schnell.
Setze einige messbare Ziele und prüfe sie bei jedem Release:
Optimiere, was Nutzer zuerst herunterladen:
font-display: swap und erwäge Self-Hosting, um Drittanfragen zu reduzieren.Nutze außerdem Caching/Delivery: statische Assets mit langen Cache-Headern servieren und ein CDN verwenden, wenn das Hosting es nicht bereits tut.
Sammle nur, was nötig ist. Wenn Fragen mit weniger Tools beantwortet werden können, tue es.
Füge leichtes Monitoring hinzu und verlinke eine Status-Seite, falls vorhanden (z. B. /status). Wenn nicht, stelle wenigstens einen Vorfall-Update-Pfad in den Footer (Link zur Support-Seite), damit Nutzer wissen, wo sie nachschauen können, wenn etwas ausfällt.
Eine kombinierte Marketing- + Docs-Site ist nie „fertig". Der schnellste Weg zur Verbesserung ist zu beobachten, wie Leute die Seite tatsächlich nutzen: was sie suchen, wo sie stecken bleiben und welche Seiten Signups treiben.
Starte mit einer grundlegenden Site-weiten Suche, die sowohl Marketing- als auch Docs-Seiten abdeckt. Selbst eine einfache Lösung ist besser als keine — besonders bei docs-lastigen Produkten.
Sobald die Suche live ist, überprüfe das Nutzerverhalten regelmäßig und optimiere. Der größte frühe Gewinn ist, „No results"-Queries zu beheben, indem fehlende Seiten, Synonyme oder bessere Überschriften hinzugefügt werden.
Docs-Suche unterscheidet sich von Marketing-Suche. Nutzer sind aufgabenorientiert und ungeduldig, daher zählen kleine UX-Features:
Pageviews allein sagen nicht, was funktioniert. Tracke Events, die Entscheidungen abbilden:
Sorge dafür, dass Marketing und Support den Daten vertrauen. Halte Namenskonventionen konsistent und dokumentiere sie auf einer internen Seite (z. B. /docs/analytics-events).
Richte leichte Dashboards für zwei Zielgruppen ein:
Dann schließe den Loop: Verwandle wiederkehrende Support-Tickets und häufige Suchanfragen in Doc-Updates, neue Beispiele oder verbessertes Troubleshooting. Mit der Zeit wird deine Docs zu einem selbstheilenden System, das Support reduziert und Konversionen erhöht.
Ein guter SaaS-Website-Launch ist kein „publish and hope". Es ist ein kontrolliertes Release mit Checks, die peinliche Probleme (kaputte Seiten, fehlende Metadaten, tote Signup-Links) entdecken, bevor Kunden sie sehen — und einem Wartungsrhythmus, der verhindert, dass Marketing-Seiten und Docs veralten.
Bevor du etwas ankündigst, mach eine komplette Durchsicht mit Fokus auf Integrität und Indexierung:
Wenn du von einer alten Seite migrierst, erstelle eine einfache Tabelle old URL → new URL und lege sie neben das Repo, damit zukünftige Änderungen den ursprünglichen Plan nicht überschreiben.
Klicke nicht nur zufällig herum. Teste „Jobs", die Marketing und Docs verbinden:
Behandle diese als Release-Blocker. Wenn ein Flow fehlschlägt, spürst du es sofort in Konversionen und Support-Volumen.
Redirects sind nicht nur für Migrationen. SaaS-Sites entwickeln sich: Features umbenannt, Docs umstrukturiert, Produktseiten neu geschrieben.
Eine Regel: lösche niemals eine URL ohne (a) Redirect oder (b) absichtliches 410, wenn Inhalt wirklich weg soll. Für Docs ist Redirect fast immer die richtige Wahl.
Einigt euch außerdem auf eine zukunftsorientierte URL-Policy (z. B. Versionsnummern nur verwenden, wenn Docs wirklich versioniert werden). Das macht spätere Refactors kleiner.
Der Launch-Tag sollte einen leichten Plan haben:
Wenn möglich, halte ein "Hotfix-Window" mit dem Team für die ersten 24–48 Stunden offen.
Ein einfacher Rhythmus verhindert langsame Veralterung:
Behandle die Website wie ein Produkt: kontinuierlich verbessern und die Auswirkungen messen.
Beginne damit, einen Ein-Satz-Ziel zu formulieren, der beide Ergebnisse enthält, z. B.: „Qualified Prospects konvertieren und gleichzeitig Kunden ermöglichen, Support selbst zu erledigen.“ Dann weise jeder Seite eine Hauptaufgabe zu:
Die meisten kombinierten SaaS-Seiten bedienen mindestens vier Gruppen:
Wenn du das Publikum für eine Seite nicht benennen kannst, überarbeite den Seitenumfang, bis du es kannst.
Verwende eine kleine Menge oberster Bereiche und platziere alles andere im Footer:
Für die meisten SaaS-Produkte ist /docs die beste Standardwahl:
Wähle eine separate Subdomain nur, wenn deine Docs andere Tools, Berechtigungen oder einen separaten Wartungsworkflow benötigen.
Behandle URLs als Versprechen:
Plane URL-Konventionen früh, besonders wenn du Docs versionieren möchtest.
Stelle die Seiten bereit, die drei Fragen beantworten: Was ist das? Kann ich dem vertrauen? Was mache ich als Nächstes?
Mindest-Marketing-Set:
Mindest-Docs-Set:
Wähle abhängig davon, wer Inhalte aktualisiert und wie oft:
Ein häufiges Hybridmodell: Markdown/MDX für Docs + CMS-Felder für strukturierte Marketing-Inhalte.
Gib jeder wichtigen Seite eine Primary- und eine Secondary-CTA und halte die Wortwahl konsistent:
Nutze eine vorhersehbare Docs-Struktur und Templates:
Standardisiere ein Template wie Problem → Steps → Expected result → Troubleshooting, sodass jede Seite vertraut wirkt.
Messt Verhalten, das zu Geschäftsergebnissen passt, nicht nur Pageviews:
Review monatlich und verwandle wiederkehrende Suchen/Tickets in Doc-Updates, Troubleshooting-Einträge und bessere interne Verlinkungen (z. B. von Features zu /docs/getting-started und zurück zu ).
Die globale Navigation sollte marketing-orientiert bleiben; die Dokumentationsnavigation gehört in die Docs-Sidebar (Getting started, Guides, API, Troubleshooting).
Platziere Vertrauenssignale (Logos, Testimonials, Case Studies) nahe Entscheidungsstellen, um Hürden zu reduzieren.