Updated September 2026: this guide replaces an older test based on YSlow, a global API key and a long-retired Cloudflare interface. It now covers a safer WordPress setup: DNS migration, strict encryption, cache boundaries, optional APO and verification.
Cloudflare can improve delivery and filter unwanted traffic before a request reaches WordPress. It cannot repair slow database queries, an overloaded origin server or a broken theme. The right goal is a clean edge layer in front of a healthy WordPress installation—not a collection of aggressive switches.
Cloudflare for WordPress: the short version
- Back up the current DNS zone and identify every web, email and verification record.
- Add the domain to Cloudflare and verify the imported records before changing nameservers.
- Proxy only web traffic that should pass through Cloudflare.
- Use Full (strict) encryption once the origin has a valid matching certificate.
- Start with Cloudflare’s normal static-file caching and conservative performance settings.
- Exclude login, account, cart, checkout and other personalized responses from full-page caching.
- Test anonymous, logged-in and purchase journeys before considering the setup complete.
What Cloudflare does—and what it does not do
Cloudflare can provide authoritative DNS, a reverse proxy, TLS termination, a content delivery network and security controls. By default, it is especially useful for serving cacheable static files such as CSS, JavaScript, fonts and images closer to visitors.
Standard caching does not automatically make every WordPress HTML page an edge-cached page. Features such as Automatic Platform Optimization (APO) or custom cache rules can cache more HTML, but they also increase the importance of correct bypass rules and reliable purging.
Before changing nameservers
A nameserver change affects the entire domain, not only the website. Export or record the existing DNS zone and compare these records carefully:
- apex and
wwwA, AAAA or CNAME records; - MX records and mail-related SPF, DKIM and DMARC TXT records;
- subdomains used for apps, staging, APIs or client portals;
- service-verification and ownership TXT records;
- CAA records that control certificate issuance.
If DNSSEC is active at the registrar, follow Cloudflare’s current onboarding instructions. Cloudflare advises disabling the old DNSSEC configuration before changing nameservers and enabling DNSSEC again after the zone is active. Skipping this step can make an otherwise correct site appear unreachable.
Step 1: add the site and verify DNS
- Add the apex domain—not an individual URL—to the correct Cloudflare account.
- Let Cloudflare scan the existing records, then compare the result with the authoritative zone.
- Add anything missing before changing nameservers.
- At the registrar, replace the current nameservers with the two assigned by Cloudflare.
- Wait until Cloudflare marks the zone as active, then retest the website and email.
Cloudflare’s official domain onboarding guide documents the current sequence and DNSSEC warning.
Which records should be proxied?
Proxy the web hostnames that should receive Cloudflare’s HTTP protection and delivery features. Keep mail and non-HTTP services DNS-only unless their documentation explicitly supports Cloudflare proxying. An orange cloud is not a generic “make this faster” switch for every DNS record.
Step 2: configure SSL/TLS correctly
Install a valid certificate on the origin server first. Then use SSL/TLS → Overview → Full (strict). In this mode, traffic is encrypted from the visitor to Cloudflare and from Cloudflare to the origin, and Cloudflare validates the origin certificate.
Avoid Flexible mode for a normal WordPress site. It leaves the Cloudflare-to-origin connection unencrypted and commonly creates redirect loops when WordPress is configured to require HTTPS. Cloudflare recommends Full (strict) whenever the origin can present an unexpired certificate matching the hostname.
After changing the mode, verify the homepage, WordPress login, REST API and any webhooks. A 526 error usually means the origin certificate cannot be validated in strict mode; fix the origin certificate instead of permanently weakening encryption.
Step 3: choose a caching strategy
Begin with one owner for each cache layer. Your host may already provide a page cache, WordPress may have a cache plugin and Cloudflare may cache at the edge. These layers can work together, but only when purge behaviour and exclusions are understood.
Safe starting point
- Let Cloudflare cache static files using its standard behaviour.
- Keep HTML caching conservative until forms and personalized routes have been mapped.
- Do not create a blanket “cache everything” rule for the entire domain.
- Document how editors purge the WordPress, host and Cloudflare caches.
Pages that usually need a bypass
Do not serve shared cached HTML for WordPress administration, authentication or customer-specific experiences. Typical examples include /wp-admin/, /wp-login.php, preview URLs, account pages, carts and checkout. WooCommerce and membership sites also use cookies that must trigger a cache bypass.
The exact paths depend on the site. Test password resets, form success messages, plan selection, cart contents and logged-in navigation rather than relying on a generic rule copied from another installation.
If the current cache stack is unclear, start with our WordPress caching comparison and testing workflow before adding another layer.
Should you use Cloudflare APO?
Automatic Platform Optimization can cache eligible WordPress HTML at Cloudflare’s edge and uses the official WordPress plugin to purge changed content. It can improve time to first byte for geographically distributed visitors, but it is optional—not a prerequisite for using Cloudflare.
Use a scoped API token instead of a global API key. Cloudflare’s current APO setup guide requires DNS to be active on Cloudflare and explains plugin activation and verification. Cloudflare also recommends initially disabling overlapping page-cache plugins while APO is being tested because duplicate cache layers can produce unexpected results.
Performance settings to test carefully
- Compression and protocol features: generally low risk, but verify the response headers rather than assuming they are active.
- Image optimization: useful when available on the selected plan, but compare image quality and existing WordPress processing.
- JavaScript optimization or Rocket Loader: test menus, consent, analytics, forms and checkout. It is not automatically safe for every script.
- Minification: avoid running multiple tools that independently rewrite the same CSS or JavaScript.
Security controls worth considering
Enable appropriate managed security rules, protect login and XML-RPC endpoints according to how the site is used, and review bot or rate-limiting controls available on the account. Security rules should target a defined problem. An overly broad challenge can block payment webhooks, monitoring services, administrators or legitimate customers.
Cloudflare does not replace WordPress updates, least-privilege accounts, two-factor authentication, backups or origin monitoring. It is one layer in the security model.
How to verify the setup
- Confirm DNS answers with the intended Cloudflare nameservers.
- Inspect HTTPS and verify that the origin also has a valid certificate.
- Check response headers such as
cf-rayandcf-cache-status. - Test the site while logged out and logged in.
- Submit forms and verify success/error states.
- For WooCommerce, test cart changes, checkout and the customer account.
- Publish a small content update and confirm every cache layer purges as expected.
Common Cloudflare errors
Redirect loop after enabling HTTPS
Check the SSL/TLS mode, WordPress site URLs and any HTTPS redirects at the host. Flexible mode combined with an origin HTTPS redirect is a common cause.
521, 522 or 523 errors
These usually point to origin availability, firewall or routing problems. Confirm that the origin is online and allows Cloudflare’s current IP ranges.
Old pages remain after an update
Identify whether the stale copy lives in WordPress, the host cache or Cloudflare. Purging only one layer may not change the public page. Verify the unparameterized canonical URL because query parameters can bypass or create a different cache entry.
Real visitor IP addresses are missing
Configure the origin to restore the client IP from trusted Cloudflare headers using the host’s supported integration. Do not trust forwarded IP headers from arbitrary direct traffic.
Document Cloudflare ownership and emergency access
The business should know who controls the Cloudflare account, domain zone, billing, DNS changes and origin certificates. Use named access where available, record the current nameservers and export or document critical DNS records before changing agencies or administrators.
Include Cloudflare in the WordPress handover checklist and define who may bypass caching, change DNS or contact hosting during an incident. A website support SLA should identify that escalation path before the site is unavailable.
If DNS, caching or the origin fails during a live incident, follow a documented WordPress incident response process so containment changes, stakeholder updates and recovery tests have one owner.
Cloudflare for WordPress FAQ
Is Cloudflare free for WordPress?
Cloudflare has a free plan with useful DNS, proxy, CDN and security capabilities. Some features, including APO for certain plans and advanced controls, may require a paid add-on or plan.
Do I need the Cloudflare WordPress plugin?
Not for basic DNS and proxy use. The official plugin is useful for WordPress-aware integrations such as APO and coordinated purging.
Will Cloudflare fix a slow WordPress admin?
Usually not. Logged-in administration is dynamic and normally bypasses shared page caching. Slow admin requests require plugin, database, remote-call or server profiling.
Need help untangling the cache layers?
CodaStudio can audit the origin, WordPress cache and Cloudflare together, remove overlap and test the routes that customers actually use. See our WordPress speed optimization service or send us the problem.
