Cloudflare is a forward post placed between your visitors and your server. All the traffic runs through it: it filters out what is malicious, serves from its own memory whatever can be served that way, and lets nothing reach your hosting but the strict minimum. It is powerful, free in its basic form, and perfectly useless when badly configured. This article sets out what the service really brings, the four settings that make the difference, the five classic traps, and above all what it does not repair.
What Cloudflare actually does
Four functions, four distinct benefits that are best not confused with one another.
- Geographic distribution. Your static files are copied into a network of points of presence spread around the world. A visitor in Lille downloads an image from a server nearby rather than from Amsterdam. Gain: a few tens of milliseconds per resource, very visible on a page that loads sixty of them.
- Page caching. The most powerful lever, and the most delicate. An HTML page served from the edge never reaches your server: no PHP, no database, no plugins. On a brochure site, that relieves the hosting of very nearly all its work.
- Filtering. Vulnerability scanning bots, brute force login attempts and denial of service attacks are absorbed before they reach your server. Denial of service protection is included with no volume limit on every plan, the free one included.
- Encryption. A universal certificate is supplied and renewed automatically, which settles the daft outage of a certificate expiring on a Sunday.
| Function | Free plan | Paid plans |
|---|---|---|
| Universal SSL certificate | Included | Included |
| Delivery network and caching | Included | Included |
| Denial of service protection | Included, not billed by volume | Included |
| Application firewall, free rule set | Included | Included, with the full managed rule sets |
| Rate limiting rules | 1 rule | 2 rules on Pro, 5 on Business |
| Image optimization | No | From the Pro plan upward |
Before you start: what you are moving
Going through Cloudflare, in the most common mode, means handing the management of your domain name zone to a new party. This is not a configuration detail: it is the relocation of the most critical point in your online presence. A mistake here does not break the site, it breaks the email, by far the outage a business takes worst.
Start by writing down every one of your existing records in a file, including the ones whose purpose you do not know. The following commands give you the essentials of what concerns the mail:
dig +short MX example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT selector._domainkey.example.comThen check, once the import is done, that Cloudflare has genuinely picked those records up: its automatic scan misses some on a regular basis, mail signatures and technical subdomains in particular. Finally, keep an active login at your registrar: it is your only way out, and rolling back is simply a matter of putting the original name servers back in place. One last point to watch: the mail records must stay in “DNS only” mode. A mail record switched into proxied mode by mistake cuts off everything coming in.
The settings that genuinely change something
The default configuration brings almost nothing. Four settings do the bulk of the work.
The encryption mode
“Flexible” mode encrypts the leg between the visitor and Cloudflare but leaves the second half of the journey in clear: the padlock appears, the security is painted scenery, and on WordPress this mode throws in redirect loops for good measure. The documentation explicitly recommends “Full” or “Full (strict)”, the latter also verifying that your server’s certificate is valid. The service now selects for itself the safest mode your origin supports, ramping the traffic up gradually. Check the result anyway.
The caching rules
Caching images, stylesheets and scripts is automatic and carries no risk. Caching whole HTML pages is the real gain, and the real danger: this is where most sites break. A shopping cart shared between two visitors is a privacy incident, not a display bug.
The bypass rule must therefore be written before the caching rule, never after it:
(http.request.uri.path contains "/cart"
or http.request.uri.path contains "/checkout"
or http.request.uri.path contains "/my-account"
or http.request.uri.path contains "/wp-admin"
or http.request.uri.path contains "/wp-login.php"
or http.request.uri.path contains "/wp-json"
or http.cookie contains "wordpress_logged_in_"
or http.cookie contains "woocommerce_items_in_cart")Associated action: bypass the cache. Every other address can then move to “eligible for caching”. The check takes a single command, with the cf-cache-status header expected to read HIT on a public page and BYPASS on the checkout funnel:
curl -sI https://example.com/ | grep -i "cf-cache-status\|cache-control"Compression and images
Beware the out of date articles still doing the rounds: automatic minification of HTML, CSS and JavaScript was withdrawn from Cloudflare on August 5, 2024. If a tutorial tells you to switch it on, it dates from before that and its author has not been back to it. Transport compression, for its part, remains automatic.
With images, do not stack two layers. If your visuals are already served as WebP or AVIF and resized to the right dimensions, optimization at the edge brings only a marginal gain and complicates the diagnosis. Optimize at source: leaner, and more predictable.
The application firewall and rate limiting
The free rule set covers the most heavily exploited vulnerabilities and is enough to make a large part of the noise disappear. Beyond that, rate limiting is the tool that pays back best: a single rule is available on the free plan, and the best use you can put it to is protecting the login page, for example ten attempts per minute per IP address on /wp-login.php.
Then watch the false positives for a week: internal calls from the admin area, notifications from the payment provider, the legitimate bots belonging to your own analytics tools. A customer blocked at checkout costs more than a bot that slips through.
The five traps that waste your time
- The logged in page served to a stranger. Symptom: one visitor sees somebody else’s cart or name. Check: the
cf-cache-statusheader must readBYPASSon every personalized page. - The invisible changes. You publish, nothing changes. The cache has not been purged. Automate the purge at the end of a deployment rather than having to remember it every time.
- Mail records copied across badly. Symptom: emails go out but no longer arrive, or land in the junk folder. Compare the record you took at the start with the current zone, entry by entry.
- Filtering that is too zealous. An internal call from the admin area or a blocked payment notification produces ghost outages, visible only in the security logs.
- The double layer of cache. Server cache at the host plus cache at the edge: the behavior becomes unpredictable and debugging impossible. Choose which of the two serves the pages, and neutralize the other.
The purge can be scripted, which saves having to think about it:
curl -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/purge_cache" \
-H "Authorization: Bearer $CF_TOKEN" \
-H "Content-Type: application/json" \
--data '{"purge_everything":true}'What this does not repair
A forward post corrects no fault that sits behind it. A badly indexed database stays slow, a plugin that runs forty queries per page stays expensive. Worse: the cache masks the problem by making it invisible to your measurements, until the day a page that is not cached, the checkout funnel for instance, collapses under the traffic.
So diagnose before you configure. If your server takes 1.8 seconds to produce a page for a logged in visitor, no setting at the edge will change that; our method for diagnosing the real cause of a slow site describes the measurement chain. The same logic applies on the security side: filtering upstream does not replace the measures in our guide to securing WordPress in depth.
Going further: computing at the edge
For bespoke projects, the network becomes a place of execution in its own right: redirects handled at the edge without touching the server, layout tests, light personalization by country, simple application endpoints, object storage for heavy media. This is no longer a setting, it is development, with the matching demands on version control and testing.
One signal about the direction the ecosystem is taking: Cloudflare announced on January 16, 2026 that it had bought the team behind the Astro framework, undertaking to keep it open source and usable elsewhere. The border between hosting, network and build foundation is moving, and that now weighs on the choice of an architecture, as we explain in our comparison of Astro and WordPress. It is also what opens the way to bespoke development at the edge.
Where we stand: a multiplier, not a repair
We put Cloudflare in front of most of the sites we look after, for three reasons in this order: the certificate that never expires, the filtering that divides the noise in the logs by ten, and availability on peak days. Speed comes fourth, because on a site that is already light the gain is a modest one.
What we refuse to do is offer it as a fix: on an ailing site, the configuration displaces the problem and makes the diagnosis harder. We audit first, we configure second. There is, finally, a reading of it in terms of restraint, consistent with our Ocean Friendly approach: serving a resource from a point close by and no longer recalculating the same page a thousand times genuinely reduces the energy drawn on, provided the page was light to begin with. A 4 MB site served from the edge is still a 4 MB site, a subject we go into in our piece on hosting that is genuinely low impact. For the implementation, our technical support by ticket covers the configuration and the check on the mail records.
Frequently asked questions
Do you have to change host to use Cloudflare?
No. The service places itself in front of your existing hosting: your site stays exactly where it is, only the DNS records change manager. It is reversible in a few minutes.
Is it worth it for a small brochure site?
Yes for the certificate, the protection against bots and availability during a spike. Less so for speed if the site is already light and correctly hosted: on a well cached 400 KB page, the gain you can perceive is marginal.
My site is showing an out of date version, why?
Two possible causes. The cache was not purged after a change, or a rule is caching a page that should never be cached. Purge it, then check the cf-cache-status header on the page in question.
Does Cloudflare replace a security plugin?
No. It filters upstream, which cuts the noise enormously, but it does not see what goes on inside the site. A compromised administrator account or a vulnerable plugin remain problems at the application level.
Cloudflare is a multiplier: on a healthy site it brings a great deal for very little effort; on an ailing site it displaces the problem and makes it harder for you to see. Before you open your account, write down your DNS records and measure your server’s response time. Those two figures will tell you what you really stand to gain from it.
Also worth reading: Web hosting: how to choose the right host for your site
