Docusaurus vs GitBook 2026: Open Source gegen SaaS

Die Entscheidung zwischen Docusaurus und GitBook sitzt auf der Bruchlinie zwischen Open Source und gehostetem SaaS im Markt für Entwicklerdokumentation. Docusaurus ist der React-basierte Generator für statische Websites von Meta, kostenlos unter MIT-Lizenz, ausgeliefert auf dem statischen Hosting, das dein Team ohnehin betreibt. GitBook ist die gehostete SaaS-Plattform rund um einen geschliffenen Blockeditor und KI-gestützte Erstellung, abgerechnet pro Website und pro Person, ohne Build-Schritt. Beide Produkte tragen Entwicklerdoku in ernsthaftem Maßstab, beide haben 2026 spürbar in KI investiert, und beide teilen eine tiefere Frage, über die die Marketingseiten hinweggehen: ob kundenseitige Anleitungen überhaupt in einem Werkzeug für Entwicklerdoku leben sollten.

Dieser Artikel vergleicht Docusaurus und GitBook nach Editor-Tiefe, Anpassbarkeit, KI-Funktionen (GitBook AI Assistant und Agent gegen Docusaurus plus Suchplugins), Versionierung und Git-Ablauf, Hosting und Auslieferung, Mehrsprachigkeit, Preisökonomie und der größeren Frage, die unter dem Vergleich liegt. Am Ende steht ein Entscheidungsrahmen nach Teamprofil und die Frage, wo ein selbst aktualisierendes Help Center in die Lücke passt, die beide Werkzeuge für produktnahe Inhalte offen lassen.

Was ist Docusaurus?

Docusaurus ist ein quelloffener Generator für statische Websites von Meta (früher Facebook), inzwischen in Version 3.10.1. Das Produkt ist gezielt für Dokumentationsseiten gebaut und bringt Konventionen für Seitenleisten, Versionierung, Internationalisierung, Suche und Theming ab Werk mit. Die Hauptfläche ist eine React-basierte Anwendung, die beim Build aus MDX-Dateien (Markdown plus JSX) erzeugt wird, das heißt: Schreibende arbeiten in Markdown, und Entwickelnde können React-Komponenten für interaktive Beispiele, Code-Spielwiesen oder eigene Widgets einbetten. Gehostet wird auf dem statischen Anbieter des Teams (GitHub Pages, Netlify, Vercel, Cloudflare Pages oder selbst gehostet).

Das Ergebnis von Docusaurus ist eine statische Website unter deiner vollen Kontrolle: Themes sind React-Komponenten, Plugins erweitern die Website in jeder Bauphase, und der gesamte Inhaltsbaum liegt versioniert als Markdown neben der Codebasis. Versionierung ist erstklassig (jeder Release-Branch kann eigene Doku tragen), MDX v3 erlaubt tieferes Einbetten von Komponenten, das offizielle Algolia-Plugin treibt die Volltextsuche, und Internationalisierung kommt ab Werk mit Abläufen für Crowdin und Git-basierte Übersetzung. Der Kompromiss: Alles außer dem Schreiben ist Entwicklungsarbeit, also Aufbau, Auslieferungspipelines, Theme-Anpassung, Pluginauswahl, Suchanbindung.

Was ist GitBook?

GitBook ist eine gehostete SaaS-Dokumentationsplattform, die sich in den letzten Jahren um einen geschliffenen Blockeditor und einen KI-first-Ablauf herum neu gebaut hat. Verkauft wird pro Website und pro Person, ohne Build-Schritt und ohne Auslieferungspipeline: anmelden, einen Space anlegen, die Doku ist live. Die Hauptfläche ist ein Web-Editor, der komplexe Formatierung (Tabellen, Callouts, Tabs, Codeblöcke) sauberer beherrscht als die meisten Wettbewerber, dazu ein Git-Sync, der Inhalte zwischen GitBook und einem angebundenen GitHub- oder GitLab-Repo in beide Richtungen spiegelt.

Das Ergebnis von GitBook ist eine gehostete Doku-Website auf der Infrastruktur von GitBook, mit eigenen Domains in den bezahlten Stufen, KI-Suche mit dialogorientierten Antworten, dem GitBook AI Assistant (500 Antworten in Ultimate enthalten), der Inhalte entwirft und Doku aus einer angebundenen Codebasis erzeugt, und dem GitBook Agent für dokumentübergreifende Operationen. Versionierung, Branching und Prüfabläufe sind eingebaut. Der Kompromiss: Das Team tauscht Entwicklungskontrolle gegen Anbietertempo. Die Anpassung endet an der Vorlagenschicht, KI-Funktionen hängen an der Stufe, und schwerere Seiten können bei großen Doku-Beständen träge wirken.

