What Your WordPress Host Won't Do For You
6 min read
Plenty of WordPress site owners believe they don't need to think about security, because their host handles it. The hosting company's marketing says "secure", there's a firewall mentioned somewhere, and updates seem to happen on their own. So the assumption is that it's covered.
It isn't, not the way most people think. A good host does real, valuable work. But there's a clear line between what they protect and what's left entirely to you, and most compromises I see happen squarely on your side of that line.
This post is about where that line actually sits.
What a good host does cover
Credit where it's due. A decent managed WordPress host genuinely does protect a lot.
- The server operating system, kept patched and current
- The web server and PHP, updated and configured sensibly
- Network level DDoS protection and edge filtering
- Server level isolation between accounts on shared infrastructure
- Backups of the underlying infrastructure, sometimes of your site too
That's a real layer of protection, and a site on good hosting is genuinely safer than one on a cheap, neglected server. None of what follows is an argument against good hosting.
The point is narrower. Everything above sits below WordPress. It's the floor your site stands on. The things that actually get WordPress sites compromised mostly happen at the WordPress layer, and that layer is yours.
Your host will not fix your weak admin password
If an administrator account on your site uses a weak, reused, or breached password, your host cannot help you. A correct login with valid credentials looks exactly like you to the server. There is nothing for a firewall to block.
Brute force attempts, credential stuffing from leaked password lists, an admin reusing the same password as their breached email account. These are the most common ways an attacker simply walks in the front door. Strong unique passwords and two factor authentication are the fix, and both are entirely on you.
Your host will not manage your plugins
This is the big one. Outdated and abandoned plugins are the single most common entry point for WordPress compromises, and your host has nothing to do with them.
Your host does not know that a plugin you installed two years ago has a known vulnerability disclosed last week. It does not know you have five plugins installed that you stopped using long ago, each one still sitting there as live code. It does not know that the bargain theme you bought from an unfamiliar marketplace ships with a backdoor.
Plugins and themes are code you chose to install. Keeping them updated, removing the ones you don't use, and being careful about what you install in the first place is your job and only yours.
Your host will not notice a stranger logged into your dashboard
Server monitoring watches the server. It sees CPU, memory, disk, and traffic. It does not see a new administrator account appearing in your Users screen, a plugin being installed that you didn't install, or a theme file being edited at three in the morning.
That visibility has to come from inside WordPress. An audit log plugin records who did what and when. Without one, an attacker can be active in your dashboard for weeks and nothing on the server side will flag it, because from the server's point of view it's just normal WordPress traffic.
"We have a firewall" rarely means what you think
When a host mentions a firewall, it is usually a network firewall, working at the edge. It filters traffic by IP, blocks obvious floods, and stops known bad actors. Useful, but it operates well before anything reaches WordPress.
It does not inspect whether a request is trying to exploit a specific plugin vulnerability. It does not understand what a legitimate WordPress request looks like. That job belongs to a web application firewall that sits inside or directly in front of WordPress itself, like Wordfence or Cloudflare's application rules. Most hosting plans do not include one, and the ones that do rarely have it tuned for your specific site.
Host backups are not a recovery plan
Many hosts take backups. Fewer make them easy to restore, and fewer still keep them long enough to be useful.
If a compromise goes unnoticed for two weeks and your host only keeps seven days of backups, every backup you have is already infected. If the backups live on the same infrastructure as the site, a serious server level problem can take both down together. And a backup you have never tested restoring is a guess, not a safety net.
A backup strategy you actually control, with copies kept off the server and a restore you've tested at least once, is your responsibility regardless of what the host provides.
Where this leaves you
None of this is a reason to distrust your host. It's a reason to be precise about the division of labour.
Your host secures the server. That is real and worth paying for. But the configuration of WordPress itself, the accounts that can log in, the plugins and themes you run, the monitoring that catches a problem early, and a backup plan you can actually rely on, all of that sits with you. It is exactly the layer where most compromises happen, and it is exactly the layer hosting does not reach.
If you've been assuming "the host has it covered", the honest position is that they have half of it covered, and the half that's left is the half that gets sites hacked.
Closing the gap
Working out everything that falls on your side of the line, and configuring it properly, is what the Protect My WP handbook is for. It covers the WordPress layer in detail, from login and authentication hardening through plugin hygiene, file permissions, monitoring, and a backup strategy that doesn't depend on your host.
If reading this has made you less sure than you were that your site is covered, that uncertainty is worth resolving. That's where the book picks up.
Get the book for £19.
Get the free WordPress Security Checklist
The security checks I'd run through on any WordPress site, delivered straight to your inbox.
Want to go deeper?
The first chapter of Protect My WP is free. Start with the foreword, then read Chapter 1 on hosting and server security.