Welches Feedformat für den Blog? RSS 2.0 gewinnt – aber nur zusammen mit Atom und Dublin Core

Kurz gesagt: Veröffentliche das, was dein CMS ohnehin ausliefert — mit sehr hoher Wahrscheinlichkeit ist das RSS 2.0. Von den unterschiedlichen Feed-Adressen, die Proofite-Nutzer tatsächlich abonniert haben (Erhebung vom 23. August 2026), deklarieren 93 Prozent <rss version="2.0">. Atom 1.0 kommt auf 5 Prozent, die RDF-Syntax von RSS 1.0 auf 1 Prozent, und 1 Prozent ist überhaupt kein Feed mehr, sondern liefert HTML oder gar nichts. Atom — das einzige Format, das ein Standardisierungsgremium durchlaufen hat — unterliegt damit 18:1. Nur: 88 Prozent der RSS-2.0-Feeds deklarieren trotzdem den Atom-Namespace. Acht von neun Feeds sind also beides gleichzeitig. Die Frage „RSS oder Atom“ ist damit weitgehend beantwortet, bevor man sie stellt.

Der Formatkrieg endete mit einer Verschmelzung, nicht mit einem Sieg

Wer sich die 88 Prozent genauer ansieht, findet fast immer denselben Grund: <atom:link rel="self">. Das ist das Element, mit dem ein Feed seine eigene kanonische Adresse angibt. RSS 2.0 hat dafür nichts Vergleichbares. Also holt sich RSS 2.0 das Teil aus Atom.

Das Muster wiederholt sich. RSS 2.0 stellt den Container, andere Vokabulare liefern die fehlenden Bauteile: content:encoded für den Volltext, Media RSS für Vorschaubilder, Laufzeiten und Lizenzen, itunes: für Kategorie, Dauer und Cover. Was in Blogbeiträgen um 2003 als Glaubenskrieg beschrieben wurde, ist in der Praxis eine Arbeitsteilung geworden.

RSS 1.0 hat die Syntax verloren und das Vokabular gewonnen

89 Prozent der RSS-2.0-Feeds deklarieren xmlns:dc — Dublin Core, also genau jenes Vokabular, auf das RSS 1.0 gesetzt hatte. Die RDF-Syntax von RSS 1.0 liegt bei 1 Prozent.

Der Verlierer der Spaltung vom Dezember 2000 lebt demontiert im Format weiter, das ihn geschlagen hat: dc:creator für den Autor, dc:date für das Datum. Praktisch heißt das: Wer einen Parser schreibt und Dublin Core ignoriert, verliert bei knapp neun von zehn Feeds die Autorenangabe.

Was wie eine Redaktionsentscheidung aussieht, ist Werkseinstellung

Die Verbreitung der Erweiterungen über alle gültigen Feeds:

| Namespace | Anteil | |---|---| | dc (Dublin Core) | 90 % | | atom | 82 % | | content | 75 % | | sy (Syndication) | 49 % | | slash | 48 % | | wfw (Well-Formed Web) | 46 % | | media (Media RSS) | 35 % | | itunes | 7 % |

Die ersten sechs sind exakt die Namespaces, die WordPress standardmäßig ausgibt. Niemand hat sich für slash:comments entschieden. Es war einfach da. Wer wissen will, was ein Feed enthält, sollte deshalb nicht nach dem Format fragen, sondern nach dem Generator.

In über einem Drittel der Fälle ist der Content-Type falsch — aus historischen Gründen

Nur 63 Prozent der gültigen Feeds werden mit korrektem MIME-Type ausgeliefert (61 Prozent application/rss+xml, 2 Prozent application/atom+xml). Bei 37 Prozent stimmt der Header nicht: 22 Prozent kommen als application/xml, 14 Prozent als text/xml, ein Feed als text/html. Nebenbei: 2 Prozent der Feeds laufen noch über unverschlüsseltes HTTP.

Die Ursache liegt in der Registrierungsgeschichte. application/rss+xml ist bei der IANA nie registriert worden. Zwei Anläufe als Internet Draft liefen aus, weil hinter RSS kein anerkanntes Gremium stand, das die Registrierung hätte einreichen können. application/atom+xml ist dagegen regulär registriert, über RFC 4287 vom Dezember 2005. Der De-facto-Standard hat also den formal unsauberen Header, der formale Standard den sauberen — und den geringeren Marktanteil.

Der falsche MIME-Type stört Leser kaum, Browser aber schon