Kurzes Fazit zur Frage Docusaurus gegen GitBook

Wenn dein Team engineering-geführt ist, eine Build-Pipeline betreiben will, volle Kontrolle über Theme und Plugins wünscht, Open-Source-Lizenzierung und Self-Hosting priorisiert und akzeptiert, dass alles außer dem Schreiben Entwicklungsarbeit ist, gewinnt Docusaurus bei Anpassbarkeit, Leistung und Gesamtkosten. Wenn dein Team keinen Build-Schritt will, einen geschliffenen Editor für Nicht-Entwickelnde braucht, KI-Erstellung ab Werk will, gehostete Infrastruktur mit eigenen Domains und ein Preismodell pro Website und Person, das mit der Nutzung wächst, gewinnt GitBook bei Zeit bis zur Veröffentlichung und Editor-Tiefe. Keines der Werkzeuge wurde für die Veralterungslücke bei kundenseitigen Anleitungen gebaut, und genau diese Dimension überspringen die meisten Bewertungen.

Wie du mit beiden Werkzeugen Dokumentation erstellst

Der Alltag am ersten Tag sagt dir fast alles darüber, für wen das jeweilige Werkzeug gedacht ist. Docusaurus erwartet eine entwickelnde Person an der Tastatur. GitBook erwartet eine schreibende Person (oder jede andere ohne Entwicklungshintergrund).

Veröffentlichen in Docusaurus

In Docusaurus führst du npx create-docusaurus@latest my-docs classic aus, um ein Projekt aufzusetzen, schreibst Inhalte als Markdown- oder MDX-Dateien im Verzeichnis docs/, konfigurierst die Seitenleiste in sidebars.js, passt das Theme an, indem du React-Komponenten in der Swizzle-Schicht überschreibst, und lieferst aus, indem du npm run build ausführst und das Ergebnis auf dein statisches Hosting schiebst. Inhaltsänderungen laufen über Pull Requests; die Doku wird mit der Codebasis ausgeliefert. Die Suche hängt am Algolia-Plugin (für Open-Source-Projekte über Algolia DocSearch kostenlos). Die Versionierung friert die aktuelle Doku bei jedem Release in einem versionierten Ordner ein.

Veröffentlichen in GitBook

In GitBook meldest du dich an, legst einen Space an, klickst auf Neue Seite, schreibst im Blockeditor (Absätze, Überschriften, Callouts, Tabs, Codeblöcke, Einbettungen, Tabellen) und veröffentlichst. Die Website ist sofort auf einer gitbook.io-Subdomain live (oder in bezahlten Stufen auf einer eigenen Domain). Ein bidirektionaler Git-Sync spiegelt die Inhalte in ein GitHub- oder GitLab-Repo für Teams, die Pull-Request-Abläufe wollen; ein einseitiger Sync (Git als Quelle der Wahrheit) wird ebenfalls unterstützt. Der GitBook AI Assistant entwirft Inhalte aus Prompts, erzeugt Dokumentation aus einem angebundenen Repo und beantwortet Fragen in der dialogorientierten Suche.

Auf der Konsumseite sieht das Endprodukt unterschiedlich aus. Docusaurus-Websites fühlen sich meist flotter an (statisches HTML mit React-Hydration, keine Datenbankabfrage pro Seite), haben engere Designkontrolle, weil jedes Theme-Element bearbeitbar ist, und verzahnen sich tiefer mit dem Entwicklungsablauf. GitBook-Websites wirken über das GitBook-Ökosystem hinweg einheitlicher, gehen schneller live, weil es keinen Build-Schritt gibt, und setzen auf KI-Suche als Hauptweg zur Entdeckung.

Funktionen von Docusaurus und GitBook im Detail

Sechs Dimensionen entscheiden die meisten Bewertungen, sobald die Marketingseiten aus dem Weg sind: Editor und Erstellung, Anpassbarkeit und Theming, KI-Funktionen, Versionierung und Git-Ablauf, Hosting und Auslieferung sowie Internationalisierung.

