Difference Between Rules - When To Use What for Redirect?

I need to set up a rule to redirect all traffic/URLs with:

  1. HTTP to HTTPS.
  2. www to non-www. (for all subdomain levels).

There are:

  • Transform Rules (URL Rewrites)
  • Page Rules
  • Origin Rules
  • Configuration Rules
  • Redirect Rules

With respect to the task that I need to do, what is the order of rule types I should be considering to handle it?


  1. Regarding the “Always Redirect to HTTPS” option in the dashboard. Can I enable that and only set up a rule to deal with www, or should I set up a rule for both and disable the option? If I combine the two, would that form 2 redirects or will they be blended into 1?
  2. I want to do this for all domains on the account so is there a way to do it like that or do I need to define the same rule for each one?
  3. For those who know, can you please elaborate a little bit on the difference in rules, when to use what?


That would result in 2 redirects for requests that need both (http://www.example.com). You can do with one redirect by crafting a Redirect Rule and turning off AUH.

When incoming requests match:
Hostname eq "www.example.com"
Redirect Type: Dynamic
Expression: concat("https://example.com", http.request.uri.path)
Preserve query string: Yes

You need to setup rules for each zone.

I’d refer you to the documentation, as they are clearly explained. In case you try something that doesn’t work, then open a topic here for a specific question detailing what you have tried and what were the expected and actual results (error messages, redirect loop etc.)

I’ll only point out that Page Rules will at one point become obsolete, as other Rules were created to replace their functionality; please read The future of Page Rules.

Hi, @muresanmihaicristian, I’d suggest you refrain from posting ChatGPT or other AI-generated responses without first thoroughly reviewing them, as, despite your best intentions, they tend to be based in old documentation and are often incorrect, too verbose and repetitive.

If your reply was, as I suspect, AI-generated, please remove it as it contains several incorrections:

  1. The suggested Page Rule pattern would create a redirect loop, as it also includes the target URL.
  2. The answer to the question about redirecting several domains within an account solves a different problem, that of redirecting several hostnames within the same zone.
  3. The description of Origin Rules is completely wrong.
  4. The Redirect Rules description is overly and unnecessarily repetitive.

But if instead you wrote the reply yourself, I suggest you spend some time reviewing it, as well as reading the relevant documentation.


Thank you @cbrandt, I did used it to help me format while giving some instructions, I do apologise for not spending enough time onto ensuring the response was acurate and up to date with the latest documentation provided, I will keep this in mind for future, spend more time onto providing acurate feedback and ensure clarity.

1 Like

Thank you so much! I’m testing this and will get back to you in a day or two with the results.

Just one question in the meantime: will this rule remove www from any subdomain level, for example:


No. The suggested rule only redirects www.example.com or http://example.com to https://example.com.

If you want to redirect any subdomain (not only www., but any other, such as blog. etc.), you could change from:

Hostname eq "www.example.com"


Hostname ne "example.com"

keeping the rest unchanged.

However, for sub-subdomains, such as www.sub.example.com, you’d need to be mindful of the “subdomain too deep” issue re: SSL.

1 Like

I’m on cPanel and it creates www as ServerAlias for any subdomain, which makes them accessible over the www variant. That is exactly the reason I want to redirect to a version without it.

I’m aware of the fact that Universal SSL doesn’t cover deeper subdomain levels than the first. Now that you mentioned it, in case I want to cover deeper levels, what are my options with Cloudflare certs? BTW, I know that I can reissue the Origin cert to include deeper subdomains, but what about the Edge cert?

Not to forget, I’ll try out the solutions you suggested and get back to you.

Here is the big picture. I need one redirect rule to do three things:

  1. Replace HTTP with HTTPS in URLs.
  2. Remove www. from URLs.
  3. Append a trailing slash / to the end of URLs. But this is a tricky one and needs explaining. I’m on WordPress and it has its own logic for URIs therefore a trailing slash is not needed always. I use a WP plugin that does this but it creates an additional redirect and I would like to form just one redirect here at Cloudflare to take care of everything. I contacted the maker of the plugin and he was kind enough to talk to me about the code that he uses in .htaccess to append a trailing slash for WP-specific logic. I will post the code here soon.

Just ignore those subdomains. As long as you don’t create DNS for them in Cloudflare, they won’t be accessible, and therefore no redirection is needed. You can also safely delete any such www.sub DNS record Cloudflare may have imported from cPanel, if applicable, since you’re not using them.

That’s a tricky one. To add the trailing slash, you’d need to exclude any possible path that you may have that does not end with a trailing slash, such as images, CSS, JS files etc, not to mention ads.txt, sitemap.xml etc.

But why would you need this? If your permalinks structure ends with a slash, your sitemap should only publicize URLs ending with a slash. Just because you can manually type in a URL without a slash, it doesn’t mean visitors will. Most visitors (I’d say >99%) will never ever type in a URL, they just click what is available in search engines, menu links, ads links etc. As long as those links are properly set, you shouldn’t worry.

1 Like

I do have www subdomains in DNS and cPanel creates them by default. I import the entire zone from a file to Cloudflare and going through files to remove www records is a job I don’t want. I would rather comply with the native cPanel login and do a redirect than remedy something by hand. Plus I have a lot of domains.

Regarding the trailing slash, WordPress will serve any requested URL variant, with or without the slash. For SEO purposes I don’t want to have both wondering through SERPs. Actually, there are quite a few plugins and their makers that are solving this very neatly.

My task is to form this into a single redirect.

WordPress’s “dictionary redirection” will also redirect any path missing not only the trailing slash, but one or several characters, as long as the provided characters match a permalink.



will all redirect to


None of those redirects create an SEO issue. It would only be an SEO issue if the redirects were being advertised by you via sitemap, ads, etc, or by a third-party (but who’d do that?). If that worries you, you can disable the dictionary redirects, just :search: online and you’ll find plenty of blogs teaching you how.

You could try to craft a Redirect Rule to add a trailing slash:

URI Path does not start with "/wp-"
AND URI Path does not end with "/"
AND URI Path does not end with ".jpg"
AND URI Path does not end with ".css"
etc. etc.

Redirect Type: Dynamic
Expression: concat(“https://”, http.host, http.request.uri.path, “/”)
Preserve query string: yes

But… it would be rife with potential collateral issues. Even if you create a perfect matching expression, it could stop working any moment a plugin is updated or installed that requires a file not matching the expression. You simply don’t want to go that direction, imho

I wouldn’t disable this option as it is useful and rarely actually triggered. After all, it’s 301 redirect which is SEO-friendly.

You can access the same page on my site via these 4 links and Google treats them as completely different pages. You can see how this might be an issue.


I need to remove www and add a trailing slash and join all 4 pages into one for search engines. It is also OK to opt for URLs with www and without the slash, it doesn’t matter as long as you are consistent with using the chosen variant.

This is actually WordPress’s built-in functionality and is easy to set by adding or removing a slash after the permalink template:

/%postname%/ — Adds trailing slash
/%postname% — Removes trailing slash

This actually as far as I know doesn’t create a redirect it just sets which variant is served by WordPress.

But I’m using a great plugin called Permalink Manager Pro that allows me to customize URLs far beyond what WP is capable of but unfortunately, it disables this WP built-in capability and deals with it by adding a 301 redirect. And since I want to use Cloudflare for other redirects I would like to join all 3 things with 1 Cloudflare redirect.

OK, I’ve done a lot of research and decided to make peace with 2 redirects. One here at Cloudflare will redirect to HTTPS and non-www URLs and the other on my WordPress will append the trailing slash.

Can you help me form a redirect rule that will change “HTTP” into “HTTPS” and remove “www.” from the URLs, including any level subdomain:

www.example.com => example.com
www.blog.example.com => blog.example.com
www.john.blog.example.com => john.blog.example.com

Should I use a single or a bulk redirect, since I want to apply this rule to all domains on my account?

Thank you!

Admittedly this is more complicated than I anticipated without regex :slight_smile: We can use substring to remove certain parts.


Thank you! Will this take care of HTTP => HTTPS as well? But not just in case when www. is present but for all URLs with HTTP.

1 Like

I tested it and it doesn’t take care of HTTP+www. It redirects the following:


But not the following:


cbrandt suggested that having a redirect rule and the option “Always Redirect HTTPS” turned on will form two redirects but it doesn’t. It is blended into one redirect. I checked with multiple tools.

These are two different use cases.
To remove WWW, you need to use what i shared above.
To redirect all HTTP traffic to HTTPS (i.e. tell clients to reconnect to HTTPS://) you need to use Always Use HTTPS Always Use HTTPS · Cloudflare SSL/TLS docs


Not possible to cover both cases at the same time as you want. The replacement suggested by @smarsh will modify the hostname by removing the first 4 characters (the www and it’s subsequent dot), so it should only apply to requests with www.. Now, suppose a requests arrives for http://example.com, where there’s no need to change the hostname, but only to change from http to https. You of course don’t want a redirect from




Also, you may be worrying unnecessarily about the http to https redirect, as most recent browser updates includes a DNS-based redirect, so that users will first request https even when they click on, or type, a http URL. Only bots will have their requests to http impacted by the double redirect. And bots include curl requests and those from most online tools.

This has already been answered.

A zone includes a domains (e.g. example.com) and its subdomains (blog.example.com, www.blog.example.com etc.)

You can write a script to copy the Redirect Rule over to all your zones using the Cloudflare API.

That’s the best decision, as WordPress knows exactly what is a front-end request, and what isn’t.


Thank you guys both, you’ve been a great help!

1 Like

I just realized there are two more things I need this redirect to do:

  1. I want to redirect not just the hostname, but the path and query string as well, in other words, everything after the hostname, for example, example.com/contact?page=1234.

  2. This redirect doesn’t append the trailing slash at the end of the hostname, for example:
    https://www.example.com/ => https://example.com
    But I want this:
    https://www.example.com/ => https://example.com/
    I know it’s not a big deal but I want to be consistent.