Changelog-Seite bauen: Einträge, Tags, RSS und „Neu bei uns“

Eine Changelog-Seite ist eine datierte Liste dessen, was sich in deinem Produkt geändert hat, neueste zuerst, geschrieben für die Menschen, die es nutzen. Um eine zu bauen, brauchst du Einträge mit Datum, klarem Titel, kurzer Erklärung und einem Tag (Neu, Verbessert, Behoben), eine Seite, die sie auflistet, eine eigene URL pro Eintrag und idealerweise einen RSS-Feed sowie eine Möglichkeit, Nutzern mitzuteilen, dass es etwas Neues gibt. Es gehört zu den einfachsten Dingen, die du bauen kannst. Die wichtigste Entscheidung ist, wo die Einträge liegen: als Dateien in deiner Website oder in einer Datenbank mit Admin-Seite.

Warum ein Changelog sich lohnt

Ein Changelog zeigt Kunden und Interessenten, dass das Produkt gepflegt wird. Support und Vertrieb haben einen Link, den sie schicken können, wenn jemand fragt: „Kann es schon X?“. Außerdem ist es ein Ort, um Feedback abzuschließen: Wenn eine gewünschte Funktion erscheint, verweist du die Leute auf den Changelog-Eintrag. Betreibst du ein Feedback-Portal für Kunden, verlinke ausgelieferte Wünsche direkt auf ihre Einträge.

Ein Changelog ist nicht dein interner Commit-Verlauf. „Abrechnungsdienst refaktoriert“ bedeutet einem Nutzer nichts. „Rechnungen zeigen jetzt die USt-Nummer deines Unternehmens“ dagegen schon.

Was die Seite braucht

Inhalt pro Eintrag

Seiten

• Changelog-Übersicht: neueste zuerst, mit Tag-Filtern und einfacher Seitennummerierung oder „Mehr laden“.
• Eintragsseite: ein Eintrag pro URL, damit er verlinkt und geteilt werden kann.
• RSS- oder Atom-Feed: damit Leute und Tools Updates ohne E-Mail verfolgen können.
• Admin-Seite (nur bei der Datenbankvariante): Einträge schreiben, Vorschau, planen und veröffentlichen.

Extras in der App

• „Neu“-Badge: ein Punkt an einem Menüeintrag, wenn es Einträge gibt, die der Nutzer noch nicht gesehen hat. Speichere das Datum des zuletzt geöffneten Eintrags, pro Nutzer oder im Browser.
• E-Mail-Zusammenfassung: eine Übersicht für Nutzer, die zustimmen. Dafür brauchst du einen Versanddienst; siehe wie du E-Mails aus deiner App verschickst.

Die wichtigste Entscheidung: Dateien oder Datenbank

Einträge als Dateien in der Website

Jeder Eintrag ist eine Markdown-Datei im Projekt. Einen Eintrag zu veröffentlichen heißt, eine Datei hinzuzufügen und neu zu deployen. Das ist der einfachste und robusteste Ansatz: keine Datenbank, keine Admin-Anmeldung, nichts abzusichern, und Seiten können vorgerendert werden, damit sie schnell laden und Suchmaschinen sie leicht lesen.

Er passt zu Teams, in denen die Schreibenden damit klarkommen, einen KI-Builder zu bitten oder eine Datei zu bearbeiten.

Einträge in einer Datenbank mit Admin-Seite

Die Einträge liegen in einer Tabelle, und eine private Admin-Seite erlaubt es jedem im Team, zu schreiben, Vorschau zu sehen, zu planen und zu veröffentlichen. Das passt, wenn Marketing oder Support Updates schreibt oder wenn du zeitgesteuertes Veröffentlichen oder Einträge für bestimmte Zielgruppen willst (zum Beispiel Enterprise-Funktionen nur Enterprise-Kunden zeigen).

Der Preis ist mehr Aufwand beim Bauen und Pflegen: eine Admin-Anmeldung, Bild-Uploads und die Sicherstellung, dass die öffentlichen Seiten weiterhin für Suchmaschinen lesbar sind, was eine Seite, die Einträge erst im Browser lädt, nicht unbedingt ist.

Einträge schreiben, die Leute lesen

• Mit dem Nutzen beginnen. „Berichte nach Excel exportieren“ schlägt „Neues Exportmodul“.
• Sag, wer es bekommt. Alle Tarife, nur Pro, wird diese Woche ausgerollt.
• Zeig es. Ein Screenshot oder ein kurzer Clip.
• Kleine Korrekturen bündeln. Ein wöchentlicher Eintrag „Korrekturen und Verbesserungen“ mit Aufzählungspunkten verhindert, dass die Seite überflutet wird.
• Sei ehrlich bei Entfernungen. Wenn etwas wegfällt, sag wann und was man stattdessen nutzt.