Editor und Erstellung

In Docusaurus entstehen Inhalte als Markdown- oder MDX-Dateien im Repository, bearbeitet im Editor, den das Team ohnehin nutzt (VS Code, Cursor, JetBrains, klassisches vim). Die Oberfläche ist der vorhandene Editor. Der Kompromiss: Nicht-Entwickelnde empfinden Git-Abläufe als Reibung. GitBook liefert einen geschliffenen Blockeditor, der komplexe Formatierung (verschachtelte Tabellen, Callouts, Tabs, Codeblöcke, Formeln) sauberer beherrscht als die meisten Wettbewerber und für Nicht-Entwickelnde optimiert ist. Der Kompromiss ist der Verlust der Git-Historie pro Datei, wenn kein Git-Sync konfiguriert ist. Schreiben in deinem Team überwiegend Entwickelnde, ist der Editor von Docusaurus (die vorhandene Entwicklungsumgebung) schneller. Verantworten Produktmanagement oder technische Redaktion die Doku, ist der Editor von GitBook deutlich freundlicher.

Anpassbarkeit und Theming

Docusaurus bietet volles Theming über React-Komponenten. Jedes Oberflächenelement lässt sich überschreiben, Plugins schieben Inhalte in jede Bauphase, und das Theme lässt sich mit CSS-Modulen oder jeder anderen Lösung gestalten. Die Decke der Anpassbarkeit ist das React-Ökosystem, also faktisch unbegrenzt. GitBook bietet gebrandete Anpassung (Logo, Farben, eigene Domains, Navigationsbezeichnungen), endet aber an der Vorlagenschicht. Für Teams, deren Doku-Website wie eine Erweiterung des Produkts aussehen soll, gewinnt Docusaurus. Für Teams, die eine saubere, geschliffene Doku-Website ohne Entwicklungsinvestition wollen, gewinnt GitBook.

KI-Funktionen: GitBook AI und Agent gegen Docusaurus plus Suchplugins

GitBook liefert in Ultimate den AI Assistant (500 Antworten enthalten) für Inhaltsentwürfe, KI-Suche über den Space und Dokumentationserzeugung aus einer angebundenen Codebasis. Der GitBook Agent ergänzt laut aktueller Preisseite von GitBook dokumentübergreifende Operationen, etwa den Stil über einen ganzen Space zu vereinheitlichen oder Release Notes aus einem Git-Diff zu erzeugen. In den höheren Stufen ist die KI-Fläche ein erstklassiger Teil des Produkts. Docusaurus liefert keine native KI-Erstellung; Teams, die KI wollen, binden Drittwerkzeuge an (typischerweise Algolia-KI-Suche, Mendable für Doku-Chat oder eigene RAG-Pipelines auf der Markdown-Quelle). Der Kompromiss: Die offene Architektur erlaubt jedes KI-Werkzeug, doch die Integrationsarbeit ist Sache des Teams.

Versionierung und Git-Ablauf

Die Versionierung von Docusaurus ist erstklassig: Jeder Release-Branch kann eine eigene Momentaufnahme tragen, und die Website zeigt oben ein Versions-Dropdown. Das Muster passt zu semantisch versionierten SDKs und Bibliotheken (Doku für 1.x gegen 2.x gegen aktuell). Der Ablauf lebt in Git. GitBook liefert Versionierung über Varianten und Branches in der eigenen Oberfläche, mit Git-Sync als optionaler Brücke zu einem angebundenen Repo. Für Teams, die SDKs in mehreren Versionen ausliefern und Doku an Bibliotheksversionen binden müssen, passt Docusaurus sauberer. Für Teams mit einem einversionigen SaaS-Produkt und leichtem Branching zur Prüfung ist der oberflächengetriebene Ablauf von GitBook reibungsärmer.

Hosting und Auslieferung

Docusaurus läuft überall, wo statische Dateien laufen: GitHub Pages, Netlify, Vercel, Cloudflare Pages, S3 mit CloudFront oder selbst gehostet. Die Kosten sind die Hostingrechnung, auf den meisten statischen Hosts vernachlässigbar. GitBook hostet auf eigener Infrastruktur, mit eigenen Domains ab Premium. Der Kompromiss ist die Bindung an die Plattform: Ein GitBook-Export lässt sich als Markdown herunterladen, doch KI-Funktionen, Kommentare, Bearbeitungshistorie und Prüfabläufe wandern nicht mit. Teams, die Hostingkontrolle priorisieren oder die Doku im eigenen Cloud-Konto halten wollen, wählen Docusaurus. Teams, die null Infrastrukturaufwand wollen, wählen GitBook.

