The typical WordPress security article tells you to hide the version number, rename the login page and install a security plugin. The problem is that none of that closes the route used in most compromises.
How sites actually get in
An outdated plugin with a known vulnerability
First place by a wide margin. When a vulnerability is found in a popular plugin it gets published. After that, automated tools sweep millions of sites checking who has not updated. Nobody picked your site specifically; it just appeared on a list.
A pirated theme or plugin
A premium theme downloaded from a site offering free versions. The backdoor is already in it, and that is not an accident, it is the business model of whoever uploaded the file.
A weak or reused password
Not necessarily the WordPress one. Attackers often come in through the hosting panel or FTP and edit files from there.
A neighbouring site on the same hosting
On cheap plans several sites sit side by side. One abandoned site gets hacked and the rest follow.
Popular advice that barely helps
Hiding the WordPress version. Automated tools do not read the version meta tag, they simply try the exploit on everything.
Renaming wp-login. It reduces brute force noise in the logs. It does nothing about a plugin vulnerability, which is the main cause.
A security plugin as the only measure. Useful, but it does not update your plugins for you. A site with a security plugin and an outdated WooCommerce gets hacked all the same.
What does work
Updates, preferably automatic
The dullest advice and the most effective. Enable automatic updates for plugins you trust and do manual rounds regularly. Yes, updates occasionally break something, which is why you need backups, not an excuse to stop updating.
Remove everything unused
An inactive plugin is still files on the server that can often be reached directly. Same for an unused theme. The rule: if you do not use it, delete it rather than deactivate it.
Two-factor authentication for administrators
Closes an entire class of password problems in one move.
File permissions and a dedicated database user
Files should not be world-writable, and the database user should not hold privileges it does not need.
Backups stored off the server
A backup sitting next to the site gets encrypted or deleted along with it.
Watch Search Console
The cheapest early warning system you have. A sudden jump in indexed pages is a reason to run site:yoursite.com the same day. That is how spam in search results is usually discovered, including the japanese keyword hack.
About hosting. If several sites share one account and at least one is neglected, hardening the others is close to pointless. Separating sites into their own accounts buys more than any security plugin.
The minimum working set
- Core, plugins and themes kept up to date.
- Everything unused deleted.
- Licensed themes and plugins, no pirated copies.
- Two-factor authentication for administrators.
- Backups off the server, tested to make sure they restore.
- An occasional look at Search Console.
In short
Attackers come in through outdated plugins, pirated themes, weak passwords and neighbouring sites on shared hosting. Hiding the version and renaming the login page change none of that. Updates, removing what you do not use, two-factor authentication and off-server backups do.
Need help with a hacked site?
I check it, clean it, and close the vulnerability they came through.