Optimal Cloudflare settings for WordPress in 2026 aren’t about enabling all security and optimization options simultaneously. Effective settings must balance DNS, SSL/TLS, caching, bot security, and application needs. A website that feels faster but causes visitors to fail to log in, misspell their shopping cart, or get stuck on challenges isn’t the result of optimization.
This guide updates the author’s original experience with DDoS and scrapers on his blog and explains the modern Cloudflare menu. The Firewall Rules, Page Rules, and Scrape Shield views in the 22 old screenshots are kept for historical documentation; use the latest vendor documentation for new configurations.
Recommended Cloudflare settings for WordPress
| Feature | Baseline 2026 | Need to be careful |
|---|---|---|
| DNS web | Proxied if HTTP/HTTPS service supports it | Origin remains open from other subdomains |
| SSL/TLS | Full (strict) with valid origin certificate | Error 525/526 or redirect loop |
| Cache | Cache Rules for public assets and pages | User data is publicly cached |
| Bot/WAF | Managed Rules and challenges based on logs | False positive on visitors/Googlebot |
| Monitoring | Cache status, errors, CWV and conversion | Only relying on one score |
1. How to set Cloudflare DNS correctly
Add your domain and check all A, AAAA, CNAME, MX, and TXT records before changing nameservers. For websites that need to go through Cloudflare, enable Proxied (orange cloud) on supported HTTP/HTTPS records. Email records and non-web services require special handling; do not proxy unsupported ports. Ensure your service is properly configured. SMTP email service not broken after DNS migration.
To protect the origin, see IP origin protection, IP address, And check server IP. Orange cloud reduces exposure of origin IP through web records, but does not replace server firewalls when the IP is known from another source.
2. Cloudflare SSL: prioritize Full (strict)
Fashion Full (strict) Encrypts browser-Cloudflare and Cloudflare-origin connections and validates origin certificates. Use a valid public CA certificate or Cloudflare Origin CA for the hostname. Regular Full mode doesn’t rigorously check origin certificates, while Flexible doesn’t provide end-to-end encryption to the origin. When enabling Always Use HTTPS, check for redirect loops, mixed content, and canonical URLs.
If you see a 502 Bad Gateway error, differentiate upstream errors from TLS issues. After WordPress migration, check the origin connection before changing the domain redirect. 301 redirect helps you understand the difference between a permanent redirect and an SSL setting.
3. Modern Cloudflare Rules replace reliance on legacy Page Rules
Cloudflare in 2026 has Cache Rules for caching and TTL eligibility, Configuration Rules for setting specific requests, Redirect Rules for URL changes, and WAF Custom Rules for protection. Legacy Page Rules can still be found, but Cloudflare recommends a more flexible Rules product for new use cases. Check the priority order, as some rules can interact with each other.
Cache WordPress sites without exposing private content
Don’t blindly apply cache everything to all URLs. Bypass cache for login, admin, cart, payment, or personal pages; consider relevant cookies and headers. If there is page caching from WordPress plugins, understand their relationship to edge caches to ensure proper purging and content variation. Static asset caching is often easier and safer than personalized HTML caching.
4. Configure WAF and Bot Management
Enable managed rules according to your package, then check Security Events. Use measured challenges for suspicious traffic rather than blocking entire countries, ASNs, or user agents based on guesswork. The author’s extensive experience with scraping remains useful, but the AGC bot protection procedure requires request proof and evaluation of false positives. Ensure visitors, verified crawlers, APIs, and monitoring systems are functioning.
For traffic spikes, read DDoS mitigation and monitor server errors. Incorrectly configured protection can interfere with Google indexing and the resulting traffic growth. Your website should remain accessible to legitimate customers.
5. Speed up WordPress with asset compression and caching
Test Brotli compression, HTTP/3, and caching according to actual needs, rather than simply enabling all features. Rocket Loader can defer JavaScript, but it can also change menu, analytics, or checkout behavior. Perform technical A/B testing on staging and compare PageSpeed Insights and blog loading after deployment. On busy pages, hosting bandwidth limits and server performance are still important factors.
6. Maintain origin and application security
Restrict direct traffic to the origin web port if appropriate for your architecture, consider Authenticated Origin Pulls or Cloudflare Tunnel, and perform backups. For self-hosted WordPress, patching of PHP, core, themes, and plugins is still essential. CDNs do not automatically fix WordPress vulnerabilities. Audit technical SEO to ensure sitemap files, robots, and rendering resources remain available.
7. Testing after changing Cloudflare settings
| What is tested | Purpose |
|---|---|
| Homepage, articles, categories | HTML and cache correct |
| Admin, login, form and checkout | Not publicly cached |
| API, cron and sitemap | Not blocked by WAF |
| SSL and redirects | No loops or mixed content |
| Mobile performance | Field data and functions are the same Improved |
Check the XML sitemap and note the settings changes, times, and rollback steps. The best configuration for an informational blog might not be appropriate for a membership or e-commerce website.
Example of a safer Cache Rules configuration for WordPress
For example, a website has 90% public articles and a login/member area. Assets like CSS, JavaScript, and images can benefit from edge cache, but personal pages should be handled differently. In Cloudflare, create rule conditions based on the exact hostname and path, rather than “cache everything” for the entire domain without cookie evaluation or authentication.
What happens when migrating from Page Rules?
Cloudflare documents that in its Cache Rules product, selecting Eligible for cache enables the equivalent behavior of Cache Everything by default. In the legacy Page Rules product, this behavior must be explicitly enabled. This distinction is important when admins migrate legacy configurations. If you previously only wanted to cache static assets, test the basic settings before enabling HTML caching.
| URL Type | General treatment | Required tests |
|---|---|---|
| Public articles and landing pages | Cache when safe and policy-compliant | Content updates, cookies, page variations |
| /wp-admin/ and login | Bypass cache and access protection | Admins can still work |
| Cart/checkout/member | Bypass personal cache | No data mixing between users |
| Static versions of images, CSS, JS | Cache with the correct TTL | The latest assets appear after deployment |
Cloudflare QA steps before and after the change
Check response headers and cache status
Use the DevTools Network browser or an HTTP client command you understand to view cache status, status codes, redirect locations, and security headers. Values like HIT, MISS, DYNAMIC, or BYPASS need to be interpreted in the context of the rule. Don’t treat all MISSes as failures; on private pages or first requests, MISS/BYPASS can be the desired behavior.
Test from different accounts
Open the website as an anonymous visitor and a logged-in user on different browsers. Verify that user content is never visible to others. On an online store website, test the cart, coupon, shipping, checkout, payment, and confirmation pages. If functionality is compromised, roll back the rule rather than forcing caching solely to improve PageSpeed.
Evaluate false positives on bots
Pay attention to changes in challenges for legitimate users and verified crawlers. Overly aggressive WAF changes can reduce visibility and conversion rates. Document the rule expression, the reason for its creation, the responsible party, and the date of the periodic review. Protections should remain auditable and easily reversible if unintended consequences are found.
Archive of 22 screenshots of an older Cloudflare configuration
All historical images from previous tutorials, including the Firewall/SSL/Caching/Page Rules examples, remain available for documentation. Some menu names and button options have now moved or changed.
Show all 22 original screenshots
FAQ: optimal Cloudflare settings
1. Is Cloudflare Free enough for a blog?
Sufficient for many basic needs, but features and quotas depend on the package.
2. What are the most recommended SSL settings?
Full (strict) if the origin has a valid certificate and matches the hostname.
3. What is the difference between Full and Full (strict)?
Full does not validate the origin certificate strictly, Full (strict) validates it.
4. Do you have to use Flexible SSL?
No; for modern WordPress use end-to-end encrypted connections.
5. What is the replacement for Page Rules?
Cache Rules, Configuration Rules, Redirect Rules and WAF products as per their function.
6. Are all URLs safe to cache?
No. Login, checkout and personal data require bypass or special rules.
7. Does Rocket Loader always help?
No; test whether critical JavaScript is broken or delayed.
8. Should WAF block entire countries?
Only after evaluation because it can hinder legitimate users.
9. Does Cloudflare automatically improve PageSpeed scores?
No; results depend on the origin, resource type, cache, and user experience.
10. How to fix error 526?
Check the origin certificate and Full (strict) mode.
11. What does Cloudflare Tunnel do?
Helps connect origins through outbound connections without exposing specific public listeners.
12. How do you know if optimization is successful?
Compare errors, cache, CWV, legitimate traffic, and website functionality before and after.
External references
- Cloudflare — SSL Full (strict)
- Cloudflare — Cache Rules
- Cloudflare — migration Page Rules
- Cloudflare — Configuration Rules
