_redirects Rule Linter

A redirect rule that fails loudly costs you ten minutes. A redirect rule that fails silently costs you the traffic, and you find out from a chart three weeks later.

This linter sorts a _redirects file into those two piles.

Read this before you trust a result

Everything this tool knows came from one local Cloudflare Pages emulator, wrangler 4.65.0, run on 2026-09-09 — a pre-registered matrix of 48 rule shapes, each requested three times, with four controls passing.

That is not the production Cloudflare edge, and this page makes no claim about it. Nothing here says "Cloudflare does not support X"; every finding says "on this emulator, on this day, this shape did Y." If a rule matters to your traffic, the linter tells you where to look — your own deploy tells you the truth.

The four shapes it flags

The interesting axis is not does the rule work. It is does anything tell you it doesn't.

Shape	Warned at deploy?	What the request did
Source //host/path	No	404 — and 11 of the 12 were counted as valid
Destination //host/path with 200	No	200, with this site's own homepage as the body
Source https://host/path	Yes, by line number	404
Destination https://host/… with 200	Yes, by line number	404

The bottom two fail, but they fail in front of you: wrangler names the file line and the reason while you are deploying. Annoying, survivable.

The top two are why this tool exists.

The one nothing warns you about

A source written as //example.com/pricing/ looks like a path — it starts with a slash, so it passes the "must be relative" check. In the matrix, all twelve of these rules 404'd, and eleven of them produced no diagnostic at any layer. Those eleven were counted inside wrangler's own Parsed N valid tally: accepted as valid rules, matching nothing, forever. The twelfth was named at parse time — for its destination, not its source.

The one that is worse than failing

/promo/ //cdn.example.com/promo/ 200 returned HTTP 200. It looked like the proxy worked. The body was byte-for-byte this site's own root index.html — not the remote host at all.

A smoke test that asserts "200 OK" passes this. A human clicking the link sees a page. Only a byte comparison caught it.

Both were found by rolling out the whole matrix, not by suspecting them. Neither shape appears in Cloudflare's _redirects documentation as read on 2026-09-09 — they are not documented features. Why the parser accepts them we did not verify: we read its output, not its source.

What it does not check

Splat sources (/a/*) were in the matrix and behaved as written. What was not in the matrix: :splat / :name substitution on the destination side, query strings, rule ordering, shadowing, and the per-file rule limits. The linter stays quiet about those on purpose: a checker that guesses is worse than one with a stated edge.

Worked example

Paste this (it is also a downloadable file):

# marketing redirects
/blog/* /journal/:splat 301
//example.com/pricing/ /plans/ 301
/docs/ https://docs.example.com/ 200
https://example.com/old-home/ / 301
/promo/ //cdn.example.com/promo/ 200
/beta/ /product/

You get this back — the text below is generated by running the tool's own logic on the lines above, not written by hand:

6 rules checked — 2 that fail with no warning, 2 that fail loudly.

FAILS WITH NO WARNING — nothing tells you these are broken:
  L3: //example.com/pricing/ /plans/ 301
    → Protocol-relative source. In the lab, all 12 such rules matched nothing; 11 of the 12 were counted as valid and gave no warning at any layer.
    ✎ Drop the host: write the source as a site-relative path starting with a single slash.
  L6: /promo/ //cdn.example.com/promo/ 200
    → Protocol-relative destination with 200. In the lab, both such rules returned 200 with the site's own homepage as the body.
    ✎ A 200 destination must be a path on this site. To send visitors to another host, use 301 or 302 with a full https:// URL.

FAILS LOUDLY — wrangler names these at parse time:
  L4: /docs/ https://docs.example.com/ 200
    → Cross-origin destination with 200. In the lab, both rules whose only defect was this one were rejected at parse time with the line named, and 404'd.
    ✎ Cross-origin needs a redirect, not a proxy: change the status to 301 or 302 (both worked in the matrix), or proxy to a path on this site.
  L5: https://example.com/old-home/ / 301
    → Absolute-URL source. In the lab, all 12 such rules were skipped at parse time with the line named, and 404'd.
    ✎ Drop the scheme and host: the source is a path on this site, not a URL.

WORTH KNOWING:
  L7: /beta/ /product/
    → No status written — takes the documented default of 302 (temporary). All 6 such rules in the lab answered 302.
    ✎ If the move is permanent, write 301 — a 302 asks search engines to keep the old URL.

Checked against shapes observed on wrangler 4.65.0 local Pages emulator, 2026-09-09 — 48 rule shapes × 3 requests (144), controls C1–C4 pass. Not the production Cloudflare edge. atomstorm.ai/en/tools/redirects-rule-linter/

The scope line rides in the report itself, so the caveat survives being pasted into a ticket.

What we verified, and what we did not

• Verified. The four shapes above, each observed three times with identical results across 144 requests, on wrangler 4.65.0, with four controls passing. The parse-time messages are quoted from the run log. The reference card carries the same scope note as this page.
• Not verified. The production Cloudflare edge — not tested, not claimed. Other wrangler versions. Any shape outside the matrix. Whether your rules are in your build output at all, which is the other half of every redirect bug and something no linter can see.