How to Secure a WordPress Website: The Checklist I Run After a Hack

To secure a WordPress website, keep plugins, themes and core updated, protect every login with a strong unique password and two-factor authentication, give each person and each API or AI tool only the access it needs, run off-site backups you have tested, and put a firewall and monitoring in front of the site. Here’s the checklist, and the recovery steps to follow when a site has been hacked.

The short answer

• Securing a WordPress website means reducing the ways in (outdated plugins, weak logins, too much access) and making sure you can recover fast if something gets through.
• Patchstack recorded 11,334 new WordPress ecosystem vulnerability disclosures in 2025:91% in plugins,9% in themes and six in core. Disclosures are not a count of attacks or your site’s risk.
• Plan urgent mitigation as well as patches:46% of those disclosures had no developer fix at disclosure. A routine weekly review alone is not enough for an actively exploited issue.
• The non-negotiables are updates, two-factor logins, least-privilege user roles, a web application firewall, and tested off-site backups.
• If you are hacked, contain it, change every credential, restore from a clean backup, close the hole that let them in, and check your legal obligations.

Security is not about being too small to notice. It is about not being the easy one. Not long ago an industrial supplier asked my team to look at a site nobody had been looking after. We found an active backdoor spread across about a hundred files in uploads, plugins and core, injected through a vulnerable display plugin, plus two admin accounts nobody could explain, no backup for years and no two-factor login on several accounts. We cleaned the files and database, replaced the plugin, then added backups, two-factor logins and hardening, and checked the site again afterwards. Nothing suggests anyone picked that business out: one vulnerable plugin on a site nobody owned was enough.

How do you secure a WordPress website?

You secure a WordPress website with layers: keep everything updated, lock down logins, limit user access, harden the server and WordPress configuration, filter traffic with a firewall, monitor for changes, and keep tested backups off-site. No single plugin does all of this. Each layer catches what the one before it misses.

Layer	Action	How often
Updates	Update plugins, themes and core; apply security fixes the same day	Weekly, and on release for security fixes
Plugins	Remove unused and abandoned plugins; install only from trusted sources, never nulled copies	Quarterly review
Logins	Strong unique passwords, two-factor authentication for every admin, limit login attempts	Set once, review quarterly
Users	Least-privilege roles, no shared accounts, remove people who have left	Monthly
Server	Supported PHP version, SSL everywhere, secure file permissions, SFTP not FTP	On setup, then quarterly
WordPress config	Protect wp-config.php, disable file editing in the dashboard, unique salts	On setup
Firewall	Web application firewall at the host, CDN or plugin level	Always on
Monitoring	Malware scanning, file change alerts, uptime monitoring	Continuous
Backups	Daily off-site backups, kept for 30+ days, restore tested	Daily, test quarterly

The numbers explain why updates come first. Patchstack’s State of WordPress Security in 2026 counted 11,334 new vulnerabilities in 2025, up 42% on 2024. 91% were in plugins, 9% in themes, and just 6 in WordPress core.

What are the most important WordPress security settings?

Prioritise appropriate authentication, least-privilege capabilities, supported software, restricted code-change paths, encrypted transport and traffic filtering. These reduce exposure but need review across the host, WordPress, plugins and enabled API/tool routes; a settings list alone does not establish that common attacks are blocked.

1. Two-factor authentication for every account that can publish or change settings.
2. Limit login attempts, so automated password guessing is blocked.
3. Least privilege. Match capabilities to the job. A Contributor may suit draft-only work; Authors can publish and edit/delete their own published posts; Editors have broader powers. Shop Manager is substantial access too, not the minimum for every shop employee. Review application passwords and tool/API permissions separately.
4. Disable the built-in file editor where appropriate. DISALLOW_FILE_EDIT removes that editor; it does not stop a compromised Administrator from every other plugin-installation or code-change path.
5. Protect wp-config.php and use unique security keys and salts.
6. Force SSL on every page, including the admin area.
7. Firewall at the host or CDN, so bad traffic is stopped before it reaches WordPress.

Two-factor protection on the interactive login does not automatically cover application passwords or every API/tool connection. Use unique, revocable credentials with server-enforced capability limits, and test what the account can publish, edit or delete through every enabled route.

Renaming the login URL reduces noise from bots, but it is not protection on its own. Treat it as a nice-to-have after the steps above.

Why do WordPress updates matter so much for security?

Patchstack’s 2026 report says 46% of 2025 disclosures lacked a fix at disclosure. Its 5-hour figure is an attack-activity-weighted median from RapidMitigate rule deployment to the first observed exploit attempt, not a universal window from public disclosure to mass exploitation. Set patch and mitigation priorities from the actual exposure and threat. Keep the computers used to administer the site supported too: Microsoft ended normal Windows 10 support on 14 October 2025, while its current consumer ESU page offers security updates through 12 October 2027 for eligible enrolled devices. Other editions/programmes have separate terms.

That has two practical consequences:

• Apply security updates the same day, after a quick test on staging. Weekly is fine for feature updates, not for security fixes.
• Have a plan for when no patch exists. Deactivate and remove the plugin if the site can run without it, or replace it with a maintained alternative. If you cannot remove it yet, a firewall with virtual patching can block known attacks on that flaw, and you can restrict who can reach the affected feature until a fix ships.

Automatic updates help for minor WordPress releases and low-risk plugins. For a WooCommerce store or a site with custom code, test updates on staging first, because a broken checkout is also a business incident. The full update process is in my guide to WordPress maintenance.

How do you secure a WooCommerce store?

