RSS Feeds
How search engines use RSS 2.0 and Atom 1.0 feeds as a discovery channel for fresh content — Feedfetcher, robots.txt, WebSub, and why a feed complements but never replaces an XML sitemap.
Google and Bing both accept RSS 2.0 and Atom 1.0 feeds as a sitemap-style discovery signal — but a feed only surfaces your recently changed URLs, so it complements a full XML sitemap rather than replacing it. Google crawls feeds with Feedfetcher, a separate crawler that ignores robots.txt (block it with a 4xx, not a disallow). Feeds are a pull channel; WebSub turns them into push for Google, while IndexNow is now Bing's preferred push signal. Feeds help discovery speed, not rankings, and like sitemaps they never guarantee indexing.
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 — An RSS or Atom feed is an XML file that lists your most recent pages. Search engines can use it to find new content faster — you can submit the feed in Google Search Console or Bing Webmaster Tools, just like a sitemap. But a feed only shows recent URLs, so it works alongside a full XML sitemap, not instead of one. And like a sitemap, it helps a page get found — it doesn’t make you rank higher.
What an RSS feed is
An RSS feed (Really Simple Syndication) or Atom feed is an XML file your site publishes that lists your latest content — usually the last few dozen posts. Most blog and CMS platforms generate one automatically. Readers use feeds to follow your updates in a feed reader, but the same file does double duty: search engines can read it to discover your newest URLs.
How search engines use it
A feed works a lot like a sitemap. Two things can happen:
- You submit it. In Google Search Console or Bing Webmaster Tools, you can add the feed’s URL as a sitemap. The engine then checks it for new pages.
- Crawlers find it on their own. If you put a small autodiscovery tag in your
page’s
<head>— a<link rel="alternate" type="application/rss+xml">line — a crawler can spot your feed without you submitting anything.
Either way, the engine pulls your feed periodically and notices the recently added or changed URLs in it.
The one thing to remember
A feed doesn’t replace your XML sitemap. A feed only lists your recent content — it won’t include your older pages or archives. Google’s own advice is to use both: the sitemap for full coverage of your whole site, and the feed as a freshness signal for what just changed.
And just like a sitemap, a feed only helps with discovery — getting a page found and crawled. It doesn’t guarantee the page gets indexed, and it doesn’t lift your rankings.
Want the deeper version — Feedfetcher (Google’s separate feed crawler), why it ignores robots.txt, WebSub, and how Bing’s guidance has shifted toward IndexNow? Switch to the Advanced 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 and Atom 1.0 are accepted by Google as a sitemap format, and other engines may support feed submission under their current webmaster guidance. A feed only surfaces your recently changed URLs, so it complements a full XML sitemap — it never replaces one. Feeds are a pull channel; WebSub can add publish-subscribe notifications, while IndexNow is a separate URL-notification protocol used by participating engines. Feeds help discovery speed, not rankings, and like sitemaps they never guarantee indexing.
A feed is a sitemap-format discovery signal
If your CMS already publishes an RSS or Atom feed, search engines can use it the
same way they use a sitemap — as a list of URLs to discover. Google is explicit:
“Google accepts RSS 2.0 and Atom 1.0 feeds,” and “if your CMS generates an RSS
or Atom feed, you can submit the feed’s URL as a sitemap.” That submission slot in
Google Search Console takes a feed URL just as happily as a sitemap.xml.
The catch is scope. A full XML sitemap aims to catalog every URL on your site; a feed is a rolling window of your most recent items. Google says it plainly: “This feed only provides information on recent URLs.” So a feed is a freshness signal, not a comprehensive index of your pages. This is exactly how I frame it on the Discovery hub — Google accepts feeds as a sitemap format, but a feed only surfaces your recently changed URLs.
Two different things are true here, and it’s worth keeping them separate: the feed
is recent because of which URLs are currently listed in it — that part is
structural and reliable. What each item’s pubDate/updated value does once a
provider fetches the feed is a separate question; Google and Bing don’t publish a
detailed spec for exactly how they weigh those date fields, so treat them as
useful context you supply, not a documented processing guarantee.
Feeds complement a sitemap — they don’t replace it
This is the myth worth killing up front: “an RSS feed replaces my XML sitemap.” It doesn’t. Google’s documented recommendation is to use both — the sitemap for comprehensive, site-wide coverage (older pages, archives, everything), and the RSS/Atom feed as the freshness layer for what just changed. Drop the sitemap and keep only the feed, and your archive of older URLs loses its most reliable discovery path.
A practical note on what feeds can carry: an mRSS (Media RSS) feed can give Google details about video content, but RSS/Atom feeds can only describe videos — not images or news. For image discovery you still want an image sitemap, and for Google News you submit through News-specific channels. The feed is a discovery aid, not a universal metadata pipe.
Feedfetcher: Google’s feed crawler for News and WebSub — and the robots.txt footgun
Here’s the part most write-ups miss, and worth being precise about scope: Google’s own Feedfetcher documentation describes it narrowly as “how Google crawls RSS or Atom feeds for Google News and WebSub.” That’s the documented use — Google doesn’t say on that page that Feedfetcher is what handles every feed you submit as a sitemap in Search Console, so I won’t generalize it into a claim about the sitemap-submission path. Two things Feedfetcher’s own documentation does establish, for the News/WebSub context it names:
- It ignores robots.txt — by design. Google states it directly: Feedfetcher
doesn’t obey robots.txt rules, because it’s treated as acting on behalf of a
human who explicitly subscribed to the feed — “a direct agent of the human
user, not as a robot.” So if your plan to “block the feed from crawlers” is a
robots.txt
Disallow, it won’t stop Feedfetcher. To actually block Feedfetcher, return a 4xx (404 or 410) for the feed URL — not a disallow. This is the same shape of mistake as trying to deindex a page with robots.txt: you’re reaching for the wrong control. - It crawls only the feed URL, not the links inside it. Google is explicit that “unlike normal web crawlers, Feedfetcher isn’t discovering links to crawl at all; instead, it crawls a single URL that’s provided to it.” It also says Feedfetcher “shouldn’t retrieve feeds from most sites more than once every hour on average,” though frequently-updated sites may be refreshed more often. What Google doesn’t document is what happens next to the URLs inside a feed you submit as a general Search sitemap — that hand-off isn’t described on this page, so treat it as undocumented rather than assuming it flows through Feedfetcher.
How Bing uses feeds — and why IndexNow changed the picture
Bing accepts a broad set of sitemap formats: XML, RSS 2.0, mRSS, Atom 0.3 and Atom 1.0, and plain text. RSS/Atom feeds are a natural fit for blogs that publish frequently, and historically Bing would monitor those feeds to catch new content.
But Bing’s modern guidance has moved on. Its 2025 sitemaps guidance emphasizes XML
with accurate lastmod plus IndexNow as the preferred stack, and notably stops
foregrounding RSS/Atom. The reasoning is in Bing’s own words on 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.” In other words, IndexNow is meant to replace the old
“Bing monitors your RSS feed” pattern with an explicit push. RSS still works with
Bing and submitting it is low-effort — but if you’re choosing where to invest for
Bing freshness, IndexNow is the primary recommendation now.
Pull vs push: where WebSub fits
Feeds are fundamentally a pull channel — the engine re-fetches your feed on its own schedule. To make that a push, you add WebSub (formerly PubSubHubbub). Google supports it: “If you use Atom or RSS, you can use WebSub to broadcast your changes to search engines, including Google.” Instead of waiting to be re-pulled, your feed broadcasts the change to subscribed engines, so the update lands closer to real time. The simplest mental model for the two engines:
- Google: RSS/Atom feed for pull discovery, WebSub to push feed changes.
- Bing: RSS/Atom accepted, but IndexNow is the preferred push for real-time notification.
WebSub is the push complement to RSS — the same way lastmod and IndexNow are
push complements on the sitemap side. (More on the whole pull/push landscape on the
Discovery hub.)
Setting up a feed for discovery
A short, practical checklist:
- Publish a valid RSS 2.0 or Atom 1.0 feed (most CMSes do this automatically). Use absolute URLs inside it, and keep the item count to your recent window.
- Add an autodiscovery tag in your page
<head>so crawlers can find it:<link rel="alternate" type="application/rss+xml" title="Feed" href="/feed.xml">. - Submit the feed URL as a sitemap in Google Search Console and in Bing Webmaster Tools. Autodiscovery alone can work, but explicit submission is more reliable.
- For Google freshness, add WebSub; for Bing freshness, implement IndexNow.
- Don’t block the feed in robots.txt expecting Feedfetcher to obey it — use a 4xx if you genuinely need to block it.
The limits — same as sitemaps
Three honest limits to keep in mind:
- Recent URLs only. A feed is a freshness signal, not full coverage. Keep the XML sitemap for everything else.
- No indexing guarantee. Discovery is not indexing. A feed gets a URL found and crawled sooner; whether it’s indexed is a separate decision.
- Not a ranking signal. Feeds speed up discovery and can help fresh content get picked up before backlinks accrue, but there’s no ranking benefit beyond that — exactly the same as a sitemap.
AI summary
A condensed take on the Advanced version:
- Feeds are a sitemap-format discovery signal. Google accepts RSS 2.0 and
Atom 1.0; Bing accepts RSS 2.0 plus Atom 0.3/1.0 (and mRSS). Submit the feed
URL as a sitemap, or expose it via a
<link rel="alternate">autodiscovery tag. - A feed only covers recent URLs. It complements a full XML sitemap — it never replaces one. Google recommends using both.
- Feedfetcher is Google’s crawler for RSS/Atom feeds, documented for Google News and WebSub specifically — Google doesn’t state it’s the fetcher behind every Search sitemap-submitted feed. It ignores robots.txt by design — to block it, return a 4xx, not a disallow. It fetches only the feed URL (it doesn’t follow links inside the feed).
- Feed identity isn’t a Search control. A
guid/idgives an item stable identity inside the feed; it’s not a canonical directive.X-Robots-Tag: noindexon a feed response requires the crawler to already be able to access it, and isn’t access control. - Pull vs push: feeds are pull. WebSub turns them into push for Google (broadcast feed changes). For Bing, IndexNow is now the preferred real-time push, replacing the old “Bing monitors your RSS” pattern.
- mRSS can carry video details; feeds can’t describe images or news.
- Limits: recent URLs only, no indexing guarantee, and no ranking benefit — feeds speed up discovery, nothing more.
Official documentation
Primary-source documentation from the search engines.
- Build and submit a sitemap — RSS 2.0 / Atom 1.0 acceptance, submitting a feed as a sitemap, the “recent URLs only” caveat, mRSS for video, and WebSub.
- Feedfetcher — how Google’s dedicated feed crawler works and why it ignores robots.txt (block with 4xx).
- Best Practices for XML Sitemaps and RSS/Atom Feeds (2014) — Google’s “use both” recommendation: sitemap for coverage, feed for freshness.
- Using RSS/Atom Feeds to Discover New URLs (2009) — Google’s original announcement of feeds as a discovery method.
Bing / Microsoft
- Keeping Content Discoverable with Sitemaps in AI-Powered Search (July 2025) — Bing’s current guidance emphasizing XML +
lastmod+ IndexNow. - Submit up to 10,000 URLs/day to Bing (2019) — the Fabrice Canel statement on replacing RSS monitoring with direct notification.
Quotes from the source
On-the-record statements from Google and Bing. Each link is a deep link that jumps to the quoted passage on the source page.
Google — feeds as a 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.” — Microsoft Bing, on IndexNow / URL submission. Jump to quote
Feed setup audit checklist
Run through this before you consider a feed “done.” It’s the same ground as the Advanced tab’s setup steps, reframed as a pass/fail list:
- Feed validates as well-formed RSS 2.0 or Atom 1.0 — no broken XML, unescaped ampersands, or unclosed tags.
- Every item has a real, distinct
<link>pointing at an absolute URL (not a relative path, not a placeholder). - Every item has a
pubDate(RSS) orupdated/published(Atom) — a feed with no dates gives crawlers nothing to judge “recent” by. - Item count matches your actual recent window (roughly your last few dozen posts) — not truncated to 3-5, not bloated to your entire archive.
- Full-content vs. summary is a deliberate choice, not a default — weigh reader convenience in feed readers against licensing, republishing/scraping exposure, and how much you want to protect click-through to your own site. This isn’t a documented Google Search ranking factor either way; whichever you choose, keep the item’s markup valid and its entry identity (guid/id) stable.
- Autodiscovery tag is present in
<head>:<link rel="alternate" type="application/rss+xml" title="Feed" href="/feed.xml">. - Feed’s HTTP response has the correct
Content-Type(application/rss+xmlorapplication/atom+xml), nottext/html. - Feed URL submitted as a sitemap in both Google Search Console and Bing Webmaster Tools.
- Feed URL is not disallowed in
robots.txtif you actually want Feedfetcher and feed readers to reach it (a disallow won’t stop Feedfetcher anyway — see the anti-patterns tab). - A full XML sitemap still exists and is submitted separately — the feed is the freshness layer, not the whole map.
- WebSub configured if you want push discovery for Google; IndexNow configured if you want push discovery for Bing.
The mental models
1. Feed = freshness layer, sitemap = full map. Don’t ask “feed or sitemap” — it’s not a choice. The sitemap answers “what exists on this site,” the feed answers “what changed recently.” Use both; the feed never substitutes for the sitemap’s coverage.
2. Pull vs. push, and which engine wants which. A feed by itself is pull — the engine re-fetches it on its own schedule. WebSub turns that into push for Google. IndexNow is Bing’s preferred push channel and has moved past “monitor the RSS feed.” If your goal is faster discovery for a specific engine, match the channel to the engine: WebSub for Google, IndexNow for Bing.
3. Feedfetcher is not Googlebot.
Google’s dedicated feed-fetching bot has its own rules — most importantly, it
ignores robots.txt. Any control decision about a feed URL has to be made with
this crawler’s behavior in mind, not Googlebot’s.
4. The decision rule for “does a feed help this site?” A feed earns its keep when: (a) you publish new or updated content often enough that “recent” is a meaningful, moving window, and (b) you want that freshness signal available to more than just search engines (feed readers, WebSub subscribers, third-party aggregators). A site that rarely changes gets little extra from a feed beyond what the sitemap already provides.
5. Discovery, not indexing, not ranking. Every decision here sits inside the same boundary as a sitemap: a feed can only speed up whether a URL gets found and crawled. It has no lever on indexing decisions or on rankings.
Feed formats — what’s accepted, what’s required
Accepted as a sitemap-format discovery signal
| Format | Accepted by Google | Accepted by Bing | Notes |
|---|---|---|---|
| RSS 2.0 | Yes | Yes | Most common CMS default |
| Atom 1.0 | Yes | Yes | |
| Atom 0.3 | No | Yes | Bing’s docs list it; treat as legacy |
| mRSS (Media RSS) | Video only | Yes (as a sitemap format) | Google: video metadata only, not a general sitemap |
| JSON Feed | Not listed | Not listed | Feed-reader format; neither engine documents it as a sitemap input |
Minimum useful elements per item
| Element | RSS 2.0 | Atom 1.0 | Why it matters for discovery |
|---|---|---|---|
| Item link | <link> | <link href> | The actual URL to crawl — must be absolute |
| Date | <pubDate> | <updated> / <published> | Lets the engine judge what’s “recent” |
| Title | <title> | <title> | Human/feed-reader context, not a ranking input |
| Unique ID | <guid> (recommended) | <id> (required) | Stops the same item being re-processed as new |
Pull vs. push, by engine
| Engine | Pull (feed itself) | Push equivalent |
|---|---|---|
| RSS/Atom, re-fetched periodically | WebSub | |
| Bing | RSS/Atom, re-fetched periodically | IndexNow (preferred over feed monitoring) |
Blocking Feedfetcher — do this, not that
| Goal | Wrong tool | Right tool |
|---|---|---|
| Stop Feedfetcher from reading the feed URL | robots.txt Disallow (ignored) | Return a 4xx (404/410) for the feed URL |
Feed identity vs. Search controls — these are not the same mechanism
A feed’s guid/id and its link are part of the feed spec, not Search
directives. Don’t reach for them to do a canonicalization or access-control job
they were never built for:
| Control | What it actually does | What it does NOT do |
|---|---|---|
RSS guid / Atom id | Gives an item a stable identity within the feed, so a consumer knows “same item, don’t re-show it” | Does not tell Google or Bing which page URL is canonical |
Item link (RSS) / link href (Atom) | Points a feed reader or crawler at the destination URL | Is not a canonicalization signal on its own |
Canonical relation (rel="canonical", or an HTTP Link header) | A separate mechanism you implement on the article’s own response to consolidate duplicate URLs | Is not inferred automatically from a feed’s guid/id/link |
X-Robots-Tag: noindex on the feed response | Can apply a Search directive to a non-HTML response like a feed file — but only takes effect once the crawler can already access that response | Is not an access-control tool and won’t stop the feed from being fetched or syndicated |
| HTTP authentication / a private URL | Actually restricts who can retrieve the feed at all | Not achieved by any of the rows above |
Mistakes to avoid
Trying to block Feedfetcher with robots.txt.
Feedfetcher is documented to ignore robots.txt by design — it’s treated as
acting on behalf of a subscribed human, not as an autonomous crawler. A
Disallow rule on the feed URL does nothing to it. Do instead: if you
genuinely need to stop Feedfetcher from reading a feed, return a 4xx (404 or
410) for that URL.
Treating the feed as a replacement for the XML sitemap. A feed only lists recent items — dropping the sitemap because “the feed covers it” loses discovery for every older page and archive. Do instead: keep both; Google’s own guidance is to use the sitemap for full coverage and the feed as the freshness layer on top of it.
Shipping a feed with no pubDate/updated element.
Without a date on each item, there’s nothing for a crawler (or a feed reader) to
use to judge what’s actually recent. Do instead: make sure every item carries
a real, accurate date — not a build-time timestamp that’s the same across all
items.
No autodiscovery tag in <head>.
Without <link rel="alternate" type="application/rss+xml" href="...">, crawlers
and feed readers can only find the feed if you explicitly submit or link it
somewhere. Do instead: add the autodiscovery tag so the feed is
self-announcing on every page.
Letting the feed’s item count balloon or collapse. A feed with your entire archive stops being a “recent” signal; a feed truncated to 2-3 items can miss a batch of same-day publishes. Do instead: size the item count to your actual publishing cadence — enough to cover the gap between crawls without becoming a second sitemap.
Assuming RSS submission means faster Bing discovery today. This used to be a reasonable assumption; Bing’s own guidance has since moved toward IndexNow as the preferred real-time signal, explicitly framed as a replacement for “continually monitoring RSS.” Do instead: keep the RSS submission (it’s low-effort and still works), but treat IndexNow as the primary lever for Bing freshness, not the feed.
Prove the feed actually works
Pass/fail checks for after you publish or change a feed — each with the failure signal and when to pull the trigger on rolling back.
Test: feed is well-formed XML
- Test to run: Load the feed URL in the W3C Feed Validator.
- Expected result: “This is a valid RSS/Atom feed” with no errors (warnings about optional elements are acceptable).
- Failure interpretation: A validation error usually means malformed XML, an unescaped character, or a missing required element — the feed may still render in a browser but fail for stricter parsers.
- Monitoring window: Immediate — re-check right after any change to the feed template.
- Rollback trigger: Any validator error (not warning) means revert the template change until it re-validates clean.
Test: correct Content-Type header
- Test to run:
curl -I https://example.com/feed.xmland read theContent-Typeheader. - Expected result:
application/rss+xml(RSS) orapplication/atom+xml(Atom) — nottext/htmlortext/plain. - Failure interpretation: A
text/htmlContent-Type usually means the feed route is being served by the wrong handler (a CMS catch-all, a caching layer rewriting headers). - Monitoring window: Immediate.
- Rollback trigger: Wrong Content-Type on the live feed URL — fix the server config before relying on the feed for discovery.
Test: sitemap submission accepted
- Test to run: Submit the feed URL under Sitemaps in Google Search Console and under Sitemaps in Bing Webmaster Tools.
- Expected result: Status shows “Success” (Google) or a processed/valid state (Bing). Neither engine documents a guaranteed discovered-URL count or a committed processing window — a non-zero discovered-URL count is a good sign, but treat it as an observation, not a pass/fail requirement on its own.
- Failure interpretation: A “Couldn’t fetch” or “General HTTP error” status usually means the feed URL is blocked, returning a non-200 status, or timing out.
- Monitoring window: Checking back a day or two after submission is a practical rule of thumb, not a documented SLA — re-check after any server or CDN change that touches the feed route.
- Rollback trigger: Submission stuck in an error state after a re-check — investigate the server response before assuming the engine will “figure it out” on its own.
Test: autodiscovery tag is present and correct
- Test to run: View source on a page that should expose the feed and
confirm the
<link rel="alternate" type="application/rss+xml">(oratom+xml) tag is present with the correcthref. - Expected result: The tag exists in
<head>, and thehrefresolves to the same feed URL you validated above. - Failure interpretation: A missing tag means autodiscovery-based crawlers
and feed readers can’t find the feed without an explicit submission; a wrong
hrefmeans it points at a stale or dead feed. - Monitoring window: Immediate — check right after any template change.
- Rollback trigger: Tag missing or pointing at the wrong URL on a live page.
Test: Feedfetcher can’t be blocked by robots.txt (confirming the footgun doesn’t apply to you)
- Test to run: Check
robots.txtfor aDisallowcovering the feed path, then confirm the feed URL still returns200when fetched directly. - Expected result: If you want the feed crawled, it returns
200— a robots.txt disallow alone won’t have stopped Feedfetcher, but it’s worth confirming the feed isn’t also returning a non-200 for an unrelated reason. If you intended to block Feedfetcher, the URL should return a4xx, not rely on the disallow. - Failure interpretation: A
200when you meant to block Feedfetcher means the block isn’t actually in place — the robots.txt line is being ignored, as documented. - Monitoring window: Immediate.
- Rollback trigger: Feed URL status doesn’t match your intent (blocked when it should be open, or vice versa).
Test yourself: RSS Feeds
Five quick questions on how search engines use RSS and Atom feeds for discovery. Pick an answer for each, then check.
RSS Feeds
An RSS or Atom feed is an XML file listing a site's most recently published or updated URLs. Search engines accept it as a sitemap-style discovery signal for fresh content — not a replacement for a full XML sitemap.
Related: URL discovery, WebSub, Sitemap
RSS Feeds
An RSS feed (Really Simple Syndication, v2.0) or Atom feed (v1.0) is an XML file that lists a site’s most recently published or updated URLs — usually the last 10–50 items. Search engines treat these feeds as an alternate sitemap format: you can submit a feed’s URL in Google Search Console or Bing Webmaster Tools in place of an XML sitemap, or let crawlers find it automatically through a <link rel="alternate"> autodiscovery tag in the page <head>.
The key difference from a full XML sitemap is scope. A sitemap aims to catalog every URL on your site; a feed is a rolling window of recent content only. Google says it directly — “Google accepts RSS 2.0 and Atom 1.0 feeds” — and recommends using both: the sitemap for comprehensive coverage and the feed as a freshness signal that surfaces what just changed. So a feed complements a sitemap; it doesn’t replace one.
Feeds are a pull channel — the engine polls them on its own schedule. To turn that into a push, you add WebSub (formerly PubSubHubbub), which broadcasts feed changes to subscribed engines. On the Bing side, RSS/Atom is still accepted, but IndexNow has become Bing’s preferred way to be notified of changes in real time. As with sitemaps, a feed only helps with discovery — getting a URL crawled — and never guarantees indexing or improves rankings.
Related: URL discovery, WebSub, Sitemap
Build-time retrieval analysis plus live signals for this exact article. The automatic chunk report includes a deterministic readiness score and is ready without a model download.
Search Console
sampleGA4 traffic (28d)
sampleCloudflare traffic (7d)
sampledCrUX field data (28d, phone)
sampleGoogle NLP entities
localChangelog
Updated Jul 18, 2026.
Editorial summary and recorded change details.Summary
Corrected a scope overreach in the Feedfetcher section: Google's Feedfetcher docs are scoped to Google News and WebSub, and that documentation doesn't establish which fetcher handles every Search sitemap-submitted feed. Also added a feed-identity-vs-Search-controls table (guid/id, canonical, X-Robots-Tag, authentication are separate mechanisms), reframed the full-content-vs-summary checklist item as an editorial/rights decision rather than an SEO recommendation, and softened validation-test language that implied guaranteed processing windows or discovered-URL counts.
Change details
-
Rewrote the Advanced 'Feedfetcher' section and the ai-summary bullet to attribute robots.txt-ignoring, link-following, and fetch-frequency facts only to Google's documented Google News/WebSub scope, and removed the unsourced claim that entry URLs are handed off to a general crawl pipeline.
-
Added a 'Feed identity vs. Search controls' table to the Cheat Sheets lens distinguishing RSS guid/Atom id, entry links, the canonical relation, X-Robots-Tag noindex, and authentication.
-
Replaced the categorical 'use full content, not a teaser' checklist item with a short decision framework covering reader utility, licensing, and scraping exposure, and noted it isn't a documented Search ranking factor.
-
Softened the sitemap-submission validation test so its 'discovered-URL count' and '24-48 hour' language reads as an informal observation rather than a documented engine guarantee.
Full comparison unavailable — no prior snapshot was archived for this revision.