How to Secure a WordPress Site

Securing a WordPress site is a repeatable checklist of updates, access control, backups and monitoring, because most WordPress sites are breached through outdated plugins, weak logins and unpatched hosting, not clever attacks. A care plan runs that checklist every month, so nothing depends on someone remembering.

Most hacked WordPress sites were never targeted by anyone clever. A plugin went unpatched for months, a former employee still had admin rights, or the hosting ran software nobody had checked since launch. Automated tools scan for those gaps all day, and the first sign of trouble is often a browser warning, a spam redirect or an alert from Google.

The fix is not a single plugin. It is a short list of controls that someone checks every month: updates, logins, hosting, backups and monitoring. The hard part is usually ownership. The developer who built the site has moved on, the host assumes the site is yours to manage, and the person with the admin password has no time to run checks.

Below is the 14-item checklist we use, split into four phases. Each item gives you the reason, a check you can run in about a minute and the fix. After that you will find a plain comparison of three common security plugins, a recovery plan in the right order if the site is already compromised, and a clear split of who should own each job.

How do I lock down updates and the code running on my site?

Apply updates within days and delete any code you are not using. WordPress.org's security guidance names keeping WordPress itself and all installed plugins and themes up to date as the most important thing you can do for WordPress security, and it encourages choosing themes and plugins that are actively receiving updates.

Plugins need constant attention, because each one is written by a different team on its own release schedule. These three items control what code runs on your site and how quickly it gets fixed.

1. Apply core, theme and plugin updates within days, tested on a staging site first.
   • Why: Once a security fix ships, the flaw it patches is public, and sites that have not updated become easy targets.
   • Check: Open Dashboard > Updates. If anything has been waiting more than a few days, you are behind.
   • Fix: Copy the site to staging, run the updates, click through key pages, forms and checkout, then apply the same updates live. On a WordPress site we maintain for a consumer product brand, plugin updates and staging tests run monthly under a care plan, because the site's third-party e-commerce cart has to keep working after every change.
2. Remove unused themes and plugins.
   • Why: A deactivated plugin or spare theme still sits on your server, and its files can still be reached and exploited.
   • Check: Go to Plugins > Installed Plugins and click Inactive, then open Appearance > Themes. Note anything you are not using.
   • Fix: Delete inactive plugins outright and keep one current default theme as a fallback. Deleting removes the files; deactivating does not.
3. Choose plugins by their maintenance record.
   • Why: An abandoned plugin never gets a fix, no matter how quickly you update.
   • Check: On each plugin's page in the official plugin directory, confirm the last update was under six months ago, the active install count is healthy, and recent support threads get replies.
   • Fix: Replace any plugin that fails those tests. Never install nulled themes or plugins (pirated copies of paid products), because you cannot verify what has been added to the code.

How do I stop someone logging in as me?

Put every account behind a unique password and a second factor, then remove access nobody needs. A stolen or guessed login walks straight past every other control on this list, so treat this phase as non-negotiable.

Login security also covers accounts outside WordPress. Your hosting panel, domain registrar, SFTP account and the inbox that receives password resets can each hand someone control of the site.

4. Use strong, unique passwords stored in a password manager for every account.
   • Why: Reused passwords leak from other services and get tried against your login page automatically.
   • Check: Ask everyone with access whether their WordPress, hosting and registrar passwords live in a password manager and are used nowhere else.
   • Fix: Set up a business password manager, move hosting and registrar credentials into a shared vault, and reset any reused password.
5. Turn on two-factor authentication for every admin account.
   • Why: With two-factor authentication in place, a stolen password alone no longer gets anyone in.
   • Check: In your security plugin's login settings, confirm every administrator shows two-factor as active, not just available.
   • Fix: Enable it in a security plugin and enforce it for the Administrator and Editor roles, with backup codes stored in the password manager.
6. Limit login attempts and protect the login URL.
   • Why: Bots run brute force login attempts against wp-login.php around the clock, cycling through common usernames and passwords.
   • Check: In a private browser window, enter a wrong password several times. You should be locked out or challenged.
   • Fix: Turn on brute force protection in your security plugin. Moving or restricting the login URL cuts down bot noise, but treat it as a bonus on top of two-factor authentication, never a replacement.
7. Use least-privilege user roles, with no shared admin logins.
   • Why: Every admin account is a full key to the site, and a shared login means you cannot tell who did what or cut off one person.
   • Check: Open Users > All Users and filter by Administrator. Every name should be a current person who genuinely needs that role.
   • Fix: Move content staff to Editor or Author, give each person their own login, and delete former staff accounts after reassigning their content.

How do I harden the hosting, certificate and server side?

Use a host that patches the server for you, then add HTTPS, a firewall and a supported PHP version on top. The WordPress.org hardening handbook stresses understanding where your host's responsibility ends and yours begins, and lists providing the most recent stable versions of all server software among the qualities of a trusted host.

