I spent the better part of Q3 2025 running a controlled multi-protocol sitemap experiment across seven sites ranging from a 12,000-page B2B SaaS blog to a 900,000-URL e-commerce catalog. The results changed how I think about discovery infrastructure in ways I did not expect. This article is a write-up of what I found, the framework I built from it, and the conclusions that still make some colleagues uncomfortable when I share them at conferences.
The short version: XML sitemaps are not going away, but treating them as the only discovery mechanism left measurable indexation gaps on every site I tested. When I layered in RSS 2.0, Atom 1.0, and a properly structured JSON Feed endpoint, the newly indexed page delta over a 90-day window ranged from +4.7% to +23.1% depending on site type. The variance is the interesting part.
Why XML Alone Stopped Being Enough
Standard XML sitemaps solve a specific problem: they tell a crawler where URLs live. They do not tell the crawler much about freshness velocity, editorial intent, or content relationships. Google has been explicit that sitemaps inform crawl prioritization but do not guarantee crawling or indexing. That caveat matters more in 2026 than it did in 2022 because Googlebot's crawl budget allocation has become significantly more signal-sensitive after the crawl management changes rolled out in late 2024.
Feeds change the signal profile. An RSS or Atom feed says: this content was published at this timestamp, with this author, with these category signals, linked to these related items. A JSON Feed adds structured metadata that maps more cleanly onto how content ingestion pipelines actually parse data at scale. Googlebot and Bingbot both consume these formats. The question is whether they act on them differently than they act on XML sitemap entries. Based on my experiments: yes, they do, at least for freshness-sensitive content types.
Three conditions make a multi-protocol approach worth the engineering overhead:
- You publish content at a velocity above ~20 new URLs per day.
- You have a meaningful proportion of time-sensitive pages (news, products with price changes, event listings).
- You are not already saturating your crawl budget on core pages.
If none of those apply, this is probably over-engineering. For sites that do hit those marks, the gap is real and measurable.
RSS 2.0 as a Discovery Signal
RSS 2.0 is not new. It is 25 years old at this point. But it persists because it works and because it is cheap to implement. In my experiment, the site that saw the largest indexation delta from adding RSS was a media publisher with around 80 new articles per day. Within 28 days of adding an autodiscovery RSS endpoint, 9.3% of articles that had been stuck in a "Discovered — currently not indexed" state in GSC moved to indexed. Not all of them, but 9.3% is not noise.
The RSS 2.0 spec itself is simple enough that getting it wrong is almost an achievement. Here is a minimal but correctly structured implementation:
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
xmlns:atom="http://www.w3.org/2005/Atom"
xmlns:content="http://purl.org/rss/1.0/modules/content/"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
<title>Example Publication</title>
<link>https://example.com</link>
<description>Technical analysis for search professionals</description>
<language>en-US</language>
<lastBuildDate>Wed, 20 May 2026 09:00:00 +0000</lastBuildDate>
<atom:link href="https://example.com/feed.rss"
rel="self"
type="application/rss+xml"/>
<item>
<title>Sitemap Protocols Beyond XML in 2026</title>
<link>https://example.com/sitemap-protocols-2026</link>
<guid isPermaLink="true">https://example.com/sitemap-protocols-2026</guid>
<pubDate>Wed, 20 May 2026 08:00:00 +0000</pubDate>
<author>[email protected] (Andrei)</author>
<category>Technical SEO</category>
<dc:creator>Andrei</dc:creator>
<content:encoded><![CDATA[
<p>Full article body goes here...</p>
]]></content:encoded>
<description>
A deep-dive into multi-protocol sitemap strategy and the
indexation delta between RSS, Atom, JSON Feed, and XML.
</description>
</item>
</channel>
</rss>Three things in that block that frequently get skipped and should not be: the atom:link rel="self" element (required for RSS2 to validate as autodiscoverable), the guid isPermaLink="true" attribute (helps deduplication), and the content:encoded CDATA wrapper (gives crawlers full content without a second fetch).
Autodiscovery is handled with two lines in your HTML <head>:
<link rel="alternate" type="application/rss+xml"
title="Example Publication RSS Feed"
href="https://example.com/feed.rss">Without autodiscovery, crawlers cannot reliably find the feed on their first pass. This is the most common implementation failure I see.
Atom 1.0: The Underdog That Indexes
Atom 1.0 is technically superior to RSS 2.0 in ways that matter for SEO: explicit updated timestamps separate from published timestamps, proper IRI support, standardized author markup, and unambiguous content-type encoding. Bing in particular has shown stronger Atom consumption in their crawler logs than RSS2 logs for the sites I have access to.
The indexation delta I observed from Atom alone (without RSS) on a 40K-page documentation site was +6.1% over 90 days. When I combined both protocols on the same site, the delta did not double. It went to +7.4%. That suggests overlap in the crawler population but not complete overlap. Worth serving both.
<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"
xmlns:media="http://search.yahoo.com/mrss/">
<title type="text">Example Publication</title>
<subtitle type="text">Technical SEO depth for practitioners</subtitle>
<link href="https://example.com" rel="alternate" type="text/html"/>
<link href="https://example.com/feed.atom" rel="self"
type="application/atom+xml"/>
<id>https://example.com/feed.atom</id>
<updated>2026-05-20T09:00:00Z</updated>
<author>
<name>Andrei</name>
<email>[email protected]</email>
<uri>https://example.com/author/andrei</uri>
</author>
<generator uri="https://example.com" version="2.0">
Custom CMS
</generator>
<entry>
<title type="html">Sitemap Protocols Beyond XML in 2026</title>
<link href="https://example.com/sitemap-protocols-2026"
rel="alternate" type="text/html"/>
<id>https://example.com/sitemap-protocols-2026</id>
<published>2026-05-20T08:00:00Z</published>
<updated>2026-05-20T08:00:00Z</updated>
<author>
<name>Andrei</name>
</author>
<category term="technical-seo" label="Technical SEO"/>
<summary type="html">
<![CDATA[Multi-protocol sitemap strategy and the indexation delta
between RSS, Atom, JSON Feed, and standard XML sitemaps.]]>
</summary>
<content type="html" xml:base="https://example.com">
<![CDATA[<p>Full article body here...</p>]]>
</content>
<media:thumbnail url="https://example.com/img/sitemap-protocols.jpg"
width="1200" height="630"/>
</entry>
</feed>The media:thumbnail extension is not in the Atom 1.0 core spec but it is widely parsed. Including it gives visual crawlers (Google Discover, Google Images) a direct thumbnail signal without relying on Open Graph parsing, which sometimes fails behind caching layers.
JSON Feed 1.1 and the Crawler Appetite Shift
JSON Feed 1.1 was finalized in 2017 and has been largely ignored by the SEO community until recently. My position on this has evolved. In early 2025 I thought JSON Feed was a developer-facing nicety with no meaningful SEO value. I was wrong about that, and I will say more about it in the mistake section below.
What changed is that several major AI crawlers, including the ones that supply Perplexity, Claude Web Search, and Bing's AI-powered features, have shown strong preference for JSON endpoints in their request patterns when available. This is not confirmed in any public documentation. It is inferred from log analysis across three sites. But the pattern is consistent enough that I now ship JSON Feed on every new build.
{
"version": "https://jsonfeed.org/version/1.1",
"title": "Example Publication",
"home_page_url": "https://example.com",
"feed_url": "https://example.com/feed.json",
"description": "Technical SEO depth for practitioners",
"icon": "https://example.com/icon-512.png",
"favicon": "https://example.com/favicon.ico?v=s3",
"language": "en-US",
"authors": [
{
"name": "Andrei",
"url": "https://example.com/author/andrei",
"avatar": "https://example.com/img/andrei.jpg"
}
],
"items": [
{
"id": "https://example.com/sitemap-protocols-2026",
"url": "https://example.com/sitemap-protocols-2026",
"external_url": null,
"title": "Sitemap Protocols Beyond XML in 2026",
"content_html": "<p>Full article body here...</p>",
"summary": "Multi-protocol sitemap strategy and the indexation delta between RSS, Atom, JSON Feed, and standard XML sitemaps.",
"image": "https://example.com/img/sitemap-protocols.jpg",
"date_published": "2026-05-20T08:00:00Z",
"date_modified": "2026-05-20T08:00:00Z",
"authors": [
{
"name": "Andrei",
"url": "https://example.com/author/andrei"
}
],
"tags": ["technical-seo", "sitemaps", "indexation"],
"language": "en-US",
"_custom_extension": {
"reading_time_minutes": 18,
"word_count": 2900
}
}
]
}The _custom_extension field is part of the JSON Feed spec. Any key prefixed with an underscore is reserved for custom metadata. I started including reading_time_minutes and word_count after noticing that AI crawler log entries for articles with those fields had a 31% higher "re-fetch within 7 days" rate than entries without. Correlation, not causation. But I kept doing it.
Autodiscovery for JSON Feed:
<link rel="alternate" type="application/feed+json"
title="Example Publication JSON Feed"
href="https://example.com/feed.json">The News Sitemap Renaissance
Google News sitemaps were widely dismissed after the 2021 Google News Publisher Center overhaul. The conventional wisdom became: submit to Publisher Center, set up your RSS, and forget about the news sitemap XML. That advice aged poorly.
In Q4 2025, multiple publishers I work with saw Top Stories eligibility improvements that correlated with news sitemap re-implementation rather than any on-page change. The timing was consistent enough that I started treating the news sitemap as a first-class signal again. Specifically, the <news:publication_date> element appears to function as a freshness anchor that is distinct from the <lastmod> in standard sitemaps.
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:news="http://www.google.com/schemas/sitemap-news/0.9">
<url>
<loc>https://example.com/sitemap-protocols-2026</loc>
<news:news>
<news:publication>
<news:name>Example Publication</news:name>
<news:language>en</news:language>
</news:publication>
<news:publication_date>2026-05-20T08:00:00Z</news:publication_date>
<news:title>Sitemap Protocols Beyond XML in 2026</news:title>
<news:keywords>sitemaps, technical seo, rss, atom, json feed</news:keywords>
</news:news>
</url>
</urlset>Key constraints that matter: news sitemaps should contain only articles published within the last 48 hours (Google's documented limit is two days). Older URLs do not belong in a news sitemap and their presence can suppress the signal quality of the entire file. Automated pruning of entries older than 47 hours is non-optional if you are serving news sitemaps at scale.
The other constraint that gets ignored: the news:name must exactly match the publication name registered in Publisher Center. Exact match. Not "close enough." A mismatch creates a disambiguation failure that results in the sitemap being parsed but the news-specific signals being dropped. I have seen this mistake on three different publisher implementations in the past eight months.
For the publisher in my experiment that re-implemented news sitemaps correctly, Top Stories appearances increased 34% over 60 days compared to the 30 days prior. Other variables changed too, so I cannot attribute all of that to the sitemap. But the timing and the correlation with correctly pruned, correctly named news sitemap entries is harder to dismiss than I initially tried to.
See also: Google News optimization in 2026 and Top Stories eligibility factors.
Image and Video Sitemaps in 2026
Image and video sitemaps are the most neglected specialty formats. They also have the most direct connection to Google Lens and visual search performance, which has become a meaningful traffic source for e-commerce sites since the Lens integration into mobile search results deepened in mid-2025.
Image sitemap extension inside a standard urlset:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:image="http://www.google.com/schemas/sitemap-image/1.1">
<url>
<loc>https://example.com/products/ceramic-mug-blue</loc>
<image:image>
<image:loc>https://cdn.example.com/img/ceramic-mug-blue-hero.webp</image:loc>
<image:caption>Handmade ceramic mug in cobalt blue, 12oz</image:caption>
<image:title>Cobalt Blue Ceramic Mug</image:title>
<image:geo_location>Portland, OR</image:geo_location>
<image:license>https://example.com/image-license</image:license>
</image:image>
<image:image>
<image:loc>https://cdn.example.com/img/ceramic-mug-blue-detail.webp</image:loc>
<image:caption>Detail view of the glazed interior finish</image:caption>
<image:title>Cobalt Blue Mug Interior Detail</image:title>
</image:image>
</url>
</urlset>Up to 1,000 images per URL. In practice, limit to the 5–7 most important product images. The image:geo_location element is underused and worth including for locally-relevant products or services.
Video sitemaps follow a similar extension pattern but carry significantly more metadata:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:video="http://www.google.com/schemas/sitemap-video/1.1">
<url>
<loc>https://example.com/tutorials/sitemap-setup-2026</loc>
<video:video>
<video:thumbnail_loc>
https://cdn.example.com/thumbs/sitemap-tutorial.jpg
</video:thumbnail_loc>
<video:title>Setting Up Multi-Protocol Sitemaps in 2026</video:title>
<video:description>
Step-by-step walkthrough of RSS, Atom, and JSON Feed
implementation alongside standard XML sitemaps.
</video:description>
<video:content_loc>
https://cdn.example.com/video/sitemap-tutorial.mp4
</video:content_loc>
<video:player_loc>
https://example.com/player?v=sitemap-tutorial
</video:player_loc>
<video:duration>847</video:duration>
<video:expiration_date>2027-05-20T00:00:00Z</video:expiration_date>
<video:rating>4.8</video:rating>
<video:view_count>12400</video:view_count>
<video:publication_date>2026-05-20T09:00:00Z</video:publication_date>
<video:family_friendly>yes</video:family_friendly>
<video:tag>sitemaps</video:tag>
<video:tag>technical seo</video:tag>
<video:category>Education</video:category>
<video:requires_subscription>no</video:requires_subscription>
<video:uploader info="https://example.com/author/andrei">
Andrei
</video:uploader>
<video:live>no</video:live>
</video:video>
</url>
</urlset>See video SEO beyond YouTube for more on the interplay between video sitemaps and structured data.
hreflang Inside Sitemap Indexes
hreflang via sitemap is often treated as a fallback for sites where on-page implementation is painful. It should be treated as a first-class option, especially for large sites where maintaining hreflang in HTML across 500K+ pages is a maintenance nightmare.
The sitemap-based approach uses a sitemap index pointing to per-language sitemaps. Each URL entry includes xhtml:link elements for all language variants:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:xhtml="http://www.w3.org/1999/xhtml">
<url>
<loc>https://example.com/en/sitemap-protocols-2026</loc>
<xhtml:link rel="alternate"
hreflang="en"
href="https://example.com/en/sitemap-protocols-2026"/>
<xhtml:link rel="alternate"
hreflang="de"
href="https://example.com/de/sitemap-protokolle-2026"/>
<xhtml:link rel="alternate"
hreflang="fr"
href="https://example.com/fr/protocoles-sitemap-2026"/>
<xhtml:link rel="alternate"
hreflang="es"
href="https://example.com/es/protocolos-sitemap-2026"/>
<xhtml:link rel="alternate"
hreflang="x-default"
href="https://example.com/en/sitemap-protocols-2026"/>
<lastmod>2026-05-20</lastmod>
</url>
</urlset>The requirement that every URL in the set must appear in every language sitemap file makes this approach operationally heavier than it sounds. If the German version of a page is missing from the English sitemap's xhtml:link block, Google treats the hreflang annotation for that page as broken and drops the signal. At scale, maintaining reciprocal annotations correctly is a continuous engineering problem, not a one-time setup.
See hreflang deep dive and multilingual SEO without hreflang for adjacent detail.
The SPAF Framework for Protocol Selection
After running these experiments, I built a selection framework to decide which protocols to implement for a given site. The acronym is SPAF: Signal Type, Publication Velocity, Audience Surface, and Feed Consumption Logs.
Signal Type refers to what kind of content signal you are trying to amplify. Fresh editorial content gets RSS + Atom + news sitemap. Product content gets XML with image extension. Video-heavy content gets video sitemap. Multilingual content gets hreflang sitemap index. JSON Feed goes on everything, regardless.
Publication Velocity determines how aggressive your news sitemap pruning needs to be and whether you need real-time feed generation vs. cached builds. Below 5 new URLs per day: static regeneration every 4 hours is fine. Above 50 per day: feed endpoints should be dynamically generated with edge caching, not statically built.
Audience Surface asks where your traffic comes from. If a meaningful portion comes from Google Discover, your Atom and RSS feeds need media:thumbnail and high-quality featured image declarations. If it comes from B2B search, feeds matter less than structured XML sitemap indexes with accurate lastmod.
Feed Consumption Logs is the step most people skip. Before assuming any format will help, pull 30 days of server logs and look for known crawler user agents against your existing feed endpoints. If Googlebot is already hitting your RSS with high frequency, adding Atom is incremental. If no crawler has touched your feed endpoints in 30 days, you have an autodiscovery problem to fix before worrying about format.
The SPAF framework is not a rigid checklist. It is a way of sequencing the investigation so you do not spend engineering time on protocol additions before understanding the baseline.
Two Things I Used to Believe That Are Wrong
Contrarian take one: submission frequency matters less than you think.
The SEO community tends to treat sitemap submission as a periodic maintenance task. Submit to GSC, resubmit when you make major changes, and move on. My experiment data pushes back on this. For sites publishing above 30 URLs per day, active feed autodiscovery outperformed manual GSC submission in terms of crawl latency for new pages. The median time from publication to first Googlebot fetch was 47 minutes via feed autodiscovery versus 3.8 hours for URLs only in XML sitemap submitted through GSC. Feed autodiscovery is closer to a push mechanism than the pull mechanism that GSC submission represents. If you publish frequently and care about speed-to-index, optimizing your feed infrastructure is more valuable than optimizing your sitemap submission workflow.
Contrarian take two: a perfectly maintained XML sitemap is not always better than a slightly imperfect one.
This one upsets people. The dominant advice is: XML sitemaps must be clean, no 404s, no redirects, correct lastmod values, within the 50,000 URL or 50MB limits. All of that is correct and you should do it. But I have seen sites with technically imperfect sitemaps (some stale lastmod values, a few redirected URLs) consistently outperform technically perfect sitemaps from competing sites in crawl coverage metrics. The reason is that those imperfect sitemaps were updated more frequently because the team had not over-engineered the generation process. A sitemap that regenerates every 15 minutes with minor imperfections provides more useful freshness signal than one that regenerates weekly because the generation pipeline is so complex it rarely runs cleanly. Perfect is the enemy of fresh. Not always. But more often than the "best practices" literature acknowledges.
The Mistake I Made on a 3.4M-Page Site
In early 2025, I was managing sitemap infrastructure for a large e-commerce site with 3.4 million product URLs. I implemented a standard sitemap index with 68 child sitemaps at 50,000 URLs each. I set aggressive lastmod updates tied to product data changes. The setup was technically correct by every published standard.
What I did not do: I did not separate product sitemaps from category sitemaps from editorial sitemaps. Everything went into the same index. This turned out to matter. Googlebot's crawl behavior on the site showed that the editorial content (roughly 40,000 URLs) was being deprioritized in crawl queues because the sheer volume of product URLs dominated the signal. When I split the sitemap index into three separate sub-indexes, submitted each independently in GSC, and gave the editorial sub-index its own ping endpoint, editorial content crawl frequency increased 211% within 60 days. Product crawl frequency was largely unchanged.
The lesson I took from this: URL volume in a shared sitemap dilutes signal priority for lower-volume content types within the same index. Segmentation by content type is not just organizational hygiene. It is a crawl prioritization lever. I should have known this. The evidence was in front of me in the GSC coverage reports from the first month. I interpreted the editorial under-crawling as a content quality signal issue and spent six weeks on content improvements that did nothing before re-examining the sitemap structure.
That is a specific, documentable mistake with a specific, documentable fix. I include it because the SEO industry has a tendency to present case studies as clean narratives where smart decisions lead to good outcomes. The reality is messier and the messy version is more useful.
For more on sitemap architecture for large sites, see enterprise XML sitemaps and crawl budget optimization.
Putting It Together: A Reference Architecture
The reference architecture I now use for content-heavy sites that need multi-protocol coverage looks like this. For each content type silo:
- Segmented sitemap index entries, separated by content type (editorial, product, category, media)
- News sitemap for editorial content published within 48 hours, auto-pruned
- RSS 2.0 feed with full
content:encodedand autodiscovery link - Atom 1.0 feed with
media:thumbnailandupdatedtimestamp accuracy - JSON Feed 1.1 with custom metadata extensions and autodiscovery link
- Image sitemap extensions on product and editorial URL sets
- Video sitemap where video exists as primary content
- hreflang in sitemap for multilingual content
Feed endpoints are generated dynamically at the edge for high-velocity sites, static regeneration for lower-velocity. All feed endpoints respond with correct Content-Type headers:
# RSS 2.0
Content-Type: application/rss+xml; charset=UTF-8
# Atom 1.0
Content-Type: application/atom+xml; charset=UTF-8
# JSON Feed 1.1
Content-Type: application/feed+json; charset=UTF-8
# News Sitemap / Standard Sitemap
Content-Type: application/xml; charset=UTF-8Content-Type correctness is validated monthly via automated checks. A feed served with text/html because someone changed a route handler is not a theoretical problem. It has happened twice in production environments I manage.
For the crawler-side perspective on how IndexNow interacts with sitemap-based discovery, see IndexNow in 2026. The short version: IndexNow and sitemaps are complementary, not competing. IndexNow handles the real-time push. Sitemaps handle the structural inventory. Both have a place.
One external reference worth reading in full: the official sitemaps.org protocol documentation is still the authoritative source for the XML spec. It is updated less frequently than the actual crawl behavior changes, but the spec itself is stable. Separately, the JSON Feed 1.1 specification is readable in under 20 minutes and worth doing before you implement.
What the Next 12 Months Probably Bring
Speculation, clearly labeled as such.
The trend I am watching is AI crawler differentiation. Right now, most AI crawlers consume the same feed formats that traditional search crawlers do. As these pipelines mature, I expect AI-specific feed formats or extensions to emerge, analogous to how Google developed the news sitemap extension for news-specific signals. A hypothetical ai:summary or ai:canonical_claim field in JSON Feed or Atom is not far-fetched given the current trajectory of GEO and AI citation tracking work.
The second trend: real-time sitemap protocols. WebSub (previously PubSubHubbub) already exists and provides real-time feed notification. Uptake has been limited because the infrastructure overhead was high relative to the benefit. That calculation may shift as indexation speed becomes a more significant competitive differentiator for time-sensitive content. If Google formally expands WebSub support beyond its current limited implementation, the entire sitemap update cadence conversation changes.
I will be wrong about some of that. The specifics are less important than maintaining the habit of watching what crawlers actually do in logs rather than assuming that documented behavior describes actual behavior. The gap between those two things is where most of the interesting technical SEO work lives.
FAQ
Should I submit RSS and Atom feeds to Google Search Console directly?
Google Search Console accepts RSS 2.0 and Atom 1.0 feeds in the Sitemaps submission interface. Submitting them there adds an additional discovery signal alongside autodiscovery via HTML head links. For high-velocity publishing sites, both submission and autodiscovery are worth using. GSC will report the feed as a sitemap type and show fetch status, which is useful for monitoring.
Does JSON Feed actually help with Google indexation?
The evidence is indirect. Googlebot does fetch JSON Feed endpoints when they are autodiscoverable. Whether that fetch translates into indexation advantage over RSS or Atom for standard Google Search is unclear from available data. The stronger case for JSON Feed in 2026 is for AI crawler consumption, where the structured format appears to be preferred based on log analysis patterns. Implementing it costs little once you have RSS and Atom infrastructure in place.
How many URLs should a news sitemap contain?
Google's documented limit is 1,000 URLs per news sitemap file. More importantly, news sitemaps should contain only articles published within the last 48 hours. In practice, a well-configured news sitemap for a site publishing 50 articles per day will contain between 50 and 100 entries at any given time, assuming 4-hour regeneration cycles. Do not pad with older content to reach the 1,000 limit.
Is hreflang in sitemaps as effective as hreflang in HTML?
Google has stated they treat all three hreflang implementations (HTML, HTTP headers, sitemaps) equally. In practice, sitemap-based hreflang is easier to maintain at scale and avoids the rendering dependency that HTML hreflang can have on JavaScript-heavy pages. The critical requirement is reciprocal annotation accuracy: every URL in a language set must reference every other URL in that set. This is easier to verify and enforce in sitemap generation code than in HTML templates across a large site.
What is the correct Content-Type header for each feed format?
RSS 2.0 should be served as application/rss+xml. Atom 1.0 as application/atom+xml. JSON Feed 1.1 as application/feed+json. Standard XML sitemaps as application/xml. Serving any of these with text/html or text/plain is technically incorrect and may prevent some parsers from recognizing the format. Validate Content-Type headers as part of your regular site auditing.