Ein erster Prompt, der funktioniert

Füge unserer Website ein öffentliches Changelog unter /changelog hinzu. Jeder Eintrag ist eine Markdown-Datei mit Titel, Datum, Tag (Neu, Verbessert oder Behoben), optionalem Titelbild und Text. Die Übersichtsseite listet Einträge neueste zuerst mit Datum, Tag und dem ersten Absatz, hat Tag-Filterbuttons und zeigt 10 Einträge pro Seite. Jeder Eintrag hat eine eigene Seite unter /changelog/<slug> mit einem passenden Seitentitel und einer Beschreibung für Suchmaschinen. Füge einen RSS-Feed unter /changelog/rss.xml hinzu. Erstelle drei Beispieleinträge. Passe das bestehende Website-Design an, halte es auf dem Handy gut lesbar und rendere die Seiten vor, damit sie schnell laden.

Für die Datenbankvariante ersetzt du den ersten Satz durch: „Speichere Einträge in einer Datenbank mit Entwurfs- und Veröffentlichungsstatus und einem Veröffentlichungsdatum, und füge eine passwortgeschützte Admin-Seite hinzu, um sie zu schreiben, in der Vorschau zu sehen und zu veröffentlichen.“

Build-Schritte

1. Dateien oder Datenbank entscheiden anhand der Tabelle oben.
2. Übersichts- und Eintragsseiten bauen mit ein paar Beispieleinträgen.
3. Tags und Filter hinzufügen.
4. RSS-Feed hinzufügen und von der Seite aus verlinken.
5. Seitentitel, Beschreibungen und einen Sitemap-Eintrag für jeden Eintrag ergänzen. Unser Leitfaden zu SEO für mit KI gebaute Websites deckt die Grundlagen ab.
6. Admin-Seite und Anmeldung, falls du den Datenbankweg gewählt hast.
7. „Neu“-Badge in deiner App.
8. Echte Einträge für die letzten Monate schreiben, damit die Seite nicht leer startet.

Häufige Fehler

• Commit-Nachrichten kopieren. Schreib für Nutzer, nicht für Entwickler.
• Eine riesige Seite ohne URLs pro Eintrag. Niemand kann auf eine bestimmte Änderung verlinken, und Suchmaschinen sehen eine Seite statt vieler.
• Updates hören nach einem Monat auf. Ein Changelog, das seit einem Jahr nicht aktualisiert wurde, wirkt wie ein aufgegebenes Produkt. Lege einen Rhythmus fest, den du halten kannst.
• Einträge nur im Browser laden. Suchmaschinen und Link-Vorschauen sehen dann womöglich eine leere Seite. Vorrendern oder auf dem Server rendern.
• Störungen mischen. Ausfälle gehören auf eine Statusseite, nicht ins Changelog.

Wann ein gehostetes Changelog-Tool die bessere Wahl ist

Es gibt gehostete Changelog- und Produkt-Update-Tools, manche gebündelt mit Feedback-Boards oder In-App-Widgets. Sie lohnen sich, wenn du ein Pop-up in der App, Zielgruppen-Steuerung und Analysen ohne Eigenbau willst oder wenn dein Team bereits für ein Tool mit Changelog zahlt. Auch die Software für deinen Blog oder dein Hilfecenter hat vielleicht schon ein passendes Format.

Selbst bauen lohnt sich, wenn du das Changelog auf deiner eigenen Domain, in deinem eigenen Design und vollständig indexierbar willst. Für eine einfache Liste datierter Beiträge ist das nicht viel Arbeit.

Mit Mythex bauen

In Mythex kannst du den Agenten bitten, ein Changelog zu einem bestehenden Projekt hinzuzufügen oder es als eigene kleine Website zu bauen, und du siehst es in der Live-Vorschau während des Bauens. Die dateibasierte Variante braucht keine Datenbank. Wählst du die Admin-Variante, ergänzt der Agent eine eigene Postgres-Datenbank, sobald Einträge gespeichert werden müssen (oder tippe /database), und Screenshots landen im Dateispeicher des Projekts. Die Admin-Anmeldung fügst du mit deinem eigenen Auth-Ansatz hinzu (Rezept Anmeldung).

Neue Mythex-Apps sind oft clientseitig gerenderte Single-Page-Apps, die laut SEO-Rezept für Suchmaschinen schwächer sind. Verlange deshalb statische oder vorgerenderte Changelog-Seiten, wenn Einträge in der Suche gefunden werden sollen. Dasselbe Rezept behandelt Titel, Beschreibungen und Sitemaps. Als Ausgangspunkt mit eingebautem Changelog eignet sich die Vorlage Produktwissens-Hub.

Fragen