Cloudflare's free plan is one of the few genuine no-catch wins left in the WordPress stack. You point your domain at it, and your site picks up a global CDN, automatic HTTPS, unmetered DDoS mitigation, and a basic firewall — for exactly zero dollars, forever. The trouble isn't getting it switched on; it's that the dashboard's defaults are tuned for static brochure sites, and WordPress is anything but static. Get the settings wrong and you'll cache a logged-out homepage for every editor, serve stale cart totals, or lock yourself out of wp-admin. This walkthrough gets you to a configuration that actually works for a dynamic CMS.

Before you start: the one decision that matters

Cloudflare's free plan operates at the DNS level, which means it needs to become your domain's authoritative nameserver. That's the orange-clouded "full" mode, and it's what unlocks the CDN and proxy. Two things follow from this:

You must be able to change nameservers at your registrar. If your host bundles DNS and won't let you move it (some managed WordPress hosts like WP Engine prefer you stay on their CDN), Cloudflare's free orange-cloud proxy is off the table — you'd be limited to using it as DNS-only, which gives you none of the caching benefit.
Email lives in DNS too. The single most common self-inflicted outage during a Cloudflare migration is losing MX records. If your mail runs through Google Workspace, Microsoft 365, or your host, those MX (and often SPF/DKIM TXT) records have to survive the move intact.

If you'd rather not touch nameservers at all, Cloudflare offers a partial "CNAME setup," but it's a paid Business-plan feature — not relevant to the free tier.

Connecting the domain

Sign up at dash.cloudflare.com, add your domain, and pick the Free plan when prompted. Cloudflare scans your current DNS and imports what it finds. This import is not magic — it reads whatever is publicly resolvable right now, so always cross-check it against your host's DNS panel before you commit:

Confirm your A record (or AAAA for IPv6) points at the right origin IP, and that it shows the orange cloud (proxied).
Confirm every MX record and any mail-related TXT records (SPF, DKIM, DMARC) came across. MX records should be grey-clouded (DNS-only) — you never proxy mail.
If you use a subdomain for a separate service (a status page, a help desk), decide per-record whether it should be proxied.

Then change your nameservers at the registrar (Namecheap, GoDaddy, Porkbun, wherever the domain actually lives) to the two Cloudflare assigned you — they look like aria.ns.cloudflare.com. Activation usually completes within an hour or two, though some TLDs and registrars drag it out toward the 24-hour mark. Your site stays up the whole time; traffic simply shifts to Cloudflare as the new nameservers propagate.

SSL/TLS: the setting people get wrong

Under SSL/TLS → Overview, the encryption mode controls how Cloudflare talks to your origin server. The historical default was "Flexible," and it is almost always the wrong choice for WordPress.

Full (strict) — the correct setting for any modern WordPress host. Nearly every host issues a free Let's Encrypt certificate on your origin, so Cloudflare can validate it end to end. Use this.
Full — encrypts origin traffic but doesn't validate the certificate. A fallback if your origin uses a self-signed cert.
Flexible — encrypts only the visitor-to-Cloudflare leg and talks plain HTTP to your origin. This causes the classic infinite redirect loop in WordPress, because WordPress sees an HTTP request, tries to redirect to HTTPS, and the cycle repeats. Avoid it.

While you're here, turn on Always Use HTTPS and enable the Automatic HTTPS Rewrites toggle so mixed-content warnings from old http:// image URLs get fixed on the fly.

Caching WordPress without breaking it

This is where the free tier earns its keep and where most guides hand-wave. By default, Cloudflare caches static assets (images, CSS, JS) but passes HTML straight through to your origin. That's safe but conservative — your actual PHP page generation still happens on every visit. WordPress is mostly fine with the defaults as long as you carve out the dynamic paths.

Cloudflare's free plan no longer offers the old three "Page Rules" the same way for new features, but it does include the modern Cache Rules and Configuration Rules under the Rules section, and the free allotment is generous enough for WordPress. Create bypass rules so these never get cached:

Admin and login: bypass cache for any URL containing /wp-admin/ or matching /wp-login.php. Caching these is how you end up staring at someone else's dashboard.
Logged-in users generally: Cloudflare automatically bypasses cache when it sees the wordpress_logged_in cookie, which covers most of this — but an explicit rule is cheap insurance.
Previews: bypass anything containing preview=true so editors don't see a cached old draft.
WooCommerce: bypass /cart/, /checkout/, /my-account/, and crucially any request matching wc-ajax=*. Skip this and the cart fragment (the little item counter) caches at zero for everyone after the first visitor — a bug that quietly kills conversions.

If you want Cloudflare to cache HTML aggressively and serve full pages from the edge, the clean way is the official Cloudflare plugin combined with its APO (Automatic Platform Optimization) feature. APO is the one genuinely worthwhile paid add-on at $5/month — it caches logged-out HTML at the edge and purges intelligently when you publish, which can drop TTFB for non-cached pages from 400–800ms down toward 50–100ms. On the strictly free tier, install the plugin anyway: it handles automatic cache purging on post updates and writes the correct visitor IP back into WordPress so your comment and security logs aren't full of Cloudflare's IPs.

Speed toggles worth flipping

Under Speed → Optimization, the free plan still gives you a few real wins:

Brotli compression — on. Better than gzip for text assets, free, no downside.
Auto Minify — Cloudflare has been deprecating this in favor of doing it in your own build, and a good WordPress optimization plugin (WP Rocket, FlyingPress, or the free LiteSpeed Cache) minifies more reliably. If yours already does, leave Cloudflare's off to avoid double-minification glitches.
Rocket Loader — leave it off unless you've tested it page by page. It defers JavaScript in a way that breaks sliders, analytics, and plenty of theme scripts. The performance gain rarely justifies the breakage on a real WordPress build.

Security without locking out real users

The free WAF gives you Cloudflare's managed ruleset and basic bot mitigation. The trap is Bot Fight Mode: it challenges traffic that looks automated, and WordPress's own admin-ajax.php and the REST API can trip it, breaking contact forms, the block editor's autosave, and legitimate plugin calls. If forms or the editor start misbehaving, create a firewall rule to skip security checks for /wp-admin/admin-ajax.php and the /wp-json/ REST routes you rely on, and keep the global Security Level at Medium rather than High. You can also add a free rule to rate-limit or challenge requests to /wp-login.php, which blunts the brute-force login attempts every public WordPress site receives constantly.

What you actually got for free

When the orange cloud is live and configured, your WordPress site is now served through 300-plus edge locations, sits behind unmetered DDoS protection, runs on a valid TLS certificate you never have to renew, and offloads the bulk of its static bandwidth to Cloudflare's network instead of your host. For a visitor on the other side of the world, that's often the difference between a sluggish page and one that comfortably clears the Core Web Vitals LCP target of under 2.5 seconds. The whole thing took fifteen minutes — most of which was double-checking your MX records, which is exactly where you should have spent it.

Setting Up Cloudflare for WordPress: The Free Tier Walkthrough