Internationalisierung und Mehrsprachigkeit

Die Internationalisierung von Docusaurus kommt ab Werk mit Git-basierten Übersetzungsabläufen, dazu Anbindungen an Crowdin und andere Übersetzungsverwaltungen. Jede Sprache liegt in einem eigenen Unterordner, was die Prüfung der Lokalisierung erleichtert. GitBook unterstützt Mehrsprachigkeit über Varianten und angebundene Crowdin-Abläufe in höheren Stufen. Für Teams, die in fünf oder mehr Sprachen mit bestehendem Übersetzungsablauf ausliefern, ist das Git-Muster von Docusaurus reibungsärmer. Für Teams mit ein bis drei Sprachen decken beide Werkzeuge das Feld ab.

Preisvergleich: quelloffen und selbst gehostet gegen SaaS pro Website und Person

Die Ökonomie läuft scharf auseinander, weil die beiden Produkte für völlig Verschiedenes berechnen. Docusaurus ist unter MIT-Lizenz kostenlos; es fällt nur die Hostingrechnung an (GitHub Pages kostet für öffentliche Repos 0 Dollar, die kostenlosen Stufen von Netlify und Vercel decken die meisten Doku-Websites ab, ein Enterprise-Self-Host kann bei ernsthaftem Traffic 50 bis 500 Dollar pro Monat kosten). Die größere Position ist die Entwicklungsinvestition für Aufbau, Theme-Anpassung und laufende Pflege.

GitBook berechnet pro Website und pro Person. Die kostenlose Stufe deckt Einzelpersonen mit GitHub- oder GitLab-Sync ab. Premium kostet 65 Dollar pro Website und Monat plus 12 Dollar pro Person und Monat für gebrandete öffentliche Doku. Ultimate kostet 249 Dollar pro Website und Monat plus 12 Dollar pro Person und Monat für AI Assistant, Agent, adaptive Inhalte und authentifizierten Zugriff. Enterprise gibt es laut aktueller Preisseite von GitBook auf Anfrage mit SAML-SSO und begleiteter Migration. Jährliche Zahlung spart zwei Monate.

Das Muster ist der klassische Handel zwischen Open Source und gehostetem SaaS. Die Lizenzkosten von Docusaurus bleiben bei null; die Entwicklungsinvestition wächst mit dem Anpassungsgrad. Die Rechnung von GitBook wächst mit Websites und Personen, doch die Zeit bis zur Veröffentlichung bleibt in jeder Stufe nahe null. Die vollständige Aufschlüsselung der GitBook-Preise geht jede Stufe durch; der Vergleich GitBook gegen ReadMe behandelt die benachbarte Entscheidung, vor der die meisten GitBook-Käufer stehen.

Die größere Frage darunter: gehört Kundendoku überhaupt in ein Entwicklerwerkzeug?

Das Gespräch über Docusaurus gegen GitBook wird meist als Werkzeugwahl für Entwicklung gerahmt. Beide Produkte wurden für Entwicklerdokumentation entworfen: API-Referenzen, SDK-Anleitungen, Integrationstutorials, Bibliotheksdoku. Für diesen Zweck funktionieren beide gut. Die Falle ist, dass Teams eines auswählen (oft entlang der Vorliebe für Open Source oder SaaS) und es dann still auf kundenseitige Anleitungen ausdehnen: Rundgänge durch die Oberfläche, Supportartikel, Onboarding-Anleitungen, Fehlerbehebung.

Diese Ausdehnung ist der Bruchpunkt. Entwicklerdokumentation bewegt sich im Releasetakt (eine neue SDK-Version alle paar Wochen oder Monate); kundenseitige Anleitungen bewegen sich im Deploy-Takt (eine UI-Änderung alle paar Tage). Dieselben Werkzeuge, die API-Referenzen gut tragen, brechen bei Oberflächenrundgängen, weil sich die Fläche darunter (Screenshots, Klickpfade, Feldbezeichnungen) schneller bewegt, als die menschliche Prüfschleife folgen kann. Veraltende Dokumentation ist der versteckte Kostenblock jedes Help Centers, und der Fehlermodus wird erst sichtbar, wenn genug Kundschaft verwirrt genug war, um Tickets in Menge zu schreiben.

