Skip to main content

Your Cloudflare Pages Redirect Is Probably Backwards

· 9 min read
Scott Havird
Engineer

Your Cloudflare Pages Redirect Is Probably Backwards

Here's a scenario that's more common than it should be: you set up a site on Cloudflare Pages, configure a redirect so that www points to your apex domain, and everything looks fine. Then six months later you check Google Search Console and your impressions are split across four different URL variants. Half your SEO equity is leaking because both www.yourdomain.com and yourdomain.com are being indexed as separate pages.

The culprit isn't your code. It's Cloudflare Pages silently redirecting your apex domain to www — the exact opposite of what you intended.

I ran into this on my own site and spent longer than I'd like to admit tracing it down. Here's exactly what happens and how to fix it permanently.

How the Trap Works

When you add custom domains to a Cloudflare Pages project, the first domain you add becomes the primary domain. All other domains redirect to it.

Most developers add www.yourdomain.com first — it's the traditional domain, and it's what you're told to set up a CNAME for. Then they add yourdomain.com (apex) as a second domain. Cloudflare Pages sees this and starts redirecting apex → www, because www was there first.

You now have two problems:

  1. Your apex domain (the one you probably want as canonical) is 301-redirecting to www
  2. Any redirect rule you set up to redirect www → apex creates an infinite loop

The insidious part: this isn't documented anywhere obvious. There's no warning in the Cloudflare Pages UI that says "this domain will be treated as secondary and will redirect to your primary." It just happens.

What the Damage Looks Like in GSC

If this has been running for a while, open Google Search Console → Performance → Pages. You'll see something like this:

URLImpressions
www.yourdomain.com/blog/your-post6,039
yourdomain.com/blog/your-post/2,243
yourdomain.com/blog/your-post1,749
www.yourdomain.com/blog/your-post/1,268

The same page, four URLs, ~11K impressions split four ways. Google doesn't know which one is canonical, so it indexes all of them at partial strength instead of consolidating the full authority onto one URL.

This is a direct hit to your rankings. A page with 11K consolidated impressions at position 6 would rank materially better than four pages averaging 2-3K impressions each.

Diagnosing Your Current State

First, check which direction the redirect is actually going:

# Check if apex redirects to www (bad)
curl -sI https://yourdomain.com/ | grep -i location

# Check if www redirects to apex (good)
curl -sI https://www.yourdomain.com/ | grep -i location

If the first command returns location: https://www.yourdomain.com/, you have the problem.

Next, check what's causing it. There are three places Cloudflare can be redirecting you:

  1. Redirect Rules (Rules → Redirect Rules) — newer mechanism
  2. Page Rules (Rules → Page Rules) — legacy mechanism, still common
  3. Cloudflare Pages custom domain order — the silent one

You might have rules in more than one place creating a loop. Check all three.

The Fix

The cleanest long-term solution is a Page Rule that handles the www → apex redirect at the DNS level, completely independent of Cloudflare Pages custom domain settings.

Step 1: Remove www from Cloudflare Pages custom domains

Go to Cloudflare Pages → your project → Custom Domains. Remove www.yourdomain.com. Keep only the apex domain. This eliminates the Pages-controlled redirect entirely.

Step 2: Create a proxied DNS record for www

For the Page Rule to intercept www traffic, Cloudflare needs a proxied (orange cloud) DNS record for www. If you don't have one:

Go to DNS → Add record:

  • Type: A
  • Name: www
  • IPv4: 192.0.2.1 (discard IP — traffic never reaches this, Cloudflare intercepts it)
  • Proxy status: Proxied (orange cloud)

The 192.0.2.1 address is intentional. It's a reserved IP that discards traffic. Since Cloudflare proxies the record, your Page Rule fires before any request ever reaches that IP.

Step 3: Create the Page Rule

