Shipping ohne Sichtbarkeit: dein bestes Marketing liegt im Git-Log
«Wir shippen ständig, aber niemand merkt es»: Diesen Satz höre ich von SaaS-Teams öfter als jede Feature-Frage. Das Team liefert jede Woche, die Releases stapeln sich im Git-Log, und nach außen wirkt das Produkt wie eingefroren. Der letzte Blogartikel: acht Monate alt. Die Produktseite: Stand vom Launch.
Dabei existiert der Beweis für deine Entwicklungsgeschwindigkeit längst, er muss nur sichtbar werden. Das Werkzeug dafür heißt Changelog und kostet dich pro Release rund zwanzig Minuten Schreibarbeit. In diesem Artikel zeige ich dir, wer Changelogs wirklich liest, welches Format funktioniert und warum eine eigene /changelog-Route dem Drittanbieter-Widget meist überlegen ist.
Wer dein Changelog liest: Kunden, Prospects und Maschinen
Vorab eine Begriffsklärung: Ein Changelog ist die chronologische, datierte Liste deiner Produktänderungen, neuester Eintrag zuerst. Release Notes sind der Text zu einem einzelnen Release. In der Praxis laufen beide Begriffe auf dieselbe öffentliche Seite hinaus. Diese Seite hat drei Lesergruppen, und nur eine davon ist dir vermutlich bewusst:
- Bestandskunden: Sie zahlen jeden Monat und fragen sich zuweilen, wofür. Jeder Eintrag beantwortet die Frage «Entwickelt sich das Produkt weiter?», bevor sie beim Renewal auf den Tisch kommt.
- Prospects: Laut einer im März 2026 veröffentlichten Gartner-Umfrage bevorzugen 67 Prozent der B2B-Käufer einen Kaufprozess ohne Vertriebskontakt. Diese Käufer prüfen selbst, ob dein Produkt lebt — ein Changelog mit Einträgen aus dem laufenden Monat ist der schnellste Beleg.
- Google und KI-Suchen: Frische, datierte, präzise formulierte Inhalte sind genau das Material, das Suchmaschinen und KI-Assistenten zitieren. Dazu weiter unten mehr.
Für Prospects ist das Changelog damit Teil deiner Conversion-Strecke: ein Vertrauenssignal auf dem Weg zum Trial, genau wie die Trial- und Demo-Seiten selbst. Wer beides pflegt, verkauft an Selbstbediener, ohne dass ein Vertriebler tippen muss.
Ein Release, von dem niemand erfährt, ist für den Markt nie passiert.
Das Format: Nutzen statt Ticketnummer
Die meisten Changelogs scheitern nicht an der Disziplin, sondern am Format: Sie lesen sich wie ein Ticket-Export. «Fix: NPE im InvoiceService» sagt deinem Kunden nichts. Die Referenz für den Aufbau liefert der Standard Keep a Changelog, dessen erster Grundsatz lautet: Changelogs sind für Menschen, nicht für Maschinen. Vier Zutaten machen den Unterschied.
Nutzen formulieren
Schreibe jeden Eintrag aus Sicht des Nutzers: was er jetzt kann oder was er sich spart. Aus «Async-Export refactored» wird «Große Exporte blockieren dein Browserfenster nicht mehr: Du bekommst eine E-Mail, sobald die Datei fertig ist». Das Muster dahinter: erst der Nutzen in einem Satz, dann bei Bedarf ein Satz zum Wie. Ticketnummern bleiben im Tracker.
Screenshots und kurze Videos
Ein Screenshot pro Feature genügt, aber er muss sein: Menschen scrollen Changelogs, sie lesen sie nicht Wort für Wort. Linear macht es vor: großes Bild, ein erklärender Absatz, fertig. Für Interaktionen lohnt ein kurzes Video oder GIF unter dreißig Sekunden. Faustregel: Was du im Sprint-Review zeigst, gehört als Bild in den Eintrag.
Datum und Rhythmus
Jeder Eintrag trägt ein Datum, der neueste steht oben. Wichtiger als die Frequenz ist die Regelmäßigkeit: Lieber alle zwei Wochen ein gebündelter Eintrag als drei Meldungen in einer Woche und danach ein Vierteljahr Stille. Kleine Fixes sammelst du zu einem Wochen- oder Monatseintrag, statt jeden Hotfix einzeln zu melden.
Kategorien
Keep a Changelog empfiehlt sechs Änderungstypen: Added, Changed, Deprecated, Removed, Fixed, Security. Für ein Marketing-Changelog reichen meist drei: Neu, Verbessert, Behoben. Kategorien machen die Seite scanbar und liefern dir nebenbei auswertbare Daten — etwa die Antwort auf die Frage, wie viel echtes Neuland dein Team dieses Quartal geliefert hat.
Changelog als SEO- und GEO-Asset
Zum Thema Sichtbarkeit: Ein gepflegtes Changelog ist eine Seite, die sich wöchentlich ändert, auf einer Website, die sich sonst selten ändert. Solche Aktualitätssignale registrieren Suchmaschinen. Dazu kommen Long-Tail-Treffer: Wer nach deinem Produktnamen plus Feature sucht, landet auf dem passenden Eintrag statt im Leeren.
Für KI-Suchen wiegt das schwerer. ChatGPT, Perplexity und Google AI Overviews beantworten Fragen wie «Kann Tool X inzwischen Y?» aus dem, was sie zitieren können: datierte, klar strukturierte Aussagen mit Quelle. Ein Changelog-Eintrag mit Datum, Feature-Name und einem Satz Nutzen ist die zitierfähigste Textform deiner Website — das ist meine Einschätzung aus unseren GEO-Audits, keine Studie.
Messbar ist der Kanal trotzdem: In den Umami-Daten unserer eigenen Website tauchen ChatGPT und Perplexity seit Monaten als Referrer auf, also Besucher, die aus einer KI-Antwort heraus klicken. Sanity treibt die Maschinenlesbarkeit am weitesten: Jeder Changelog-Eintrag ist dort zusätzlich als Markdown-Datei abrufbar, ideales Futter für KI-Crawler (Stand September 2026).
Drei Handgriffe holen das Maximum heraus: eine eigene URL pro Eintrag statt einer endlosen Scroll-Seite, ein RSS-Feed für Abonnenten und Crawler, und sauberes HTML mit Datum im Markup. Wie sich das Changelog in die übrige Seitenarchitektur einfügt, liest du im Leitfaden zur SaaS-Website.
Eigene /changelog-Route oder Drittanbieter-Widget?
Die Standardlösung sind Dienste wie Canny, Beamer oder LaunchNotes: ein eingebettetes Panel in der App plus eine gehostete Changelog-Seite. Das ist in einer Stunde eingerichtet, hat aber einen Preis über die Abogebühr hinaus: Deine Inhalte liegen auf fremder Infrastruktur, und die SEO-Wirkung landet auf der Subdomain des Anbieters statt auf deiner Domain.
Ehrlich abgewogen: Ein Widget ist die richtige Wahl, wenn du vor allem In-App-Ankündigungen und Feedback-Voting willst und gerade keine Entwicklerkapazität frei hast. Bei Canny kostet das im Pro-Plan 79 US-Dollar pro Monat bei jährlicher Zahlung; der Gratis-Plan enthält das Changelog-Modul nicht (Stand September 2026).
| Kriterium | Eigene /changelog-Route | Drittanbieter-Widget |
|---|---|---|
| SEO-Wirkung | auf deiner Domain | auf der Subdomain des Anbieters |
| Design | dein Designsystem | Baukasten des Anbieters |
| In-App-Hinweis | selbst bauen | mitgeliefert |
| Feedback-Voting | selbst bauen | mitgeliefert |
| Laufende Kosten | keine, einmalig Entwicklungszeit | Canny Pro: 79 $/Monat (Stand 09/2026) |
| Wiederverwendung (Newsletter, Social, KI) | volle Kontrolle über die Rohdaten | Export je nach Anbieter |
Läuft deine Website ohnehin auf einem Headless CMS, ist die eigene Route wenig Arbeit: ein Dokumenttyp mit Titel, Datum, Kategorie, Text und Screenshot, dazu eine Listen- und eine Detailseite. In unserem Stack aus Sanity und Next.js ist das ein Tagesprojekt, kein Sprint. Denselben Hebel nutzt du für Hilfeseiten: Wie du Doku und Website aus einem CMS speist, zeigt der Schwesterartikel.
Der unterschätzte Vorteil der eigenen Route ist die Wiederverwendung. Jeder Eintrag liegt als strukturierter Datensatz in deinem CMS: Dieselbe Quelle füttert den Newsletter-Abschnitt «Neu diesen Monat», den LinkedIn-Post zum Release und die In-App-Meldung. Du schreibst einmal und spielst auf allen Kanälen aus — beim Widget hängt genau das am Export des Anbieters.
Drei Changelogs, die es vormachen
Alle drei Beispiele habe ich am 22. September 2026 geprüft; die genannten Daten sind dieser Stand.
- Linear (linear.app/changelog): der Maßstab der Branche. Großes Bild, klarer Nutzentext, darunter gebündelte Abschnitte für Fixes und Improvements. Rhythmus etwa wöchentlich bis vierzehntäglich; der jüngste Eintrag «Loops for product management» stammt vom 14. September 2026.
- Vercel (vercel.com/changelog): die Kurzform. Datum, Titel, zwei Sätze, Link auf Details, mehrere Einträge pro Woche; der jüngste erschien am 21. September 2026. Der Beweis, dass ein Changelog keine Redaktion braucht, sondern Takt.
- MOCO (mocoapp.com/blog): die DACH-Variante. Die Agentursoftware veröffentlicht Produktnews als deutschsprachige Blogartikel mit Screenshots, im Wochen- bis Zweiwochenrhythmus; «Quick Wins September 2026» erschien am 21. September 2026.
Was alle drei teilen: Datum, Nutzen-Sprache, Bildmaterial, eigene URL auf der eigenen Domain. Was keines von ihnen veröffentlicht: Ticketnummern.
Nächste Schritte
Du brauchst dafür kein Projekt, sondern einen Anfang. Mein Vorschlag für diese Woche: Schreib die letzten vier Releases nachträglich als Einträge auf, nach dem Muster Nutzen, Screenshot, Datum, Kategorie. Veröffentliche sie als schlichte /changelog-Seite. Ab dann gilt die Regel: kein Release ohne Eintrag — der Text entsteht im selben Pull Request wie das Feature.
Oder wir bauen es gemeinsam: Als Agentur für B2B-Websites setzen wir Changelog, Blog und Doku als Routen in einem CMS auf, damit jedes Release automatisch dort landet, wo Kunden, Prospects und KI-Suchen es sehen. Buch dir ein unverbindliches Erstgespräch: In 30 Minuten klären wir, welche Route deine Website zuerst braucht.
