How to Configure Cloudflare Settings for WordPress

Putting Cloudflare in front of a WordPress site is one of the cheapest ways to add a global CDN, a firewall, and DDoS protection at once. The catch is that a handful of default settings are actively wrong for WordPress, and one of them, Flexible SSL, causes more broken sites than any other Cloudflare option. This guide walks through how to configure Cloudflare settings for WordPress the right way: the encryption mode that won't send your site into a redirect loop, the caching setup that speeds up pages without freezing wp-admin, and the security rules that protect your login without locking you out.

Cloudflare has also changed how a lot of this works. Page Rules, which nearly every older tutorial tells you to use, are now deprecated in favor of separate Cache Rules, Configuration Rules, and Redirect Rules. Where a setting has moved, this guide points to the current location and flags where the exact screen depends on your plan or on whether your zone has been migrated to newer features.

TL;DR

• Set SSL/TLS encryption mode to Full (Strict) and enable Always Use HTTPS. Never use Flexible; it is the top cause of "Too Many Redirects" on WordPress.
• Your origin needs a valid certificate for Full (Strict). Use your host's free Let's Encrypt certificate, or generate a Cloudflare Origin CA certificate if your host doesn't provide one.
• Leave caching on Standard and add a Cache Rule to bypass cache for /wp-admin/* and /wp-login.php so the dashboard and login stay dynamic.
• Page Rules are deprecated. Use Cache Rules for caching, Configuration Rules for per-URL settings, and Redirect Rules for forwarding.
• For per-page HTML caching, consider Cloudflare APO (a $5/month add-on on the Free plan, included on paid plans), driven by the official Cloudflare plugin.
• Run only one cache integration. If a page-cache plugin already manages Cloudflare, don't duplicate it with the Cloudflare plugin.

Prerequisites

Before you touch any Cloudflare settings, make sure you have the following in place:

• A live WordPress site on a working host. Cloudflare sits in front of your existing server; it doesn't replace it.
• A Cloudflare account with your domain added as a zone, and your registrar's nameservers already pointed at the two nameservers Cloudflare assigned. Wait until the zone shows Active before changing settings.
• A valid SSL certificate on your origin server. Most managed hosts issue free Let's Encrypt certificates automatically. On MagicWP, free Let's Encrypt HTTPS is provided on the default *.magicwp.dev domain and on any custom domain, so the origin already has a trusted certificate. If your host doesn't provide one, you'll generate a Cloudflare Origin certificate in Step 2.
• Admin access to wp-admin so you can install a plugin and update your site URLs if needed.
• A recent backup. Some of these changes affect how every request to your site is handled, so take a fresh backup first. On MagicWP you can take an on-demand backup before making changes, in addition to the daily off-site backups.

Important: Point your nameservers and confirm the zone is Active before configuring SSL. Changing the encryption mode while DNS is still resolving to your old setup can produce confusing, intermittent errors.

Step 1 - Understand the "orange cloud" and what Cloudflare actually proxies

In your Cloudflare DNS settings, each record has a toggle shown as an orange or grey cloud. An orange cloud (Proxied) routes that hostname's traffic through Cloudflare, which is what enables caching, the firewall, and HTTPS at the edge. A grey cloud (DNS only) means Cloudflare just answers DNS and traffic goes straight to your origin.

For a normal WordPress site you want the root record (@) and the www record proxied (orange). Records that should usually stay DNS only (grey) include your mail (MX) records and anything that needs to reach the origin directly, such as a record used for domain validation or a service that doesn't work behind a proxy.

This matters because every setting later in this guide only applies to proxied traffic. If your site is grey-clouded, Cloudflare is doing nothing but DNS, and none of the SSL, cache, or security settings below take effect.

Step 2 - Set the SSL/TLS encryption mode to Full (Strict)

This is the single most important setting, and the one most often set wrong. The encryption mode controls how Cloudflare connects to your origin server. Cloudflare offers four modes: Off, Flexible, Full, and Full (Strict).

Use Full (Strict). It encrypts both legs of the connection and verifies that your origin's certificate is real, which is the only mode that prevents a man-in-the-middle between Cloudflare and your host. Cloudflare's own documentation recommends Full or Full (Strict) whenever feasible and warns against Flexible for any site that handles sensitive data, which includes anything with a login. WordPress has a login.

Avoid Flexible. In Flexible mode, Cloudflare talks to your origin over plain HTTP while telling the visitor's browser the page is HTTPS. WordPress sees an insecure request, tries to redirect to HTTPS, Cloudflare sends another HTTP request to the origin, and you get an infinite loop, the classic ERR_TOO_MANY_REDIRECTS error. This is the most common Cloudflare support issue for WordPress, and the fix is almost always switching to Full (Strict).

To set it:

1. In the Cloudflare dashboard, open SSL/TLS > Overview.
2. Choose Full (Strict) as the encryption mode.

Note: Cloudflare is rolling out an Automatic SSL/TLS option that probes your origin and picks the safest mode for you. If your dashboard shows Automatic and Custom SSL/TLS choices, you can either let Automatic manage it (it will not downgrade you to a less secure mode) or select Custom and set Full (Strict) yourself. If your zone hasn't been migrated, you'll only see the classic Custom options. Both paths lead to the same recommended result.

If switching to Full (Strict) breaks the site

If the page errors out the moment you switch, your origin either has no certificate or one Cloudflare doesn't trust (Cloudflare Error 525 is an SSL handshake failure). You have two options:

• Use your host's free certificate. If your host issues Let's Encrypt or AutoSSL certificates, make sure one is active for your domain. On MagicWP this is handled for you on both the default and custom domains.
• Generate a Cloudflare Origin CA certificate. Go to SSL/TLS > Origin Server and click Create Certificate. Let Cloudflare generate the private key and CSR unless you have a reason not to, then install the resulting certificate on your origin. One caveat: an Origin CA certificate is only trusted when traffic flows through Cloudflare's proxy. If you ever grey-cloud the record, direct visitors will see certificate errors.

Step 3 - Enable Always Use HTTPS and configure edge certificate settings

Once encryption is correct, force every request onto HTTPS at the edge.

1. Go to SSL/TLS > Edge Certificates.
2. Turn on Always Use HTTPS. Cloudflare will now 301-redirect any plain HTTP request to HTTPS before it even reaches your origin.

With Full (Strict) plus Always Use HTTPS handling the redirect at the edge, you can remove any HTTP-to-HTTPS redirect from your origin's server config or from a plugin. One redirect is enough; stacking two is another way to create a loop.

A few other Edge Certificate settings worth setting on the same screen:

• Automatic HTTPS Rewrites: On. This rewrites http:// references to https:// for resources Cloudflare recognizes, which fixes many "mixed content" padlock warnings without a plugin.
• Minimum TLS Version. The default may be older than you want. TLS 1.0 and 1.1 are deprecated, and some compliance standards (such as PCI DSS) require newer versions. Setting the minimum to TLS 1.2 is a safe modern baseline. You'll find this under SSL/TLS > Edge Certificates > Minimum TLS Version.
• HSTS (optional, advanced). HTTP Strict Transport Security tells browsers to only ever connect over HTTPS. It's a strong security control, but enabling preload commits your domain to HTTPS more or less permanently and is hard to reverse. Only turn on HSTS once you're confident your site will stay on HTTPS indefinitely, and treat preload as a separate, deliberate decision. A common starting point is a max-age of at least six months with subdomains included, and preload left off until you're sure.

Important: Verify each change in a private browser window before moving on. Load the homepage and the login page over HTTPS. If you see a redirect loop, revisit the encryption mode in Step 2 before changing anything else.

Step 4 - Configure caching so WordPress stays fast but functional

Cloudflare caches your static assets (images, CSS, JavaScript) automatically once traffic is proxied. The default Caching Level: Standard is correct for most WordPress sites, and by default Cloudflare does not cache HTML, which is what keeps dynamic pages, logged-in sessions, and the admin area working.

Under Caching > Configuration you'll also find:

• Browser Cache TTL. Controls how long browsers keep cached assets. "Respect Existing Headers" is a good default if your origin or a caching plugin already sets sensible Cache-Control headers; otherwise a fixed value works.
• Tiered Cache. Worth enabling. It uses Cloudflare's internal network topology to reduce trips back to your origin, which improves cache hit rates and eases origin load.

Keep the admin and login areas out of the cache

Even though HTML isn't cached by default, it's worth adding an explicit rule so that a future "cache everything" experiment, yours or a plugin's, can't accidentally cache logged-in pages. This is where the modern Rules products come in.

Page Rules are deprecated. Older guides tell you to create a Page Rule with "Cache Level: Bypass" for the admin area. Cloudflare has replaced Page Rules with separate products and is moving toward ending their life. Use a Cache Rule instead.

To bypass cache for the dashboard and login:

1. Go to Caching > Cache Rules and create a rule.
2. Set the match expression so the URI path contains /wp-admin/ or equals /wp-login.php. In the Expression Editor this looks like:

(http.request.uri.path contains "/wp-admin/") or (http.request.uri.path eq "/wp-login.php")

3. Set the cache action to Bypass cache.

One behavior change worth knowing: in Cache Rules, choosing "Eligible for cache" turns on Cache Everything by default, so be deliberate about which rule does what. Modern Rules are also stackable and evaluated in a fixed order (Origin Rules, then Cache Rules, then Configuration Rules, then Redirects), and they take precedence over any legacy Page Rules still on the zone.

For WooCommerce or membership sites, the same principle extends further: cart, checkout, and account pages must never be served from a shared HTML cache. If you enable full-page caching (via APO or a plugin), confirm those paths are excluded.

Step 5 - Add performance optimizations (with a WordPress caveat)

Under Speed > Optimization and the caching screens, Cloudflare offers several toggles. Most are safe; a couple need judgment.

• Brotli compression: On. Better compression than gzip for text assets, broadly supported.
• HTTP/2 and HTTP/3 (QUIC): On. Newer protocols that improve multiplexing and latency. Enable both.
• Rocket Loader: test before trusting. It defers JavaScript to speed up first paint, but on WordPress it can break sliders, form scripts, or theme JavaScript. Turn it on, then click through your site, especially interactive pages, before leaving it enabled.
• Image and asset optimization (such as Polish) is available on paid plans. Treat it as plan-dependent and verify what your plan includes rather than assuming.

If you need to change one of these settings for only part of the site, that's now a job for Configuration Rules, which replace the old Page Rules that toggled features per URL. For example, you can raise the Security Level or disable Rocket Loader for a specific path there.

Step 6 - Set up the security layer

Cloudflare's security features protect WordPress from bot traffic, credential-stuffing attempts against wp-login.php, and DDoS attacks. What's available depends heavily on your plan.

• Security Level. Found under the security settings, this controls how aggressively Cloudflare challenges suspicious visitors. "Medium" is a reasonable default for most sites.
• WAF (Web Application Firewall). Cloudflare's managed WAF, including WordPress-specific rulesets, is available on paid plans. If you're on a paid plan, enabling the managed ruleset gives you maintained protection against common WordPress attacks without hand-writing rules.
• Custom rules for wp-login and XML-RPC. Instead of the old Page Rule approach of setting a high security level on /wp-login.php, the current recommendation is WAF Custom Rules, which support finer conditions like bot scoring and cookie exceptions. Common uses: challenge or rate-limit requests to wp-login.php, and block or challenge xmlrpc.php if you don't use it (many sites don't, and it's a frequent brute-force target). Verify your own usage first; some plugins and the Jetpack app rely on XML-RPC.
• Email Address Obfuscation: On. Hides email addresses in your page source from scrapers while keeping them readable for humans.

Cloudflare's security is a layer on top of, not a replacement for, host-level protection. On MagicWP, managed security already includes a WAF, malware scanning, isolated containers, and automatic core updates with rollback, so Cloudflare's rules complement what the platform provides rather than being your only line of defense.

Note: If you enable an aggressive challenge on login paths, test that you can still log in from your own network before you close the tab. Locking yourself out is easy to do and annoying to undo.

Step 7 - Install the official Cloudflare plugin and decide on APO (Optional)

The official Cloudflare WordPress plugin does two useful things: it purges the Cloudflare cache automatically when you publish or update content, and it lets you toggle Automatic Platform Optimization (APO).

APO is the feature that makes Cloudflare genuinely fast for WordPress rather than just a static-asset CDN. It caches your full HTML pages at Cloudflare's edge and serves them without hitting your origin, which flattens time-to-first-byte for visitors worldwide. APO caches content for up to 30 days and invalidates within about 30 seconds of a change when the plugin is installed, so you don't need to hand-build edge-cache rules for it.

Pricing, which you should confirm as it can change: APO is a $5/month add-on on Cloudflare's Free plan and is included at no extra cost on paid plans (Pro, Business, Enterprise). To enable it, install the plugin, authenticate it with a Cloudflare API token, and turn on APO from the plugin or the Speed > Optimization screen.

Two important cautions:

• Run only one cache integration. If your page-cache plugin (WP Rocket, LiteSpeed Cache, W3 Total Cache, FlyingPress, and similar) already has its own Cloudflare integration, don't also let the Cloudflare plugin manage the cache. Two systems purging the same cache produces unpredictable invalidation. Pick one to own cache purging.
• APO doesn't support WordPress Multisite, and it has a published list of compatible and known-problematic plugins. If you run Multisite or a plugin-heavy site, check compatibility before enabling.

Also note: Cloudflare has signaled it doesn't intend to actively maintain this plugin long-term. It still works and is the supported way to enable APO today, but keep an eye on its status and treat plugin details as version-dependent.

Step 8 - Test everything and know how to roll back

Before you consider the configuration done, verify it end to end:

1. Load the site over HTTPS in a private window. Homepage, a post, the login page, and, for stores, the cart and checkout. No redirect loops, no mixed-content warnings.
2. Log in to wp-admin and confirm the dashboard behaves normally and isn't being cached.
3. Publish a test edit and confirm it appears within a minute or so on the front end. If it doesn't, your cache purge integration isn't working, check that only one system is managing the cache.
4. Confirm APO is active (if you enabled it) by checking response headers. A quick command-line check:

curl -svo /dev/null -A "CF" 'https://<example.com>/' -H 'accept: text/html' 2>&1 | grep 'cf-cache-status\|cf-edge-cache\|cf-apo-via'

Seeing cf-cache-status, cf-edge-cache, and cf-apo-via headers means APO is serving pages from the edge.

If something breaks and you need to isolate whether Cloudflare is the cause, the fastest test is to grey-cloud the record (turn off the orange cloud) in DNS temporarily. Traffic goes straight to your origin, Cloudflare's settings stop applying, and you can tell in seconds whether the problem is at the edge or on your server. Re-enable the orange cloud once you've found it. For content that got cached wrongly, use Caching > Configuration > Purge Everything to clear the edge cache.

Conclusion

Getting Cloudflare settings right for WordPress comes down to a short list of decisions that matter far more than the dozens of toggles in the dashboard. Set the encryption mode to Full (Strict) with a valid origin certificate, force HTTPS at the edge, keep /wp-admin/ and /wp-login.php out of the cache with a modern Cache Rule, and lean on Configuration Rules and WAF Custom Rules instead of the deprecated Page Rules. Add APO through the official plugin if you want true edge HTML caching, and never run two cache integrations at once. Test over HTTPS and confirm you can still log in before you walk away.

Because Cloudflare keeps moving features between screens and plans, treat any exact menu path or price here as something to re-check against the current dashboard and official documentation, and date this configuration so you can revisit it.

Cloudflare handles the edge; your host handles the origin, and the two work best when the origin is fast and secure to begin with. If you'd rather not manage certificates, WAF rules, and backups by hand, MagicWP gives every site free HTTPS, a managed WAF, isolated containers, and daily off-site backups with one-click restore out of the box, so Cloudflare becomes an enhancement rather than a crutch.

Next steps

• MagicWP performance features: https://magicwp.io/features/performance
• MagicWP security features: https://magicwp.io/features/security
• Connect a custom domain with automatic HTTPS: https://docs.magicwp.io/wordpress-hosting/domain
• Cloudflare SSL/TLS encryption modes (official): https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/
• Cloudflare Page Rules migration guide (official): https://developers.cloudflare.com/rules/reference/page-rules-migration/
• Cloudflare Automatic Platform Optimization (official): https://developers.cloudflare.com/automatic-platform-optimization/