Cloudflare's free plan is one of the best deals in the WordPress stack: a global CDN, free SSL, and DDoS protection for the price of changing two nameserver records. But the gap between "I added my domain" and "my site is faster and not broken" is full of WordPress-specific traps — an infinite redirect loop here, a Wordfence that thinks every visitor is one IP address there. This walkthrough gets you through the real setup, including the settings the official wizard quietly skips.

What the free plan actually gives a WordPress site

Cloudflare sits in front of your origin host as a reverse proxy. Once your DNS is proxied, every request hits Cloudflare's edge first. On the free plan you get:

Global CDN — static assets (images, CSS, JS) cached at edge locations worldwide, so a visitor in Sydney isn't waiting on your origin in Virginia.
Universal SSL — a free TLS certificate at the edge, auto-renewed. You no longer strictly need a cert on the origin to serve HTTPS to visitors (though you should keep one — more on that below).
Unmetered DDoS mitigation — L3/L4 and L7 attack absorption with no bandwidth cap, which is genuinely the headline free feature.
DNS hosting on one of the fastest authoritative networks available.

What's not free: HTML edge caching (Cloudflare caches assets but not your dynamic HTML by default), Automatic Platform Optimization, and the more advanced WAF managed rulesets. We'll handle the caching question head-on.

The cutover: nameservers, not a plugin

The actual switch happens at your domain registrar, not inside WordPress. The sequence:

Create a Cloudflare account and choose Add a site, entering your bare domain (example.com).
Cloudflare scans your existing DNS and imports the records it finds. Review this list carefully — automated scans routinely miss mail (MX), subdomain, or TXT records. A missing MX record means your email stops the moment you cut over.
Cloudflare assigns you two nameservers (e.g. dana.ns.cloudflare.com). Go to your registrar — GoDaddy, Namecheap, Google Domains successor, wherever the domain lives — and replace the existing nameservers with these two.
Wait for activation. Propagation is usually under an hour but can take up to 24. Cloudflare emails you when the domain is active.

In the DNS tab, the orange cloud icon means a record is proxied (traffic flows through Cloudflare); grey cloud means DNS-only (Cloudflare answers the lookup but traffic goes straight to your origin). For the CDN and protection to do anything, your root A record and www record must be orange. Leave mail-related records (MX, and the A records they point to) grey — proxying email subdomains breaks delivery.

The SSL setting that breaks WordPress (read this before anything else)

This is the single most important screen and the one that generates the most "my site is in a redirect loop" support tickets. Under SSL/TLS → Overview, you choose an encryption mode. There are two you might pick and only one is correct:

Flexible — Cloudflare talks HTTPS to the visitor but plain HTTP to your origin. On WordPress this causes the classic ERR_TOO_MANY_REDIRECTS loop: WordPress sees an HTTP request, redirects to HTTPS, Cloudflare strips it back to HTTP at the origin, repeat forever. Never use Flexible.
Full (strict) — Cloudflare talks HTTPS to both the visitor and your origin, and validates the origin certificate. This is what you want. It requires a valid cert on your origin; if your host gave you a free Let's Encrypt cert (almost all do), you already have one. If not, generate a free Cloudflare Origin Certificate and install it on the host.

Once you're on Full (strict), turn on Always Use HTTPS (under SSL/TLS → Edge Certificates) so Cloudflare handles the HTTP-to-HTTPS redirect at the edge instead of making WordPress do it. Also enable Automatic HTTPS Rewrites to silence mixed-content warnings from old http:// asset URLs.

Restore real visitor IPs (or your security and analytics lie to you)

The moment your traffic is proxied, your origin server stops seeing visitors' real IP addresses — it sees Cloudflare's. The practical fallout: Wordfence shows every request coming from a handful of Cloudflare IPs, IP-based blocking becomes useless, comment author IPs all read the same, and analytics that rely on server logs get distorted.

Cloudflare sends the real IP in the CF-Connecting-IP header. To put it back where WordPress expects it, install the official Cloudflare plugin from the plugin repository, which restores original visitor IPs and exposes your API for cache control. Inside Wordfence, set the "How does Wordfence get IPs" option to use the Cloudflare header. Do not reach for the old mod_cloudflare Apache module — it's deprecated and no longer maintained; the header-based approach is the supported path.

Caching HTML is the real performance question

Here's the part most "free Cloudflare" tutorials gloss over: on the free plan, Cloudflare caches your static assets automatically but does not cache your HTML pages. That means your TTFB still depends on your origin host generating each page, and the much-promised "Cloudflare made my site instant" only half happens.

You have three options, roughly in order of effort and reward:

Leave HTML uncached and keep a good origin-side page cache (WP Rocket, LiteSpeed Cache, or your host's built-in cache). Asset offloading alone is a meaningful win and avoids every caching landmine below. For many small sites this is the right call.
Cache HTML manually with Page Rules. The free plan includes three page rules. You can write a Cache Everything rule, but you must also exclude dynamic paths or you'll serve logged-in users each other's sessions. At minimum, bypass cache for /wp-admin/*, /wp-login.php, and — for WooCommerce — /cart/*, /checkout/*, and /my-account/*. With only three rules this gets tight fast, which is exactly why the next option exists.
Use Automatic Platform Optimization (APO). This is Cloudflare's purpose-built answer for WordPress: it edge-caches your HTML while staying aware of WordPress's logged-in cookies and automatically purging when you publish or update a post (via the official plugin). It costs $5/month as a standalone add-on on the free plan and is included at no extra charge with Pro, Business, and Enterprise. If you serve mostly anonymous traffic — a blog, a brochure site, a content publisher — APO is the cleanest way to push TTFB into the tens-of-milliseconds range globally.

Whatever you choose, install the official Cloudflare plugin and connect it with an API token. Its most valuable job is automatic cache purge on publish — without it, you'll update a post and stare at the old version wondering why nothing changed.

A sane free-plan baseline and how to verify it

For a typical WordPress site, this configuration is a solid starting point:

SSL/TLS: Full (strict), Always Use HTTPS on, Automatic HTTPS Rewrites on.
Speed → Optimization: enable Brotli compression; leave Auto Minify alone (your caching plugin handles minification better and double-minifying causes bugs).
Caching → Configuration: Browser Cache TTL set to a few hours or "Respect Existing Headers" so your origin stays in control.
Official Cloudflare plugin installed, API connected, real-IP restoration confirmed in Wordfence.

To confirm it's working, open your browser's network panel and look at the response headers for a page request. cf-cache-status tells the story: HIT means Cloudflare served it from the edge, MISS or DYNAMIC means it went to your origin (DYNAMIC is expected for HTML on the free plan without APO). Then run the URL through a field-data tool and watch the Core Web Vitals you actually care about: LCP under 2.5s, CLS under 0.1, and INP under 200ms (INP replaced FID as a Core Web Vital in 2024). The CDN should noticeably help LCP for visitors far from your origin; it won't fix layout shift or slow JavaScript, which are origin-side problems.

Done right, the free plan gives a small WordPress site faster global load times, real HTTPS, and a buffer against attacks — for nothing. The upgrades worth paying for (APO, advanced WAF) are real, but plenty of sites never need them. Get Full (strict), real IPs, and a publish-purge plugin in place first; that's where the value lives.

Cloudflare for WordPress: Free Setup Walkthrough