Wie man eine Website für SaaS-Marketingseiten und Dokumentation baut

Ziele und Publikum: Marketing + Docs auf einer Website

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.

Primäres Ziel definieren

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.“

Entscheide, wen die Seite bedient

Die meisten SaaS-Seiten bedienen mehrere Zielgruppen mit unterschiedlicher Absicht:

• Prospects suchen nach Fit, Nachweisen und Preisen
• Trial-User wollen ihren ersten Erfolgsmoment erreichen
• Kunden benötigen verlässliche How-tos und Troubleshooting
• Entwickler evaluieren APIs, SDKs und Implementierungsdetails

Wenn du das Publikum für eine Seite nicht benennen kannst, wird der Text vage.

Kern-Ergebnisse auflisten (wie „Erfolg" aussieht)

Ergebnisse halten dein Team auf Verhalten fokussiert, nicht auf Seitenanzahlen:

• Mehr Anmeldungen oder Demo-Anfragen
• Höhere Trial-zu-Paid-Konversion
• Schnellere Time-to-Value (Setup abgeschlossen, erstes Projekt erstellt)
• Mehr Self-Serve-Hilfe, weniger Support-Tickets

Erfolgsmetriken festlegen

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.

Zuständigkeiten früh bestätigen

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 und URL-Struktur

Informationsarchitektur bestimmt, wie beide Nutzerreisen offensichtlich wirken — ohne die Header-Navigation in eine Sammelstelle zu verwandeln.

Mit wenigen primären Bereichen beginnen

Die meisten Teams kommen mit einer Handvoll Top-Level-Bereiche für „Marketing + Docs“ aus:

• / (Startseite)
• /product (oder /features)
• /pricing
• /customers (Case Studies, Testimonials)
• /blog
• /docs

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.

Entscheide, wo die Docs liegen: /docs vs. Subdomain

Für die meisten SaaS-Produkte ist Hosting der Dokumentation unter /docs die einfachste Wahl.

Docs unter /docs (gleiche Domain)

• Vorteile: einheitliches Markenerlebnis, einfacheres Cross-Linking, SEO-Vorteile durch eine Domain, einfachere Analytics
• Nachteile: Design und Navigation müssen koordiniert werden, damit die Docs sich nicht wie „eine andere Seite" anfühlen

Docs auf einer Subdomain (z. B. docs.deinedomain)

• Vorteile: klarere Trennung für Tooling, Berechtigungen oder unterschiedliche Build-Systeme
• Nachteile: kann getrennt wirken, schwerer SEO-Autorität zu teilen, Analytics erfordern eventuell Extra-Setup

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.

Nutzerreisen abbilden, bevor das Menü feststeht

Denk in häufigen Pfaden und stell sicher, dass URLs und Navigation sie unterstützen.

Beispiel Marketing-Reise:

• / → /pricing → Signup

Beispiel Support-Reise:

• /docs → konkreter Artikel → verwandtes Troubleshooting → Kontakt zum Support (nur wenn nötig)

Navigation hat Rollen:

• Globale Navigation soll Marketing-Discovery unterstützen (Product, Pricing, Customers, Blog, Docs).
• Docs-Sidebar-Navigation soll bei der Aufgabenerledigung helfen (Getting started, Guides, API, Troubleshooting).

Einen stabilen URL-Plan erstellen

URLs sind Versprechen. Änderungen später brechen Lesezeichen, eingehende Links und Vertrauen.

Eine praktische Herangehensweise:

• Verwende kurze, menschenlesbare Slugs: /docs/sso, nicht /docs/2025/07/sso-guide-final
• Vermeide zu tiefe Verschachtelungen, es sei denn, sie entsprechen dem Nutzerdenken: /docs/integrations/slack ist okay; fünf Ebenen tief nicht
• Wähle einen Stil (kebab-case ist üblich): /docs/api-authentication
• Triff Versionierungsentscheidungen bewusst (wenn du Docs versionierst, entscheide das früh)

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.

Kernseitentypen (Was zuerst bauen)

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?

Unverzichtbare Marketing-Seiten (zuerst shippen)

Beginne mit den Essentials, die Besucher erwarten und auf die das Team häufig verweist:

• Homepage: eine klare Value Proposition, primärer CTA (Trial oder Demo) und ein kurzes „So funktioniert es.“
• Features (oder Use Cases): Erläutere Ergebnisse in verständlicher Sprache; verlinke jedes Feature zu relevanten Docs.
• Pricing: Preisstufen, enthaltene Leistungen, FAQ und procurement-freundliche Details (Abrechnung, Rechnung, Steuern).
• Security (oder Trust): Security-Übersicht, Datenhandhabung, Compliance-Angaben (nur wenn wahr) und eine Möglichkeit, Dokumentation anzufordern.
• Contact: Sales-/Support-Kontaktoptionen plus ein einfaches Formular.

Halte jede Seite auf eine einzelne Entscheidung fokussiert. Du kannst später erweitern.

Vertrauensbildner, die Hemmungen verringern

Vor dem Trial suchen Nutzer nach Nachweisen. Füge früh leichte Vertrauenssignale hinzu:

• Kunden-Logos und kurze Testimonials (selbst 2–3 starke helfen)
• Case Studies, wenn vorhanden (eine solide Story schlägt fünf vage Zitate)
• Integrationsseite (oder Abschnitt), damit Nutzer Kompatibilität schnell prüfen können
• Ein Link zu deiner Status-Seite (zum Beispiel /status), falls vorhanden

Conversion-fokussierte Seiten (bei Bedarf hinzufügen)

Sobald die Kernseiten stehen, ergänze Seiten, die deiner Sales-Strategie entsprechen:

• Request a demo für High-Touch-Sales
• Start trial für Self-Serve-Onboarding
• Compare pages (nur wenn du fair und konkret vergleichen kannst)

Diese Seiten sollten Reibung entfernen: klare Formfelder, Erwartungen („wir antworten innerhalb 1 Werktag“) und nächste Schritte.

Docs-Essentials (unterstütze das erste „Aha“)

Deine Dokumentation sollte neuen Nutzern helfen, schnell erfolgreich zu werden:

• Getting started: Installation/Setup, erstes Projekt und Grundkonzepte
• Guides: gängige Workflows und Best Practices
• API-Reference: falls vorhanden, vollständig und durchsuchbar
• Troubleshooting: bekannte Fehler, Lösungen und Kontaktmöglichkeiten zum Support

Unterstützende Seiten, die die Site abrunden

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.

Wahl des Tech-Stacks (einfache Optionen)

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.

Option 1: Static Site Generator (SSG)

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:

• Hervorragende Geschwindigkeit und SEO
• Einfaches Hosting (CDN + Object Storage)
• Geringes Update-Risiko (Content-Änderungen brechen selten Laufzeitlogik)

Es ist auch ein sauberer Weg, Docs in Markdown zu halten und dennoch Suche und versionierte Inhalte zu unterstützen.

Option 2: Server-gerendert oder komplette Web-App

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:

• Personalisierte Seiten (unterschiedliche Inhalte pro Account)
• Authentifizierte Docs (intern/privat)
• Komplexe Suche, Berechtigungen oder dynamische Content-Regeln

Du kannst trotzdem die meisten Marketing-Seiten statisch generieren und nur die wirklich dynamischen Teile serverseitig rendern.

Option 3: CMS-Templates (traditionell oder headless)

Ein CMS-getriebener Ansatz funktioniert gut, wenn Nicht-Techniker häufig veröffentlichen und strukturierte Inhalte (Preis-Tiers, Kundenstories, Vergleichstabellen) konsistent benötigen.

Content-Speicher: Markdown/MDX vs. CMS-Felder

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.

Umgebungen: lokal, Preview, Produktion

Richte drei Umgebungen von Anfang an ein:

• Local: schnelles Iterieren
• Preview: per-Branch oder per-PR Previews für Reviews
• Production: gesperrte Deploys mit Rollback-Unterstützung

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.

Design und UX für Marketing-Seiten und Docs

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.

Mit einem leichten Designsystem starten

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.

Wiederverwendbare Sektionen = schnellere Seiten

Erstelle wiederverwendbare Seitenabschnitte, die wie Bausteine zusammengesetzt werden können:

• Hero (Value Prop + primärer CTA)
• Feature Grid (3–6 Vorteile)
• FAQ (reduziert Support-Last)
• Vergleichstabelle (unterstützt Evaluation)
• Final CTA (Trial, Demo oder Pricing)

Wenn diese Abschnitte Spacing, Typografie und Button-Stile teilen, wirkt die Site kohärent, während Inhalte wachsen.

Docs lesbar machen (insbesondere Code)

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.

Accessibility und Mobile-First-Checks

Behandle Accessibility als Baseline:

• Ausreichender Kontrast für Text und Buttons
• Sichtbare Fokuszustände und volle Tastaturnavigation
• Alt-Text für bedeutungsvolle Bilder (bei dekorativen weglassen)

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.

Messaging, Copy und Conversion-Pfade

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.

Aufgabe jeder Seite definieren (und ihre CTAs)

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:

• Homepage: Primär Start free trial; Sekundär See a demo
• Features: Primär View pricing; Sekundär Read how it works
• Pricing: Primär Choose a plan; Sekundär Talk to sales

Halte CTAs in Wortwahl und Platzierung konsistent, damit Besucher die Seite nicht auf jeder Seite neu erlernen müssen.

Nutzenorientierten Text schreiben und spezifisch bleiben

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.

Vertrauensbeweise, denen Leute glauben

Füge Proof nahe Entscheidungspunkten hinzu (Features, Pricing, Signup). Verwende Zahlen nur, wenn du sie verifizieren kannst, und zeige Kontext:

• „Trusted by 2,400 teams“ (wenn wahr)
• „Processing time um 32% reduziert" (mit kurzer Erklärung wer/wann)

Balanceiere Metriken mit menschlichem Proof: Zitate, Mini-Case-Studies und reale Workflow-Beispiele.

Preisklarheit als Conversion-Feature

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).

