16. Mai 2025·8 Min
Wie man eine Website für SaaS‑Changelog und Release‑Notes erstellt
Erfahren Sie, wie Sie ein SaaS‑Changelog und Release‑Notes‑Portal erstellen: Struktur, Schreibtipps, Kategorien, Suche, Abonnements, SEO und Pflege‑Schritte.
Erfahren Sie, wie Sie ein SaaS‑Changelog und Release‑Notes‑Portal erstellen: Struktur, Schreibtipps, Kategorien, Suche, Abonnements, SEO und Pflege‑Schritte.
Eine SaaS‑Changelog‑Site ist eine öffentliche Seite (oder ein Mini‑Site), auf der Sie Produkt‑Updates in einem konsistenten, leicht durchsuchbaren Archiv veröffentlichen. Denken Sie daran als Ihre „was hat sich wann und warum geändert“-Zentrale — besonders wertvoll für Kund:innen, die Ihre App täglich nutzen.
Nutzer:innen suchen ein Changelog, wenn sich etwas anders anfühlt („Wo ist der Button hin?“), wenn sie entscheiden, ob sie eine Funktion aktivieren sollen, oder wenn sie bewerten, wie aktiv das Produkt gepflegt wird. Eine klare Update‑Historie reduziert Verwirrung und stärkt das Vertrauen in Ihr Produkt.
Diese Begriffe werden oft vermischt, haben aber leicht unterschiedliche Aufgaben:
Viele SaaS‑Teams veröffentlichen beides auf derselben Seite: eine kurze Zusammenfassung oben, mit ausklappbaren Details für diejenigen, die mehr wissen wollen.
Ein gut geführtes Changelog unterstützt mehrere Ziele gleichzeitig:
Entscheiden Sie, was für Kund:innen sichtbar sein soll und was intern bleibt. Öffentliche Einträge sollten sich auf Nutzer‑Auswirkungen konzentrieren, sensible Details vermeiden und klare, einfache Sprache verwenden. Interne Notizen können technischer sein (z. B. Infrastrukturänderungen) und gehören in interne Docs — nicht ins öffentliche Changelog.
Bevor Sie eine Vorlage wählen oder anfangen zu veröffentlichen, entscheiden Sie, für wen das Changelog ist. Eine einzelne „Release Notes Seite“ versucht oft, allen zu dienen — und hilft damit niemandem.
Die meisten SaaS‑Changelogs haben mindestens drei Zielgruppen mit unterschiedlichen Informationsbedürfnissen:
Sie können auch ein internes Publikum (Support, CS, Sales) haben. Selbst wenn das Changelog öffentlich ist, spart das Schreiben mit Blick auf interne Wiederverwendung Zeit: Support kann auf einen Eintrag verlinken, statt Erklärungen neu zu schreiben.
Passen Sie den Schreibstil an die Produktkomplexität und die Erwartungen der Nutzer:innen an:
Halten Sie die Stimme konsistent: wenn Ihr UI freundlich ist, kann das Changelog das auch sein — ohne zu lässig oder vage zu werden.
Eine öffentliche Produkt‑Updates‑Seite fördert Transparenz, Vertrauen und das Teilen von Links. Ein login‑pflichtiges Changelog ist besser, wenn Sie sensible Enterprise‑Funktionen, kundenspezifische Arbeiten oder sicherheitsrelevante Details veröffentlichen, die nicht indexiert werden sollten.
Wenn Sie unsicher sind, veröffentlichen Sie öffentlich, behalten aber bestimmte Einträge für authentifizierte Nutzer:innen vor.
Definieren Sie, wie „gut“ aussieht. Übliche Ziele sind weniger „Was hat sich geändert?“-Tickets, schnellere Übernahme neuer Funktionen und höhere Feature‑Nutzung. Wählen Sie ein oder zwei Metriken (Support‑Ticket‑Volumen, Aktivierungsrate, Changelog‑Seitenaufrufe) und prüfen Sie sie monatlich, damit das Changelog nützlich bleibt — und nicht nur beschäftigt aussieht.
Ein Changelog funktioniert nur, wenn Leute es schnell und zuverlässig finden können. Bevor Sie die erste Release Note schreiben, skizzieren Sie die Seiten und die Wege, die Nutzer:innen von Ihrer Hauptseite, der App und dem Help Center nehmen.
Für die meisten SaaS‑Produkte brauchen Sie keine komplexe Informationsarchitektur. Starten Sie mit einer kleinen Menge vorhersehbarer URLs:
Wenn Sie noch weniger Seiten bevorzugen, können Sie /subscribe in /changelog als sticky Call‑to‑Action integrieren.
Platzieren Sie Ihr Changelog dort, wo Nutzer:innen es erwarten:
Egal, was Sie wählen: Die URL sollte kurz, dauerhaft und leicht einzugegeben sein.
Fügen Sie einen klaren Link zum Changelog hinzu von:
Standardmäßig eine neueste‑zuerst Liste anbieten, damit Nutzer:innen sofort sehen, was neu ist. Unterstützen Sie dann das Browsen mit einfachen Filtern (z. B. nach Produktbereich oder „Bug fixes“ vs. „New“). Das balanciert Geschwindigkeit für Gelegenheitsleser:innen und Kontrolle für diejenigen, die eine bestimmte Änderung suchen.
Ein gutes Release‑Note‑Format ist vorhersehbar: Leser:innen sollten die ersten Zeilen scannen und sofort verstehen, was sich geändert hat, wann und ob sie betroffen sind. Legen Sie vor dem Schreiben eine kleine Menge Pflichtfelder fest und halten Sie sich bei jedem Post daran.
Wenn Sie diese Felder konsistent halten, wird Ihre Release‑Notes‑Seite zu einem verlässlichen Index, nicht zu einem unstrukturierten Stream von Ankündigungen.
Verwenden Sie Versionen, wenn Sie buildbasiert ausliefern oder Support eine präzise Referenz braucht (Mobile‑Apps, Desktop, API‑Versionen, Self‑Hosted). Ein Nutzer, der einen Bug meldet, kann sagen „Ich habe 2.14.3“, und Ihr Team kann ihn reproduzieren.
Verwenden Sie datumsbasierte Releases, wenn Sie kontinuierlich deployen und Änderungen hinter Feature‑Flags ausrollen. Viele SaaS‑Teams fügen intern noch eine Build‑Nummer hinzu, präsentieren öffentliche Releases aber nach Datum, weil das für Kund:innen einfacher zu verfolgen ist.
Ein Hybrid funktioniert gut: Zeigen Sie ein Datum als primären Anker und fügen Sie Version/Build in kleinerer Schrift für den Support hinzu.
Optionale Felder sind nützlich, aber nur, wenn sie gezielt bleiben:
Title
Date • Version • Category • Affected area (optional)
Summary (1–2 sentences)
Details
- Bullet 1
- Bullet 2
Rollout status (optional)
Known issues (optional)
Diese Struktur hält jeden Eintrag lesbar, erleichtert späteres Filtern und bereitet Sie auf konsistente Tags und Suche in den nächsten Schritten vor.
Ein Changelog ist am leichtesten zu überfliegen, wenn jedes Update zwei Fragen schnell beantwortet: Was für eine Änderung ist das? und Welcher Teil des Produkts ist betroffen? Kategorien und Tags tun genau das — ohne Leser:innen zu zwingen, jeden Beitrag zu lesen.
Verwenden Sie eine kleine Taxonomie, die die meisten Releases abdeckt und über die Zeit stabil bleibt:
Begrenzen Sie die Kategorien. Wenn eine Änderung nicht passt, passen Sie den Text an, bevor Sie eine neue Kategorie erfinden.
Tags sollten beschreiben, wo die Änderung stattgefunden hat, mit Begriffen, die Nutzer:innen bereits aus Ihrem UI und Ihren Docs kennen. Gängige Beispiele: Billing, API, Dashboard, Mobile.
Eine gute Regel: Jeder Eintrag bekommt 1–3 Tags. Genug, um zu filtern, nicht genug, um zu überfordern.
Tag‑Sprawl macht Filter nutzlos. Setzen Sie leichte Richtlinien:
Menschen suchen mit den Wörtern, die sie im Produkt sehen. Verwenden Sie dieselben Feature‑Namen in UI, Help‑Docs und Notes (z. B. „Saved Views“, nicht einmal „View Presets“ und an anderer Stelle „Saved Filters“). Erwägen Sie einen kurzen internen Namensleitfaden, damit alle mit derselben Wortwahl kommunizieren.
Release Notes sind kein Tagebuch dessen, was Ihr Team gebaut hat — sie sollen zeigen, was sich für Nutzer:innen geändert hat. Das Ziel: Menschen schnell den Nutzen vermitteln, ob sie betroffen sind und was (falls überhaupt) zu tun ist.
Ein guter Titel beantwortet in einer Zeile „Warum ist mir das wichtig?“
Schlecht: „Project Falcon rollout"
Besser: „Schnellere Rechnungs‑Exporte (bis zu 3× schneller)"
Besser: „Neu: Dashboards mit View‑Only‑Links teilen"
Wenn Sie zusätzlichen Kontext brauchen, fügen Sie einen kurzen, nutzerzentrierten Untertitel hinzu: „Verfügbar für Pro‑ und Business‑Pläne."
Führen Sie mit 2–5 kurzen Bullets, damit Nutzer:innen schnell überblicken können. Danach einen Details‑Abschnitt für das Was/Warum/Wie.
Beispielstruktur:
Details: Sie können jetzt einen sicheren Link erzeugen, um ein Dashboard zu teilen, ohne einen neuen Nutzer anzulegen. Links lassen sich jederzeit in Einstellungen → Sharing widerrufen.
Fügen Sie diese Angaben hinzu, wenn die Änderung Verhalten, Berechtigungen, Abrechnung oder Workflows betrifft.
Wer ist betroffen? Admins, die Sharing‑Einstellungen verwalten; alle, die geteilte Links erhalten.
Was muss ich tun? Standardmäßig nichts. Wenn Sie Link‑Sharing einschränken möchten, deaktivieren Sie „Public links“ in Einstellungen → Sharing.
Schreiben Sie in Nutzerbegriffen, nicht in internen Projektbezeichnungen. Ersetzen Sie „migrated to v2 pipeline“ durch „Uploads sind zuverlässiger“ (und erklären Sie kurz, wie sich das Nutzererlebnis ändert). Wenn Sie einen technischen Begriff nennen müssen, definieren Sie ihn in einem Satz.
Priorisieren Sie Klarheit über Vollständigkeit: Wenn etwas für Nutzer:innen nicht handlungsrelevant oder sinnvoll ist, lassen Sie es weg.
Ein Changelog ist leicht zu lesen, wenn Sie fünf Beiträge haben. Mit fünfzig wird es „Ich weiß, dass Sie es ausgeliefert haben… aber wo ist es?“ Suche und Browsing‑Tools halten Ihre Release‑Notes‑Seite nützlich — besonders für Support‑Teams, Kund:innen, die Ihr Produkt evaluieren, und alle, die später eine bestimmte Fehlerbehebung finden wollen.
Fügen Sie ein prominentes Suchfeld oben in der Changelog‑Liste hinzu. Priorisieren Sie die Suche in Titeln, Tags und dem ersten Absatz jedes Eintrags. Erwägen Sie das Hervorheben von Treffern und das Unterstützen häufiger Abfragen wie Feature‑Namen, Integrationen („Slack“) oder Fehlercodes.
Wenn Ihr Changelog mehrere Produkte oder Module hat, erlauben Sie die Suche innerhalb eines ausgewählten Produktbereichs, um Rauschen zu reduzieren.
Filter sollten das Vokabular Ihrer Nutzer:innen widerspiegeln, nicht die internen Team‑Bezeichnungen.
Nützliche Steuerungen:
Machen Sie Filter nach Möglichkeit multi‑select und platzieren Sie einen deutlichen „Alles löschen“‑Button.
Für längere Release Notes fügen Sie Ankerlinks oben hinzu (z. B. New features, Improvements, Fixes). Außerdem „Link kopieren“‑Anker an Überschriften ermöglichen es dem Support, Nutzer:innen direkt auf den relevanten Abschnitt zu verweisen.
Nutzen Sie Pagination oder „Mehr laden“ nach einer angemessenen Anzahl von Beiträgen (10–20) und zeigen Sie die Gesamtanzahl an. Halten Sie Seiten schnell: serverseitiges Rendern der Liste, Lazy‑Loading schwerer Elemente und vermeiden Sie komplexe clientseitige Filter, die bei großen Archiven blockieren. Schnelle Ladezeiten sind nicht nur nett — sie machen das Browsen vertrauenswürdig.
Ein Changelog ist am nützlichsten, wenn Leute nicht daran denken müssen, regelmäßig nachzusehen. Abonnements verwandeln Ihr Release‑Notes‑Portal in einen leichtgewichtigen Kommunikationskanal — ohne Nutzer:innen auf Social Media oder in Support‑Tickets zu treiben.
Streben Sie drei Optionen an:
Platzieren Sie klare CTAs oben auf der Seite (über der Eintragsliste): „Subscribe“ und „View latest updates.“ Wenn Sie ein dediziertes Updates‑Index haben, verlinken Sie es ebenfalls (z. B. /changelog).
Wenn Sie es unterstützen, bieten Sie Immediate, Weekly digest und Monthly digest an. Immediate eignet sich für kritische Änderungen und schnelllebige Produkte; Digests sind besser für vielbeschäftigte Stakeholder.
Abonnements sind wertvoller, wenn Nutzer:innen filtern können, was sie erhalten. Wenn Ihr Changelog Tags oder Kategorien nutzt (z. B. Billing, API, Security, Mobile), lassen Sie Abonnent:innen die Bereiche wählen, die sie interessieren — und erklären Sie in der E‑Mail, wie sie die Auswahl später anpassen können.
Wenn Sie einen Feed anbieten, halten Sie ihn vorhersehbar und leicht merkbar, z. B. /rss (oder /changelog/rss). Verlinken Sie ihn neben dem Subscribe‑Button und kennzeichnen Sie ihn klar („RSS feed“), sodass auch nicht‑technische Nutzer:innen wissen, dass er optional ist.
Ein Changelog hilft nur, wenn Leute es finden — über Suchmaschinen, Ihre In‑App‑Links und sogar „site:yourdomain.com“‑Abfragen aus dem Support. Gutes SEO hier ist kein Marketingtrick; es ist Klarheit und Konsistenz.
Behandeln Sie jede Release Note als eigene Seite mit einem beschreibenden Titel, der zu Suchanfragen passt (und den Nutzer:innen in Tabs auffällt). Verwenden Sie saubere, lesbare URLs, die später nicht geändert werden.
Beispiel:
/changelog/new-permissions-controlsFügen Sie eine eindeutige Meta‑Description pro Beitrag hinzu. Kurz und klar: was sich geändert hat, wer betroffen ist und der Hauptnutzen.
Ihre Changelog‑Seite sollte eine klare Struktur haben:
Zeigen Sie immer ein sichtbares Veröffentlichungsdatum an (und verwenden Sie einheitliches Format). Suchmaschinen und Nutzer:innen verlassen sich gleichermaßen auf dieses Signal für Aktualität und Kontext.
Auch kleine Releases sollten zwei Fragen beantworten: was hat sich geändert und warum ist es wichtig. Wenn eine Einrichtung nötig ist, verlinken Sie auf begleitende Docs (relativ), z. B. /docs/roles-and-permissions oder /guides/migrate-api-keys.
Erstellen Sie eine Changelog‑Indexseite (z. B. /changelog), die Releases mit Titeln, Daten, kurzen Zusammenfassungen und Pagination auflistet. Das hilft beim Crawlen, macht ältere Updates auffindbar und verhindert, dass wertvolle Notizen in einem unendlichen Scroll verschwinden.
Ein Changelog ist nur nützlich, wenn Menschen es schnell scannen, verstehen und ohne Hindernisse navigieren können. Gutes Design ist hier nicht Dekoration — es ist Klarheit.
Verwenden Sie gut lesbare Typografie: angenehme Schriftgröße (16–18px für Fließtext), klare Zeilenhöhe und starken Kontrast zwischen Text und Hintergrund. Release Notes enthalten oft dichte Informationen; großzügiger Abstand hilft beim Scannen von Überschriften, Daten und Bullet‑Points.
Halten Sie Überschriften konsistent (z. B. Version/Datum → Zusammenfassung → Details). Vermeiden Sie lange, voll breite Absätze; kurze Textblöcke sind auf Desktop und Mobil leichter zu lesen.
Machen Sie das Changelog ohne Maus benutzbar. Stellen Sie sicher, dass alle interaktiven Elemente — Suche, Filter, Tag‑Chips, „Mehr laden“ und Pagination — mit der Tab‑Taste in logischer Reihenfolge erreichbar sind.
Verwenden Sie zugängliche Labels für Links und Buttons. „Read more“ sollte zu „Mehr über API‑Verbesserungen lesen“ werden, damit es auch außerhalb des Kontexts Sinn ergibt. Bei Icon‑Only‑Buttons (z. B. Filter‑Icon) ein aria‑label hinzufügen.
Wenn Sie Screenshots einbinden, ergänzen Sie Alt‑Text, der beschreibt, was sich geändert hat, nicht wie das Bild aussieht (z. B. „Neuer Toggle für jährliche Pläne in den Abrechnungseinstellungen"). Vermeiden Sie text‑only Bilder: wenn die einzige Möglichkeit, das Update zu lesen, ein Screenshot ist, sind viele Nutzer:innen ausgeschlossen.
Verwenden Sie eindeutige Datumsangaben wie 2025-12-26. Das verhindert Verwirrung bei globalen Nutzer:innen und hilft Support‑Teams, Releases genau zu referenzieren.
Ihre Filter und Tabellen müssen auf kleinen Bildschirmen funktionieren. Bevorzugen Sie responsive Layouts, in denen Filter in ein Panel einklappen, Tags sauber umbrechen und Tabellen bei Bedarf in Karten gestapelt werden. Wenn Nutzer:innen „Bug fixes“ auf dem Handy nicht schnell finden, glauben sie, das Changelog sei verwaist.
Ein Changelog baut nur Vertrauen auf, wenn es verlässlich ist. Das heißt nicht, dass es häufig sein muss — es bedeutet, Nutzer:innen sollten wissen, was sie erwarten können: wie Einträge geschrieben werden, wer absegnet und was passiert, wenn sich etwas nach der Veröffentlichung ändert.
Ihr Workflow beginnt mit der Plattform:
Wählen Sie das Tool, das zu den Gewohnheiten Ihres Teams passt. Das „beste“ Tool ist das, das Sie wirklich bei jedem Release nutzen.
Wenn Sie von Grund auf neu bauen, kann eine vibe‑coding Plattform wie Koder.ai die Initialimplementierung beschleunigen: Sie beschreiben die gewünschten Seiten (z. B. /changelog, Suche, Tags, RSS, E‑Mail‑Subscribe`) im Chat und generieren ein funktionierendes React‑Frontend mit Go + PostgreSQL Backend. Das ist nützlich, wenn Sie ein maßgeschneidertes Changelog ohne Wochen an Engineering‑Aufwand wollen.
Halten Sie Stufen explizit, damit nichts im Kopf von jemandem hängen bleibt. Ein gängiger, leichter Ablauf ist:
Draft → Review → Approve → Publish → Update (if needed)
Schreiben Sie kurz auf, was jede Stufe bedeutet (ein Satz reicht) und wo Arbeit passiert (Doc, Issue, CMS‑Draft, Pull Request). Konsistenz ist wichtiger als Formalismus.
Bei phasenweisen Releases klar reflektieren:
Das verhindert „Ich habe die Funktion nicht“‑Tickets und reduziert Frust.
Korrekturen sind normal — stille Umschreibungen nicht. Entscheiden Sie:
Benennen Sie Rollen, damit das Changelog nicht „Jeder’s Aufgabe“ wird (und deshalb niemand zuständig ist): Wer schreibt, wer genehmigt und wer Kategorien/Tags pflegt.
Ein Changelog rechtfertigt seinen Aufwand nur, wenn es genutzt wird — und wenn es über die Zeit vertrauenswürdig bleibt. Ein leichtes Messkonzept und eine einfache Pflege‑Routine helfen, zu sehen, was Nutzer:innen interessiert, Support‑Last zu verringern und ältere Notizen sauber zu halten.
Starten Sie mit wenigen, handlungsfähigen Signalen:
Wenn Sie einen „What’s new“‑Link im Produkt haben, messen Sie die Klickrate und welche Einträge geöffnet werden.
Ihr Changelog kann wiederholte Fragen reduzieren — wenn es diese klar beantwortet. Nach jedem größeren Release beachten Sie:
Wenn das Ticket‑Volumen nicht sinkt, ist es wahrscheinlich ein Schreibproblem (fehlender Kontext, unklare Auswirkungen) oder ein Auffindbarkeitsproblem (Nutzer:innen finden die Notiz nicht).
Jeder Eintrag sollte Leser:innen einen nächsten Schritt bieten:
Halten Sie Feedback leichtgewichtig. Ein offenes Textfeld übertrifft oft komplexe Umfragen.
Einmal im Monat (oder vierteljährlich bei kleineren Produkten):
Löschen Sie Historie nicht. Stattdessen:
Ein gut gepflegtes Archiv stärkt Glaubwürdigkeit — und spart Ihrem Team das wiederholte Erklären derselben Änderungen.
Eine SaaS-Changelog-Seite ist eine öffentliche Seite (oder eine kleine Website), die ein fortlaufendes, leicht durchsuchbares Archiv von Produkt‑Updates enthält — was sich geändert hat, wann und kurz, warum es wichtig ist. Sie hilft Nutzer:innen zu prüfen, ob etwas ein Fehler oder eine bewusste Änderung ist, und signalisiert, dass das Produkt aktiv gepflegt wird.
Changelog‑Einträge sind normalerweise kurz und gut scannbar (z. B. Added, Improved, Fixed, Deprecated) und beantworten die Frage „Was wurde ausgeliefert?“. Release Notes liefern zusätzlichen Kontext und Handlungsempfehlungen — wer betroffen ist, wie die Änderung genutzt wird und ob Maßnahmen nötig sind — und beantworten „Wie wirkt sich das auf mich aus?“. Viele Teams veröffentlichen beides auf derselben Seite: eine Zusammenfassung zuerst und darunter aufklappbare Details.
Ein gut gepflegtes Changelog kann:
Wenn Sie nur eine Kennzahl messen, starten Sie mit dem Ticket‑Volumen nach größeren Änderungen.
Die meisten Produkte haben mehrere Zielgruppen:
Schreiben Sie zuerst für die primäre Zielgruppe und fügen Sie bei Bedarf optionale Abschnitte wie „Wer ist betroffen?“ hinzu.
Standardmäßig auf öffentlich setzen, wenn Transparenz und teilbare Links wichtig sind; auf login‑geschützt setzen, wenn Hinweise sensible Enterprise‑Funktionen, kundenspezifische Arbeiten oder sicherheitsrelevante Details enthalten, die nicht indexiert werden sollten.
Ein pragmatischer Kompromiss: das Hauptchangelog öffentlich lassen und einzelne Beiträge als authentifiziert markieren.
Halten Sie die Struktur einfach und einprägsam:
Verlinken Sie es außerdem im Footer, im In‑App‑Hilfemenü und auf der Hilfecenter‑Startseite, damit Nutzer:innen es schnell finden.
Ein vorhersehbares „Always include“ Set sieht typischerweise so aus:
Verwenden Sie Versionen, wenn der Support Präzision braucht (Mobile/Desktop‑Apps, APIs, Self‑Hosted), damit Nutzer:innen sagen können „Ich bin auf 2.14.3“. Verwenden Sie datumsbasierte Releases, wenn Sie kontinuierlich deployen und Änderungen hinter Feature‑Flags ausrollen.
Eine gute Kombination ist Datum zuerst für Lesbarkeit, mit Build/Version in kleinerer Schrift für den Support.
Starten Sie mit einer kleinen, stabilen Kategorieauswahl (z. B. New, Improved, Fixed, Deprecated, Security) und fügen Sie Produktbereich‑Tags hinzu, die dem UI‑Vokabular entsprechen (Billing, API, Dashboard, Mobile).
Um Tag‑Wildwuchs zu vermeiden:
Bieten Sie mehrere Abonnementwege an:
Wenn möglich, lassen Sie Nutzer:innen zwischen , und wählen und erlauben Sie tag‑/kategoriebasierte Präferenzen, damit Updates relevant bleiben.
Konsistenz verwandelt Ihr Changelog in ein verlässliches Index statt in einen Strom von Ankündigungen.