Cloudflare Redirect Rules Guide: Forwarding URLs at the Edge

Overview

If you manage domains, marketing landing pages, or a site migration, a cloudflare redirect setup can save time and reduce complexity. Instead of editing application code or web server files for every forwarding rule, you can often define redirect behavior at the edge. That means Cloudflare evaluates the request and returns a redirect response immediately, which is especially helpful when the old host no longer has a working origin or when multiple properties need a consistent redirect layer.

The practical value is simple: you get a central place to handle common website redirect patterns such as HTTP to HTTPS, www to non-www, old path to new path, or one domain to another. For technical SEO, this matters because redirect behavior directly affects crawl efficiency, canonical consistency, and how link equity flows from old URLs to replacement URLs.

It also helps to separate three ideas that are often mixed together:

• DNS points traffic to a service.
• Proxying through Cloudflare allows Cloudflare to inspect requests and apply edge logic.
• Redirect rules tell Cloudflare when to send the visitor somewhere else.

If those three pieces are not aligned, a url redirect may not trigger as expected.

Cloudflare’s interface and feature names can change over time, so treat this as a working model rather than a screenshot-by-screenshot manual. The principles stay stable even when menus move: define the source condition, choose the destination URL, choose the right status code, avoid overlaps, and test every critical path.

Core framework

Use this framework when planning any cloudflare redirect rules implementation. It works whether you are forwarding a whole domain or mapping a small set of legacy URLs.

1. Start with the redirect intent

Before creating rules, write down what should happen in plain language. For example:

• All HTTP requests should redirect to HTTPS.
• All www requests should redirect to the non-www host.
• Old blog URLs under /news/ should move to /blog/.
• A retired campaign domain should forward to a current landing page.

This sounds obvious, but many redirect audits reveal rules created from interface options rather than from a clear destination strategy. That is how you end up with conflicting logic, partial coverage, and redirect chains.

2. Choose the right status code

For most permanent SEO redirects, use a 301 redirect. If the move is temporary, use a 302 redirect or another temporary redirect behavior supported by your stack. The important thing is to match the business reality. If a URL has moved for good, a temporary status creates unnecessary ambiguity for search engines and teams reviewing the setup later.

If you need a refresher on status code selection, see 301 vs 302 vs 307 Redirects: When to Use Each for SEO and User Experience.

3. Define the canonical host and protocol first

Many sites need a baseline canonicalization layer before any path-specific rule is added. In practice, that usually means deciding:

• Should the site resolve on https://example.com or https://www.example.com?
• Should every HTTP request be redirected to HTTPS?
• Should alternate hostnames be consolidated before path rewrites happen?

These foundational seo redirects should be designed before one-off mappings. Otherwise, individual rules may work in isolation but still create two-step redirects such as HTTP -> www HTTPS -> non-www HTTPS.

For related planning, see WWW vs Non-WWW Redirect Strategy: Best Practices for Canonical Consistency and HTTP to HTTPS Redirect Checklist for Websites, Subdomains, and Legacy URLs.

4. Map exact matches, prefixes, and patterns carefully

Not every redirect rule should be a broad wildcard. A stable redirect architecture usually uses a mix of:

• Exact-match rules for high-value legacy URLs, backlinks, or campaign links.
• Prefix-based rules for moving whole sections such as /old-category/ to /new-category/.
• Pattern-based rules for scalable migrations where the path structure remains consistent.

The broader the pattern, the more important testing becomes. A wide match can accidentally catch admin routes, assets, API endpoints, or query-string variants that should not redirect.

5. Preserve paths and query strings only when useful

A common cloudflare redirect decision is whether to keep the original path or append parameters to the destination. There is no universal answer.

• Preserve the path when migrating a site section or keeping old deep links useful.
• Preserve query strings when campaign tracking or application logic depends on them.
• Drop unnecessary parameters when they create duplicate URLs, messy analytics, or meaningless variations.

