RSS-Feeds
Wie Suchmaschinen RSS-2,0- und Atom-1,0-Feeds als Entdeckungskanal für frische Inhalte nutzen – Feedfetcher, robots.txt, WebSub und warum ein Feed eine XML-Sitemap ergänzt, aber nie ersetzt.
Sprachen
Google und Bing akzeptieren sowohl RSS-2,0- als auch Atom-1,0-Feeds als sitemap-ähnliches Entdeckungssignal – aber ein Feed zeigt nur Ihre kürzlich geänderten URLs, ergänzt also eine vollständige XML-Sitemap, statt sie zu ersetzen. Google crawlt Feeds mit Feedfetcher, einem separaten Crawler, der robots.txt ignoriert (blockieren Sie ihn mit einem 4xx-Status, nicht mit einem Disallow). Feeds sind ein Pull-Kanal; WebSub macht sie für Google zu Push, während IndexNow inzwischen Bings bevorzugtes Push-Signal ist. Feeds beschleunigen die Entdeckung, nicht das Ranking, und wie Sitemaps garantieren sie niemals die Indexierung.
Evidence for this claim RSS 2.0 defines a channel of items with metadata such as title, link, description, publication date, and GUID. Scope: RSS 2.0 feed format; consumer behavior varies. Confidence: high · Verified: RSS 2.0 Specification Evidence for this claim Google accepts RSS 2.0 and Atom 1.0 feeds as sitemap submissions, generally covering recent URLs; submission aids discovery but does not guarantee indexing. Scope: Current Google sitemap format support. Confidence: high · Verified: Google Search Central: Build and submit a sitemapTL;DR – Ein RSS- oder Atom-Feed ist eine XML-Datei, die Ihre aktuellsten Seiten auflistet. Suchmaschinen können sie nutzen, um neue Inhalte schneller zu finden – Sie können den Feed in der Google Search Console oder in Bing Webmaster Tools einreichen, genau wie eine Sitemap. Ein Feed zeigt jedoch nur aktuelle URLs, funktioniert also ergänzend zu einer vollständigen XML-Sitemap, nicht als Ersatz. Und wie eine Sitemap hilft er dabei, eine Seite zu finden – er verbessert nicht Ihr Ranking.
Was ein RSS-Feed ist
Ein RSS-Feed (Really Simple Syndication) oder Atom-Feed ist eine XML-Datei, die Ihre Website veröffentlicht und Ihre neuesten Inhalte auflistet – normalerweise die letzten paar Dutzend Beiträge. Die meisten Blog- und CMS-Plattformen generieren automatisch einen. Leser nutzen Feeds, um Ihre Updates in einem Feed-Reader zu verfolgen, aber dieselbe Datei erfüllt einen doppelten Zweck: Suchmaschinen können sie lesen, um Ihre neuesten URLs zu entdecken.
Wie Suchmaschinen sie nutzen
Ein Feed funktioniert ähnlich wie eine Sitemap. Zwei Dinge können passieren:
- Sie reichen ihn ein. In der Google Search Console oder in Bing Webmaster Tools können Sie die URL des Feeds als Sitemap hinzufügen. Die Engine prüft sie dann auf neue Seiten.
- Crawler finden ihn selbst. Wenn Sie ein kleines Autodiscovery-Tag in den
<head>Ihrer Seite einfügen – eine<link rel="alternate" type="application/rss+xml">-Zeile – kann ein Crawler Ihren Feed erkennen, ohne dass Sie etwas einreichen.
In beiden Fällen ruft die Engine Ihren Feed regelmäßig ab und bemerkt die kürzlich hinzugefügten oder geänderten URLs darin.
Das Eine, das Sie sich merken sollten
Ein Feed ersetzt Ihre XML-Sitemap nicht. Ein Feed listet nur Ihre aktuellen Inhalte auf – er enthält nicht Ihre älteren Seiten oder Archive. Googles eigener Rat ist, beides zu nutzen: die Sitemap für die vollständige Abdeckung Ihrer gesamten Website und den Feed als Frische-Signal für das, was sich gerade geändert hat.
Und genau wie eine Sitemap hilft ein Feed nur bei der Entdeckung – eine Seite finden und crawlen zu lassen. Er garantiert nicht, dass die Seite indexiert wird, und er verbessert nicht Ihr Ranking.
Möchten Sie die ausführlichere Version – Feedfetcher (Googles separater Feed-Crawler), warum er robots.txt ignoriert, WebSub und wie sich Bings Anleitung in Richtung IndexNow verschoben hat? Wechseln Sie zum Erweitert-Tab.
Evidence for this claim RSS 2.0 defines a channel of items with metadata such as title, link, description, publication date, and GUID. Scope: RSS 2.0 feed format; consumer behavior varies. Confidence: high · Verified: RSS 2.0 Specification Evidence for this claim Google accepts RSS 2.0 and Atom 1.0 feeds as sitemap submissions, generally covering recent URLs; submission aids discovery but does not guarantee indexing. Scope: Current Google sitemap format support. Confidence: high · Verified: Google Search Central: Build and submit a sitemapTL;DR – RSS 2,0 und Atom 1,0 werden von Google als Sitemap-Format akzeptiert, und andere Engines unterstützen möglicherweise die Einreichung von Feeds unter ihrer aktuellen Webmaster-Anleitung. Ein Feed zeigt nur Ihre kürzlich geänderten URLs, ergänzt also eine vollständige XML-Sitemap – er ersetzt sie nie. Feeds sind ein Pull-Kanal; WebSub kann Publish-Subscribe-Benachrichtigungen hinzufügen, während IndexNow ein separates URL-Benachrichtigungsprotokoll ist, das von teilnehmenden Engines verwendet wird. Feeds helfen bei der Entdeckungsgeschwindigkeit, nicht beim Ranking, und garantieren wie Sitemaps nie die Indexierung.
Ein Feed ist ein Entdeckungssignal im Sitemap-Format
Wenn Ihr CMS bereits einen RSS- oder Atom-Feed veröffentlicht, können Suchmaschinen ihn auf
dieselbe Weise nutzen wie eine Sitemap – als Liste von zu entdeckenden URLs. Google ist eindeutig:
„Google accepts RSS 2,0 and Atom 1,0 feeds,“ und „if your CMS generates an RSS
or Atom feed, you can submit the feed’s URL as a sitemap.“ (Übersetzung) „Google akzeptiert RSS-2,0- und Atom-1,0-Feeds“ und „Wenn Ihr CMS einen RSS- oder Atom-Feed generiert, können Sie die URL des Feeds als Sitemap einreichen.“ Dieses Einreichungsfeld in
der Google Search Console akzeptiert eine Feed-URL genauso bereitwillig wie eine sitemap.xml.
Der Haken ist der Umfang. Eine vollständige XML-Sitemap zielt darauf ab, jede URL auf Ihrer Website zu katalogisieren; ein Feed ist ein rollierendes Fenster Ihrer aktuellsten Einträge. Google sagt es deutlich: „This feed only provides information on recent URLs.“ (Übersetzung) „Dieser Feed liefert nur Informationen zu aktuellen URLs.“ Ein Feed ist also ein Frische-Signal, kein umfassender Index Ihrer Seiten. Genau so stelle ich es auf dem Discovery-Hub dar – Google akzeptiert Feeds als Sitemap-Format, aber ein Feed zeigt nur Ihre kürzlich geänderten URLs.
Hier sind zwei verschiedene Dinge wahr, und es lohnt sich, sie getrennt zu halten: Der Feed ist aktuell, weil welche URLs aktuell darin gelistet sind – dieser Teil ist strukturell und zuverlässig. Was der pubDate/updated-Wert jedes Eintrags tut, sobald ein Anbieter den Feed abruft, ist eine separate Frage; Google und Bing veröffentlichen keine detaillierte Spezifikation darüber, wie genau sie diese Datumsfelder gewichten, also behandeln Sie sie als nützlichen Kontext, den Sie liefern, nicht als dokumentierte Verarbeitungsgarantie.
Feeds ergänzen eine Sitemap – sie ersetzen sie nicht
Das ist der Mythos, den man gleich zu Beginn ausräumen sollte: “Ein RSS-Feed ersetzt meine XML-Sitemap.” Tut er nicht. Googles dokumentierte Empfehlung ist, beides zu verwenden – die Sitemap für umfassende, seitenweite Abdeckung (ältere Seiten, Archive, alles), und den RSS/Atom-Feed als Frische-Ebene für das, was sich gerade geändert hat. Lassen Sie die Sitemap weg und behalten Sie nur den Feed, verliert Ihr Archiv älterer URLs seinen zuverlässigsten Entdeckungspfad.
Ein praktischer Hinweis dazu, was Feeds transportieren können: Ein mRSS (Media RSS)-Feed kann Google Details zu Video-Inhalten liefern, aber RSS/Atom-Feeds können nur Videos beschreiben – keine Bilder oder Nachrichten. Für die Bild-Entdeckung benötigen Sie weiterhin eine Bild-Sitemap, und für Google News reichen Sie über News-spezifische Kanäle ein. Der Feed ist eine Entdeckungshilfe, keine universelle Metadaten-Pipeline.
Feedfetcher: Googles Feed-Crawler für News und WebSub – und die robots.txt-Falle
Hier ist der Teil, den die meisten Artikel übersehen, und es lohnt sich, beim Umfang präzise zu sein: Googles eigene Feedfetcher-Dokumentation beschreibt ihn eng als “how Google crawls RSS or Atom feeds for Google News and WebSub.” Das ist die dokumentierte Verwendung – Google sagt auf dieser Seite nicht, dass Feedfetcher jeden Feed verarbeitet, den Sie als Sitemap in der Search Console einreichen, daher werde ich das nicht zu einer Behauptung über den Sitemap-Einreichungspfad verallgemeinern. Zwei Dinge, die Feedfetchers eigene Dokumentation für den genannten News/WebSub-Kontext feststellt:
- Er ignoriert robots.txt – absichtlich. Google sagt es direkt: Feedfetcher
befolgt keine robots.txt-Regeln, weil er als im Auftrag eines Menschen handelnd
behandelt wird, der den Feed explizit abonniert hat – “a direct agent of the
human user, not as a robot.” Wenn Ihr Plan, “den Feed vor Crawlern zu
blockieren”, also ein robots.txt-
Disallowist, wird er Feedfetcher nicht stoppen. Um Feedfetcher tatsächlich zu blockieren, geben Sie einen 4xx-Status (404 oder 410) für die Feed-URL zurück – kein Disallow. Das ist dieselbe Art von Fehler wie der Versuch, eine Seite mit robots.txt zu deindexieren: Sie greifen zum falschen Werkzeug. - Er crawlt nur die Feed-URL, nicht die Links darin. Google stellt klar, dass “unlike normal web crawlers, Feedfetcher isn’t discovering links to crawl at all; instead, it crawls a single URL that’s provided to it.” Außerdem sagt es, dass Feedfetcher “shouldn’t retrieve feeds from most sites more than once every hour on average,” wobei häufig aktualisierte Seiten öfter aktualisiert werden können. Was Google nicht dokumentiert, ist, was als Nächstes mit den URLs innerhalb eines Feeds passiert, den Sie als allgemeine Such-Sitemap einreichen – diese Übergabe wird auf dieser Seite nicht beschrieben, also behandeln Sie sie als undokumentiert, anstatt anzunehmen, dass sie über Feedfetcher läuft.
Wie Bing Feeds nutzt – und warum IndexNow das Bild verändert hat
Bing akzeptiert eine breite Palette von Sitemap-Formaten: XML, RSS 2,0, mRSS, Atom 0,3 und Atom 1,0 sowie Klartext. RSS/Atom-Feeds sind eine natürliche Wahl für Blogs, die häufig veröffentlichen, und historisch hat Bing diese Feeds überwacht, um neue Inhalte zu erfassen.
Aber Bings moderne Anleitung hat sich weiterentwickelt. Ihre Sitemap-Anleitung von 2025 betont XML mit korrektem lastmod plus IndexNow als bevorzugten Stack und stellt RSS/Atom nicht mehr in den Vordergrund. Die Begründung steht in Bings eigenen Worten zu IndexNow: “Instead of Bing continually monitoring RSS and similar feeds or frequently crawling websites to check for new pages… websites will notify Bing directly about relevant URLs changing on their website.” (Übersetzung) „Statt dass Bing kontinuierlich RSS und ähnliche Feeds überwacht oder Websites häufig crawlt, um nach neuen Seiten zu suchen … werden Websites Bing direkt über relevante URL-Änderungen auf ihrer Website informieren.“ Mit anderen Worten: IndexNow soll das alte Muster „Bing überwacht Ihren RSS-Feed“ durch einen expliziten Push ersetzen. RSS funktioniert bei Bing weiterhin und die Einreichung ist mit geringem Aufwand verbunden – aber wenn Sie sich entscheiden müssen, wo Sie für Bing-Aktualität investieren, ist IndexNow jetzt die primäre Empfehlung.
Pull vs. Push: Wo WebSub passt
Feeds sind grundsätzlich ein Pull-Kanal – die Suchmaschine ruft Ihren Feed nach eigenem Zeitplan erneut ab. Um daraus einen Push zu machen, fügen Sie WebSub (früher PubSubHubbub) hinzu. Google unterstützt dies: “If you use Atom or RSS, you can use WebSub to broadcast your changes to search engines, including Google.” (Übersetzung) „Wenn Sie Atom oder RSS verwenden, können Sie WebSub nutzen, um Ihre Änderungen an Suchmaschinen, einschließlich Google, zu übertragen.“ Statt darauf zu warten, erneut abgerufen zu werden, sendet Ihr Feed die Änderung an abonnierte Suchmaschinen, sodass die Aktualisierung näher an Echtzeit erfolgt. Das einfachste mentale Modell für die beiden Suchmaschinen:
- Google: RSS/Atom-Feed für Pull-Erkennung, WebSub zum Pushen von Feed-Änderungen.
- Bing: RSS/Atom akzeptiert, aber IndexNow ist der bevorzugte Push für Echtzeit-Benachrichtigungen.
WebSub ist die Push-Ergänzung zu RSS – genauso wie lastmod und IndexNow Push-Ergänzungen auf der Sitemap-Seite sind. (Mehr zur gesamten Pull/Push-Landschaft finden Sie im Discovery-Hub.)
Einrichten eines Feeds für die Erkennung
Eine kurze, praktische Checkliste:
- Veröffentlichen Sie einen gültigen RSS-2,0- oder Atom-1,0-Feed (die meisten CMS tun dies automatisch). Verwenden Sie darin absolute URLs und begrenzen Sie die Anzahl der Einträge auf Ihr aktuelles Zeitfenster.
- Fügen Sie ein Autodiscovery-Tag in den
<head>Ihrer Seite ein, damit Crawler ihn finden können:<link rel="alternate" type="application/rss+xml" title="Feed" href="/feed.xml">. - Reichen Sie die Feed-URL als Sitemap in der Google Search Console und in den Bing Webmaster Tools ein. Autodiscovery allein kann funktionieren, aber die explizite Einreichung ist zuverlässiger.
- Für Google-Aktualität fügen Sie WebSub hinzu; für Bing-Aktualität implementieren Sie IndexNow.
- Blockieren Sie den Feed nicht in robots.txt in der Erwartung, dass Feedfetcher ihn befolgt – verwenden Sie einen 4xx-Status, wenn Sie ihn wirklich blockieren müssen.
Die Grenzen – wie bei Sitemaps
Drei ehrliche Grenzen, die Sie im Hinterkopf behalten sollten:
- Nur aktuelle URLs. Ein Feed ist ein Aktualitätssignal, keine vollständige Abdeckung. Behalten Sie die XML-Sitemap für alles andere.
- Keine Indexierungsgarantie. Erkennung ist nicht Indexierung. Ein Feed führt dazu, dass eine URL schneller gefunden und gecrawlt wird; ob sie indexiert wird, ist eine separate Entscheidung.
- Kein Ranking-Signal. Feeds beschleunigen die Erkennung und können helfen, dass frische Inhalte aufgegriffen werden, bevor Backlinks entstehen, aber es gibt keinen darüber hinausgehenden Ranking-Vorteil – genau wie bei einer Sitemap.
KI-Zusammenfassung
Eine komprimierte Darstellung der erweiterten Version:
- Feeds sind ein Discovery-Signal im Sitemap-Format. Google akzeptiert RSS 2,0 und Atom 1,0; Bing akzeptiert RSS 2,0 sowie Atom 0,3/1,0 (und mRSS). Reichen Sie die Feed-URL als Sitemap ein oder machen Sie sie über ein
<link rel="alternate">-Autodiscovery-Tag zugänglich. - Ein Feed deckt nur aktuelle URLs ab. Er ergänzt eine vollständige XML-Sitemap – ersetzt sie aber nie. Google empfiehlt, beide zu verwenden.
- Feedfetcher ist der Crawler von Google für RSS/Atom-Feeds, dokumentiert speziell für Google News und WebSub – Google gibt nicht an, dass er der Fetcher hinter jedem über die Suche eingereichten Sitemap-Feed ist. Er ignoriert robots.txt absichtlich – um ihn zu blockieren, geben Sie einen 4xx-Status zurück, kein Disallow. Er ruft nur die Feed-URL ab (er folgt keinen Links innerhalb des Feeds).
- Die Feed-Identität ist kein Suchsteuerungselement. Eine
guid/idgibt einem Element eine stabile Identität innerhalb des Feeds; sie ist keine kanonische Anweisung.X-Robots-Tag: noindexauf einer Feed-Antwort setzt voraus, dass der Crawler bereits darauf zugreifen kann, und ist keine Zugriffskontrolle. - Pull vs. Push: Feeds sind Pull. WebSub macht sie für Google zu Push (Broadcast von Feed-Änderungen). Für Bing ist IndexNow jetzt der bevorzugte Echtzeit-Push und ersetzt das alte Muster „Bing überwacht Ihr RSS”.
- mRSS kann Videodetails enthalten; Feeds können keine Bilder oder Nachrichten beschreiben.
- Grenzen: nur aktuelle URLs, keine Indexierungsgarantie und kein Ranking-Vorteil – Feeds beschleunigen die Discovery, sonst nichts.
Offizielle Dokumentation
Primärquellen-Dokumentation der Suchmaschinen.
- Sitemap erstellen und einreichen – Akzeptanz von RSS 2,0 / Atom 1,0, Einreichen eines Feeds als Sitemap, der Hinweis „nur aktuelle URLs”, mRSS für Videos und WebSub.
- Feedfetcher – wie der dedizierte Feed-Crawler von Google funktioniert und warum er robots.txt ignoriert (mit 4xx blockieren).
- Best Practices für XML-Sitemaps und RSS/Atom-Feeds (2014) – Googles Empfehlung „beides verwenden”: Sitemap für Abdeckung, Feed für Aktualität.
- Verwenden von RSS/Atom-Feeds zum Entdecken neuer URLs (2009) – Googles ursprüngliche Ankündigung von Feeds als Discovery-Methode.
Bing / Microsoft
- Inhalte mit Sitemaps in der KI-gestützten Suche auffindbar halten (Juli 2025) – Bings aktuelle Anleitung mit Schwerpunkt auf XML +
lastmod+ IndexNow. - Bis zu 10 000 URLs pro Tag bei Bing einreichen (2019) – die Aussage von Fabrice Canel zur Ersetzung der RSS-Überwachung durch direkte Benachrichtigung.
Zitate aus der Quelle
Aussagen von Google und Bing, die öffentlich dokumentiert sind. Jeder Link ist ein Deep-Link, der direkt zur zitierten Passage auf der Quellseite springt.
Google – Feeds als Discovery-Format
- “Google accepts RSS 2.0 and Atom 1.0 feeds.” — Google Search Central docs. Jump to quote
- “If you use Atom or RSS, you can use WebSub to broadcast your changes to search engines, including Google.” Jump to quote
Bing / Microsoft
- “Instead of Bing continually monitoring RSS and similar feeds or frequently crawling websites to check for new pages, discover content changes and/or new outbound links, websites will notify Bing directly about relevant URLs changing on their website.” (Übersetzung) „Statt dass Bing kontinuierlich RSS und ähnliche Feeds überwacht oder Websites häufig crawlt, um neue Seiten, Inhaltsänderungen und/oder neue ausgehende Links zu entdecken, werden Websites Bing direkt über relevante URL-Änderungen auf ihrer Website benachrichtigen.” – Microsoft Bing, zu IndexNow / URL-Einreichung. Zum Zitat springen
Checkliste für das Feed-Setup-Audit
Gehen Sie dies durch, bevor Sie einen Feed als „fertig“ betrachten. Es ist derselbe Grund wie die Einrichtungsschritte im Tab „Erweitert“, hier als Bestanden/Nicht bestanden-Liste umformuliert:
- Feed validiert als wohlgeformtes RSS 2,0 oder Atom 1,0 – kein kaputtes XML, nicht maskierte kaufmännische Und-Zeichen oder ungeschlossene Tags.
- Jedes Element hat einen echten, eindeutigen
<link>, der auf eine absolute URL zeigt (kein relativer Pfad, kein Platzhalter). - Jedes Element hat ein
pubDate(RSS) oderupdated/published(Atom) – ein Feed ohne Daten gibt Crawlern nichts, anhand dessen sie „aktuell“ beurteilen können. - Die Anzahl der Elemente entspricht Ihrem tatsächlichen aktuellen Zeitfenster (ungefähr Ihre letzten paar Dutzend Beiträge) – nicht auf 3–5 gekürzt, nicht auf Ihr gesamtes Archiv aufgebläht.
- Volltext vs. Zusammenfassung ist eine bewusste Entscheidung, kein Standard – wägen Sie den Lesekomfort in Feed-Readern gegen Lizenzierung, Wiederveröffentlichungs-/Scraping-Risiko und ab, wie viel Sie den Klick auf Ihre eigene Website schützen möchten. Dies ist in keinem Fall ein dokumentierter Google-Such-Rankingfaktor; was auch immer Sie wählen, halten Sie das Markup des Elements gültig und seine Eintragsidentität (guid/id) stabil.
- Autodiscovery-Tag ist im
<head>vorhanden:<link rel="alternate" type="application/rss+xml" title="Feed" href="/feed.xml">. - Die HTTP-Antwort des Feeds hat den korrekten
Content-Type(application/rss+xmloderapplication/atom+xml), nichttext/html. - Feed-URL als Sitemap in beiden Google Search Console und Bing Webmaster Tools eingereicht.
- Feed-URL ist nicht in
robots.txtgesperrt, wenn Sie tatsächlich möchten, dass Feedfetcher und Feed-Reader sie erreichen (ein Disallow stoppt Feedfetcher ohnehin nicht – siehe Tab „Anti-Patterns“). - Eine vollständige XML-Sitemap existiert weiterhin und wird separat eingereicht – der Feed ist die Aktualitätsebene, nicht die gesamte Karte.
- WebSub konfiguriert, wenn Sie Push-Erkennung für Google möchten; IndexNow konfiguriert, wenn Sie Push-Erkennung für Bing möchten.
Die mentalen Modelle
1. Feed = Aktualitätsebene, Sitemap = vollständige Karte. Fragen Sie nicht „Feed oder Sitemap“ – es ist keine Wahl. Die Sitemap beantwortet „Was existiert auf dieser Website?“, der Feed beantwortet „Was hat sich kürzlich geändert?“ Verwenden Sie beide; der Feed ersetzt niemals die Abdeckung der Sitemap.
2. Pull vs. Push und welche Engine welche möchte. Ein Feed allein ist Pull – die Engine ruft ihn nach eigenem Zeitplan erneut ab. WebSub verwandelt das für Google in Push. IndexNow ist Bings bevorzugter Push-Kanal und hat sich über „RSS-Feed überwachen“ hinausentwickelt. Wenn Ihr Ziel eine schnellere Erkennung für eine bestimmte Engine ist, passen Sie den Kanal an die Engine an: WebSub für Google, IndexNow für Bing.
3. Feedfetcher ist nicht Googlebot.
Der dedizierte Feed-Abruf-Bot von Google hat seine eigenen Regeln – am wichtigsten: Er
ignoriert robots.txt. Jede Kontrollentscheidung über eine Feed-URL muss unter Berücksichtigung des Verhaltens dieses Crawlers getroffen werden, nicht des Googlebots.
4. Die Entscheidungsregel für „Hilft ein Feed dieser Website?“ Ein Feed zahlt sich aus, wenn: (a) Sie oft genug neue oder aktualisierte Inhalte veröffentlichen, sodass „aktuell“ ein aussagekräftiges, sich bewegendes Fenster ist, und (b) Sie möchten, dass dieses Aktualitätssignal mehr als nur Suchmaschinen zur Verfügung steht (Feed-Reader, WebSub-Abonnenten, Drittanbieter-Aggregatoren). Eine Website, die sich selten ändert, zieht aus einem Feed wenig zusätzlichen Nutzen über das hinaus, was die Sitemap bereits bietet.
5. Entdeckung, nicht Indexierung, nicht Ranking. Jede Entscheidung hier liegt innerhalb derselben Grenze wie eine Sitemap: Ein Feed kann nur beschleunigen, ob eine URL gefunden und gecrawlt wird. Er hat keinen Einfluss auf Indexierungsentscheidungen oder Rankings.
Feed-Formate – was akzeptiert wird, was erforderlich ist
Als Sitemap-Format-Entdeckungssignal akzeptiert
| Format | Von Google akzeptiert | Von Bing akzeptiert | Hinweise |
|---|---|---|---|
| RSS 2,0 | Ja | Ja | Häufigster CMS-Standard |
| Atom 1,0 | Ja | Ja | |
| Atom 0,3 | Nein | Ja | Bings Dokumentation listet es; als veraltet behandeln |
| mRSS (Media RSS) | Nur Video | Ja (als Sitemap-Format) | Google: nur Video-Metadaten, keine allgemeine Sitemap |
| JSON Feed | Nicht aufgeführt | Nicht aufgeführt | Feed-Reader-Format; keine der Engines dokumentiert es als Sitemap-Eingabe |
Mindestanforderungen an nützliche Elemente pro Eintrag
| Element | RSS 2,0 | Atom 1,0 | Warum es für die Entdeckung wichtig ist |
|---|---|---|---|
| Eintragslink | <link> | <link href> | Die tatsächliche zu crawlende URL – muss absolut sein |
| Datum | <pubDate> | <updated> / <published> | Ermöglicht der Engine zu beurteilen, was “aktuell” ist |
| Titel | <title> | <title> | Kontext für Menschen/Feed-Reader, kein Ranking-Eingabefaktor |
| Eindeutige ID | <guid> (empfohlen) | <id> (erforderlich) | Verhindert, dass derselbe Eintrag erneut als neu verarbeitet wird |
Pull vs. Push, nach Engine
| Engine | Pull (Feed selbst) | Push-Äquivalent |
|---|---|---|
| RSS/Atom, regelmäßig neu abgerufen | WebSub | |
| Bing | RSS/Atom, regelmäßig neu abgerufen | IndexNow (bevorzugt gegenüber Feed-Überwachung) |
Feedfetcher blockieren – so machen Sie es, nicht so
| Ziel | Falsches Werkzeug | Richtiges Werkzeug |
|---|---|---|
| Feedfetcher daran hindern, die Feed-URL zu lesen | robots.txt Disallow (ignoriert) | Einen 4xx-Status (404/410) für die Feed-URL zurückgeben |
Feed-Identität vs. Suchsteuerung – das sind nicht dieselben Mechanismen
Die guid/id eines Feeds und sein link sind Teil der Feed-Spezifikation, keine
Suchdirektiven. Verwenden Sie sie nicht für Kanonisierung oder Zugriffskontrolle,
für die sie nie gedacht waren:
| Steuerung | Was sie tatsächlich tut | Was sie NICHT tut |
|---|---|---|
RSS guid / Atom id | Gibt einem Eintrag eine stabile Identität innerhalb des Feeds, sodass ein Konsument weiß: “gleicher Eintrag, nicht erneut anzeigen” | Sagt Google oder Bing nicht, welche Seiten-URL kanonisch ist |
Eintrags-link (RSS) / link href (Atom) | Weist einen Feed-Reader oder Crawler auf die Ziel-URL | Ist allein kein Kanonisierungssignal |
Kanonische Relation (rel="canonical" oder ein HTTP-Link-Header) | Ein separater Mechanismus, den Sie in der eigenen Antwort des Artikels implementieren, um doppelte URLs zu konsolidieren | Wird nicht automatisch aus guid/id/link eines Feeds abgeleitet |
X-Robots-Tag: noindex auf der Feed-Antwort | Kann eine Suchdirektive auf eine Nicht-HTML-Antwort wie eine Feed-Datei anwenden – wirkt aber nur, wenn der Crawler bereits auf diese Antwort zugreifen kann | Ist kein Zugriffskontrollwerkzeug und verhindert nicht, dass der Feed abgerufen oder syndiziert wird |
| HTTP-Authentifizierung / eine private URL | Schränkt tatsächlich ein, wer den Feed überhaupt abrufen kann | Wird durch keine der obigen Zeilen erreicht |
Zu vermeidende Fehler
Versuch, Feedfetcher mit robots.txt zu blockieren.
Feedfetcher ignoriert robots.txt nachweislich absichtlich – er wird als im Auftrag
eines abonnierten Menschen handelnd behandelt, nicht als autonomer Crawler. Eine
Disallow-Regel für die Feed-URL bewirkt nichts. Stattdessen: Wenn Sie
wirklich verhindern müssen, dass Feedfetcher einen Feed liest, geben Sie für diese
URL einen 4xx-Status (404 oder 410) zurück.
Den Feed als Ersatz für die XML-Sitemap behandeln. Ein Feed listet nur aktuelle Einträge – wenn Sie die Sitemap weglassen, weil “der Feed das abdeckt”, verlieren Sie die Entdeckung für alle älteren Seiten und Archive. Stattdessen: Behalten Sie beides; Googles eigene Empfehlung ist, die Sitemap für vollständige Abdeckung und den Feed als Aktualitätsebene darüber zu verwenden.
Ein Feed ohne pubDate/updated-Element.
Ohne ein Datum für jeden Eintrag gibt es für einen Crawler (oder einen Feed-Reader) nichts, anhand dessen er beurteilen kann, was tatsächlich aktuell ist. Stattdessen: Stellen Sie sicher, dass jeder Eintrag ein echtes, genaues Datum trägt – keinen Build-Zeitstempel, der bei allen Einträgen identisch ist.
Kein Autodiscovery-Tag im <head>.
Ohne <link rel="alternate" type="application/rss+xml" href="..."> können Crawler und Feed-Reader den Feed nur finden, wenn Sie ihn explizit irgendwo einreichen oder verlinken. Stattdessen: Fügen Sie das Autodiscovery-Tag hinzu, damit der Feed auf jeder Seite selbstankündigend ist.
Die Anzahl der Feed-Einträge explodieren oder schrumpfen lassen. Ein Feed mit Ihrem gesamten Archiv ist kein „aktuelles“ Signal mehr; ein auf 2-3 Einträge gekürzter Feed kann eine Reihe von Veröffentlichungen am selben Tag übersehen. Stattdessen: Dimensionieren Sie die Anzahl der Einträge entsprechend Ihrer tatsächlichen Veröffentlichungsfrequenz – genug, um die Lücke zwischen Crawls abzudecken, ohne zu einer zweiten Sitemap zu werden.
Annehmen, dass die RSS-Einreichung heute eine schnellere Bing-Erkennung bedeutet. Das war früher eine vernünftige Annahme; Bings eigene Anleitung hat sich inzwischen in Richtung IndexNow als bevorzugtes Echtzeitsignal bewegt, das ausdrücklich als Ersatz für „kontinuierliches Überwachen von RSS“ formuliert ist. Stattdessen: Behalten Sie die RSS-Einreichung bei (sie ist mit geringem Aufwand verbunden und funktioniert weiterhin), behandeln Sie IndexNow jedoch als primären Hebel für Bing-Aktualität, nicht den Feed.
Beweisen, dass der Feed tatsächlich funktioniert
Bestanden/nicht bestanden-Prüfungen für nach der Veröffentlichung oder Änderung eines Feeds – jeweils mit dem Fehlersignal und dem Zeitpunkt, an dem Sie den Rollback auslösen sollten.
Test: Feed ist wohlgeformtes XML
- Durchzuführender Test: Laden Sie die Feed-URL im W3C Feed Validator.
- Erwartetes Ergebnis: „This is a valid RSS/Atom feed“ ohne Fehler (Warnungen zu optionalen Elementen sind akzeptabel).
- Fehlerinterpretation: Ein Validierungsfehler bedeutet normalerweise wohlgeformtes XML, ein nicht maskiertes Zeichen oder ein fehlendes Pflichtelement – der Feed kann in einem Browser trotzdem angezeigt werden, schlägt aber bei strengeren Parsern fehl.
- Überwachungsfenster: Sofort – direkt nach jeder Änderung an der Feed-Vorlage erneut prüfen.
- Rollback-Auslöser: Jeder Validierungsfehler (keine Warnung) bedeutet, die Vorlagenänderung zurückzusetzen, bis sie wieder sauber validiert.
Test: Korrekter Content-Type-Header
- Durchzuführender Test:
curl -I https://example.com/feed.xmlund denContent-Type-Header lesen. - Erwartetes Ergebnis:
application/rss+xml(RSS) oderapplication/atom+xml(Atom) – nichttext/htmlodertext/plain. - Fehlerinterpretation: Ein
text/html-Content-Type bedeutet normalerweise, dass die Feed-Route vom falschen Handler bedient wird (ein CMS-Catch-all, eine Caching-Schicht, die Header umschreibt). - Überwachungsfenster: Sofort.
- Rollback-Auslöser: Falscher Content-Type auf der Live-Feed-URL – korrigieren Sie die Serverkonfiguration, bevor Sie sich für die Erkennung auf den Feed verlassen.
Test: Sitemap-Einreichung akzeptiert
- Durchzuführender Test: Reichen Sie die Feed-URL unter Sitemaps in Google Search Console und unter Sitemaps in Bing Webmaster Tools ein.
- Erwartetes Ergebnis: Status zeigt „Success“ (Google) oder einen verarbeiteten/validierten Zustand (Bing). Keine der beiden Suchmaschinen dokumentiert eine garantierte Anzahl erkannter URLs oder ein verbindliches Verarbeitungsfenster – eine Anzahl erkannter URLs größer als null ist ein gutes Zeichen, aber behandeln Sie es als Beobachtung, nicht als eigenständige Bestanden/nicht bestanden-Anforderung.
- Fehlerinterpretation: Ein Status „Couldn’t fetch“ oder „General HTTP error“ bedeutet normalerweise, dass die Feed-URL blockiert ist, einen Nicht-200-Status zurückgibt oder eine Zeitüberschreitung auftritt.
- Überwachungsfenster: Ein oder zwei Tage nach der Einreichung erneut zu prüfen, ist eine praktische Faustregel, kein dokumentiertes SLA – nach jeder Server- oder CDN-Änderung, die die Feed-Route betrifft, erneut prüfen.
- Rollback-Auslöser: Einreichung bleibt nach einer erneuten Prüfung in einem Fehlerzustand – untersuchen Sie die Serverantwort, bevor Sie annehmen, dass die Suchmaschine es von selbst „herausfindet“.
Test: Autodiscovery-Tag ist vorhanden und korrekt
- Durchzuführender Test: Zeigen Sie den Quelltext einer Seite an, die den Feed bereitstellen soll, und bestätigen Sie, dass das
<link rel="alternate" type="application/rss+xml">-Tag (oderatom+xml) mit dem korrektenhrefvorhanden ist. - Erwartetes Ergebnis: Das Tag existiert im
<head>, und derhrefverweist auf dieselbe Feed-URL, die Sie oben validiert haben. - Fehlerinterpretation: Ein fehlendes Tag bedeutet, dass Crawler und Feed-Reader, die Autodiscovery nutzen, den Feed ohne explizite Einreichung nicht finden können; ein falscher
hrefbedeutet, dass er auf einen veralteten oder toten Feed verweist. - Überwachungszeitraum: Sofort – prüfen Sie direkt nach jeder Vorlagenänderung.
- Rollback-Auslöser: Tag fehlt oder verweist auf einer Live-Seite auf die falsche URL.
Test: Feedfetcher kann nicht durch robots.txt blockiert werden (Bestätigung, dass der Stolperstein für Sie nicht zutrifft)
- Durchzuführender Test: Prüfen Sie
robots.txtauf einDisallow, das den Feed-Pfad abdeckt, und bestätigen Sie dann, dass die Feed-URL bei direktem Abruf weiterhin200zurückgibt. - Erwartetes Ergebnis: Wenn Sie möchten, dass der Feed gecrawlt wird, gibt er
200zurück – ein robots.txt-Disallow allein hätte Feedfetcher nicht gestoppt, aber es ist sinnvoll zu bestätigen, dass der Feed nicht auch aus einem anderen Grund einen Nicht-200-Status zurückgibt. Wenn Sie beabsichtigt haben, Feedfetcher zu blockieren, sollte die URL einen4xx-Status zurückgeben, nicht sich auf das Disallow verlassen. - Fehlerinterpretation: Ein
200, wenn Sie Feedfetcher blockieren wollten, bedeutet, dass die Blockierung tatsächlich nicht greift – die robots.txt-Zeile wird, wie dokumentiert, ignoriert. - Überwachungszeitraum: Sofort.
- Rollback-Auslöser: Der Status der Feed-URL entspricht nicht Ihrer Absicht (blockiert, wenn er offen sein sollte, oder umgekehrt).
Testen Sie sich selbst: RSS-Feeds
Fünf kurze Fragen dazu, wie Suchmaschinen RSS- und Atom-Feeds zur Erkennung nutzen. Wählen Sie für jede eine Antwort und prüfen Sie dann.
Änderungsprotokoll
Aktualisiert am 18. Juli 2026.
Redaktionelle Zusammenfassung und aufgezeichnete Änderungsdetails.Änderungsdetails
-
Detaillierte Änderungsangaben sind derzeit auf Englisch verfügbar.
-
Detaillierte Änderungsangaben sind derzeit auf Englisch verfügbar.
-
Detaillierte Änderungsangaben sind derzeit auf Englisch verfügbar.
-
Detaillierte Änderungsangaben sind derzeit auf Englisch verfügbar.
Vollständiger Vergleich nicht verfügbar — für diese Version wurde kein früherer Schnappschuss archiviert.