WordPress Security Services: Two Layers, Two Different Jobs

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. Most incidents we see 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.

Yes. Admin and hosting access is enough to start, and the first step is an inventory: who has administrator rights, which plugins are installed and which are actually used, what version everything is on, and whether Cloudflare or a security plugin is already in place and how it was set up. Most of the useful findings come from that list rather than from a scan.

No, and anyone who says otherwise is overselling. Good configuration removes the common automated routes in (out-of-date plugins, reused passwords, open login screens) and makes anything unusual visible soon enough to act on. That covers most of the real-world risk for most business sites, which is a realistic goal rather than a promise.

Not at all. CloudyWP is Melbourne based, so WordPress security for a site in Perth or Brisbane is the same job as one in Richmond. Support runs all week, 9 to 5 AET.

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.