Go to Rules → Page Rules → Create Page Rule:

  • URL: www.yourdomain.com/*
  • Setting: Forwarding URL
  • Status code: 301 - Permanent Redirect
  • Destination: https://yourdomain.com/$1

The $1 wildcard captures the full path so /blog/my-post/ stays intact through the redirect.

Step 4: Verify

# www should 301 to apex
curl -sI https://www.yourdomain.com/ | head -3

# Apex should 200
curl -sI https://yourdomain.com/ | head -3

Expected output:

HTTP/2 301
location: https://yourdomain.com/
HTTP/2 200
content-type: text/html

Why Not Use Cloudflare Redirect Rules Instead?

You might be wondering why I'm using the legacy Page Rules instead of the newer Redirect Rules.

The reason is that Cloudflare Pages owns the http_request_dynamic_redirect ruleset for zones where Pages is deployed. When you try to create a Redirect Rule via the API or Terraform, you get:

Error: request is not authorized to modify this ruleset

This is by design — Cloudflare Pages manages that ruleset to handle its own custom domain redirects. You can't touch it with a zone-level API token, even with full Firewall permissions. Page Rules are a separate system that Pages doesn't own, so they work.

If you manage your infrastructure as code (Terraform, Pulumi, etc.), note this in your DNS config so future you doesn't waste an hour trying to figure out why cloudflare_ruleset keeps failing.

Codifying It in Terraform

If you're managing Cloudflare config in Terraform:

# Proxied A record for www — required for Page Rule to fire
resource "cloudflare_record" "www" {
zone_id = data.cloudflare_zone.main.id
name = "www"
type = "A"
content = "192.0.2.1"
proxied = true
comment = "Dummy record — proxied so Page Rule intercepts www traffic"
}

# Page Rule: www → apex redirect
resource "cloudflare_page_rule" "www_redirect" {
zone_id = data.cloudflare_zone.main.id
target = "www.${var.domain}/*"
priority = 1

actions {
forwarding_url {
url = "https://${var.domain}/$1"
status_code = 301
}
}
}

Add a comment explaining why you're using Page Rules instead of Redirect Rules. The next person (or future you) will thank you.

What Happens to Your GSC Data

After the fix, expect 7-14 days before you see it reflected in Google Search Console. Google needs to:

  1. Recrawl the www URLs and follow the 301 to apex
  2. Consolidate the canonical in its index
  3. Surface the updated data in GSC (there's a 2-3 day lag)

You won't lose impressions — they consolidate onto the canonical URL. The page that was showing fragmented across 4 URLs with 11K total impressions should show up as one URL with ~11K impressions. Rankings typically improve once Google stops splitting authority.

Submit the canonical URL for re-indexing to speed things up: GSC → URL Inspection → enter the apex URL → Request Indexing.

The Short Version

If you're using Cloudflare Pages and your apex domain is redirecting to www:

  1. Check if www was added to Pages custom domains before apex — if so, remove it
  2. Add a proxied A record for www pointing to 192.0.2.1
  3. Create a Page Rule: www.yourdomain.com/* → 301 → https://yourdomain.com/$1
  4. Verify with curl, then check GSC in a week

The redirect direction matters more than most developers realize. Every day your apex redirects to www is another day Google's splitting your authority across URL variants you didn't intend to create.

Frequently Asked Questions

Why does Cloudflare Pages redirect my apex domain to www?

Cloudflare Pages treats the first custom domain you add as the primary domain. If you added www.yourdomain.com before yourdomain.com, Cloudflare Pages redirects the apex to www automatically. Remove the www domain from Pages custom domains and use a Page Rule instead for explicit control.

Why use 192.0.2.1 for the www DNS record?

192.0.2.1 is a reserved "discard" IP (RFC 5737). Since the DNS record is proxied through Cloudflare (orange cloud), traffic never reaches that IP — Cloudflare intercepts it and applies the Page Rule redirect first. The IP is just a placeholder to satisfy the DNS record requirement.

Why can't I use Cloudflare Redirect Rules instead of Page Rules?

Cloudflare Pages owns the http_request_dynamic_redirect ruleset on zones where it's deployed. Zone-level API tokens and Terraform cannot modify this ruleset — you'll get an authorization error. Page Rules are a separate system that Pages doesn't control, so they work reliably for this use case.

How long until Google Search Console shows the fix?

GSC data has a 2-3 day lag, and Google needs to recrawl the redirected URLs before it consolidates the canonical. Expect 7-14 days for the full effect. Use URL Inspection → Request Indexing on the canonical apex URL to accelerate re-crawling.