Nearly every question about securing a WordPress site comes down to one confusion: Cloudflare and a security plugin are not competing products. One decides whether a request reaches your server; the other watches what happens once it has. Sites that understand the split spend less and get more.
Australian team
Based here, working your hours — not a timezone away
144+ projects delivered
Over 10+ years building and maintaining sites for Australian businesses
One developer, start to finish
The same person every time — no re-explaining your site
Straight answers, on your terms
We only take work we can finish. Ask us anything first — no obligation
Hardening a site that is already infected achieves very little — cleaning has to come first, and that is malware removal from $299. Configuration here is a job with an end; if what you want is somebody watching continuously afterwards, that is a care plan from $159/mo.
This table is the whole argument. Nearly every "which one should we buy" question dissolves once the two columns are side by side.
| Feature | Cloudflare — the edge | Wordfence — inside WordPress |
|---|---|---|
| Stops a request before it reaches your server | Yes | No |
| Helps when the problem is sheer volume | Yes | No |
| Notices a core file has changed | No | Yes |
| Notices a new administrator account | No | Yes |
| Knows a plugin you run has a published vulnerability | No | Yes |
| Consumes your server resources to do its job | No | Yes |
| Free tier adequate for a small, well-updated site | Yes | Usually — new rules arrive about a month later |
Nothing in the left column substitutes for anything in the right, or the other way round. That is the entire reason both exist.
Cloudflare sits in front of your hosting, so anything it turns away never touches your server — no PHP, no database, no cost. That matters most when the trouble is sheer quantity: thousands of login attempts, a scraper walking every URL your filters can generate, submissions arriving faster than the site can process them. Software installed inside WordPress cannot help with any of that, because WordPress has to be running before it gets an opinion.
A security plugin runs within WordPress, which is precisely why it can do things the edge cannot: notice that a core file changed, that a new administrator appeared overnight, that a plugin on the site has a known vulnerability, or that someone is logging in successfully from somewhere improbable. None of that is visible from outside. It is also why a plugin cannot save an overloaded server — by the time it has an opinion, the work is done.
Buying more products is not the same as covering more ground, and the sites we see with the most security software installed are not noticeably the safest. What separates them is whether anybody finished configuring what is there. Each of the two pages below opens with the specific thing that is almost always left half-done on that layer — and in both cases it is a setting rather than a purchase.
The sites we are called to clean were rarely broken into by anything sophisticated. They were running a plugin with a published vulnerability and an update available, or an administrator account with a password used elsewhere, or both. That is unglamorous and it is good news: the things that actually prevent this are ordinary, cheap and boring, and they matter far more than any product you can buy.
If your problem is spam, bots or traffic volume, start with the Cloudflare page — that is edge work and it is the cheaper fix. If your problem is knowing what is happening inside the site, or you already run Wordfence and are not sure whether it is configured properly, the Wordfence page covers what most installations get wrong. If you are not sure which, a diagnostic is $249 and ends with a written answer rather than a quote.
A request your server has to boot WordPress to reject has already cost you the thing you were trying to protect.
Junk traffic is turned away at Cloudflare rather than inside WordPress. A plugin cannot save a server from load it must start PHP to evaluate, which is why sites under real pressure need the filtering to happen one layer earlier.
Behind a proxy every request looks like it came from Cloudflare unless the original address is put back. Until that is fixed, every IP-based rule on your site is reading the wrong address — the most common Cloudflare fault there is.
Rules aim at the handful of paths that actually attract abuse. Ordinary visitors never request any of them, so the noise disappears without a single real customer meeting a challenge.
No puzzle for your visitors, no Google script loading on pages that have no form, and no sending your customers away to be scored. It is free, and it usually stops more than whatever it replaced.
Verified search crawlers are allowlisted deliberately and checked from outside afterwards. A configuration that quietly challenges Googlebot decays your rankings for weeks without reporting a single error.
Cart, checkout, account and anything varying by login are excluded before caching is turned up. Get that order wrong on a shop and two customers can be served the same page — a data problem wearing a performance costume.
Most sites benefit from both because they do different jobs, and neither substitutes for the other. If budget or complexity forces a choice, it depends on the symptom: volume problems are solved at the edge, and visibility problems are solved inside the site. What we would not do is run two plugins that overlap heavily and call that defence in depth.
No. It runs a very large share of the web, which makes it worth attacking at scale, and that is a different thing. The overwhelming majority of incidents trace back to an out-of-date plugin with a known vulnerability or a reused password — neither of which is a flaw in WordPress. Keep things updated and take administrator accounts seriously and you have addressed most of the real risk.
They handle their part, which is the server, the network and usually some malware scanning. What no host manages is the plugins you install, the accounts you create and the updates you postpone — and that is where incidents come from. It is worth knowing exactly where their responsibility ends, because the gap is rarely where people assume it is.
Common signals are unexpected administrator accounts, core files that differ from the official release, outbound spam from your domain, redirects that only affect visitors arriving from search, and a sudden appearance in Search Console's security reports. If any of those apply, treat it as an incident rather than a configuration problem — cleaning comes first, hardening second, and in that order for good reason.
Edge filtering generally makes a site faster, because rejected traffic never reaches your server. In-site scanning does consume resources and can be noticeable on modest shared hosting, which is a scheduling and configuration question rather than a reason to go without. Anything we set up is checked against the site's actual response times rather than assumed to be free.
A short call, a fixed quote, and no obligation either way.
Get a fixed quoteWhy CloudyWP
Cloudflare decides who reaches your server; a plugin watches what happens once they do. Two layers, two jobs — set up so neither is wasted. Melbourne-based.
Get a fixed quote02 — How we work
Every CloudyWP project runs the same way, whether it is a one-page site or a store with a thousand SKUs. Here is exactly what happens.
01
A single scoping call, then a written plan: what gets built, what it costs, and when it ships. No discovery-phase invoices, no moving targets.
02
Custom WordPress or Shopify on clean code you own outright. Every build ships fast, passes Core Web Vitals, and is handed over documented.
03
Your site talks to the tools you already run — CRM, invoicing, email, stock. The repetitive admin stops being someone's job and starts running itself.
Scope
A fixed quote, in writing
Deliverables, price and dates agreed before a line of code is written.
48 hrs to your quote