For marketing teams, this is where link management and attribution intersect. If your redirects interfere with UTM tracking links, your reporting may become less reliable. If your redirects preserve every parameter forever, your logs and crawl paths may become noisy.

That tradeoff is worth documenting in advance. If analytics quality is a priority, pair redirect planning with a clear measurement plan. A related read is Real-Time Analytics for Website Owners: What to Log, What to Ignore, and What to Automate.

6. Order rules by specificity

When multiple rules could match the same request, the more specific rule should usually win. Put narrow exceptions above broad catch-alls. For example:

1. Redirect one retired PDF to a replacement resource page.
2. Redirect the old docs section to the new docs section.
3. Redirect all remaining requests on the old domain to the homepage.

That order prevents the broad domain redirect from swallowing the more useful page-level mappings.

7. Keep edge and origin logic from fighting each other

Cloudflare is only one layer in the request path. Your origin may still have Apache, Nginx, WordPress, or application-level redirect rules. If the edge sends visitors one way and the origin sends them back another way, you create a redirect loop fix project for yourself.

If the site also uses origin redirects, document which layer owns which behavior:

• Edge for host-level forwarding, retired domains, and simple canonicalization.
• Origin for app-specific logic, signed-in flows, or redirects based on internal business rules.

For origin-side comparisons, see How to Set Up Redirects in Nginx Without Breaking Existing Rules and How to Set Up 301 Redirects in Apache .htaccess.

8. Test like a redirect auditor, not just a casual user

Do not stop at loading one page in a browser. A proper redirect audit checks:

• Status code returned
• Final destination URL
• Number of hops
• Behavior with and without trailing slash
• Behavior for HTTP and HTTPS
• Behavior for www and non-www
• Behavior with common query strings
• Whether files, images, or APIs are accidentally redirected

This is where a redirect checker or redirect chain checker becomes useful. The goal is one clean hop wherever possible.

Practical examples

Here are the most common edge redirects teams implement in Cloudflare, along with the thinking behind them.

Example 1: One domain to another

You acquired a shorter brand domain and want oldbrand.com to forward to newbrand.com. This is a classic domain redirect use case. The clean version sends every request on the old domain to the corresponding path on the new domain, using a permanent redirect if the move is final.

Good pattern:

• http://oldbrand.com/pricing -> https://newbrand.com/pricing
• https://www.oldbrand.com/about -> https://newbrand.com/about

Why it works: users and search engines reach the final host quickly, deep links stay meaningful, and backlinks continue to land on relevant pages.

What to watch: if the new domain already redirects www to non-www or HTTP to HTTPS, make sure the old-domain rules send traffic directly to the final canonical destination in one step.

Example 2: HTTP to HTTPS at the edge

This is one of the simplest and highest-value redirects. If all content should be served securely, redirect every HTTP request to its HTTPS equivalent.

Good pattern:

• http://example.com/contact -> https://example.com/contact

Why it works: it consolidates protocol variants and supports a clearer canonical structure.

What to watch: if your origin also forces HTTPS, confirm you are not creating duplicate enforcement logic that produces more than one redirect hop.

Example 3: WWW to non-WWW consolidation

Suppose the canonical site should live at https://example.com. Redirect all www.example.com requests to the non-www version.

Good pattern:

• https://www.example.com/blog/post -> https://example.com/blog/post

Why it works: this reduces duplicate hostname variants and makes canonical tags, internal links, and sitemaps easier to keep consistent.

What to watch: avoid separate rules that turn HTTP into HTTPS first and then run a second host redirect. Aim for one clean destination.

Example 4: Section migration with path preservation

You are moving a content hub from /resources/ to /guides/. If the slugs remain the same, edge redirects can handle the entire section elegantly.

Good pattern:

• /resources/seo-basics -> /guides/seo-basics
• /resources/redirect-audit -> /guides/redirect-audit

Why it works: this scales without hand-writing every rule.

What to watch: confirm there are no exceptions inside the old folder that now belong elsewhere. A small list of exact-match overrides may be needed above the broad rule.

