Changelog Vorlage für React: RSS, E-Mail und Permalinks

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, 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 (opens in a new tab) (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 (opens in a new tab) (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:

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.

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 für den Filter New / Improved / Fixed, das Badge für die Gruppenlabels und den Tag Latest und die Pagination für Load older releases. Ohne die Prop releases rendert die Vorlage acht Beispiel-Releases eines erfundenen Produkts namens Acme.

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.

// 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).

// 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 <link rel="alternate" type="application/rss+xml">, damit Feedreader den Feed finden
    types: { "application/rss+xml": "/changelog/rss.xml" },
  },
}

export default function ChangelogRoute() {
  return <ChangelogView />
}

// 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 (
    <ChangelogPage
      header={false}
      footer={false}
      // der Sticky Header deines Layouts ist 65px hoch; die Versionsleiste klebt darunter
      style={{ "--topbar-offset": "65px" } as CSSProperties}
      releases={releases}
      linkComponent={Link}
      rssHref="/changelog/rss.xml"
      onSubscribe={subscribeToChangelog}
      // alle Releases sind schon geladen, also die 700 ms Wartezeit des Platzhalters überspringen
      onLoadMore={() => {}}
      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:

// 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<Metadata> {
  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 <ReleaseView release={release} latest={release === releases[0]} />
}

// 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 (
    <main className="px-4 pt-6 sm:px-6">
      {/* der Titel des Eintrags ist ein h2, die Seite braucht also trotzdem ein h1 */}
      <h1 className="sr-only">{`${release.version}: ${release.title}`}</h1>
      <ChangelogReleaseEntry release={release} latest={latest} layout="stacked" linkComponent={Link} />
      <NewsletterSection
        layout="inline"
        title="Das nächste Release per E-Mail"
        description="Eine kurze E-Mail, wenn wir etwas veröffentlichen. Sonst nichts."
        // der Standard zeigt eine Beispielzahl an Lesern; blende sie aus, bis du eine echte hast
        subscribers={0}
        onSubscribe={subscribeToChangelog}
        linkComponent={Link}
      />
    </main>
  )
}

Das Release ist reines JSON und gelangt deshalb problemlos aus der Server-Page in den Client-Wrapper. Achte auf subscribers={0}: Die 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.

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.

// 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, "&amp;").replace(/</g, "&lt;").replace(/>/g, "&gt;").replace(/"/g, "&quot;")

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 `<h3>${label}</h3><ul>${changes.map((change) => `<li>${escape(change.text)}</li>`).join("")}</ul>`
      }).join("")
      return `<item>
  <title>${escape(`${release.version}: ${release.title}`)}</title>
  <link>${url}</link>
  <guid isPermaLink="true">${url}</guid>
  <pubDate>${new Date(`${release.date}T12:00:00Z`).toUTCString()}</pubDate>
  <description>${escape(`<p>${escape(release.summary)}</p>${body}`)}</description>
</item>`
    })
    .join("\n")

  const xml = `<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"><channel>
<title>Northwind Changelog</title>
<link>${SITE}/changelog</link>
<description>Neue Features, Verbesserungen und Fixes in Northwind.</description>
${items}
</channel></rss>`

  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 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 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.

// 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 passt in ein Seitenpanel und liest dieselben Daten.

// 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 <Timeline items={items} timeFormat="date" timePosition="side" locale="de-DE" />
}

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 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. Die Support-Seite derselben Website, mit Suche, Themen und Artikeln, behandelt unser Guide zum 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). In der Vorlage Changelog Page kannst du dich vorher durch alle drei Designs klicken (classic, minimal und editorial).

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.