Die KCS-Methodik des Consortium for Service Innovation setzt als Maßstab, dass organisationales Wissen spätestens zum Zeitpunkt des Fallabschlusses verfügbar sein sollte. Diese Marke bei kundenseitigen Anleitungen zu treffen verlangt ein Aktualitätssignal, das weder Docusaurus noch GitBook nativ liefert, weil keines der Produkte für dieses Problem entworfen wurde.

Welcher Fehlermodus stört mehr

Die beiden Werkzeuge scheitern unterschiedlich, wenn sie in den Dienst kundenseitiger Anleitungen gedehnt werden.

Der Fehlermodus von Docusaurus ist die verwaiste Version. Versionierte Momentaufnahmen sind erstklassig, was die Doku zu 1.x unsterblich macht. Ändert sich die Oberfläche in 2.x und aktualisiert niemand die Momentaufnahme zu 1.x, taucht sie in Suche und KI-Abruf weiterhin als maßgeblicher Inhalt auf. Wer sie liest, folgt Schritten, die nicht mehr zur aktuellen Oberfläche passen, und der Vertrauensverlust kommt verzögert, aber kumulativ. Die Stärke des Versionsmodells (unsterbliche Momentaufnahmen) wird für nicht versionierte Produkte zur Schwäche.

Der Fehlermodus von GitBook ist die selbstsicher von der KI neu geschriebene veraltete Seite. Der GitBook AI Assistant erzeugt Inhalte aus einer angebundenen Codebasis, was nach Aktualitätssignal klingt, aber die Codebasis liest, nicht das laufende Produkt. Sind Kommentare im Code veraltet, erbt die KI die veraltete Rahmung. Erzeugt der Assistent einen Onboarding-Ablauf aus dem API-Schema, während der tatsächliche Ablauf in der Oberfläche abgewichen ist, ist das Ergebnis überzeugend falsch. Die KI-Schicht verstärkt die Aktualitätslücke schneller als eine statische Seite.

Was mehr stört, hängt vom Anwendungsfall ab. Ein SDK mit vielen Versionen auf Docusaurus spürt die verwaiste Version als Suchmaschinenproblem (Google indexiert die falsche Momentaufnahme). Ein einversioniges SaaS auf GitBook mit AI Assistant spürt die neu geschriebene veraltete Seite als Vertrauensproblem. Beides sind Symptome derselben Ursache: Keines der Werkzeuge liest das laufende Produkt.

Wann Docusaurus die richtige Antwort ist

• Dein Team ist engineering-geführt, betreibt eine Build-Pipeline und behandelt Doku als Code neben der Codebasis.
• Du lieferst SDKs oder Bibliotheken in mehreren Versionen aus und brauchst Momentaufnahmen je Release, die das Versionsmodell ab Werk trägt.
• Du willst volle Kontrolle über Theme und Plugins über React-Swizzling, und die Decke der Anpassbarkeit zählt mehr als der Feinschliff ab Werk.
• Du priorisierst quelloffene MIT-Lizenzierung und die Möglichkeit, auf GitHub Pages, Netlify, Vercel oder eigener Infrastruktur zu hosten.
• Du kannst laufende Entwicklungsinvestition für Aufbau, Pluginauswahl und Pflege verkraften. Der Vergleich der Mintlify-Alternativen zeigt, wo Docusaurus im breiteren Markt für Entwicklerdoku landet.

Wann GitBook die richtige Antwort ist

• Zu deinem Team gehören schreibende Personen ohne Entwicklungshintergrund (Produktmanagement, technische Redaktion, Support-Engineering), die einen geschliffenen MDX-Editor ohne Git-Reibung brauchen.
• Du willst null Infrastrukturaufwand: anmelden, Space anlegen, die Doku ist live, ohne Build-Schritt und ohne Auslieferungspipeline.
• Du willst KI-Erstellung ab Werk (GitBook AI Assistant mit 500 Antworten in Ultimate, Agent für dokumentübergreifende Operationen).
• Du lieferst ein einversioniges SaaS-Produkt aus, bei dem Versionierung je Release überzogen ist und eine einfachere Historie über Varianten reicht.
• Du kannst die Preise pro Website und Person verkraften (65 plus 12 Dollar pro Person in Premium, 249 plus 12 Dollar pro Person in Ultimate) und bevorzugst planbare SaaS-Rechnungen gegenüber Entwicklungskosten.