These four items are the server-side half of WordPress hardening. Most of them take one email to your host and a few minutes in the dashboard.

8. Serve every page over HTTPS with an auto-renewing certificate and HSTS.
   • Why: HTTPS encrypts logins and form data in transit, and an expired certificate puts a full-page browser warning in front of visitors.
   • Check: Type your domain with http:// in front and confirm it redirects to https://. Click the padlock to see the certificate's expiry date, and look for a Strict-Transport-Security header in your browser's developer tools under Network.
   • Fix: Turn on certificate auto-renewal at your host, force HTTPS redirects site-wide, and add the HSTS header once every page loads cleanly over HTTPS.
9. Use managed hosting with server-level patching and isolation.
   • Why: WordPress runs on top of the operating system, web server and PHP, and an unpatched server undoes everything you do inside the dashboard.
   • Check: Email your host and ask who patches the server software and whether your site is isolated from other accounts on the same machine. Keep the written answer.
   • Fix: If the answers are vague, move to managed WordPress hosting that handles patching and isolation, or have your developer take on server patching in writing.
10. Run a web application firewall and scheduled malware scanning.
    • Why: A web application firewall blocks known attack patterns before they reach WordPress, and malware scanning catches what gets through.
    • Check: Confirm your DNS routes through a cloud firewall such as Cloudflare, or that your security plugin's firewall shows as active, then check the date of the last malware scan.
    • Fix: Put the site behind a cloud firewall and schedule daily scans in a security plugin. The plugin comparison below covers three common options.
11. Keep PHP on a supported version.
    • Why: PHP versions past end of life stop receiving security fixes, and every request your site handles runs through PHP.
    • Check: Open Tools > Site Health > Info > Server to see your PHP version, then compare it with the supported versions list on php.net. The Site Health status screen also flags outdated PHP.
    • Fix: Ask your host to upgrade PHP on staging first, test your plugins and theme, then switch the live site.

How do I make sure I can recover and get told when something changes?

Keep daily backups off the server, prove they restore, and set up alerts so you hear about a problem before your clients do. The official guidance describes security as reducing risk and planning for recovery, because risk can never be reduced to zero.

This phase is what turns a bad day into a short one. Each item here is cheap to set up and easy to forget.

12. Run daily off-site backups and test the restore.
    • Why: A backup stored on the same server can be deleted or encrypted in the same attack, and an untested backup may not restore at all.
    • Check: Find when the last backup ran, confirm it is stored outside your hosting account, and ask when anyone last restored one.
    • Fix: Schedule daily automated backups to separate cloud storage and restore one to staging every quarter. A restore you have practised is one you can run under pressure.
13. Disable file editing in the dashboard, and XML-RPC if you do not use it.
    • Why: The built-in theme and plugin editor lets anyone with an admin login change PHP code directly, and XML-RPC is another door for login guessing.
    • Check: Look under Appearance or Tools for a Theme File Editor menu item; if it appears, editing is on. Then visit yourdomain.com/xmlrpc.php: a message saying the XML-RPC server accepts POST requests only means it is live.
    • Fix: Add define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php, which the hardening handbook covers in its own section. Block XML-RPC through your security plugin or host unless Jetpack or a mobile publishing app depends on it.
14. Monitor uptime, file changes and Search Console security issues.
    • Why: Without alerts, a hacked or offline site can run for weeks before anyone notices, and you can read more on how website downtime hurts your Google rankings.
    • Check: Confirm you get an email when the site goes down, that your last plugin update triggered a file-change alert, and that the Security issues report in Search Console (under Security & Manual Actions) shows no problems.
    • Fix: Set up an uptime monitor, enable file change detection in your security plugin, and add a second verified owner in Search Console so alerts never land in one forgotten inbox.

Which WordPress security plugin is right for my site?

Choose by where you want the filtering to happen and what your host already covers. Of the three tools firms usually shortlist, one runs inside WordPress, one filters traffic in the cloud before it reaches your server, and one now ships as part of a wider add-ons bundle.

Wordfence

Wordfence is a plugin-based firewall and malware scanner that runs on your own server, with login protection and two-factor authentication managed from the dashboard.

• Free versus paid: a free plugin is available, with paid tiers on top.
• Price: we did not verify current pricing for this post, so check the vendor's own pricing page before buying.
• Honest limitation: because it runs inside WordPress, attack traffic reaches your server before it is filtered, and scans use your hosting resources.

Sucuri

Sucuri's firewall page describes a cloud web application firewall that protects sites from hacks, DDoS attacks and zero-day exploits before they reach the server, with guaranteed malware removal, a 24/7 security team and a 30-day guarantee.

• Free versus paid: paid platform plans.
• Price: the Basic Platform plan is listed at $229 per year, aimed at site owners "requiring occasional cleanups with ongoing security scans." The page does not mark the figure as Canadian dollars, so confirm the currency at checkout.
• Honest limitation: activation means changing your DNS records, and uploading a custom SSL certificate requires the Professional or Business plan.

