Five Cloudflare rules I add to every site in 2026

Every site we onboard gets the same short list of Cloudflare rules before anything else. Not fifty. Five. They cover the problems that actually cause tickets: mixed content, a cache that either does nothing or caches the wrong thing, an exposed admin login, and bots hammering the origin. Here is the exact set we add, and why each one earns its slot in 2026, now that Page Rules are on the way out.

First, the thing nobody tells you: Page Rules are deprecated

If you are following a guide from 2022, stop. Cloudflare deprecated Page Rules and split their job across separate, better tools: Cache Rules, Configuration Rules, Redirect Rules, and Origin Rules. You still get three free Page Rules on a new zone, but Cloudflare’s own docs now steer you to the newer engines, and the free tier for the new rules is far more generous — dozens of rules instead of three. So the five below are written as modern Rules, not legacy Page Rules. If your zone still runs old Page Rules, they keep working, but do not build anything new on them.

The practical upshot: the new rules use a proper expression editor. You match on hostname, URI path, query string, country, user agent — then apply an action. It reads like a filter, not a wildcard URL box. Once you switch, you will not go back.

Rule 1 — Always Use HTTPS, at the edge

Turn on “Always Use HTTPS” (SSL/TLS > Edge Certificates). This is a one-toggle setting, not even a rule, but it belongs at the top of every checklist because it kills mixed-content warnings and the redirect loops people fight for hours. It forces every http request to https before it reaches your origin, so your WordPress or OpenCart install never has to do the redirect itself.

Pair it with “Automatic HTTPS Rewrites” on. Between the two, a site that was serving half its images over http cleans up without you touching a single template. We have fixed “not secure” browser flags in under five minutes this way on sites the owner swore were broken.

Rule 2 — Cache everything static, with a Cache Rule

This is where the old Page Rule “Cache Level: Cache Everything” moves to a Cache Rule. Create one that matches your static assets and images, set Edge Cache TTL to something long (a month is fine for versioned assets), and let Cloudflare serve them without ever waking your server.

The mistake we see constantly: people apply “Cache Everything” to the whole site, then wonder why a logged-in user sees someone else’s cart or a stale price. Do not cache the whole thing blindly. Cache the predictable stuff: /wp-content/, /wp-includes/, images, fonts, CSS, JS. Leave HTML to a smarter rule or to your origin cache. On a typical WordPress site this alone drops origin requests by more than half, which is often the difference between a $10 VPS coping and falling over during a campaign.

Rule 3 — Bypass cache for admin and checkout

The counterpart to Rule 2. Write a Cache Rule that sets “Bypass cache” for the paths that must never be cached: /wp-admin/, /wp-login.php, the WooCommerce cart and checkout, /my-account/, and anything under a preview or ajax endpoint. For OpenCart it is index.php?route=checkout and the admin folder. For Drupal it is /user and /admin.

Skip this and you will eventually get the support ticket that starts with “a customer saw another customer’s details.” Caching a dynamic page that carries session state is how that happens. Two rules, cache the static and bypass the private, cover most of what people used to need a dozen Page Rules for.

Rule 4 — Lock the login with a WAF custom rule

WordPress login is the single most-attacked URL on the internet after the front page. Instead of a plugin that logs failed attempts after they hit PHP, block them at the edge. Create a WAF custom rule: if the URI path equals /wp-login.php or contains /wp-admin, and the country is not on your allow-list, then Managed Challenge (or Block, if you and your editors all sit in one or two countries).

For a client whose team is entirely in one region, we just block everything else outright — the login stops receiving bot traffic entirely, and the server stops burning CPU on requests it was always going to reject. If your editors travel, use Managed Challenge instead of a hard block so a real person can still get in with one click. This one rule removes more load than most caching tweaks, because brute-force traffic never touches the origin.

Rule 5 — A redirect rule for the canonical host

Pick one hostname and force it. www or non-www, it does not matter which, but a site that answers on both splits your SEO signals and occasionally serves a duplicate that Google indexes. Build a Redirect Rule: if the host is www.example.com, 301 to example.com (or the reverse), preserving the path and query. This replaces the classic “forwarding URL” Page Rule and does it with a clean 301 that search engines respect.

While you are there, add a second redirect for any legacy paths from a migration. We fold old-URL cleanup into this rule whenever we move a site, so the redirects live at the edge instead of bloating an .htaccess file the origin has to parse on every request.

What we deliberately leave off the list

We do not add Rocket Loader, Auto Minify (Cloudflare retired it anyway), or aggressive “optimize everything” toggles by default. They break more themes than they help, and when a site renders blank after a Cloudflare change, it is almost always one of those. Rules should be predictable. Five rules you understand beat twenty you copied and cannot debug at 2am.

If you want the full hardening pass — origin lockdown so the server only accepts Cloudflare IPs, rate limiting, bot management tuned to your traffic — that is the work we do in a Cloudflare security audit, and it pairs well with our broader Cloudflare setup and support. But the five rules above are the floor. Add them first, on every site, and most of the “Cloudflare is doing something weird” problems never start.