Nutze keines von beiden als kundenseitiges Help Center für ein Produkt mit wöchentlichen Releases. Beide Werkzeuge wurden für Dokumentation im Releasetakt gebaut, nicht für Dokumentation im Deploy-Takt. Eines davon in den Help-Center-Dienst zu dehnen erzeugt genau die oben beschriebene Aktualitätslücke.

HappySupport sitzt neben Docusaurus oder GitBook, nicht anstelle von einem der beiden. Entwicklerdokumentation (API-Referenzen, SDK-Anleitungen, Integrationstutorials) gehört in das gewählte Entwicklerwerkzeug. Kundenseitige Anleitungen (Rundgänge im Produkt, an der Oberfläche verankerte Fehlerbehebung, Onboarding-Abläufe) gehören in ein Werkzeug, das das laufende Produkt liest. Welches Entwicklerwerkzeug du auch betreibst: Setze für die kundenseitige Artikelschicht HappySupport ein, damit sie zwischen Releases nicht mehr abdriftet.

Alternativen zu Docusaurus und GitBook

Wenn die Bewertung auf einer Seite eine Fehlpassung zeigt, lohnen je nach Anwendungsfall vier Alternativen einen ernsten Blick.

1. Mintlify. Markdown-first gehosteter SaaS-Wettbewerber zu GitBook, entworfen um API-first-Entwicklerdoku mit starker OpenAPI-Unterstützung.
2. ReadMe. OpenAPI-natives gehostetes SaaS mit Fokus auf Entwicklerportale (Schlüsselverwaltung, interaktiver API-Explorer, Anfragehistorie).
3. MkDocs. Quelloffener Generator für statische Websites auf Python-Basis, leichter als Docusaurus, beliebt für kleinere Doku-Bestände.
4. HappySupport. Gebaut für produktgetriebenes B2B-SaaS mit wöchentlichen Releases, wo bei kundenseitigen Anleitungen das Pflegeproblem das Editorproblem dominiert. Unten im Detail.

Für den breiteren Blick behandelt der Vergleich der besten Wissensdatenbank-Software nach Teamprofil das gesamte Feld aus Help-Center- und Doku-Werkzeugen, inklusive der Frage, wie sich Entwicklerwerkzeuge gegen dedizierte Wissensdatenbanken schlagen.

HappySupport in der Debatte Docusaurus gegen GitBook

HappySupport gehört zu einer anderen Kategorie von Help Center als Docusaurus oder GitBook. Die beiden Platzhirsche der Entwicklerdoku veröffentlichen Inhalte; HappySupport gleicht Inhalte mit dem Produktzustand ab. Die Architektur ruht auf zwei Teilen: HappyRecorder, einer Chrome-Erweiterung, die UI-Abläufe als DOM- und CSS-Selektoren statt als Pixel-Screenshots erfasst, und HappyAgent, einer GitHub-Sync-Schicht, die das Produkt-Repository auf Änderungen an dokumentierten Abläufen beobachtet und die betroffenen Artikel zur Aktualisierung markiert. Benennt das Engineering ein Feld um oder baut es einen Bildschirm um, tauchen die betroffenen Artikel automatisch mit einer Liste der genau anzuwendenden Änderungen auf, statt darauf zu bauen, dass der nächste Sprint die Drift bemerkt oder der GitBook AI Assistant eine veraltete Seite selbstsicher aus einer veralteten Codebasis neu schreibt. Das drückt die Pflegearbeit zusammen, die die Gesamtkosten über drei Jahre bei jeder kundenseitigen Anleitungs-Website dominiert, egal ob sie auf Docusaurus oder GitBook steht. Für Teams, die kundenseitige Anleitungen zu einem Produkt ausliefern, das sich schneller bewegt als sein Releasetakt, schließt HappySupport die Schleife, die die Entscheidung zwischen Docusaurus und GitBook offen lässt. Mehr dazu, was ein selbst aktualisierendes Help Center in der Praxis bedeutet, und dazu, warum die Wahl zwischen Docusaurus und GitBook die Veralterungsschicht verfehlt, die über das langfristige Vertrauen in jeden kundenseitigen Artikel entscheidet.