Redirects on Cloudflare

Your options at a glance

Cloudflare has several features that send redirects. They overlap, so it pays to pick deliberately:

Feature	Scope	Best for
Single Redirects (Redirect Rules)	One zone	Rule-based redirects with conditions and dynamic targets: www, HTTPS, folders, patterns
Bulk Redirects	Whole account	Long lists of fixed URL-to-URL redirects, domain moves
Always Use HTTPS	One zone	A single switch that sends every HTTP request to HTTPS
Page Rules (Forwarding URL)	One zone	Legacy, don't use for new setups
Workers	Routes you define	Logic the rules can't express, such as lookups in a KV store

All of them only work for hostnames whose DNS records are proxied (orange cloud). A DNS-only record sends traffic straight to your server, and Cloudflare never sees the request.

Single Redirects

Single Redirects are the successor to Forwarding URL page rules. In your zone, go to Rules and create a Redirect Rule. Each rule has two parts: a filter expression that decides which requests match, and a redirect action with target URL, status code (301, 302, 303, 307 or 308) and a "Preserve query string" option. The number of rules you can create depends on your plan. Details are in the Cloudflare documentation.

Redirect a single page (static target)

Expression:

http.request.uri.path eq "/old-page"

Action: type Static, URL https://example.com/new-page/, status code 301. Tick "Preserve query string" if parameters like tracking codes should survive.

Same path on another host (dynamic target)

For a www to non-www redirect, the target is an expression built with concat():

Expression:  http.host eq "www.example.com"
Target:      concat("https://example.com", http.request.uri.path)
Status:      301, preserve query string: on

Because the path comes from http.request.uri.path and the query string is preserved separately, https://www.example.com/shop/?page=2 ends up at https://example.com/shop/?page=2.

Folders and patterns

Wildcard patterns are the simplest way to move a folder. In the rule editor choose wildcard matching and enter request and target URL, or write it as an expression:

Expression:  http.request.full_uri wildcard r"https://example.com/blog/*"
Target:      wildcard_replace(http.request.full_uri, r"https://example.com/blog/*", "https://example.com/articles/${1}")

${1} is replaced with whatever the first * matched. For more complex cases there is regex_replace() together with the matches operator; whether regular expressions are available depends on your plan.

HTTPS and www in a single hop

The classic setup is "Always Use HTTPS" (under SSL/TLS → Edge Certificates) plus a Single Redirect from www to the apex domain. Depending on how the two interact, http://www.example.com/ can end up with two hops: first to https://www.example.com/, then to https://example.com/. Every extra hop costs time and makes redirect chains more likely.

A single rule avoids that by handling both cases:

Expression:  (http.host eq "www.example.com") or (http.host eq "example.com" and not ssl)
Target:      concat("https://example.com", http.request.uri.path)
Status:      301, preserve query string: on

The ssl field is true when the visitor connected via HTTPS. With this rule, Always Use HTTPS isn't needed for these two hostnames. If you keep it switched on for other subdomains, run http://www.example.com/ through the redirect checker and confirm that it arrives in exactly one step. The background on both topics: HTTP to HTTPS and www redirects.

Bulk Redirects

Bulk Redirects are made for lists: hundreds or thousands of fixed source and target URLs, for example after a relaunch or a domain migration. They are configured at account level, not per zone, and consist of two parts:

1. A Bulk Redirect List with the entries. You add them one by one or upload a CSV file.
2. A Bulk Redirect Rule that activates the list. Without a rule, a list does nothing.

Each entry has a source URL, a target URL, a status code and a few options:

• Preserve query string: carries parameters over to the target.
• Include subdomains: the entry also matches subdomains of the source host.
• Subpath matching: the entry also matches all paths below the source URL.
• Preserve path suffix: together with subpath matching, appends the rest of the path to the target. old-domain.com/ to https://example.com/ with both options set moves a whole domain while keeping every path.

If the source URL has no scheme, it matches both HTTP and HTTPS. Bulk Redirects deliberately don't support regular expressions or wildcards, which is exactly what makes them fast with very large lists. If you need patterns, use Single Redirects.

A domain you only keep for redirects doesn't need a server. Add a proxied DNS record pointing to a placeholder address, such as an A record to 192.0.2.1 or an AAAA record to 100::, and let the redirect rule answer every request.

Page Rules are legacy

For years, "Forwarding URL" in Page Rules was the way to redirect on Cloudflare. Page Rules are deprecated, and Cloudflare recommends replacing them with the newer Rules products. For redirects, that means Single Redirects. Migrating is usually straightforward: a Page Rule pattern like www.example.com/* with target https://example.com/$1 becomes the wildcard or concat() rule shown above. After migrating, disable the old page rule and test, so the two don't overlap.

Avoiding double redirects and loops with your origin

Most Cloudflare redirect problems come from two layers doing the same job: Cloudflare at the edge and your web server (.htaccess, nginx, a CMS plugin) at the origin.

• SSL mode "Flexible" plus HTTPS redirect on the origin is the most common loop. With Flexible, Cloudflare talks to your server over plain HTTP. Your server sees HTTP, redirects to HTTPS, the browser comes back through Cloudflare, which again uses HTTP to your server, and so on until the browser shows "too many redirects". Fix: install a certificate on the origin and switch to Full (strict).
• Contradicting host rules. Cloudflare sends www to apex while the origin (for example WordPress with the www URL configured) sends apex back to www. That is a loop. Decide on one canonical host and configure it identically everywhere.
• Stacked hops. The edge redirects to https://example.com/shop, then the origin adds a trailing slash. Two hops. Make your edge targets point to the final URL, including slash and case.
• Cached redirects. Cloudflare can cache redirect responses from your origin. After changing redirects on the server, purge the cache before you test.

Rule of thumb: handle protocol and host once, at the edge, and only keep content-specific redirects on the origin. Edge redirects are answered without a round trip to your server, which is also the fastest option for visitors.

Testing

Redirect rules take effect within seconds. Test with the redirect checker rather than your browser, which caches 301s. Check every variant: HTTP and HTTPS, with and without www, with a query string. Each should reach the final URL in exactly one hop with the status code you chose. For large Bulk Redirect lists, run a sample of the source URLs through the bulk redirect checker.