Example 5: Campaign URL forwarding

Marketing teams often need short, memorable links on print materials, QR codes, or paid media. A cloudflare redirect can forward a vanity path such as /summer to a longer destination with UTM parameters.

Good pattern:

• example.com/summer -> https://example.com/landing-page?utm_source=qr&utm_medium=offline&utm_campaign=summer

Why it works: campaign links remain easy to change at the edge without redeploying site code.

What to watch: campaign redirects should be governed like product URLs. Keep naming conventions, owners, and expiry dates documented so old links do not accumulate into untracked clutter.

Example 6: Broken backlink remediation

When a high-value URL is gone but still attracts links, create an exact-match redirect to the closest relevant replacement rather than dropping visitors onto the homepage.

Good pattern:

• /old-whitepaper.pdf -> /guides/new-whitepaper

Why it works: it preserves more user intent and usually creates a stronger experience than a generic catch-all destination.

What to watch: if the old asset still receives meaningful traffic, verify the new page answers the same need. Redirect relevance matters.

Common mistakes

Most redirect problems are not caused by one bad rule. They come from unmanaged growth over time. These are the mistakes worth checking first.

Using Cloudflare and origin redirects without a clear boundary

If no one knows whether the edge or the application owns canonicalization, duplicate rules accumulate. Decide where each redirect lives and document it.

Creating redirect chains

A request should not move from old URL to temporary host to canonical host to final page. That slows users and wastes crawl budget. If you suspect this issue, review How to Fix Redirect Chains and Loops Before They Hurt SEO and Speed.

Redirecting everything to the homepage

This is common during migrations and domain forwarding. It is easy, but it is rarely the best answer. Search engines and users both benefit from a destination that matches the original intent.

Forgetting query-string behavior

Some redirects should preserve UTM tracking links; others should strip noise. Failing to decide leads either to lost attribution or bloated URL variants.

Overbroad wildcard patterns

A simple path match can accidentally catch CSS, JS, media, APIs, or admin routes. Test with representative URLs, not just a homepage and one content page.

Ignoring security implications

Any redirect system should be reviewed for abuse. Be cautious with dynamic destinations or user-controlled parameters that could enable an open redirect vulnerability. If the destination can be manipulated, bad actors may use your domain in phishing or trust abuse scenarios. Safer redirect rules use fixed destinations or tightly constrained patterns.

Not maintaining a redirect inventory

If your team runs multiple campaigns or migrations, create a simple inventory with source pattern, destination pattern, status code, owner, reason, and review date. This turns redirect rules from hidden infrastructure into managed assets.

When to revisit

Cloudflare redirect rules are not a one-time task. Revisit them whenever the inputs change, especially in these situations:

• You launch a rebrand or move to a new domain.
• You change canonical host strategy, such as switching from www to non-www.
• You complete a site migration or restructure major content sections.
• You add QR code destinations, vanity URLs, or campaign links at scale.
• You notice crawl anomalies, indexation drift, or a spike in 404s.
• You change origin infrastructure and need to rebalance edge versus server redirects.
• Cloudflare changes the primary interface or method for configuring redirects.

A practical review routine looks like this:

1. Export or document current redirect rules.
2. Check whether each rule still has a business reason.
3. Run a redirect audit on your highest-traffic hosts and paths.
4. Look for chains, loops, and homepage fallbacks.
5. Confirm analytics parameters behave as intended.
6. Retest after any DNS, origin, or platform change.

If you want one final rule of thumb, use Cloudflare at the edge for redirects that are simple, global, and infrastructure-oriented. Keep application-specific routing closer to the origin. That separation makes url forwarding cloudflare setups easier to reason about and easier to update when your stack changes.

Done well, edge redirects are not just a convenience feature. They are a control layer for SEO, user experience, and link management. The teams that get the most value from them usually do three things consistently: they define canonical targets clearly, they minimize hops, and they revisit their rules whenever the site or campaign architecture changes.