GUIDE

Verify Cloudflare Bulk Redirects

Cloudflare Bulk Redirects can be silently overridden by Page Rules, Transform Rules, trailing-slash or query-string match settings, and origin redirects. This guide tests every source URL against the live edge to verify each rule fires as expected.

Why Cloudflare redirects need verification

Cloudflare Bulk Redirects execute at the CDN edge before requests hit your origin. They are fast and handle thousands of rules. But the dashboard shows you your rules, not what the user actually experiences. Page Rules, Transform Rules, origin redirects, and Bulk Redirects can all touch the same URL. The only way to know the real result is to test the actual URLs.

The dashboard is not the truth. It shows your redirect rules, not the final outcome after all rules, transforms, and origin behavior combine. Test the real URLs.

Common reasons rules fail

Rule priority conflicts. A Page Rule or Transform Rule intercepts the request before the Bulk Redirect fires.
Trailing slash mismatch. Your source URL has a trailing slash but the request does not, or the other way around. The rule never matches.
Query string inclusion. By default, query strings are part of the match. So /page?ref=123 will not match a rule for /page.
Subpath settings wrong. "Include subpaths" is on when it should be off, or off when it should be on.
Origin server conflicts. Your origin has its own redirects (.htaccess, Nginx, app-level). Cloudflare redirects /old to /new, the origin redirects /new to /old. Loop.

How to verify

Export your source URLs. Grab the "from" column of your Bulk Redirect list. If you built the list from a CSV, use that same file. Make sure URLs include the full protocol and domain.
Batch check them. Paste all source URLs into the batch checker and run. The tool follows each redirect to its final destination, regardless of whether it happens at Cloudflare or the origin.
Compare destinations. Export results (Google Sheets or CSV) and compare each URL's actual final destination against the expected destination in your Cloudflare list.
Check for chains. Sort by hop count. A redirect that should be one hop but shows 2+ means the Cloudflare redirect is chaining with an origin redirect.
Check for non-matches. If a source URL returns 200 (no redirect) or 404, the Cloudflare rule did not fire. Check the URL match settings: trailing slash, query string, subpath options.

Test specific Cloudflare features

Query strings

If your URLs get traffic with UTM parameters or tracking codes, test both versions: the bare URL and the URL with a query string. If "Preserve query string" is on, both should redirect and the query string should carry over. If not, the query string version may not match at all.

Subpath redirects

If you enabled "Include subpaths," test the parent and a few children. With "Preserve path suffix" on, /old-section/page-1 should land on /new-section/page-1. With it off, everything goes to /new-section/ with no path appended.

Status codes

Cloudflare defaults to 301 but can be set to 302. Check the actual status code in your batch results to confirm it matches what you configured.

Common fixes

Redirect not firing: Check trailing slash, query string handling, and whether the list is actually linked to an enabled Bulk Redirect Rule.
Double redirects: Make sure the destination URL in Cloudflare already matches the canonical version (correct protocol, correct www/non-www). See our HTTPS audit and www vs non-www guides.
Loops: Cloudflare redirects /a to /b, but the origin redirects /b back to /a. Find which system owns each hop and remove the conflict.

Ongoing verification

Set up redirect monitoring on a sample of your redirected URLs. Configuration changes, list updates, and rule priority changes can break redirects that were working yesterday.

If these redirects are part of a site migration, follow our site migration redirect checklist for the full before, during, and after process.

Verify your Cloudflare redirects

Batch check every source URL in your rule list against the live edge.