Cloudflare is a genuinely great tool. It speeds up your site, blocks garbage traffic, and adds a solid layer of security. In production, I recommend it regularly.
But if you leave it fully active while you’re still building? It will drive you crazy — and it’ll do it in ways that aren’t always obvious.
Here’s what actually happens, and how to stop fighting it.
It Gets Between You and Your Own Work
The whole point of Cloudflare is to sit in front of your site and manage traffic. That’s exactly what makes it valuable — and exactly what makes it a problem during development.
When you’re building, you need a direct line: change something, refresh, see the result. Cloudflare interrupts that loop at every turn. It caches, rewrites, filters, and sometimes flat-out blocks requests. That’s fine for a live site. It’s maddening when you’re trying to iterate.
Caching Is the Big One
This is where most of the lost hours go.
You update your CSS. Refresh. Nothing changed. You update it again. Still nothing. You start wondering if your changes are even saving. They are — Cloudflare is just serving a cached version of your file instead of the new one.
Same thing happens with JavaScript, page content, API responses. You’re debugging something that isn’t actually there anymore.
403 Errors That Seem to Come From Nowhere
You hit your own REST API endpoint and get blocked. Your AJAX calls start failing. WordPress admin actions stop working.
What’s happening is that Cloudflare is seeing your rapid, repeated testing as suspicious activity. During development, aggressive testing is exactly what you’re doing — and its security layer doesn’t know the difference between you and a bot.
JavaScript and CSS “Optimizations” That Break Things
Rocket Loader, auto-minification, deferred scripts — these all sound like good ideas. And they are, on a finished site.
During development, they cause scripts to load out of order, break jQuery dependencies, and make plugins behave unpredictably. If you’re working with a complex WordPress stack, this can send you down rabbit holes that have nothing to do with your actual code.
CSS gets the same treatment — Cloudflare may minify it, reorder it, or inject “critical CSS,” leading to layout shifts and styles that simply don’t apply the way they should.
A Note on WordPress + Divi Specifically
If you’re building with WordPress and the Divi theme, Cloudflare friction gets amplified. Divi relies heavily on its own JavaScript framework, dynamic CSS output, and builder-specific AJAX calls. When Cloudflare’s Rocket Loader defers or reorders those scripts, the Visual Builder can break mid-session, module styles can stop rendering, and saved layouts may not reflect on the frontend — even after a manual cache purge.
The same goes for any site using Advanced Custom Fields, WooCommerce, or multi-plugin setups where load order actually matters. Cloudflare doesn’t know your plugin stack — it just optimizes generically, and that’s where things come apart.
Bottom line: if you’re running Divi, disable Rocket Loader and JS minification first. That alone will eliminate a surprising number of unexplained breakages.
Generic Error Pages Instead of Real Ones
This one’s particularly frustrating. Instead of a PHP error or a server message that tells you what’s actually wrong, you get a Cloudflare 520 or 522 page. The real problem — maybe a memory limit, a fatal error, a crashed process — is hidden behind a wall.
You’re debugging blind.
Rate Limiting When You’re Doing Your Job
Constantly refreshing pages, hammering endpoints, submitting test forms — that’s just what development looks like. Cloudflare sees the same behavior and thinks it’s under attack. Temporary blocks, CAPTCHA challenges, failed API requests. It’s not broken; it’s doing its job. It just doesn’t know you’re doing yours.
What to Do About It
The fix isn’t to ditch Cloudflare — it’s to use it at the right stage.
While you’re actively developing, at minimum:
- Enable Development Mode in your Cloudflare dashboard (it bypasses caching for three hours at a time)
- Turn off Rocket Loader, JS/CSS minification, and any performance optimizations
- Set up cache bypass rules for
/wp-admin/*and/wp-json/*
The cleaner approach — and the one I prefer — is to keep your development environment completely separate from Cloudflare altogether. A local setup with LocalWP or MAMP, or a staging server that Cloudflare isn’t proxying, gives you the direct feedback loop you need. Bring Cloudflare in when the site is stable and ready to go live.
The Short Version
Cloudflare isn’t broken. It’s doing exactly what it was designed to do.
The problem is asking it to do that job while you’re still building the site. Leave it fully active during development and it becomes a middleman that caches what you’re changing, blocks what you’re testing, and hides what’s actually going wrong.
Get the site built first. Then let Cloudflare do its thing.
Looking for more practical tips on WordPress development, web design, and getting the most out of your tools? Check out the MacKenzie Arts & Design blog for more no-nonsense guides.
A couple of notes: you’ll want to confirm your actual blog URL path (I used /blog as a guess), and if you have a specific Cloudflare dashboard page you’d prefer to link to — like their docs or the login page — just say the word and I’ll swap it in.