Praktisch kein Aggregator wertet den Content-Type aus. Er lädt das Dokument, sieht sich das Wurzelelement an und arbeitet weiter. Der Fehler bleibt unsichtbar.

Browser verhalten sich anders. Wer application/rss+xml ausliefert, riskiert, dass der Browser die Datei zum Download anbietet, statt sie anzuzeigen. Für Leser, die eine Feed-Adresse zuerst anklicken, um zu sehen, was dahintersteckt, ist das ein Abbruch. Deshalb kehren manche Publisher bewusst zu text/xml zurück. Das ist kein Konfigurationsfehler, sondern eine Abwägung — nur wird sie selten dokumentiert.

Audio ist der Teil von RSS, der nie in die Krise geriet

21 Prozent der Feeds enthalten mindestens ein <enclosure>, 7 Prozent deklarieren den itunes-Namespace, sind also Podcasts im engeren Sinn. Das Element <enclosure> kam mit RSS 0.92 im Dezember 2000 — vorgeschlagen von Tristan Louis, angetrieben von Adam Curry. Danach lag es drei Jahre ohne Publikum herum.

Heute hängt daran eine Industrie. Die großen Hörplattformen hosten die Episoden nicht, sie indexieren öffentliche RSS-Feeds. Wer einen Podcast betreibt, betreibt einen RSS-Feed, ob er das Wort benutzt oder nicht.

Die Versionsnummern erklären nichts

Netscape veröffentlichte den ersten RSS-Entwurf im März 1999. UserLand übernahm den XML-Zweig im Juni 2000. Am 6. Dezember 2000 publizierte die RSS-DEV Working Group — eine unabhängige Gruppe, nicht das W3C — RSS 1.0 auf RDF-Basis. Neunzehn Tage später antwortete UserLand mit Version 0.92. RSS 2.0 folgte im August 2002.

Daraus folgt: RSS 1.0 ist nicht die Vorversion von RSS 2.0, sondern ein paralleler Zweig mit inkompatibler Syntax. Und version="2.0" bezeichnet keine zweite Fassung, sondern den UserLand-Zweig; zwischen 2002 und 2009 erschienen elf Revisionen der Spezifikation, ohne dass die deklarierte Nummer sich änderte. Kein einziger RSS-Stand hat je ein Standardisierungsgremium durchlaufen. Die Autodiscovery-Konvention wurde erst 2006 vom RSS Advisory Board formal beschrieben, Jahre nachdem Browser sie schon unterstützten.

Der schlimmste Ausfall ist der stille

Ein Feed, der brav mit HTTP 200 antwortet, gültiges XML liefert und dessen jüngster Eintrag älter als sechs Monate ist, produziert keine Fehlermeldung. Kein Aggregator warnt. Das Schweigen der Quelle liest sich wie Nachrichtenmangel.

Für Leser heißt das: Prüfe das Datum des letzten Eintrags, nicht das Ausbleiben von Neuem. Für Betreiber heißt es: Ein Feed, der nach einem Relaunch auf die alte Adresse zeigt, verschwindet nicht — er versteinert.

30 Feeds, 19 Newsletter, ein Nebeneffekt

Ein aktiver Proofite-Nutzer verfolgt typischerweise 70 Quellen: 30 RSS-Feeds, 20 Web-Suchen, 19 Newsletter, ein Social-Profil, verteilt auf acht Rubriken. Der Vergleich zwischen den Kanälen fällt eindeutig aus. In 40 real ausgewerteten Newslettern enthielten 12 (30 Prozent) mindestens einen deklarierten Sponsorenblock; in einer einzelnen PetaPixel-Ausgabe nahm die Anzeige 959 Zeichen ein, 18 Prozent des redaktionellen Textes, bei TLDR AI 624 Zeichen. RSS liefert Werbung nur dann, wenn sie im Beitrag selbst steht.

Dafür produzieren viele Quellen dasselbe: Über vier reale Digests mit 37 Einträgen entstanden 27 Prozent der Einträge aus zwei oder mehr verschiedenen Redaktionen zum identischen Vorgang — etwa Coindesk, Wired und Corriere della Sera zu einer Finanzierungsrunde. Wer neben heise online noch FAZ und Handelsblatt abonniert, bekommt Überschneidungen. Das ist kein Formatproblem, aber es ist der Grund, warum die Feed-Liste eines Vielesers ohne Deduplizierung schnell unlesbar wird.

Die Checkliste für den eigenen Blog

