Your RSS Feed Returns 403 to Feed Readers and Agents: Cloudflare and Firewall Rules That Block It

Cloudflare's Bot Fight Mode and its "block AI bots" switch can answer your RSS feed with a 403 challenge page, and a feed reader or AI agent has no way to solve one. On 1 November 2026 we requested 29 live feeds with three client identities. Two of the 12 behind Cloudflare refused us. None of the 17 others did. This guide shows how to see which kind of refusal you have, and the narrow fix that keeps your bot protection on.

Quick summary

Direct answer: request the feed with curl -sI, read the status and the cf-mitigated header, then add one Cloudflare custom rule with the Skip action that matches only your feed paths. Do not allow-list the whole site.

Why a working feed returns 403

A feed is a plain file, but Cloudflare's bot products judge the requester, not the file. According to Cloudflare's own Bot Fight Mode documentation, the product issues challenges to traffic that matches known bot patterns, and it "may challenge API or mobile app traffic." A feed reader is that kind of traffic. Open RSS made the same point in October 2024: with Bot Fight Mode or the "AI scrapers and crawlers" option on, readers get a human-verification page they can never complete.

Check E5 looks for a feed at the usual paths and for a <link rel="alternate"> that declares it, per the content checks documentation. A declared feed that answers with a challenge page is declared and unreadable. Our feed census of 340 sites lists "feed refused to bots" as one of five failure types and notes the scanner may not see it. This post is the fix for that row.

Test your feed in 30 seconds

Run the scan first: npx aiscan-cli yoursite.com, then read the E5 line in the content dimension. The scan tells you whether a feed is found and declared. It cannot tell you what a feed reader sees from its own network, so check by hand as well:

FEED=https://example.com/feed/
for UA in "Mozilla/5.0 Chrome/140.0" "Feedly/1.0 (+http://www.feedly.com/fetcher.html)" "curl/8.5.0"; do
  echo "== $UA"
  curl -s -o /dev/null -D - -A "$UA" "$FEED" | grep -iE '^(HTTP|content-type|cf-mitigated|server)'
done

A healthy feed prints 200 and content-type: application/rss+xml (or application/atom+xml, application/xml, application/feed+json). A challenged one prints 403, content-type: text/html and cf-mitigated: challenge. Cloudflare documents that header: every Challenge Page response carries cf-mitigated set to challenge, whatever the challenge type.

What we measured

We fetched 30 feed URLs on 1 November 2026, one request per identity, from one datacenter address. One URL (a Google blog feed path) returned 404 for all three and was dropped, leaving 29. Redirects were followed.

The two refusals differ. Indie Hackers returned 403 to all three identities. Search Engine Land returned 200 to a Feedly-style user agent and 403 to the Chrome string and to curl. So a rule keyed on the user agent can let a named reader in and shut out everything else, which is the opposite of what a verified-bot check is meant to do.

Limits: Both sites also challenged their homepages from our address, so what we saw is a site-wide challenge for one datacenter IP, not proof of a rule scoped to the feed. We cannot tell you how often a residential feed reader is refused. Ten of the 12 Cloudflare feeds answered normally, so the failure needs a bot setting someone turned on.

Fix it: Cloudflare

Which fix applies depends on the product that is blocking you, and the plan you are on decides which products you have.

Option 1, Pro plan or above: a skip rule on the feed paths.

1. Go to Security > Security rules in the dashboard and select Create rule > Custom rules.
2. Name it Allow feed fetchers.
3. Under When incoming requests match, choose Edit expression and paste: (http.request.uri.path in {"/feed/" "/feed.xml" "/rss.xml" "/atom.xml" "/index.xml"})
4. Under Then take action, choose Skip.
5. Tick All Super Bot Fight Mode Rules. If the feed still fails, also tick Browser Integrity Check under the products list.
6. Leave Log matching requests on, then select Deploy.

Use your real feed path from the <link> tag, not this list. Cloudflare's skip options page says you can skip phases or specific products, and that skipping a phase does not skip products outside the Ruleset Engine. That is why the second tick matters.

Option 2, Free plan: Bot Fight Mode cannot be skipped. Your choices are to turn it off under Security > Settings (filter by Bot traffic), or to upgrade. According to Open RSS, allow-listing a reader by IP address is safer than by user agent, because user agents can be faked. That works for a rule on a paid plan, not for Bot Fight Mode.

Do not write a site-wide allow. A rule on /feed/ exposes one cheap, public file. A rule on everything removes the protection you turned on.

Fix it: other blockers

Verify the fix

1. Re-run the three-identity loop above. All three should print 200 with an XML or JSON content type and no cf-mitigated line.
2. Run npx aiscan-cli yoursite.com and read E5. A declared, reachable feed should report pass.
3. Check Security > Events for the skip rule. Matches should appear within minutes of a fetch.
4. Validate the feed against RFC 4287 for Atom, or the JSON Feed 1.1 spec, if the XML itself is suspect.

If it still returns 403, the first debugging step is the cf-mitigated header. Present means Cloudflare is still challenging, so recheck the path in your expression. Absent means the refusal comes from your origin or another layer.

Maintenance

Re-run the loop after any change to bot settings and once a quarter. Every Cloudflare setting above was verified on 1 November 2026 against pages fetched from developers.cloudflare.com, and their last-updated dates run from May to October 2026. A new managed rule can undo a skip.

Next step

Scan your site at aiscan.site and read the E5 line, then browse the other fixes in /guides. If the feed is fine but the crawlers are blocked elsewhere, the Cloudflare AI Crawl Control guide covers per-crawler rules, and the blocked-probe study shows how often a firewall, not the site, caused a failing score.