Blogging & Offenes Web

Stabile IDs für Feed-Einträge - Ein Beitrag darf sich ändern, ohne wieder neu zu werden

Geschrieben von Adam Muiz 31 Oct 2026 Aktualisiert: 31 Oct 2026 9 Min. gelesen

Ein Beitrag wird veröffentlicht, am nächsten Morgen korrigiert und einen Monat später unter eine übersichtlichere URL verschoben. Für einen Leser bleibt es derselbe Beitrag. Für einen Feedreader hängt diese Kontinuität jedoch von einem kleinen Feld ab, das leicht versehentlich neu erzeugt wird: der Kennung des Eintrags.

Wenn ein Feedgenerator die Identität aus Titel, Zeitstempel oder aktuellem Slug ableitet, kann eine gewöhnliche Bearbeitung einen anderen Wert erzeugen. Manche Clients zeigen die Überarbeitung dann möglicherweise als neuen Eintrag an. Auch der umgekehrte Fehler ist möglich: Wird eine alte Kennung für tatsächlich neue Inhalte wiederverwendet, können diese wie ein Update wirken. Die schwierige Aufgabe besteht nicht darin, eine eindeutig aussehende Zeichenfolge zu erzeugen. Es geht darum, ihre Bedeutung festzulegen und diese Bedeutung dauerhaft zu bewahren.

Identität, Ort und Zeit beantworten unterschiedliche Fragen

Ein Feed-Eintrag enthält gewöhnlich mehrere Werte, die austauschbar wirken, es aber nicht sind:

Kennung: Um welchen logischen Eintrag handelt es sich?
Permalink: Wo kann eine Person seine Webdarstellung abrufen?
Veröffentlichungszeit: Wann wurde er erstmals öffentlich?
Änderungszeit: Wann wurde diese Darstellung zuletzt überarbeitet?

Ein Permalink kann zugleich als Kennung dienen, und das ist häufig ein vernünftiger Entwurf. Die beiden Rollen bleiben dennoch verschieden. Eine Weiterleitung kann den Abruf von einer alten zu einer neuen URL verlagern, während die Identität des Beitrags unverändert bleibt. Ebenso sollte die Korrektur eines Absatzes die Änderungsmetadaten aktualisieren und nicht unbemerkt einen weiteren logischen Eintrag erzeugen.

Man kann sich ein Bibliotheksbuch vorstellen. Sein Standort im Regal sagt, wo es zu finden ist; seine Katalognummer sagt, welches Buch der Datensatz beschreibt. Manchmal verwendet ein System denselben Wert für beide Aufgaben. Probleme entstehen, wenn Software annimmt, dass ein Umstellen des Buches ihm auch eine neue Identität geben muss.

RSS, Atom und JSON Feed drücken die Regel unterschiedlich aus

Alle drei Formate erkennen die Notwendigkeit von Kontinuität an, ihre Anforderungen sind jedoch nicht identisch. Wer sie auf eine einzige Regel reduziert, kann ungültige Ausgaben erzeugen.

RSS 2.0: `guid` ist optional, aber nützlich

Die RSS-2.0-Spezifikation definiert guid als Zeichenfolge, die ein Element eindeutig kennzeichnet. Ein Aggregator kann sie verwenden, um festzustellen, ob ein Element neu ist. Diese Formulierung ist wichtig: RSS schreibt keinen universellen Deduplizierungsalgorithmus vor. Ein Herausgeber kann deshalb kein identisches Verhalten in jedem Reader versprechen.

RSS gibt isPermaLink außerdem einen überraschenden Standardwert. Fehlt das Attribut oder ist es auf true gesetzt, wird der Wert als dauerhafte, dem Element zugeordnete URL behandelt. Ein undurchsichtiger interner Wert benötigt daher ausdrücklich isPermaLink="false":

<item>
  <title>A Durable Post Title</title>
  <link>https://example.com/posts/durable-title/</link>
  <guid isPermaLink="false">post:1842</guid>
  <pubDate>Sat, 31 Oct 2026 00:00:00 GMT</pubDate>
</item>

Die Kennung oben ist lediglich eine beispielhafte, vom Herausgeber kontrollierte Zeichenfolge. Ihre Eindeutigkeit hängt davon ab, dass der Herausgeber post:1842 keinem anderen Element dieses Feeds zuweist. Das Best-Practices-Profil des RSS Advisory Board empfiehlt einen guid für jedes Element, obwohl das Kernformat ihn nicht verlangt.

Atom 1.0: `atom:id` ist erforderlich und dauerhaft

Atom ist strenger. RFC 4287, Abschnitt 4.2.6, verlangt genau ein atom:id in jedem Eintrag. Sein Wert muss eine IRI sein, muss so erzeugt werden, dass Eindeutigkeit gewährleistet ist, und muss nicht im Browser auflösbar sein. Der RFC sagt ausdrücklich, dass er sich nicht ändern darf, wenn ein Eintrag verschoben, migriert, syndiziert, erneut veröffentlicht, exportiert, importiert oder überarbeitet wird.