1. Erstes Tag ansehen. Steht dort nicht <rss, <rdf:RDF oder <feed, publizierst du keinen Feed. Genau diese Prüfung hat das 1 Prozent aussortiert.
2. <atom:link rel="self"> setzen. Ohne diese Angabe weiß ein Aggregator, der das Dokument auf anderem Weg erhält, nicht, von welcher Adresse er es künftig nachladen soll.
3. <guid> pro Eintrag prüfen, mit isPermaLink="true", wenn die ID der Artikel-URL entspricht. Das verhindert Doppelungen, sobald du eine Überschrift korrigierst.
4. Autodiscovery in den <head>: <link rel="alternate" type="application/rss+xml" title="RSS" href="...">.
5. Durch den W3C-Validator schicken (validator.w3.org/feed). Er meldet auch das Nichtblockierende, etwa mehrdeutige Datumsangaben.
6. Wenn du einen Generator von Grund auf baust: Atom nehmen. Ein einziges Datumsformat, Sprache pro Element, explizite Unterscheidung zwischen Text und HTML, registrierter MIME-Type. Für einen Blog auf WordPress ist die Frage dagegen theoretisch.

Häufige Fragen

RSS oder Atom — was soll ich für meinen Blog veröffentlichen?

Das, was dein CMS bereits ausliefert. Alle verbreiteten Leseprogramme verarbeiten beide Formate, und 88 Prozent der RSS-2.0-Feeds enthalten ohnehin Atom-Elemente. Eine exklusive Antwort gibt es nur für den Fall, dass du einen Generator selbst schreibst: dann Atom, wegen des präziseren Datenmodells und des bei der IANA registrierten MIME-Typs.

Ist RSS 1.0 neuer als RSS 2.0?

Nein. RSS 1.0 erschien am 6. Dezember 2000, RSS 2.0 im August 2002 — es sind zwei getrennte Zweige aus einer Spaltung, mit inkompatibler Syntax. Die höhere Nummer bezeichnet keine spätere Version.

War RSS 1.0 ein W3C-Standard?

Nein. Herausgeber war die RSS-DEV Working Group, eine unabhängige Gruppe. Kein RSS-Stand ist je durch ein Standardisierungsgremium gegangen. Standardisiert ist allein Atom 1.0, über RFC 4287 der IETF vom Dezember 2005.

Welchen Content-Type soll ich ausliefern?

Korrekt sind application/rss+xml beziehungsweise application/atom+xml; 63 Prozent der Feeds machen das. Aggregatoren interessiert der Header praktisch nicht, sie prüfen den Inhalt. Wenn Leser die Adresse im Browser öffnen und dieser die Datei nur herunterlädt, ist text/xml die pragmatische Wahl.

Brauche ich einen separaten Feed für einen Podcast?

Nur wenn du getrennte Zielgruppen bedienen willst. Technisch reicht ein RSS 2.0 mit <enclosure> je Episode plus itunes-Namespace für Kategorie, Dauer und Cover. 21 Prozent der abonnierten Feeds enthalten mindestens ein <enclosure>, 7 Prozent den itunes-Namespace.

Woran erkenne ich, dass ein Feed tot ist?

Am Datum des jüngsten Eintrags. Liegt es mehr als sechs Monate zurück, behandle die Quelle als tot — der Feed selbst antwortet weiter fehlerfrei und meldet nichts.

---

Zur Methode: Die Prozentzahlen stammen aus einer Erhebung aller unterschiedlichen Feed-Adressen, die Proofite-Nutzer tatsächlich abonniert haben. Jedes Dokument wurde am 23. August 2026 geladen und anhand des Wurzelelements sowie der deklarierten Namespaces klassifiziert; die Messung wird wiederholt und die Werte werden aktualisiert. Die Newsletter-Zahlen (40 Newsletter, 4 Digests mit 37 Einträgen, Juli 2026) beruhen auf automatischer Analyse der empfangenen E-Mail-Körper und der erzeugten Digests, nicht auf Angaben der Verlage oder Umfragen. Das ist kein repräsentatives Abbild des Webs: Es sind die Quellen, die eine Gemeinschaft aktiver Leser ausgewählt hat, also vorgefiltert auf lebende, gepflegte Seiten — der Grund, warum nur 1 Prozent nicht erreichbar war. Bei einer Zufallsstichprobe des Webs wäre dieser Anteil deutlich höher. Rohdaten, eine Zeile pro Feed, auf Anfrage.