Webflow Sitemap Returns application/rss+xml: What It Means and How to Fix It

You're doing your site's technical SEO audit. You check the sitemap content-type header with curl -sI https://your-domain.com/sitemap.xml | grep -i content-type and it comes back:

That's wrong. A sitemap should return application/xml or text/xml. And if your site is on Webflow, you didn't misconfigure anything — this is a known platform-level behaviour that affects a significant portion of Webflow-hosted sites.

This article explains exactly what's happening, whether it actually hurts your rankings, and what your options are to fix it.

What Is application/rss+xml and Why Is It Wrong?

When a browser or bot makes a request for a file, the server responds with a Content-Type header that tells the client what kind of content it's receiving. For a sitemap, the correct values are:

• application/xml — the standard MIME type for XML files
• text/xml — also acceptable, widely supported

application/rss+xml is the MIME type for RSS feeds — the XML format used by blog syndication, podcast feeds, and news aggregators. It's a valid MIME type, but it's semantically wrong for a sitemap. A sitemap is not an RSS feed.

The difference matters because:

• Google Search Console's sitemap validator checks for correct XML MIME types and flags application/rss+xml as an error
• Third-party SEO tools (Screaming Frog, Ahrefs, Semrush) treat it as a misconfiguration
• Some older or strict XML parsers may refuse to process a document served with the wrong MIME type

Why Webflow Sitemaps Have This Bug

Webflow auto-generates a sitemap at /sitemap.xml for every published site. The sitemap XML structure itself is typically correct — it follows the sitemaps.org protocol with proper <urlset> and <url> elements. The problem is in how Webflow's edge infrastructure sets the response headers when serving that file.

The most likely explanation is that Webflow's CDN layer (historically built on Fastly) has a configuration that maps the .xml extension to the application/rss+xml MIME type for certain file routes — possibly because sitemaps in some early Webflow iterations were generated with RSS-format XML. Whatever the origin, it's been reported by Webflow users since at least 2021 and affects sites across multiple Webflow plan tiers.

Does Google Actually Care?

The honest answer: for most Webflow sites, the practical ranking impact is low. Google's sitemap parser reads the XML content of the file and does not strictly require the correct Content-Type. Googlebot can and does process sitemaps served with application/rss+xml — it's been confirmed in multiple developer discussions and Google's own crawlers are built to be forgiving about header mismatches.

However, "Google can probably still parse it" is not the same as "it has no effect." Here's where the wrong Content-Type does cause real problems:

Google Search Console Sitemap Errors

When you submit your sitemap in GSC, the validator checks the response headers. A application/rss+xml response often triggers a "Couldn't fetch" or format error in the coverage report, even if Google is actually reading and processing the sitemap. This means you lose visibility into indexation issues — your GSC sitemap status becomes unreliable.

New Page Indexation Lag

For SaaS sites that regularly publish new pages (feature releases, blog posts, landing pages), sitemap reliability matters. If Googlebot is uncertain about the sitemap's format, it may deprioritise processing it during busy crawl cycles. This can add days to the indexation of new content — not a catastrophic failure, but a meaningful delay if you're in a competitive niche.

SEO Audit Failures

Every SEO audit tool — and every SEO consultant — will flag this. When you're raising funding or going through due diligence, having documented technical SEO failures that you "knew about but didn't fix" looks sloppy. For a funded SaaS company, this is a $0 fix with a non-trivial credibility cost if left unaddressed.

How to Verify Your Sitemap Content-Type

Before you try to fix it, confirm the issue actually exists on your site. Webflow's behaviour has been inconsistent — some plans or regions may have already been patched.

Expected correct output:

Problematic output (the Webflow bug):

How to Fix It

You have three realistic options. They are ordered by effort and control:

Option 1: Contact Webflow Support (Lowest Effort, Variable Success)

Submit a support ticket to Webflow describing the issue: your sitemap at /sitemap.xml returns application/rss+xml instead of application/xml. Reference your plan tier. Some users have reported this being resolved by Webflow on specific plans or site configurations.

This is the right starting point, but don't wait on it. Webflow support response times vary and this type of infrastructure-level bug often gets deprioritised. Move to Option 2 in parallel.

Option 2: Host a Custom Sitemap with Correct Headers (Recommended)

This is the most reliable long-term fix. You create your own sitemap.xml file with the correct URLs, host it somewhere that serves XML with proper headers, and tell Google about it.

The cleanest approach for a Webflow site:

1. Export your current Webflow sitemap: visit your-domain.com/sitemap.xml, save the XML content to a file
2. Host it as a static file on Cloudflare Pages, Netlify, or GitHub Pages — all of these serve XML with correct application/xml headers by default
3. Update your robots.txt (in Webflow Site Settings → SEO → robots.txt) to point to your custom sitemap URL:

4. Submit the new sitemap URL in Google Search Console → Sitemaps
5. Set up a process to keep the custom sitemap updated whenever you add new pages (or generate it programmatically from your Webflow CMS)

Option 3: Use Cloudflare Transform Rules (Most Elegant)

If your site is proxied through Cloudflare (the orange cloud is enabled for your domain in Cloudflare DNS), you can rewrite the Content-Type header at the edge without changing anything about your Webflow setup:

1. In Cloudflare, go to Rules → Transform Rules → Modify Response Headers
2. Create a new rule with the filter: URI Path equals /sitemap.xml
3. Action: Set header content-type to application/xml; charset=utf-8
4. Save and deploy

This fixes the Content-Type header for every request to your sitemap without touching Webflow at all. Googlebot and GSC will now see the correct header.

What Not to Do

A few fixes that sound reasonable but aren't worth the effort:

• Don't disable Webflow's auto-generated sitemap entirely — you lose the auto-update behaviour and then you have to maintain the custom sitemap manually every time pages change
• Don't create a sitemap at a different URL (e.g. /sitemap2.xml) — you end up with two sitemaps and have to manage which one GSC uses
• Don't use a third-party sitemap generator plugin for a plain Webflow site — unnecessary complexity when a static hosted file does the job

Frequently Asked Questions