If your website works without www, you probably want anyone who adds it to reach the same page. Having two working versions can be confusing, and an error on the www version is even less helpful.
In this guide, I’ll show you how to redirect www to non-www using Cloudflare’s Single Redirects. I’ll cover the DNS setup too, because the redirect rule can only work once requests for www reach Cloudflare.
I’ll use example.com throughout. The result we’re aiming for is a redirect from:
http://www.example.com/tutorial/?utm_source=testto:
https://example.com/tutorial/?utm_source=testThe page path and query string stay intact. You get the preferred hostname without sending someone who asked for a specific page back to your homepage.
I’ve already covered moving traffic between different domains in my guide to redirecting a domain with Cloudflare. Here, I’m focusing on the www and non-www versions of the same domain.
Before changing anything
Before touching the redirect settings, I’d check that https://example.com works. Open the homepage and a page further into your site. If either fails to load, shows a certificate error or sends you back to www, sort that out first. That’s the address you’re about to send visitors to.
You’ll need access to the domain’s DNS and Rules settings in Cloudflare, with the domain active there. Cloudflare’s Single Redirects require the incoming traffic to be proxied through its network. Its dashboard instructions document that requirement and the current rule creation route.
When I refer to the source below, I mean www.example.com, where the visitor starts. The destination is example.com, where your website should load.
Check that Cloudflare can serve HTTPS for the source hostname too. A visitor using https://www.example.com needs a valid secure connection before receiving the redirect. Check the certificate’s status and hostname coverage in your account; don’t assume an error will disappear after the rule is deployed.
I’d also take a screenshot or copy the settings you’re about to change: the www DNS record, its proxy status and any existing redirects. You’ll have something to refer back to if you need to undo a change.
1. Check the DNS record for www
I’d check the DNS setup before creating the redirect rule in step 2. The www hostname needs a suitable proxied record, and a dummy address is an option when that hostname is used only for redirects.
In Cloudflare, select your domain and open DNS → Records.
You don’t need to replace a suitable www record that’s already proxied. If you don’t have one, and www will only be used for this redirect, you can use the placeholder setup Cloudflare documents:
| Field | Value |
|---|---|
| Type | A |
| Name | www |
| IPv4 address | 192.0.2.1 |
| Proxy status | Proxied |
| TTL | Auto |
Cloudflare’s redirect setup example uses this address for redirects without an origin server. I’d keep this change limited to the redirect source. Leave your destination’s hosting records, email records and unrelated subdomains alone.
DNS lets the browser reach Cloudflare; the rule supplies the new URL. If the rule does not match, a placeholder address cannot serve your website. Check the rule if this source produces an origin error.
2. Create the Single Redirect
Go to Rules → Overview → Create rule → Redirect Rule. Choose Single Redirect if Cloudflare asks which type you want to create. If your dashboard looks different, the documentation linked above has the current navigation.
Give the rule a name you’ll recognise later. I’d use something like www to root.
Choose Custom filter expression for incoming requests. Set Hostname, equals, www.example.com, or use:
(http.host eq "www.example.com")For the destination, select Dynamic and enter:
concat("https://example.com", http.request.uri.path)Set the status to 301 and enable Preserve query string. Replace example.com with your domain in both expressions.
I’m using an exact hostname match here so the rule covers both HTTP and HTTPS requests to www.example.com, while leaving the root and other subdomains alone. The destination expression adds the requested path to your HTTPS hostname. Don’t add a slash after example.com inside the quotes; the path already supplies it.
Understand the redirect controls before deploying
I’d use 301 when you’re ready to make this permanent. If you’d rather check everything with a temporary redirect first, use 302, then change it to 301 once you’re happy with the result.
Keep the destination set to Dynamic. We want each requested page to carry across, rather than giving every visitor the same homepage address.
I’d pay particular attention to Preserve query string. In /tutorial/?utm_source=test, the path is /tutorial/ and the query is utm_source=test. Keeping the path doesn’t automatically keep the query. Cloudflare’s Single Redirects settings document this as a separate control, disabled by default, so make sure you switch it on.
This example is for normal website navigation. Review redirect status behavior separately for method-sensitive application endpoints.
Review the hostname, target, status and query setting, then deploy the rule.
What about the WWW to root template?
Cloudflare also provides a WWW to root template. Its documented https://www.* pattern leaves HTTP requests unchanged.
That’s why I’m using the hostname condition above for this guide. If you choose the template instead, check its matching pattern so you know which requests it covers.
3. Verify the redirect with a real page
I’d start by opening the www version of an existing page in your browser. Watch the address bar: it should change to your preferred HTTPS hostname and keep you on the same page. Add a harmless test query if the page allows one, and check that it survives too.
For a closer look at the response, I recommend checking with curl in a terminal:
curl -I 'http://www.example.com/tutorial/?utm_source=test'
curl -I 'https://www.example.com/tutorial/?utm_source=test'Replace the example domain and path with your own. Quotes keep the URL together when the shell reads it.
For this configuration, an illustrative response would include:
HTTP/2 301
location: https://example.com/tutorial/?utm_source=testYour HTTP version may look different from this example. I’d check the status code and the Location header: you want the correct hostname with the page path and query still attached.
Check the four starting addresses separately:
| Starting address | What to check |
|---|---|
http://www.example.com |
Redirects to the preferred HTTPS root |
https://www.example.com |
Redirects without a certificate error |
http://example.com |
Check its existing HTTPS behavior separately |
https://example.com |
Loads the destination without returning to www |
The new rule does not match root-host requests. If http://example.com still loads over HTTP, the www rule has not failed; you have found a separate configuration to review.
Don’t stop after testing the homepage. I’d check a page further into the site too, because a redirect that drops the path can still appear to work perfectly on the homepage.
To follow the complete sequence of responses, run:
curl -IL --max-redirs 5 'https://www.example.com/tutorial/?utm_source=test'Read each status and Location in order. The destination may perform legitimate additional normalization, such as changing a page’s trailing slash. Investigate an unexpected detour, a lost query, or repeated movement between the same addresses.
Troubleshooting
The browser reports NXDOMAIN
I’d go back to DNS first. A name-resolution failure means the browser hasn’t reached the redirect response. Check the www record and make sure you’re editing the active Cloudflare zone for the right domain.
Do not start rewriting the destination expression while www itself fails to resolve. Establish the source DNS first, then repeat the redirect check.
www still loads without redirecting
Confirm that the source record is Proxied, the rule is deployed, and the hostname in the condition exactly matches your domain. Look for a spelling error or an example hostname that was never replaced.
Also inspect other redirects affecting the starting URL. Opening the destination directly does not test the redirect.
Every page lands on the homepage, or the query disappears
Inspect the destination type and expression. Check that the requested path is included, rather than using a fixed homepage target. For a missing query, inspect Preserve query string.
Use the same path and query in each retest. Otherwise, you may be comparing two different requests and missing the change that matters.
The browser and curl disagree
Your browser may be remembering an earlier permanent redirect. Before changing the rule again, I’d compare the result with a fresh curl -I request. Trying another browser can help too.
Compare the exact same starting URL before deciding that caching is the cause.
HTTPS fails before the redirect
Check the source hostname’s certificate status and coverage. The redirect cannot help a visitor whose secure connection fails before a response is delivered.
Keep that separate from an error on the destination. Test https://example.com directly to identify which end of the journey needs attention.
The browser reports too many redirects
I’d check whether two settings are pulling in opposite directions. Cloudflare might be sending www to the root while your CMS or host sends the root straight back to www. Check the preferred website address in those services alongside your Cloudflare rules.
Cloudflare also documents loops caused by SSL/TLS and origin configuration conflicts. Use the response chain to identify the loop and review the relevant setting. Disabling TLS is not a fix for conflicting redirects.
Prefer www instead? Reverse the direction
If you want www to be your main address, you can reverse the setup. First, make sure https://www.example.com already serves your website correctly, and keep the DNS and hosting it needs.
Match the root hostname:
(http.host eq "example.com")Then use this dynamic destination:
concat("https://www.example.com", http.request.uri.path)Use the same status and query decisions, then repeat the checks with the source and destination roles reversed. Do not deploy both directions together: each would send visitors back toward the other.
Align your website with the chosen hostname
Once the redirect works, I’d check your CMS site address, canonical tags, internal links and sitemap. They should all point to the hostname you’ve chosen. Google’s canonical URL guidance explains how these signals work together.
I wouldn’t switch away from www expecting a ranking boost. The aim here is to make your preferred address consistent and get visitors to the page they asked for.
My final check would be to open the same page through both the HTTP and HTTPS versions of www, then follow each to its final address. If something is wrong, disable the new rule while you investigate and use your saved settings to restore any DNS change where appropriate. Keep those test URLs handy for your next hosting or CMS change.