Most security folklore is half right, which is what makes it hard to correct. Somebody did once get hacked through a particular plugin, somebody else added a security tool and never had trouble again, and both stories harden into rules. The rules then get repeated to people who have a small site, a limited budget and no wish to become a security specialist.
This page takes six common claims about keeping a WordPress site and its owner safe, gives the verdict on each, and explains the mechanism behind it. Where the answer is "do this one cheap thing", I say so. The aim is to leave you with fewer things to worry about, and the right ones.
Everything here applies to ordinary shared hosting and small VPS setups. Large organisations have extra concerns, but the basics below stop the great majority of compromises that reach a hosting support desk.
1. Hacked WordPress sites are mostly the platform's fault
Mostly myth
WordPress core is well maintained and updates quickly. The incidents that fill support forums tend to involve outdated or abandoned plugins and themes, nulled (pirated) premium extensions, weak or reused passwords, and servers with sloppy file permissions.
Core can be at fault occasionally, and fixes usually arrive fast, but the safest posture is to keep everything updated, remove what you do not use, and use unique passwords with two-factor authentication.
When a customer sends a compromised site to support, the first job is working out the way in. The pattern across many cases is consistent. An old contact form plugin with a published vulnerability, installed years ago and never updated. A theme downloaded from a "free premium themes" site, with a backdoor tucked into functions.php. An FTP password reused from a breached forum account. A folder set to 777 so that any other process on the server could write to it. In none of these did the core software fail.
Core has had serious flaws over the years, and the project's answer has been automatic background updates for minor and security releases, enabled by default. That has shrunk the window for core problems considerably. Plugins are different, because there are tens of thousands of them, written by people with very different levels of care, and many are updated rarely or never. The dangerous ones are abandoned plugins: the author has gone, a vulnerability is published, and no patch will come.
Nulled extensions deserve a special warning. A paid plugin offered free on a download site has been modified by somebody, and the modification is rarely charity. Typical payloads add a hidden administrator account, send spam, or inject links into pages. Savings of thirty pounds can cost days of cleaning.
Practical steps: turn on automatic updates for plugins you trust, check the dashboard weekly, delete deactivated plugins and themes rather than leaving them on disk (a deactivated plugin's files can still be reached directly), and check that the "last updated" date of anything you install is within the last year or so.
2. A strong password is enough without two-factor authentication
Myth
A strong password protects against guessing. It does not protect against the password being stolen by a phishing page, a data leak elsewhere or malware on your computer. Two-factor authentication stops most of those cases because the thief lacks the second factor.
Use both, and use an authenticator app or a hardware key in preference to text messages.
It helps to separate the ways a password gets compromised. Guessing, where a bot tries thousands of common passwords against your login page, is defeated by length and randomness. But most real account takeovers do not involve guessing at all. A convincing email links to a fake login page and you type the correct password into it. A different site you use suffers a breach, and attackers try the leaked email and password pairs against every service they can think of. A keylogger on a laptop reads what you type. In each case the password was strong and still failed, because the attacker holds the actual value.
A second factor breaks that chain. With a time-based code from an authenticator app, a stolen password alone does not get in, since the attacker also needs a six-digit code that changes every thirty seconds. Hardware keys go further, since they check the website's address and refuse to respond to a lookalike domain, which removes most phishing risk.
Text messages are better than nothing, but they can be intercepted through SIM swapping, where an attacker persuades a mobile operator to move your number to their SIM. Use them as a last resort.
The places to turn it on, in order of importance: your email account (which can reset everything else), your hosting control panel, your domain registrar, and the WordPress administrator accounts. If you only have time for one, pick email.
3. Security plugins make a WordPress site unhackable
Myth
They add useful layers: login protection, scanning, firewalls. They can also have vulnerabilities of their own and can give owners a false sense of safety, so updates and backups get neglected.
Treat a security plugin as an extra, and the basics as the foundation: updates, unique passwords, minimal plugins.
No tool makes anything unhackable, and a plugin sits in a particular spot that limits what it can do. It runs inside WordPress, as PHP, with the same privileges as the code it is trying to watch. A file scanner compares your files against known-good copies of core and known malware signatures. That catches a lot of ordinary infections, but custom malware, or a backdoor placed in a file the scanner does not check, can slip through. A plugin-level firewall runs only after PHP has started, so it cannot stop an attack that exploits something earlier in the chain; a firewall at the server or network level sees the request first.
Security plugins are also large, privileged pieces of software, and that makes them attractive targets. Several popular ones have had serious vulnerabilities in the past. Installing one adds to your attack surface even as it subtracts from it elsewhere.
What I see most often is complacency. An owner installs a well-known security plugin, sees a green tick, and stops checking updates. Six months later a different plugin is exploited and the green tick turns out to have been telling them only what the scanner knew about.
What a decent security plugin does well: limits login attempts, adds two-factor authentication for WordPress accounts, alerts on file changes, and shows who logged in from where. Those are worth having. Pick one, keep it updated, and read its alerts rather than muting them.
Also consider what your host already provides. Many hosting accounts include a server-side web application firewall, malware scanning and brute-force protection. Running a second layer is fine, but know which one is doing which job.
4. Changing the WordPress login address fully protects you
Myth
It reduces the noise from automated attempts on the standard address, which is a modest benefit. It does not fix weak passwords or vulnerable plugins, and an attacker who finds the new address is back where they started.
Combine it with limits on login attempts and two-factor authentication.
Out of the box, WordPress login lives at /wp-login.php, and bots know that. Look at the access log of almost any site and you will find a steady stream of POST requests to that file from addresses all over the world, each trying a few common usernames and passwords. Moving the login to a custom address makes those bots get 404 errors instead. Logs get quieter and server load drops a little, which is useful on a small plan.
That is where the benefit stops. The new address is not a secret in any strong sense. It can leak through a link in an email, a browser history, a referrer header or a plugin that prints it. Other entry points exist as well: xmlrpc.php accepts login attempts and, on many sites, remains enabled although nothing uses it. The REST API exposes user names by default on many configurations, which tells an attacker which accounts to target.
Most important, hiding the door does nothing about what is behind it. A site with a vulnerable plugin can be taken over without ever touching the login page. A weak password is as weak at the new address as at the old one.
A stronger setup is layered. Limit failed attempts per address, require two-factor codes, use a username that is not "admin" and not the same as the public author name, and disable XML-RPC if you do not use it. If you also move the login page, count it as noise reduction and nothing more.
To check what the bots are doing, you can look at your own logs:
grep "POST /wp-login.php" /path/to/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | headThe path to the log depends on the host; the control panel usually shows where it is.
5. Small sites are not targeted
Myth
Most attacks are automated. Scanners probe huge numbers of addresses for known weaknesses, and they do not care how large the site is. A small site with an outdated plugin is found as readily as a large one.
Compromised small sites are valuable to attackers as hosts for spam, phishing and malware.
"Why would anyone bother with my village society's website?" is a fair question, and the answer is that nobody is bothering. Attackers write a script that checks a list of known vulnerable plugin versions against every site it can find, and the script costs the same to run on ten million sites as on ten. Your site's size, topic and owner never enter into it. What matters is whether it answers to a known weakness.
The value of a compromised small site is as infrastructure. It has a reputation (older domain, clean history) and it sends email from a reasonable address. Attackers use it to host a phishing page imitating a bank, to relay spam, to redirect search visitors to other sites, or to serve malware downloads. The owner often learns about it from a hosting suspension, a search engine warning or a message from a visitor.
The costs to the owner are real: a suspended account, a domain with a damaged email reputation so that legitimate messages go to spam, cleaning work, and sometimes a loss of search visibility that takes weeks to recover. A small organisation may have fewer resources to absorb this than a large one.
6. Backups protect me from ransomware automatically
Myth
Backups help only if the attacker cannot reach them. If backups live in a folder the compromised site can write to, or on a drive that stays connected, they can be encrypted or deleted as well.
Keep at least one copy offline or in storage with separate credentials, and test restoring it.
Ransomware on a website host usually means one of two things: files encrypted by malware that gained code execution, or a database wiped with a demand for payment. Either way the attacker has the same access the site has, and that is the point. A backup plugin that writes zip files into wp-content/backups gives you copies in the one place the attacker can already reach. They encrypt the live files and the backups in one go.
The same holds for any backup storage that your server can write to and delete from without restriction. A network drive that is always mounted, a cloud bucket where the stored access key has delete rights, a second folder in the same hosting account: all of these are reachable from a compromised process.
What survives is a copy that the compromised system cannot alter. Options include backups pulled by a separate machine using read-only access, storage with versioning or object lock so that deleted files can be recovered for a set period, and snapshots taken by the host at a level the account cannot touch. Ask your provider what they keep and for how long, and if you can restore it yourself.
The other half is testing. A backup that has never been restored is a hope. Once a quarter, restore to a scratch location or staging site and check that pages load, images appear and the database is complete. Time it, so you know how long a real recovery will take.
Also note that backups restore the vulnerability along with the data. If you restore a clean copy but the hole that let the attacker in is still open, they will be back. Update everything and change all passwords, including database and FTP, straight after restoring.
Look at your own configuration
Spend half an hour on a list. Log in and open the plugin list: note anything not updated in a year, anything inactive, anything you cannot explain. Look at the user list for administrators you do not recognise. Check that two-factor authentication is on for email, hosting and registrar accounts. Find out where your backups go and who can delete them. Look at your access log for the login-request pattern shown under claim 4. If your hosting account has a malware scanner, run it and read the result. Our troubleshooting guide covers what to do if something looks wrong.
Quick answers
How often should I update plugins?
Security releases should go on within days. Automatic updates for plugins you trust are a reasonable default, with a backup running first and a quick look at the site afterwards.
Is it safe to use the admin username?
It is not a vulnerability by itself, but it gives attackers half of the credentials for free. Use a different login name from the displayed author name.
What should I do first if I think the site is hacked?
Change passwords from a clean computer, take a copy of the files and logs for analysis, and contact your host. Do not delete files you do not recognise before you have kept a copy.
Do I need a firewall as well?
One at the server or network level is useful because it stops requests before PHP runs. Your host may already provide one, so ask.