Skip to content

Cloudflare and WordPress: the sane setup

Cloudflare in front of WordPress speeds up static assets for distant visitors, and whole pages too once the cache rules are right. This guide covers the free setup most sites should run, the WordPress-specific traps, and when the enterprise tier is worth paying for.

An umbrella over a small house with rain falling beyond its edge, one panel in vermilion.

By Sam Moreton

First-hand + researched

A CDN, with Cloudflare being the one most WordPress sites end up with, puts a layer of servers between your visitors and your host, serving files from whichever server is nearest. For a WordPress site this fixes a real problem: images, scripts and stylesheets arriving slowly for anyone far from your server. With the right cache rules it also fixes a second one, serving whole pages from the edge for anonymous visitors. What it never fixes is a page your host must build from scratch for each request. Those still travel to your origin and back, and PHP and the database still do all the work, so a CDN complements your hosting and never replaces it.

What the proxy does

When you add your domain to Cloudflare, its DNS takes over: visitors connect to Cloudflare, and Cloudflare fetches from your host. With the proxy enabled on a DNS record, the orange cloud in the dashboard, your static assets get cached at Cloudflare's edge locations, your origin IP stops being public, and you inherit HTTPS plus basic filtering of abusive traffic. Records can also stay DNS-only, which you will want for anything that must reach your server directly, a mail subdomain for instance.

The free setup that suits most sites

The free tier is enough for the large majority of WordPress sites, and the sane setup is an afternoon:

  1. Add the site to Cloudflare and let it import your DNS records.
  2. Flip the nameservers at your registrar when prompted.
  3. Turn the proxy on for the apex domain and www.
  4. Set the SSL mode so Cloudflare connects to your origin over an encrypted connection. With a valid certificate at the origin, which any competent host provides by default, choose the strict mode. The flexible mode encrypts only the visitor's leg and quietly breaks redirects and cookies.

Beyond that, the defaults already cache static assets at the edge, and the correct next move is to stop. Live with it for a week before changing anything else.

Caching HTML, carefully

The bigger win, and the bigger risk, is caching entire pages at the edge. Done right, an anonymous visitor on another continent gets your homepage from a server in their country and your host is never involved. Done carelessly, the edge starts handing one visitor's page to another.

The rules that keep it sane: bypass the cache for the WordPress admin, for logged-in sessions, and for anything personalised. On a WooCommerce store that means cart, checkout and account pages by name. The login page belongs on the bypass list with the admin, since caching it makes logins misbehave in ways that look like a password problem. Two symptoms tell you an exclusion is missing elsewhere: an admin bar appearing for strangers, and a cart showing contents that belong to somebody else. Test as a shopper, never only as an administrator. For a blog or brochure site, where nearly all traffic is anonymous, edge caching of HTML gets you close to a full page cache for nothing.

The WordPress traps

A few failures recur whenever WordPress and Cloudflare meet.

The change you deployed that appears not to have deployed: the edge is serving the old asset, and the fix is a cache purge, or development mode, which suspends edge caching while you work. Then there are optimisation plugins that fight the proxy: plugins rewriting asset URLs or expecting to be reached directly occasionally misbehave with an edge in front, and when something breaks immediately after enabling Cloudflare, the proxy is the first suspect. Finally, the dashboard's speed extras, script loaders and their relatives, break more WordPress sites than they speed up. The proxy's caching does the real work here, and the tick-box extras are optional in the most literal sense.

When the enterprise tier is worth paying for

The free tier serves most sites indefinitely. What changes at Cloudflare's enterprise tier, in practice, is sophistication: smarter edge caching, image handling at the edge, more rules, priority support when something is wrong. Historically that tier meant an enterprise contract and an account manager, which put it out of reach for ordinary sites.

What makes it worth mentioning here is the price it now comes at through Cloudways: Cloudflare Enterprise from $4.99 per domain per month. At that level it becomes a sane upgrade for a commercial site with a genuinely global audience, or one whose revenue tracks edge performance, a store where conversions visibly move with load time, for instance. For a local business site serving one region, the free tier is the correct answer, and paying would buy capacity for traffic that does not exist.

The CDN layer is also the last layer. It is worth little if the layers beneath it are broken, so before this, hosting and page caching, images, database and plugin weight all come first. The order of operations lives in the WordPress speed guide, and the platform context, including what the add-ons cost alongside hosting itself, is in the Cloudways review.