<entry xmlns="http://www.w3.org/2005/Atom">
  <title>A Durable Post Title</title>
  <id>tag:example.com,2026:post-1842</id>
  <author><name>Example Author</name></author>
  <link rel="alternate"
        href="https://example.com/posts/durable-title/" />
  <published>2026-10-31T00:00:00Z</published>
  <updated>2026-10-31T08:15:00Z</updated>
</entry>

Atom vergleicht IDs Zeichen für Zeichen und unter Beachtung der Groß- und Kleinschreibung. Zwei Zeichenfolgen, die zufällig dieselbe Ressource auflösen, sind weiterhin unterschiedliche IDs, wenn ihre Zeichen voneinander abweichen. Eine Normalisierung oder Neuerzeugung bei jeder Ausgabe ist daher riskant. In Atom stellen Einträge mit demselben atom:id denselben Eintrag dar; atom:updated übermittelt den Zeitpunkt der Überarbeitung.

Das Beispiel verwendet eine tag:-URI. RFC 4151 definiert dieses Schema für Kennungen, die eindeutig sein können, ohne abrufbar zu sein. Es kombiniert eine Autorität, ein mit dieser Autorität verbundenes Datum und einen vom Herausgeber verwalteten spezifischen Teil. Das ist eine mögliche Strategie, keine Anforderung. Auch eine HTTPS-IRI oder eine andere gültige und dauerhafte IRI kann Atom erfüllen.

JSON Feed: `id` und `url` sind getrennte Felder

JSON Feed 1.1 verlangt für jedes Element eine Zeichenfolge id, die innerhalb dieses Feeds dauerhaft eindeutig bleibt. Ein aktualisiertes Element behält seine ID, und ein neues Element darf keine frühere ID wiederverwenden. Das optionale Feld url ist der Permalink. Es darf der ID entsprechen, doch das Format hält beide Rollen sichtbar getrennt:

{
  "id": "post:1842",
  "url": "https://example.com/posts/durable-title/",
  "title": "A Durable Post Title",
  "date_published": "2026-10-31T00:00:00Z",
  "date_modified": "2026-10-31T08:15:00Z",
  "content_html": "<p>Corrected content.</p>"
}

JSON Feed weist Reader an, ein Element ohne ID zu verwerfen. Das ist strenger als RSS, wo guid optional ist. Auch deshalb sollten die Formate nicht als bloß kosmetische Serialisierungen eines nur lose definierten Objekts behandelt werden.

Eine Kennungsstrategie wählen, die Veränderungen übersteht

Zwei verbreitete Strategien sind gut vertretbar.

Einen stabilen Permalink als ID verwenden

Dieser Ansatz ist einfach und für Menschen lesbar. Er funktioniert gut, wenn veröffentlichte URLs tatsächlich dauerhaft sind, Weiterleitungen gepflegt werden und eine Migration die ursprüngliche Kennungszeichenfolge bewahren kann, selbst wenn sich der aktuelle Link ändert. RSS unterstützt dies von Natur aus durch sein standardmäßiges Permalink-Verhalten, und Atom erlaubt auflösbare IRIs.

Die Einschränkung ist eher organisatorisch als syntaktisch. Wenn ein CMS die ID automatisch aus der aktuellen Domain und dem aktuellen Slug neu zusammensetzt, verändert eine Domainmigration oder Slug-Bearbeitung die Identität. Eine URL-basierte ID ist nur dann stabil, wenn die gespeicherte ursprüngliche URL als unveränderliche Identität behandelt und nicht aus der heutigen Routing-Konfiguration neu berechnet wird.

Eine undurchsichtige, gespeicherte Veröffentlichungs-ID verwenden

Ein datenbankgestützter Wert kann Identität und Routing voneinander trennen:

feed_entry_id = tag:example.com,2026:post-1842
current_url   = https://example.com/posts/durable-title/

Damit lassen sich Änderungen an Slug und Domain leichter modellieren. Daraus entstehen aber auch Pflichten: Der Wert muss global für Atom geeignet, im vorgesehenen Geltungsbereich eindeutig, niemals erneut vergeben und bei Migrationen exportiert werden. Eine undurchsichtige ID ist nicht automatisch sicherer, nur weil sie technisch aussieht. Ohne dauerhafte Speicherung und Eindeutigkeitsregeln ist sie lediglich eine weitere veränderliche Zeichenfolge.

Ein praxisnahes CMS kann die Kennung einmal erzeugen, wenn ein Eintrag erstmals in den öffentlichen Feed gelangt, sie in einer eigenen unveränderlichen Spalte speichern und den aktuellen Permalink getrennt ausgeben. Wenn das CMS mehrere Formate erzeugt, sollte es für jedes eine ausdrückliche Zuordnung definieren. Ein älterer RSS-guid darf bei Kennzeichnung als Nicht-Permalink eine beliebige Zeichenfolge sein, während eine Atom-ID eine IRI sein muss. Nicht jeder historische RSS-Wert kann daher unverändert und konform nach Atom kopiert werden.