For WooCommerce, add a reviewed payment integration, appropriate staff permissions, tested checkout changes and monitoring of orders/accounts. Hosted payment pages or fields can reduce card-data handling, but tokenisation alone does not prove card numbers never pass through your server or remove PCI obligations. Confirm the actual gateway integration and responsibilities.

• Never store card details on your site. Use a payment gateway that handles card data on its own secure pages or fields.
• Update WooCommerce and its extensions promptly, after testing checkout on staging.
• Give each staff member only the order/product capabilities they need; review Shop Manager permissions rather than assigning it to everyone.
• Watch for fake accounts and card-testing attacks, where bots try stolen card numbers through your checkout.
• Keep customer data to what you need, and know where it is stored, including backups.
• Use SSL, a firewall and a CDN, so traffic is encrypted and attacks are filtered.

What should you do if your WordPress site is hacked?

If your WordPress site is hacked, contain it first, then change every credential, find and remove the infection or restore from a clean backup, close the vulnerability that let the attacker in, and check whether personal data was exposed. Do not just delete the visible malware. If you do not find the way in, the attacker can simply come back the same way.

The recovery checklist I follow:

1. Contain. Ask the host/security responder to restrict public and attacker access at the host, edge or application boundary. A maintenance-screen plugin alone can leave API or backdoor routes active.
2. Preserve evidence. Take a copy of the hacked files, database and logs before you change anything.
3. Change every credential. WordPress admins, hosting, SFTP, database, CDN, email, and any API keys in plugins. Regenerate the WordPress security keys and salts.
4. Remove unknown admin users and check every remaining account.
5. Find the way in. Usually an outdated plugin or theme, a stolen password or a nulled plugin. Check the logs and update history.
6. Clean or restore in isolation. Establish a clean recovery point and preserve recent legitimate data. Patch and verify the restored copy before reopening it; reconcile orders, payments, inventory, accounts and subscriptions if a database restore goes back in time.
7. Update everything and remove plugins you do not need.
8. Rotate credentials again once the site is clean, because passwords changed while a backdoor was still active may have been captured.
9. Scan again and watch file changes, new users and logins for the next few weeks. A clean scan is a good sign, not proof.
10. Check Google Search Console for security issues and request a review if Google has flagged the site.
11. Assess notification duties. For entities covered by the Australian Notifiable Data Breaches scheme, an eligible breach generally involves likely serious harm and may require notice to affected people and the OAIC. Assess the circumstances and remedial action promptly using the OAIC guidance; not every suspected exposure automatically meets the notification test.

A tested clean recovery point can shorten an incident, but it does not guarantee an afternoon recovery. The investigation, data reconciliation, patching, access changes and notification assessment still need owners.

Can a security plugin keep WordPress safe on its own?

A security product can provide useful scanning, login, firewall, update, backup or restore features depending on the product. Those features still need configuration, testing, monitoring and decisions about access and incidents. Check what the actual product does; do not assume a plugin alone owns the whole security process.

What a security plugin does well, and what it does not:

Covered well by a security plugin	Needs a person, the host or a process
Login attempt limits and two-factor authentication	Deciding who has which role, and removing old users
Malware and file change scanning	Updating plugins and testing the updates
Application firewall rules	Server hardening, PHP version and network security
Security alerts	Responding to an alert at 2am
Some backup features	Off-site backups and tested restores

Your host matters too. Managed WordPress hosting usually adds server firewalls, isolation between sites and malware scanning. If you are choosing a host, my web hosting buyer guide covers what to check.

What to do next

1. Turn on two-factor authentication for every administrator today.
2. Remove users who no longer need access and downgrade anyone who does not need Administrator.
3. Delete unused plugins, then update everything that is left.
4. Confirm your backups are off-site and restore one to staging.
5. Put a firewall and malware monitoring in front of the site.

If your site has been hacked or you want an independent check, book a free call. My team looks after WordPress support and maintenance in Sydney and across Australia, including security clean-ups.

Frequently asked questions

Is WordPress secure?

Assess WordPress security from the deployed stack, permissions, patch process, monitoring and recovery. Patchstack’s six core disclosures versus thousands in extensions describe its 2025 dataset; they do not establish comparative attack risk or prove one platform will outperform another. Keep the evidence and responsibilities specific to your installation.

How do I know if my WordPress site has been hacked?

Signs your WordPress site has been hacked include unknown admin users, redirects to spam or scam sites, strange pages or links in search results, Google or browser security warnings, sudden slowdowns, unexpected emails being sent, and files changed that nobody touched. A security scan and Google Search Console’s Security issues report can confirm a problem, but a clean result cannot rule one out: scanners miss new or well-hidden malware, and Search Console shows only what Google has found. If the signs persist, have someone check files, users and server logs by hand.

How often should I back up WordPress for security?

Back up WordPress at least daily, store the backups away from your web server, and keep at least 30 days of history so you can go back to a point before an infection. Take an extra backup before every update. Test a restore every quarter, because an untested backup may fail when you need it.

Should I hide the WordPress login page?

Hiding the WordPress login page reduces automated login attempts and log noise, but it does not replace real protection. A determined attacker can still find it. Prioritise two-factor authentication, limited login attempts and strong unique passwords. Treat a custom login URL as an extra layer, not a security measure on its own.

What are nulled plugins and why are they dangerous?

“Nulled” usually refers to redistributed premium packages with licensing controls changed or removed. GPL rights and commercial support terms need separate assessment; the practical security issue is an untrusted or modified source and an unreliable update channel. Do not assume every such package contains malware, but use a trusted distribution, review provenance and maintain a supported update path.