Solid Security

Solid Security's page now presents the product as Kadence Security, part of a Kadence add-ons bundle. It lists a real-time firewall with automatic rule updates, two-factor authentication, Patchstack virtual patching, brute force protection, file change detection and a security dashboard, with daily incremental off-site backups in the same bundle.

• Free versus paid: included with the bundle's Pro and Elite plans.
• Price: the security page shows no figure, so check the vendor's bundle pricing.
• Honest limitation: security now comes packaged with WooCommerce, membership and design tools, so you may pay for features you will never use.

Tool	Where it filters	Free version	Listed price (vendor's currency, billing cycle)	One limitation
Wordfence	On your server, inside WordPress	Yes	Not verified for this post	Traffic reaches your server before filtering
Sucuri	In the cloud, before your server	No, paid plans	Basic Platform at $229 per year (vendor page, not marked CAD)	Requires a DNS change to activate
Solid Security (Kadence Security)	Inside WordPress, with virtual patching	No, included in Pro and Elite	No price on the security page	Bundled with tools you may not need

Whatever you pick, run one security plugin firewall, not two. Overlapping firewalls can conflict and make problems harder to trace.

What do I do if my WordPress site is already hacked, and who owns this every month?

Contain the damage first, then restore, rotate, re-scan and only then ask Google for a review. After that, give the checklist a named owner so it runs every month instead of after the next incident.

Recovery, in this order

1. Put the site in maintenance mode or take it offline. If you cannot log in, ask your host to suspend it. This stops visitors and search engines seeing malware while you work.
2. Restore from a clean backup. Pick one dated before the compromise, then update core, plugins and themes straight away, because the restore brings back the old hole too.
3. Rotate every password and key. Reset WordPress user, hosting, SFTP and database passwords, and regenerate the security keys and salts in wp-config.php, which signs everyone out.
4. Re-scan. Run a full malware scan, delete any admin users you do not recognise and review recent file-change alerts.
5. Request a review if flagged. If the Security issues report in Search Console lists problems, fix each one, then click Request Review and describe what you cleaned.

If there is no clean backup, have a specialist clean the site before it goes back online.

Who owns WordPress security?

Who	What they should own	Where it breaks down
The owner	Credentials, who has access, Search Console ownership, budget	Rarely has time to run monthly checks
The original developer	Hardening at launch: HTTPS, roles, backups, file editing off	Often not contracted after launch
A care plan	Monthly updates with staging tests, backups, scans, monitoring and reporting	Only works if the owner keeps access and approvals current

We run monthly care plans for WordPress sites covering updates, backups, security and speed. For the consumer product brand mentioned earlier, plugin updates, staging tests and backups all run every month under that plan. Our guide to what a monthly website care plan covers walks through the routine. If a site is too old or too patched-together to secure properly, our web design and build service can rebuild it on a clean base.

What does the full WordPress security checklist look like?

Here are all 14 steps with the one-minute check for each. Copy the table into a shared document, put an owner's name beside every row and rerun it monthly.

Step	Check
1. Updates applied within days, tested on staging	Dashboard > Updates shows nothing waiting more than a few days
2. Unused themes and plugins removed	Inactive plugins list is empty; only one fallback theme remains
3. Plugins chosen by maintenance record	Each plugin updated under six months ago, with active installs and answered support threads
4. Strong, unique passwords in a password manager	Every user confirms passwords live in the manager and are not reused
5. Two-factor authentication on all admins	Security plugin shows two-factor active for every administrator
6. Login attempts limited, login URL protected	Repeated wrong passwords in a private window trigger a lockout
7. Least-privilege roles, no shared admin logins	Administrator filter lists only current people who need the role
8. HTTPS with an auto-renewing certificate and HSTS	http:// redirects to https://, certificate valid, Strict-Transport-Security header present
9. Managed hosting with patching and isolation	Written answer from the host on who patches and how sites are isolated
10. Web application firewall and malware scanning	Firewall shows active and the last scan ran recently
11. Supported PHP version	Site Health shows a PHP version on php.net's supported list
12. Daily off-site backups with a tested restore	Last backup ran in the past day, sits off the server, restore tested this quarter
13. File editing and unused XML-RPC disabled	No Theme File Editor menu; xmlrpc.php blocked if unused
14. Uptime, file-change and Search Console monitoring	Alerts arrive by email and the Security issues report is clear

Wrapping Up

WordPress security is a routine, not a rescue. Keep the code updated and lean, lock down every login, get written answers from your host, and make sure backups restore and alerts reach someone who reads them. Each of the 14 checks takes about a minute to verify, so the real question is who runs them next month and the month after.

If nobody in your office can answer that today, start there. We can audit your site against this checklist, show you what is unmonitored right now and set up a monthly care plan that keeps it covered. Book a free consultation with our team in Saint John.