# Changelog Vorlage für React: RSS, E-Mail und Permalinks
> Bau eine Changelog Vorlage in Next.js, die Nutzer zurückholt: datierte Releases nach Neu, Verbessert und Behoben, eine Seite pro Release, RSS und E-Mail-Abo.
- Autor: [Serban Rusu](https://wingo-ui.com/blog/authors/serban), Founder of Wingo UI
- Veröffentlicht: 6. Nov. 2026
- Kategorie: [Praxis: Screens und Apps](https://wingo-ui.com/de/blog/category/build)
- Lesezeit: 10 Min.
- Kanonische URL: https://wingo-ui.com/de/blog/changelog-page-template
- Englische Fassung: https://wingo-ui.com/blog/changelog-page-template
## Kurz gesagt
Eine Changelog Vorlage zeigt datierte Releases, die neuesten zuerst, gruppiert die Änderungen jedes Releases nach Neu, Verbessert und Behoben, gibt jedem Release einen Permalink und bietet RSS und eine E-Mail-Anmeldung an, damit Leute von selbst zurückkommen. In Next.js liegen die Releases in einer einzigen Datendatei, die die Seite, eine statische Seite pro Release und die RSS-Route gemeinsam lesen. Die Vorlage Changelog Page von Wingo UI rendert Liste, Filter und Abo-Zeile; Daten, Feed und Anmeldung schließt du selbst an.
Auf der Changelog-Seite prüft ein Käufer, ob sich dein Produkt noch bewegt, und ein Nutzer erfährt, dass das Feature, um das er gebeten hat, endlich da ist. An der zweiten Aufgabe scheitern die meisten: Niemand denkt daran, eine Seite zu besuchen, und das Release, an dem ihr einen Monat gearbeitet habt, lesen fünf Leute. Dieses Tutorial baut im Next.js App Router eine Changelog Vorlage, zu der Leute zurückkommen: datierte Releases, gruppiert nach Neu, Verbessert und Behoben, eine Seite pro Release, ein RSS-Feed und eine E-Mail-Anmeldung, alles aus einer einzigen Datendatei. Die UI ist unsere [Vorlage Changelog Page](https://wingo-ui.com/templates/changelog-page), wir sind also nicht neutral. Datenmodell, Routen und Feed funktionieren aber genauso mit jeder anderen React Changelog Komponente oder Vorlage für Release Notes.
## Was macht ein SaaS Changelog lesenswert?
Ein SaaS Changelog wird gelesen, wenn es sich leicht überfliegen und leicht verfolgen lässt. Beim ersten Punkt herrscht weitgehend Einigkeit. [Keep a Changelog 1.1.0](https://keepachangelog.com/en/1.1.0/) (geprüft am 6. November 2026) nennt die Grundsätze: für Menschen geschrieben, ein Eintrag für jede Version, Änderungen derselben Art zusammengefasst, Versionen, die man verlinken kann, die neueste zuerst und bei jeder ein Release-Datum, empfohlen im ISO-Format (`2026-11-06`).
Keep a Changelog gruppiert nach sechs Typen: Added, Changed, Deprecated, Removed, Fixed und Security. Das passt zu einer Bibliothek für Entwickler. Ein Produkt-Changelog, das Kunden lesen, lässt sich mit weniger Gruppen leichter überfliegen. Die [Changelog-Vorlage von Gleap](https://www.gleap.ai/blog/changelog-template) (aktualisiert am 27. September 2026, geprüft am 6. November 2026) stellt New, Improved und Fixed nach vorn, ergänzt Deprecated und Security und warnt, dass zu viele Labels ein Changelog schwerer lesbar machen. Wir gehen einen Schritt weiter und bleiben bei drei. So verteilen sich die sechs darauf:
| Typ bei Keep a Changelog | Gruppe im Produkt-Changelog | So schreibst du ihn |
|---|---|---|
| Added | Neu | Was Nutzer jetzt können, was vorher nicht ging |
| Changed | Verbessert | Was schneller, klarer oder einfacher geworden ist, in den Worten der Nutzer |
| Fixed, Security | Behoben | Das Symptom, das verschwunden ist; bei Sicherheitslücken die Auswirkung ohne Details zum Exploit |
| Deprecated, Removed | Zusammenfassung plus eine Zeile unter Verbessert | Zuerst in der Zusammenfassung des Releases nennen, mit Datum und Link zur Migration |
Der zweite Punkt, das Verfolgen, bekommt weniger Aufmerksamkeit. Als wir am 6. November 2026 nach „changelog page template“ gesucht haben, standen oben Vorlagen für Page Builder (Framer, Ceptile), ein Starter mit Next.js und MDX auf GitHub und Textformate für einen einzelnen Eintrag zum Kopieren. Sie kümmern sich darum, wie die Seite aussieht. Kaum etwas davon behandelt die drei Dinge, die Leser zurückholen: einen Link pro Release, der dauerhaft funktioniert, einen Feed und eine E-Mail, wenn etwas live geht.
## Wie installierst du die Changelog-Vorlage?
Ein Befehl kopiert die Vorlage und die Teile, die sie importiert. Sie ist ein Pro-Item, das Konto hinter der CLI braucht also Wingo UI Pro.
```bash
npx wingo-ui@latest add changelog-page
```
Du bekommst `components/templates/changelog-page.tsx` und `changelog-page-data.ts`, dazu alles, was die beiden nutzen: die kostenlose Marketing Section (für den Seitenhintergrund, die Überschrift und das E-Mail-Formular), Marketing Header und Footer, die [Segmented Control](https://wingo-ui.com/components/segmented-control) für den Filter New / Improved / Fixed, das [Badge](https://wingo-ui.com/components/badge) für die Gruppenlabels und den Tag Latest und die [Pagination](https://wingo-ui.com/components/pagination) für Load older releases. Ohne die Prop `releases` rendert die Vorlage acht Beispiel-Releases eines erfundenen Produkts namens Acme.
> Live-Demo (Changelog Page): Wähl im Filter Fixed und sieh zu, wie sich Liste und Release-Zahl ändern, dann scroll: Ab 768px bleibt die Versionsleiste neben dem Release stehen, das du gerade liest. Probier sie unter [Changelog Page](https://wingo-ui.com/templates/changelog-page) aus und installier sie mit `npx wingo-ui@latest add changelog-page`.
## Wie speicherst du Releases, damit Seite, Feed und E-Mails übereinstimmen?
In einer schlichten TypeScript-Datei. Die Seite, die Seiten pro Release, die RSS-Route und alles, was E-Mails verschickt, importieren sie. So kann ein Release nicht an einer Stelle auftauchen und an einer anderen fehlen.
```ts
// lib/changelog.ts
import type { ChangelogRelease } from "@/components/templates/changelog-page-data"
// neueste zuerst; date ist ein ISO-Tag, yyyy-mm-dd
export const releases: ChangelogRelease[] = [
{
version: "1.4.0",
date: "2026-11-03",
title: "Wiederkehrende Aufgaben",
summary: "Wiederhol jede Aufgabe täglich, wöchentlich oder nach eigenem Zeitplan.",
glyph: "repeat",
tone: "success",
changes: [
{ type: "new", text: "Wiederkehrende Aufgaben mit täglichem, wöchentlichem und eigenem Zeitplan.", href: "/docs/recurring-tasks" },
{ type: "improved", text: "Boards mit 500 Karten öffnen schneller." },
{ type: "fixed", text: "Fälligkeitsdaten verschieben sich über Zeitzonen hinweg nicht mehr um einen Tag." },
],
},
// ältere Releases darunter
]
// changelogAnchor aus der Vorlage, kopiert: ihr Modul ist "use client", Servercode kann es also nicht aufrufen
export const releaseSlug = (version: string) => `v${version.replace(/[^a-z0-9]+/gi, "-")}`
export const findRelease = (slug: string) => releases.find((release) => releaseSlug(release.version) === slug)
```
Der Typ-Import kostet auf dem Server nichts: Typen verschwinden beim Build, und `changelog-page-data.ts` hat ohnehin keine `"use client"`-Direktive, du könntest also auch `CHANGELOG_RELEASES` daraus importieren. Beim Slug-Helper ist das anders: `changelog-page.tsx` ist ein Client-Modul, und eine Server Component, die eine Funktion daraus aufruft, bekommt einen Fehler statt eines Strings. Kopierst du den Einzeiler, bleiben deine Slugs identisch mit den Ankern der Vorlage, und aus `1.4.0` wird überall `v1-4-0`.
`glyph` und `tone` wählen das gezeichnete Cover (die Glyph-Schlüssel stehen in `CHANGELOG_GLYPHS`: timeline, repeat, workflow, doc, chart, plug, cloud, shield, sparkles). Gib `cover` eine Bild-URL mit, wenn du stattdessen einen Screenshot zeigen willst.
## Wie renderst du die Changelog-Seite im App Router?
Teil sie in zwei Dateien auf, wie bei jeder Client-Vorlage: eine Server-`page.tsx` für die Metadaten und einen kleinen Client-Wrapper für alles, was eine Funktion ist (`linkComponent`, `onSubscribe`).
```tsx
// app/(marketing)/changelog/page.tsx
import type { Metadata } from "next"
import { ChangelogView } from "./changelog-view"
export const metadata: Metadata = {
title: "Changelog",
description: "Neue Features, Verbesserungen und Fixes in Northwind, Release für Release.",
alternates: {
canonical: "/changelog",
// ergänzt , damit Feedreader den Feed finden
types: { "application/rss+xml": "/changelog/rss.xml" },
},
}
export default function ChangelogRoute() {
return
}
```
```tsx
// app/(marketing)/changelog/changelog-view.tsx
"use client"
import type { CSSProperties } from "react"
import Link from "next/link"
import { ChangelogPage } from "@/components/templates/changelog-page"
import { releases } from "@/lib/changelog"
import { subscribeToChangelog } from "./actions"
export function ChangelogView() {
return (
{}}
labels={{
title: "Neu in Northwind",
description: "Neue Features, Verbesserungen und Fixes, die neuesten zuerst.",
}}
/>
)
}
```
Drei Props übersieht man leicht. Mit `header={false}` reserviert die Vorlage keinen Platz mehr für ihre eigene Sticky-Leiste. Gib die Höhe deines Headers also über `--topbar-offset` weiter, sonst rutscht die Versionsleiste darunter. Ohne `onLoadMore` wartet Load older releases 700 ms, um eine Anfrage vorzutäuschen; ein No-op macht den Button sofort, wenn die Daten lokal liegen. Und jeder sichtbare Text steckt in `labels`: Der Titel nennt Acme, und die Beschreibung verspricht jede Woche ein Release, bis du beides änderst.
## Warum braucht jedes Release eine eigene Seite?
Weil der Anker-Link bricht, sobald die Liste paginiert, und weil sich ein Release unter einer eigenen URL am leichtesten teilen lässt. Jedes Release auf der Seite hat eine `id` (`v1-4-0`), und die Versions-Pill verlinkt darauf. Die Seite rendert anfangs aber nur `pageSize` Releases (standardmäßig 4). Ein Link auf `/changelog#v1-0-0` aus einer alten E-Mail landet also oben auf einer Seite, auf der es dieses Release noch gar nicht gibt.
Eine statische Seite pro Release löst das und gibt RSS-Einträgen, E-Mails und Posts einen Link, der immer funktioniert. `ChangelogReleaseEntry`, der Teil, mit dem die Vorlage jedes Release rendert, zeigt eins auch für sich allein an:
```tsx
// app/(marketing)/changelog/[slug]/page.tsx
import type { Metadata } from "next"
import { notFound } from "next/navigation"
import { findRelease, releaseSlug, releases } from "@/lib/changelog"
import { ReleaseView } from "./release-view"
export const dynamicParams = false
export function generateStaticParams() {
return releases.map((release) => ({ slug: releaseSlug(release.version) }))
}
type Props = { params: Promise<{ slug: string }> }
export async function generateMetadata({ params }: Props): Promise {
const release = findRelease((await params).slug)
if (!release) return {}
return {
title: `${release.version}: ${release.title}`,
description: release.summary,
alternates: { canonical: `/changelog/${releaseSlug(release.version)}` },
}
}
export default async function ReleaseRoute({ params }: Props) {
const release = findRelease((await params).slug)
if (!release) notFound()
return
}
```
```tsx
// app/(marketing)/changelog/[slug]/release-view.tsx
"use client"
import Link from "next/link"
import { ChangelogReleaseEntry } from "@/components/templates/changelog-page"
import type { ChangelogRelease } from "@/components/templates/changelog-page-data"
import { NewsletterSection } from "@/components/blocks/newsletter-section"
import { subscribeToChangelog } from "../actions"
export function ReleaseView({ release, latest }: { release: ChangelogRelease; latest: boolean }) {
return (
{/* der Titel des Eintrags ist ein h2, die Seite braucht also trotzdem ein h1 */}
{`${release.version}: ${release.title}`}
)
}
```
Das Release ist reines JSON und gelangt deshalb problemlos aus der Server-Page in den Client-Wrapper. Achte auf `subscribers={0}`: Die [Newsletter Section](https://wingo-ui.com/components/newsletter-section) zeigt standardmäßig eine Beispielzahl von 12.400 Lesern. In einer Demo ist das in Ordnung, auf deiner Website ist es eine erfundene Zahl. Bei null wird diese Zeile ausgeblendet.
> Live-Demo (Newsletter Section): Gib eine E-Mail-Adresse ein und drück auf Subscribe: Eine ungültige Adresse zeigt einen Fehler, bei einer gültigen dreht sich kurz ein Spinner, dann wird das Formular zu einer Erfolgsmeldung. Auf dem Smartphone stehen Feld und Button in voller Breite untereinander. Probier sie unter [Newsletter Section](https://wingo-ui.com/components/newsletter-section) aus und installier sie mit `npx wingo-ui@latest add newsletter-section`.
## Wie fügst du einem Next.js-Changelog einen RSS-Feed hinzu?
Mit einem Route Handler, der dieselben `releases` liest und RSS 2.0 zurückgibt. Verlinke jeden Eintrag auf seine Release-Seite und pack die gruppierten Änderungen in die Beschreibung, damit Leser das ganze Release sehen, ohne ihren Feedreader zu verlassen.
```ts
// app/(marketing)/changelog/rss.xml/route.ts
import { releases, releaseSlug } from "@/lib/changelog"
export const dynamic = "force-static"
const SITE = "https://northwind.dev"
const GROUPS = [["new", "Neu"], ["improved", "Verbessert"], ["fixed", "Behoben"]] as const
const escape = (text: string) =>
text.replace(/&/g, "&").replace(//g, ">").replace(/"/g, """)
export function GET() {
const items = releases
.slice(0, 50)
.map((release) => {
const url = `${SITE}/changelog/${releaseSlug(release.version)}`
const body = GROUPS.map(([type, label]) => {
const changes = release.changes.filter((change) => change.type === type)
if (!changes.length) return ""
return `
${body}`)}`
})
.join("\n")
const xml = `
Northwind Changelog
${SITE}/changelog
Neue Features, Verbesserungen und Fixes in Northwind.
${items}
`
return new Response(xml, { headers: { "Content-Type": "application/rss+xml; charset=utf-8" } })
}
```
Die Beschreibung wird absichtlich zweimal escaped: einmal für den Text im HTML, einmal, damit das HTML selbst im XML gültig ist. Seit Next.js 15 werden `GET` Route Handler standardmäßig nicht gecacht, erst `force-static` macht den Feed zu einer Datei, die einmal pro Deploy gebaut wird. Mit aktivierten Cache Components lässt du diese Zeile weg: Ein Handler, der keine Request-Daten liest, wird ohnehin vorgerendert. Mittag UTC (`T12:00:00Z`) hält das Release für Leser zwischen UTC-12 und UTC+11 auf seinem Kalendertag; die Vorlage geht noch weiter und formatiert ihre Datumsangaben in UTC, sodass alle Besucher denselben Tag sehen. Ein Beispiel im echten Einsatz: Unser eigenes [Changelog](https://wingo-ui.com/changelog) funktioniert genau so, mit einer Seite pro Version und einem RSS-Feed. Betreibst du auch einen Blog, behandelt der [Beitrag zum Next.js Blog Template](https://wingo-ui.com/de/blog/nextjs-blog-template) einen JSON Feed neben RSS.
## Wie schließt du die E-Mail-Anmeldung an?
`onSubscribe` bekommt die getrimmte, bereits validierte E-Mail-Adresse. Das Formular zeigt einen Spinner, solange das Promise läuft, die Erfolgsmeldung, wenn es erfolgreich abschließt, und die Fehlermeldung, wenn es fehlschlägt. Der letzte Punkt ist wichtig: Eine Server Action, die `{ ok: false }` zurückgibt, schließt trotzdem erfolgreich ab, und der Besucher sieht „You're in“. Wirf stattdessen einen Fehler.
```ts
// app/(marketing)/changelog/actions.ts
"use server"
import { addSubscriber, sendConfirmation } from "@/lib/subscribers" // deine Datenbank und dein Mailer
export async function subscribeToChangelog(email: string) {
if (!/^[^\s@]+@[^\s@]+\.[^\s@]{2,}$/.test(email)) throw new Error("Ungültige E-Mail-Adresse")
const { token, alreadyConfirmed } = await addSubscriber(email, { list: "changelog" })
// Double Opt-in: an die Liste geht nichts raus, bis die Person auf den Bestätigungslink klickt
if (!alreadyConfirmed) await sendConfirmation(email, token)
}
```
Nutze Double Opt-in und antworte bei einer neuen, einer noch unbestätigten und einer bestehenden Adresse gleich, damit niemand über das Formular herausfinden kann, wer auf deiner Liste steht. Die Standard-Erfolgsmeldung sagt bereits „Check your inbox to confirm“ und passt damit zu diesem Ablauf. Wenn du ein Release veröffentlichst, schick pro Release eine kurze E-Mail mit Titel, Zusammenfassung und einem Link auf seine Seite. So wird die Seite pro Release zum Ziel jeder E-Mail, die du verschickst.
## Wie zeigst du in der App, was neu ist?
Die öffentliche Seite erreicht Leute, die nach ihr suchen. Angemeldete Nutzer erreichst du leichter: Zeig die letzten paar Releases direkt in der App, in einem Panel „Was ist neu“ oder im Hilfemenü. Eine komplette Changelog-Seite ist dort zu schwer; die [Timeline](https://wingo-ui.com/components/timeline) passt in ein Seitenpanel und liest dieselben Daten.
```tsx
// components/whats-new.tsx
"use client"
import { Timeline, type TimelineItemData } from "@/components/ui/timeline"
import { releases, releaseSlug } from "@/lib/changelog"
const items: TimelineItemData[] = releases.slice(0, 5).map((release) => ({
id: releaseSlug(release.version),
title: `${release.version}: ${release.title}`,
description: release.summary,
// Mittag UTC, damit ein Release vom 3. November in New York nie als 2. November erscheint
time: `${release.date}T12:00:00Z`,
tone: release.tone,
href: `/changelog/${releaseSlug(release.version)}`,
}))
export function WhatsNew() {
return
}
```
`timePosition="side"` stellt die Datumsangaben in eine eigene Spalte am Zeilenanfang, sobald die Timeline 512px breit ist, und schiebt sie in einem schmalen Panel oder auf dem Smartphone unter den Titel. Das ist eine Container Query, sie reagiert also auf die Breite des Panels. `timeFormat="date"` gibt den Tag aus; das Standardformat `relative` („vor 3 Tagen“) passt besser zu Activity Feeds als zu Releases. Jeder Titel verlinkt auf die Release-Seite.
## Welche Fehler passieren auf Changelog-Seiten häufig?
- **Commit-Messages als Einträge.** „fix tz offset in date util“ sagt einem Kunden nichts, „Fälligkeitsdaten verschieben sich über Zeitzonen hinweg nicht mehr um einen Tag“ dagegen schon. Beschreib das Symptom, das die Nutzer gesehen haben.
- **Bündeln.** Eine Änderung pro Zeile. Eine neue Integration und ein Fix in der Abrechnung sind zwei Einträge in zwei Gruppen.
- **Lange Pausen.** Ein Changelog, dessen neuester Eintrag fünf Monate alt ist, sagt einem Käufer genau das Gegenteil von dem, was du willst. Liefer kleine Releases aus und schreib sie gleich mit auf.
- **Tote Follow-Buttons.** Der RSS-Button der Vorlage zeigt standardmäßig auf `/changelog/rss.xml`. Bau die Route oder gib `rssHref=""` mit, um ihn auszublenden.
- **Beispielinhalte in Produktion.** Durchsuch die gerenderte Seite vor dem Launch nach Acme: Standardtitel, Beschreibung, Newsletter-Zahl und, falls du sie behältst, Header und Footer der Vorlage.
Für den Rest der Marketing-Website (Preise, Kontakt, Rechtliches, About) behandelt der [Guide zum SaaS Website Template](https://wingo-ui.com/de/blog/saas-website-template) jede Seite und zeigt, wie sie sich ein Layout teilen. Weitere Anleitungen Schritt für Schritt findest du in der Kategorie [Praxis: Screens und Apps](https://wingo-ui.com/de/blog/category/build). Die Support-Seite derselben Website, mit Suche, Themen und Artikeln, behandelt unser Guide zum [Help Center Template](https://wingo-ui.com/de/blog/help-center-template).
## Wo fängst du an?
Kopier die Datendatei und die Routen von oben, installier dann die Vorlage mit `npx wingo-ui@latest add changelog-page` und ersetz die Beispiel-Releases durch deine letzten drei. Die Vorlage, die Timeline und die Newsletter Section gehören zu Wingo UI Pro: $8 im Monat, $80 im Jahr oder einmalig $150 ([Preise](https://wingo-ui.com/de/pricing)). In der [Vorlage Changelog Page](https://wingo-ui.com/templates/changelog-page) kannst du dich vorher durch alle drei Designs klicken (classic, minimal und editorial).
## Komponenten in diesem Artikel
- [Changelog Page](https://wingo-ui.com/templates/changelog-page) (Pro): A React changelog page template: email and RSS subscribe, releases on a sticky version rail with drawn covers and New, Improved and Fixed groups. Installation: `npx wingo-ui@latest add changelog-page`
- [Timeline](https://wingo-ui.com/components/timeline) (Pro): A React timeline component for activity feeds, audit trails, changelogs and order tracking, with icons, relative times and day groups. Installation: `npx wingo-ui@latest add timeline`
- [Newsletter Section](https://wingo-ui.com/components/newsletter-section) (Pro): A React newsletter signup section for marketing pages: centered, split with the latest issue, a raised card or one compact row. Installation: `npx wingo-ui@latest add newsletter-section`
## Häufige Fragen
### Was gehört auf die Changelog-Seite eines SaaS?
Die Releases, die neuesten zuerst, jedes mit Version, ISO-Datum, kurzem Titel, einer Zusammenfassung in einem Satz und den Änderungen nach Typ gruppiert (neu, verbessert, behoben). Dazu ein Permalink pro Release, ein RSS-Feed und eine E-Mail-Anmeldung, damit Leser folgen können, ohne selbst ans Nachsehen denken zu müssen.
### Was ist der Unterschied zwischen Changelog und Release Notes?
Ein Changelog ist die fortlaufende Aufzeichnung aller Releases, an einem Ort und in einem Format. Release Notes beschreiben meist ein einzelnes Release ausführlicher, oft als E-Mail oder Blogbeitrag, der auf den passenden Eintrag im Changelog zurückverlinkt.
### Wie füge ich einem Next.js-Changelog einen RSS-Feed hinzu?
Leg unter app/changelog/rss.xml/route.ts einen Route Handler an, der dasselbe releases-Array wie die Seite liest und RSS 2.0 als XML mit dem Content-Type application/rss+xml zurückgibt. Markier ihn als force-static und trag ihn in den Metadaten der Seite unter alternates.types ein, damit Feedreader ihn finden.
### Sollte jedes Release im Changelog eine eigene Seite haben?
Ja, sobald du mehr Releases hast, als auf den ersten Bildschirm passen. Eine statische Seite pro Release gibt RSS-Einträgen, E-Mails und Social Posts einen Link, der immer funktioniert, und jede Seite bekommt ihren eigenen Titel und ihre eigene Beschreibung für die Suche.
### Ist die Changelog-Vorlage von Wingo UI kostenlos?
Nein. Die Vorlage Changelog Page, die Timeline und die Newsletter Section sind Pro-Items und lassen sich mit npx wingo-ui@latest add installieren, sobald dein Konto Pro hat. Die Marketing Section, auf der sie aufbauen, ist kostenlos.
---
Quelle: https://wingo-ui.com/de/blog/changelog-page-template