Cloudflare for WordPress configured properly: SSL that does not loop, HTML cached at the edge, real visitor IPs restored, and firewall rules that do not block your customers.
Cloudflare for WordPress delivers your site from servers near your visitors, filters hostile traffic, and handles DNS and SSL. Out of the box it caches assets but not HTML, so most sites get a fraction of the available benefit. Rates start at 15 USD per hour, a proper configuration takes two to four days, and the free plan is genuinely enough for many sites.
Cloudflare for WordPress works by sitting between your visitors and your server. Requests reach a location near the visitor first, and whatever can be served from there is served without troubling your origin at all. That is the basic CDN idea, and for anyone selling internationally from a single server it matters more than most plugin tuning.
Cloudflare for WordPress is also a DNS provider, a certificate authority, and a firewall. Running Cloudflare for WordPress therefore means four different systems are now involved in whether your site works, which is enormously useful when configured and a rich source of confusing problems when not.
The confusing problems with Cloudflare for WordPress are consistent enough to be predictable. Redirect loops from the wrong SSL mode. Every visitor showing one IP address. Content published and not appearing. Firewall rules blocking a crawler nobody intended to block. All documented in the Cloudflare developer documentation, and all things people hit before reading it.
I set up and repair Cloudflare for WordPress regularly, usually alongside origin caching rather than instead of it. The two layers do different jobs, and most of my work is making them agree with each other.
Why most sites running Cloudflare for WordPress get a fraction of what is available.
By default Cloudflare for WordPress caches static assets and treats HTML as dynamic. With Cloudflare for WordPress at defaults, your images, stylesheets, and scripts come from a nearby location, and the actual page is fetched from your server every single time. Someone in Sydney hitting a server in London still waits for that round trip on every page view.
That default is sensible, because caching HTML carelessly on a WordPress site on a site with logged-in users or a cart is how people get served each other content. But leaving it at the default means the largest available gain never arrives, and plenty of site owners believe they have a CDN when they have asset delivery.
Configuring Cloudflare for WordPress properly means deciding what is genuinely public and what is not. Blog posts, service pages, and product listings are the same for everybody and can live at the edge. Cart, checkout, account, and anything personalised must never. Cloudflare can be told to respect the cookies WordPress and WooCommerce set, which is what makes the distinction workable.
Done correctly the effect of Cloudflare for WordPress is substantial, particularly for international audiences, because the page arrives from a nearby city rather than crossing an ocean. Done carelessly it is the worst bug on this list. That is the whole reason this is a job rather than a toggle. Related work under speed optimisation, WooCommerce speed, and Core Web Vitals.
Six areas that make up most Cloudflare for WordPress engagements.
Records migrated without downtime and an encryption mode that does not produce redirect loops, which means a certificate at your origin rather than the shortcut.
HTML actually cached at the edge with the exclusions your site needs, since the default configuration caches assets only and leaves the biggest gain on the table.
Cart, checkout, account, and anything personalised excluded and verified with real transactions, so no customer is ever served another customer page.
Original visitor addresses restored so security plugins, spam filtering, analytics, and geolocation keep working instead of seeing one address for everyone.
Rules targeting behaviour rather than geography, login endpoints rate limited, and logs reviewed afterwards to confirm nothing legitimate is being blocked.
Origin cache and edge cache clearing together, so publishing a change does not mean waiting or manually purging two dashboards.
Usually part of a larger engagement: speed optimisation, security hardening, or migration services.
Any one of these means Cloudflare for WordPress is misconfigured rather than working.
Tell me the symptom and I will tell you which layer is causing it. Most Cloudflare problems are one setting, and identifying which one is usually faster than people expect.
Get a Free DiagnosisFour principles behind every Cloudflare for WordPress engagement I take on.
Flexible SSL is the shortcut that causes the redirect loop, and it is the most common Cloudflare for WordPress failure. It serves HTTPS to visitors while talking to your server over plain HTTP, so a site that also forces HTTPS ends up in an argument with itself that the browser eventually abandons.
It is also worse than it looks, because the connection between Cloudflare and your server is unencrypted. The correct setup is a certificate at your origin and full encryption end to end. Cloudflare will issue one for free, so there is no reason to take the shortcut.
Once traffic arrives through Cloudflare for WordPress, your server sees Cloudflare addresses rather than real visitors unless you restore them from the forwarded header. Skip this and your security plugin sees thousands of requests from one address and starts blocking everybody.
The knock-on effects across a Cloudflare for WordPress setup are wide and take a while to trace: spam filtering stops working, analytics geography goes flat, and country-based rules behave oddly. It is a small step during setup and a confusing multi-day investigation later. Detail under security hardening.
With Cloudflare for WordPress and an origin cache both running, each job should have one owner. Minification in one place, not both. HTML caching decided deliberately at one layer. Purging wired so clearing one clears the other rather than leaving visitors on stale content while the dashboard says everything is fresh.
This is where most of my Cloudflare repair work actually lives, and it applies equally whether the origin runs WP Rocket or a server-level cache. Two layers duplicating work is slower than one layer doing it properly.
Blocking whole countries is the tempting response to attack traffic and it catches crawlers, customers travelling, and VPN users along with the attackers. It also fails against anyone who moves, which is everyone with an incentive to.
In Cloudflare for WordPress, rate limiting the login endpoint, challenging requests that look automated, and blocking specific patterns is more effective and far less collateral. Then read the logs afterwards, because a rule that blocks something legitimate is invisible until somebody complains. Ongoing review through maintenance plans, or emergency support when a rule has already locked something out.
Four ways to get Cloudflare for WordPress sorted, depending on whether something is broken, unconfigured, or slow for other reasons.
| Model | Suits | How it works | Typical timeline |
|---|---|---|---|
| Setup and configuration | New or misconfigured Cloudflare | DNS, SSL, caching rules, verification | Two to four days |
| Break-fix | Loops, blocks, or stale content | Diagnose the layer, then fix precisely | Often same day |
| Full performance engagement | Slow beyond delivery | Audit first, Cloudflare as one part | One to three weeks |
| Maintenance plan | Ongoing rules and monitoring | Reviewed as the site changes | Monthly, ongoing |
Rates start at 15 USD per hour, though most work is quoted fixed-price. Any Cloudflare plan is paid directly to them, and the free tier is often sufficient.
Redirect loops, HTML caching, WooCommerce safety, real IPs, firewall rules, and plan choice.
Free 30-minute call. Tell me your host, your stack, and where your customers are. You get a fixed-price quote within 48 hours, and the free Cloudflare plan is often all you need.