Bearbeitungen und Migrationen benötigen eine Identitätsrichtlinie

Die Richtlinie kann kurz sein, sollte schwierige Fälle aber beantworten, bevor ein Migrationsskript dies unbeabsichtigt übernimmt.

Einen Tippfehler korrigieren oder einen Abschnitt erweitern: Die Eintrags-ID beibehalten und Änderungsmetadaten aktualisieren, sofern das Format sie vorsieht.
Einen Slug ändern: Die ID beibehalten, den aktuellen Link aktualisieren und nach Möglichkeit eine HTTP-Weiterleitung erhalten.
Auf eine andere Domain umziehen: Bereits veröffentlichte IDs bewahren. Neue Einträge dürfen einer neuen Erzeugungsrichtlinie folgen, aber der Übergang sollte die Vergangenheit nicht umschreiben.
Aus einem anderen CMS importieren: Vorhandene Kennungen übernehmen, wenn sie verfügbar und für das Zielformat gültig sind. Notwendige Zuordnungen dokumentieren, statt alles aus dem Importzeitpunkt abzuleiten.
Wesentlich neue Arbeit erneut veröffentlichen: Redaktionsseitig entscheiden, ob es sich um eine Überarbeitung oder einen neuen Eintrag handelt. Eine neue Veröffentlichung erhält eine neue ID; ein Update behält die alte.
Einen Eintrag löschen und später wiederherstellen: Auch seine ID wiederherstellen. Diese Kennung nicht für andere Inhalte wiederverwenden.

Die Änderung einer schlechten Kennungsrichtlinie bei einem etablierten Feed verlangt Zurückhaltung. Werden alle vorhandenen IDs durch ein übersichtlicheres Schema ersetzt, können alte Einträge in manchen Clients selbst als neu erscheinen. Häufig ist es am wenigsten störend, historische Werte beizubehalten, die korrigierte Richtlinie auf künftige Einträge anzuwenden und alte IDs nur aus einem konkreten, getesteten Grund zu migrieren.

Den Feed validieren und das Verhalten anschließend vorsichtig prüfen

Die Dokumentation des W3C Feed Validation Service nennt Prüfungen für fehlende RSS-GUIDs, nicht ausreichend eindeutige Werte, doppelte Atom-IDs und ungültige Permalink-Formen. Validierung ist wertvoll, weil sie strukturelle Fehler erkennt, etwa eine beliebige RSS-Zeichenfolge unter der standardmäßigen Permalink-Interpretation.

Sie kann nicht beweisen, wie jeder Reader eine Überarbeitung darstellen wird. Client-Zustand, Importverlauf und Implementierungsentscheidungen bleiben für einen Syntaxvalidator unsichtbar. Ein vorsichtiger Test verwendet einen nicht produktiven Feed und beobachtet eine Abfolge: ein Element veröffentlichen und abrufen, dann den Inhalt bearbeiten, ohne die ID zu ändern, und anschließend den Link bei gleichbleibender Identität ändern. Das erwartete Modell ist ein sich entwickelnder Eintrag. Eine Aussage über einen bestimmten Reader sollte jedoch aus einem tatsächlichen Test genau dieses Readers und seiner Version stammen.

Auch Feed-Snapshots verdienen Regressionstests. Aus derselben Datenbankzeile sollte ein Neuaufbau dieselbe ID erzeugen. Eine Änderung von Titel oder Slug darf sie nicht verändern. Eine neue Zeile darf niemals den Wert einer gelöschten Zeile wiederverwenden. Solche Tests schützen den Veröffentlichungsvertrag direkter als die bloße Prüfung, ob die Ausgabe ein Feld namens guid oder id enthält.

Ein kleines Feld trägt die Geschichte

Eine dauerhafte Eintragskennung ermöglicht Änderungen am Inhalt, ohne vorzutäuschen, der Eintrag sei zu etwas anderem geworden. RSS bietet einen flexiblen, optionalen guid; Atom verlangt eine dauerhafte IRI; JSON Feed verlangt eine stabile Zeichenfolge innerhalb des Feeds. Ihre Syntax unterscheidet sich, doch die Veröffentlichungsdisziplin ist ähnlich: Identität bewusst erzeugen, speichern und nicht aus Feldern neu berechnen, die sich voraussichtlich ändern werden.

Es gibt keinen allgemeinen Grund, URL-basierte IDs aufzugeben, und ein undurchsichtiger Wert ist nicht automatisch besser. Die nützliche Frage ist enger: Kann genau dieser Wert die Bearbeitungen, Routing-Änderungen, Exporte und Migrationen überstehen, die für die Publikation vernünftigerweise zu erwarten sind? Falls nicht, beschreibt die Kennung die heutige Darstellung statt der Kontinuität des Eintrags.