Marketing und Docs verbinden (ohne Nutzer in ein Labyrinth zu schicken)

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.

Dokumentationsstruktur und Navigation, die funktioniert

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?

Mit einer Sidebar beginnen, die der Nutzer-Absicht entspricht

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:

• Getting Started (Setup, erster Erfolg)
• Tutorials (End-to-End-Walkthroughs)
• How-to Guides (konkrete Aufgaben wie „Invite teammates")
• Reference (API, Konfigurationsoptionen)
• Explanations (Konzepte, Entscheidungsleitfäden, „how it works")

Halte Labels konsistent mit der Produktterminologie. Wenn die UI „Workspaces" sagt, nenne sie nicht in den Docs „Projects".

On-Page-Navigation, die Scrollen reduziert

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.

Templates verwenden, damit jede Anleitung vertraut ist

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.

Docs kontinuierlich verbessern leicht machen

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.

Content-Workflow: Aktualisieren ohne Dinge zu brechen

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.

Ein einfaches Content-Modell festlegen

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.

Einen redaktionellen Workflow etablieren

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.

Mit Preview-Links reviewen, nicht per Screenshot

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:

• Pull-Request-Previews (automatische Deploys pro PR)
• Eine Staging-Site, die Produktion spiegelt

Style-Guidelines, die Konsistenz gewährleisten

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.

Klare Zuständigkeiten (und Eskalationswege)

Definiere Ownership:

• Marketing owned Marketing-Seiten
• Product/Support owned Docs

Wähle außerdem einen Schiedsrichter für gemeinsame Seiten (Startseite, Navigation-Labels), damit Änderungen nicht blockieren.

SEO für kombinierte Marketing- + Dokumentationsseiten

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.

On-Page-Grundlagen, die sich auszahlen

Beginne mit Basics auf jeder indexierbaren Seite:

• Einzigartige Titles und Meta Descriptions, die der Intention entsprechen (Feature-Seiten verkaufen; Docs erklären).
• Ein klares H1, dann strukturierte H2/H3, die dem Scan-Verhalten entsprechen.
• Beschreibende interne Links (vermeide „hier klicken"). Beispielsweise von einer Feature-Seite zu Setup-Docs verlinken wie /docs/getting-started und zurück zu Conversion-Seiten wie /pricing.

Erstelle eine einfache Regel: immer relative Pfade verwenden (z. B. /pricing, /docs/api/auth). Das hält Umgebungen konsistent und reduziert kaputte Links.

Duplikate zwischen Marketing und Docs verhindern

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:

• Mach eine Seite zur „Source of Truth" und verlinke von der anderen
• Wenn zwei Seiten existieren müssen, setze canonical-Tags auf die bevorzugte Version

Strukturierte Daten sinnvoll einsetzen

Füge Schema nur ein, wenn es korrekt ist:

• SoftwareApplication auf wichtigen Produktseiten
• FAQPage auf echten FAQ-Sektionen (nicht auf Marketing-Filler)
• Article auf Blogposts und langen Guides

Topic-Cluster, die Content mit Umsatz verbinden

Baue Cluster, in denen Blogposts breite Fragen beantworten und Leser zum nächsten Schritt führen:

• Blog: „How to set up SSO for a SaaS app" → /features/sso und /docs/sso/setup
• Blog: „Webhook security checklist" → /docs/webhooks/security und /features/webhooks

Diese Struktur hilft Rankings und Konversionen — ohne Docs wie Sales-Copy klingen zu lassen.

Performance, Security und Privacy Basics

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.

Performance-Ziele, die wirklich zählen

Setze einige messbare Ziele und prüfe sie bei jedem Release:

• Schnelles Laden: strebe ein LCP (Largest Contentful Paint) von ~2–2,5s auf einem Mittelklasse-Mobilgerät an.
• Stabile Layouts: halte CLS niedrig, indem du Platz für Bilder, Embeds und Banner reservierst.
• Glatte Interaktion: vermeide lange Main-Thread-Tasks — Docs-Seiten haben oft Syntax-Highlighting und Such-Widgets, die Rendering blockieren können.

Praktische Optimierungen (hoher Impact, geringes Drama)

Optimiere, was Nutzer zuerst herunterladen:

• Bilder: moderne Formate (WebP/AVIF), responsive Größen und lazy-loading für Bilder unterhalb der Falz — besonders in Docs mit vielen Screenshots.
• Schriften: begrenze Familien/Gewichte, nutze font-display: swap und erwäge Self-Hosting, um Drittanfragen zu reduzieren.
• Skripte: defer nicht-kritische Skripte (Analytics, Chat, A/B-Tests). Betrachte jeden neuen Tag als Performance-Budget-Anfrage.

Nutze außerdem Caching/Delivery: statische Assets mit langen Cache-Headern servieren und ein CDN verwenden, wenn das Hosting es nicht bereits tut.

Security-Grundlagen, die du nicht überspringen solltest

• HTTPS überall und HTTP → HTTPS-Redirects
• Gängige Security-Header hinzufügen (HSTS, X-Content-Type-Options, Referrer-Policy; und ein CSP, wenn du ihn pflegen kannst)
• Dependencies aktuell halten, besonders Docs-Tooling, Suche und Build-Pipelines
• Keine privaten Build-Logs oder Preview-URLs offenlegen; Staging mit Auth schützen

Privacy: Tracker minimieren

Sammle nur, was nötig ist. Wenn Fragen mit weniger Tools beantwortet werden können, tue es.

• Cookie-Banner nur verwenden, wenn erforderlich (Recht/Jurisdiktion + Tracking-Verhalten)
• Privacy-freundliche Analytics bevorzugen und Marketing-Pixel auf Docs vermeiden, sofern kein klarer Grund besteht

Verfügbarkeit und Vertrauenssignale

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.

Suche, Analytics und kontinuierliche Verbesserung

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.

Site-Suche hinzufügen (einfach starten)

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-spezifische Suchfeatures, die helfen

Docs-Suche unterscheidet sich von Marketing-Suche. Nutzer sind aufgabenorientiert und ungeduldig, daher zählen kleine UX-Features:

• Filter (Version, Produktbereich, Sprache, "API" vs "Guides")
• Tastenkürzel zur Suchfokussierung (z. B. / oder Cmd/Ctrl+K)
• Ergebnis-Highlighting (gefundene Wörter in Überschriften und Snippets zeigen)

Events tracken, die Geschäftsfragen beantworten

Pageviews allein sagen nicht, was funktioniert. Tracke Events, die Entscheidungen abbilden:

• CTA-Klicks auf Marketing-Seiten
• Signup-Starts und -Abschlüsse
• Docs-Suchen (Query + ausgewähltes Ergebnis)
• „No results"-Suchen und Absprünge nach Suche

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).

Dashboards und Feedback-Loops

Richte leichte Dashboards für zwei Zielgruppen ein:

• Marketing: Top-Landing-Pages → CTA-Klicks → Signup-Starts
• Support: Top-Docs-Seiten, Top-Suchen, „No results" und Seiten mit hoher Bounce

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.

Launch-Checklist und Wartungsplan

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.

Pre-Launch-Checklist (das Unangenehme, das dich rettet)

Bevor du etwas ankündigst, mach eine komplette Durchsicht mit Fokus auf Integrität und Indexierung:

• Broken Links: crawle die Site und behebe 404s, besonders von Docs zu Docs und Docs zu Marketing-Seiten.
• Redirects: richte 301-Redirects für geänderte/entfernte URLs ein. Verlass dich nicht auf "wir fixen das später" — alte Links bleiben in Lesezeichen, E-Mails und Suchergebnissen.
• Sitemap: bestätige, dass /sitemap.xml existiert und sowohl Marketing- als auch Docs-Seiten enthält, die indexiert werden sollen.
• robots.txt: prüfe, dass /robots.txt Indexierung dort erlaubt, wo sie erwünscht ist, und private/duplizierte Bereiche (z. B. interne Previews) blockiert.

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.

Flows testen, die Kunden tatsächlich nutzen

Klicke nicht nur zufällig herum. Teste „Jobs", die Marketing und Docs verbinden:

• Pricing → signup: Pricing-Seite lädt schnell, CTA funktioniert, Signup gelingt, Bestätigungs-E-Mails werden verschickt.
• Docs → contact support: ein Leser findet keine Lösung, findet schnell Hilfeoptionen und das Formular/Email funktioniert.
• Search → article: Suche liefert relevante Ergebnisse, Titel sind lesbar und der ausgewählte Artikel passt zur Absicht.

Behandle diese als Release-Blocker. Wenn ein Flow fehlschlägt, spürst du es sofort in Konversionen und Support-Volumen.

Redirect-Strategie (jetzt und für zukünftige Änderungen)

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.

Release-Plan: ankündigen, überwachen, schnell fixen

Der Launch-Tag sollte einen leichten Plan haben:

1. Ankündigen (E-Mail, Social, In-App) nachdem die Site live verifiziert ist.
2. Überwachen: Analytics, Signup-Funnel-Dropoffs, 404s und Search-Console-Coverage beobachten.
3. Schnell beheben: priorisiere alles, was Signups, wichtige Docs oder Top-Landing-Pages bricht.

Wenn möglich, halte ein "Hotfix-Window" mit dem Team für die ersten 24–48 Stunden offen.

Post-Launch-Wartungstaktik

Ein einfacher Rhythmus verhindert langsame Veralterung:

• Monatlich SEO-Review: Search Console auf Indexierungsfehler, Queries mit sinkenden Rankings und Seiten mit hoher Impression aber niedriger Klickrate prüfen (oft Title/Meta-Problem).
• Quartalsweise Docs-Aufräumen: veraltete Screenshots entfernen, Setup-Schritte an Produktänderungen anpassen und Top-Visited-Docs auf Klarheit prüfen.

Behandle die Website wie ein Produkt: kontinuierlich verbessern und die Auswirkungen messen.