Almost every compromised WordPress store was compromised through something ordinary: an outdated plugin with a known vulnerability, a reused administrator password, an abandoned account belonging to a developer who left two years ago, or a theme downloaded from somewhere that offered it for free. Sophisticated targeted attacks exist, but they are not what happens to a store selling candles.
That is good news, because ordinary problems have ordinary fixes. This checklist is ordered by risk reduction per hour spent, and it assumes a live store where you cannot simply take everything offline to experiment.
1. Accounts, because this is where most incidents start
List every user with administrator or shop-manager rights and justify each one out loud. Agencies that finished a project, a developer who left, a plugin vendor granted temporary access — all of them should be gone. Enforce two-factor authentication for every remaining administrator, and require a password manager. Do not share one admin login across a team: when everyone is "admin", the audit log tells you nothing about who did what.
- Remove accounts nobody can justify by name
- Two-factor on every administrator, no exceptions
- One account per human, never a shared login
- Rotate hosting, database, FTP and API credentials on staff changes
2. Updates, with a path back
Unpatched plugins are the most common entry point, and "we do not update because updates break things" is the reasoning behind a large share of compromised stores. The answer is not to skip updates; it is to make them safe. Update on staging, verify checkout with a real transaction, then push to production during a quiet window with a backup taken immediately before. Security patches for actively exploited vulnerabilities are worth applying faster than your normal cadence, and Patchstack and Wordfence both publish the advisories that tell you which those are.
3. Plugin and theme hygiene
Every plugin is code running on your store with your database access. Deactivated plugins still sit on disk and can still be exploited, so delete them; deactivating is not removing. Remove anything unmaintained — a plugin with no update in two years is a liability regardless of how well it works today. And never install nulled or "free premium" themes and plugins, which are one of the most reliable ways to invite a backdoor, because the modification is the product. If your stack has grown past what anyone can justify, plugin bloat covers the performance side of the same audit.
4. Backups you have actually restored
A backup you have never restored is a belief, not a control. Backups need to include files and database, be stored somewhere separate from the server they protect, keep enough history to reach back past a compromise nobody noticed for a fortnight, and be restorable by someone other than the person on holiday. Restore one to staging deliberately, this quarter, while nothing is wrong. The exercise usually surfaces at least one broken assumption.
5. Keep card data out of scope
The safest way to protect card data is to never touch it. Hosted payment fields and redirect flows keep card details on the payment provider's infrastructure, which keeps your PCI DSS self-assessment at SAQ A — around two dozen questions — instead of the several hundred in SAQ D. If a plugin or a customisation causes card data to pass through your server, that is a decision that needs a deliberate reason and a conversation with your payment provider about what obligations follow. Order data — names, addresses, emails, purchase history — is still sensitive personal data, and deserves the same seriousness even though it is not a card number.
6. The perimeter, in plain terms
HTTPS everywhere with a certificate that renews automatically. A web application firewall at the edge, which most managed hosts and CDNs offer. Rate limiting on the login and password reset endpoints, because credential stuffing is automated and constant. File editing disabled in the WordPress admin, so a compromised account cannot immediately edit theme code. Directory listing off. XML-RPC disabled unless something you actually use requires it.
- HTTPS with automatic renewal, everywhere
- WAF at the edge; rate limiting on login and password reset
- Disable file editing in the admin
- Turn off XML-RPC unless a tool you use needs it
7. Monitoring, so you find out before your customers do
Detection matters as much as prevention. File integrity monitoring tells you when core or theme files change unexpectedly. Uptime monitoring on a checkout-path URL, not just the homepage, catches the outages that cost money. Search Console's security report is free and will tell you if Google has found something before your customers start emailing. And a login-attempt alert is a cheap early warning that someone is working through your admin accounts.
What to do if it has already happened
Do not start by cleaning files. Contain first: take the site into maintenance if payment or personal data could be exposed, preserve logs before anything overwrites them, and rotate every credential including hosting and database. Then recover from a known-clean backup instead of trying to remove what you can see, because an unexplained entry point means the cleanup is not finished. The full incident order is in what to do when your store is hacked; if card data may have been exposed, that is a conversation for your payment provider and a lawyer, not a DIY afternoon.
Security is not a plugin you install. It is a small amount of unexciting maintenance, done on a schedule, by someone whose job it is.