A practical guide to using Cloudflare with WordPress for DNS, caching and protection without creating redirect loops, stale pages or email problems.
Cloudflare can provide DNS, caching, CDN and security services in front of a WordPress website. That can improve resilience and performance, but it also adds another layer between visitors and the origin server. When configuration is unclear, a problem can be blamed on WordPress even though the request never reaches it.
Know whether Cloudflare is authoritative for the domain and keep access under business control. Importing a zone automatically is convenient but should not replace checking important records. Preserve MX, SPF, DKIM and verification records so enabling Cloudflare for the website does not disturb email.
The orange-cloud proxy is normally intended for web traffic, not every DNS record. Mail-related hostnames and some verification services may need to remain DNS-only. Follow the requirements of the service behind each record rather than enabling proxying indiscriminately.
Redirect loops often appear when Cloudflare, the origin server and WordPress each make assumptions about HTTP and HTTPS. Use a consistent SSL mode and keep redirect ownership understandable. If visitors see too many redirects, our redirect-loop troubleshooting guide explains the layers to inspect.
Caching public pages can reduce load and improve response times, but logged-in areas, carts and other personalised content require care. Do not apply an aggressive cache-everything rule to a dynamic WordPress site without exclusions. Purge relevant caches after significant content changes so visitors do not see stale output.
These Cloudflare errors usually indicate communication problems between Cloudflare and the origin rather than a broken browser. Firewall rules, overloaded hosting or slow application responses can be involved. See our Cloudflare 522 and 524 guide for a focused diagnosis.
Rate limits and firewall rules are useful, but overly broad rules can block administrators, APIs or form submissions. When introducing a rule, know what behaviour it is intended to stop and monitor the result. Security is stronger when controls are specific and observable.
Cloudflare should complement good hosting, backups and WordPress maintenance, not hide weaknesses indefinitely. Test the origin, maintain plugins and keep recovery access documented. Our WordPress care-plan guide covers those underlying checks.
Record the Cloudflare account owner, DNS role, SSL mode and important custom rules. TempWebz provides website technical support and hosting assistance for businesses that need Cloudflare and WordPress configured as one understandable system.
Cloudflare does not cache HTML or JSON by default. Its default cache behaviour documentation explains how file types, response headers and rules affect caching. A WordPress optimisation plugin or custom rule can change the behaviour, so review the actual configuration rather than assuming every page follows the default.
Test as a logged-out visitor and as a signed-in user. A public service page and a customer account page have different requirements. Check that personalised information stays private and that forms still accept valid submissions. If the setup uses full-page caching, ask the developer to document exclusions and how content updates clear the right cache.
Before changing a rule, record its current value, purpose and the problem you want to solve. Choose a representative URL and a test that will show whether the change helped. Keep DNS changes separate from cache or firewall changes where possible, so the result remains understandable.
For example, if visitors see an old phone number, confirm the live WordPress content first. Then identify whether the stale copy comes from the browser, a WordPress cache, the hosting layer or Cloudflare. Purging everything may hide the symptom temporarily without explaining why future edits will have the same problem.
If a legitimate form or integration fails, record the affected request and time for the administrator to review. Do not disable all protection simply because one workflow fails. The responsible person should identify the matching rule and consider a specific correction, with a test and review date.
After any approved change, check the public website, WordPress login and important forms. If DNS changed, also verify business email from an external account. Keep the result in the maintenance record along with who owns the Cloudflare account and who can restore the previous configuration.
Cloudflare WordPress maintenance works best when the origin and proxy form one documented system. Neither layer replaces backups, supported software or a clear recovery process. Review the arrangement after a hosting move or a new shop, booking or membership feature.