Most WordPress sites are not hacked by a genius targeting your business. They are hacked by automated bots scanning millions of domains for one of three things: a known vulnerability in an outdated plugin, a weak or reused password, or an abandoned admin account nobody remembers creating. Close those three doors properly and you remove the overwhelming majority of real-world attacks.

This guide shows you how to secure a WordPress website in a specific order, because order matters. Installing a security plugin before you have a working backup, or hardening file permissions before you have removed the four plugins you stopped using in 2023, is effort spent in the wrong place. Everything below is written for business owners and site managers who look after their own WordPress install, not for system administrators.

The order of operations (and why it is this order)

Work top to bottom. Each step assumes the previous one is done.

#	Step	Time	Why it comes here
1	Working, tested backup	30 min	You can undo every mistake that follows
2	Fix the hosting layer	20 min	No plugin can fix a bad server or old PHP
3	Lock down the login	30 min	Brute force and credential stuffing are the #1 volume attack
4	Audit users and roles	15 min	Old accounts are a permanent open door
5	Delete unused plugins and themes	20 min	Shrinks attack surface before you protect it
6	Set a real update policy	30 min	Known vulnerabilities cause most compromises
7	File permissions and wp-config	30 min	Limits damage if something does get in
8	Configure one security plugin	45 min	Adds detection and blocking on top of a clean base
9	Add a WAF / edge layer	30 min	Filters junk traffic before PHP runs
10	Backup strategy and restore test	45 min	Your last line of defence, and the only one that always works

Total: roughly half a working day for the initial pass, then about 20 minutes per month using the checklist at the end.

Step 1: Get a real backup before you touch anything

Hardening involves editing configuration files and changing permissions. Both can break a site. Before the first change, you need a backup you have actually restored at least once.

What a usable backup looks like

• Full files plus the database, not one or the other
• Stored off the server, ideally off the hosting provider entirely (Google Drive, Dropbox, S3, a different provider)
• Versioned, so you keep at least 30 days of history. Malware often sits quietly for weeks, and a 24 hour backup window means you restore the infection
• Automated, on a schedule that matches how often your content changes

Good options: UpdraftPlus, Solid Backups, WPvivid, or your host’s own snapshot system if it stores copies off-site. Host snapshots alone are risky: if the account is suspended or compromised, you may lose access to both the site and the backups at the same moment.

Do the restore test now. Spin up a staging site (most decent hosts offer one click staging) and restore yesterday’s backup into it. If that fails, nothing else in this guide will save you. It is argued more carefully on janefriedman.com.

Step 2: Fix the hosting layer

Security plugins run inside WordPress. If the server underneath is misconfigured, you are building on sand. Check these in your hosting control panel:

• PHP version: run a version that is still receiving security support. As of late 2026 that means PHP 8.2 or newer. Anything in the 7.x range has been end of life for years and will not receive patches.
• HTTPS everywhere: a valid TLS certificate, HTTP redirected to HTTPS, and no mixed content warnings. This is also what the “Not secure” browser warning is about.
• Account isolation: on cheap shared hosting, one infected neighbour can sometimes reach your files. Ask your host whether accounts are isolated at user level.
• SFTP, not FTP: plain FTP sends your password in clear text. Disable it if you can.
• Database access: remote MySQL connections should be off unless you have a specific need.
• Separate credentials: hosting panel, SFTP, database and WordPress admin should all use different passwords.

Step 3: Lock down the login page

The login form is where the highest volume of automated traffic lands. A brand new WordPress site with no inbound links will still receive login attempts within days.

3.1 Strong, unique passwords for every account

Use a password manager and let it generate 20+ character random passwords. The reason unique matters more than complex: most successful “brute force” attacks are actually credential stuffing, where attackers replay username and password pairs leaked from unrelated breaches. A complex password reused on a hacked forum is worthless.

3.2 Two-factor authentication on every administrator

This single control neutralises stolen passwords. Use a TOTP app (Google Authenticator, Authy, 1Password, Bitwarden) rather than SMS. Wordfence Login Security, Two Factor, WP 2FA and the two-factor module in most security suites all do this for free.

Make it mandatory for Administrator and Editor roles. Optional 2FA that nobody enables protects nothing.

3.3 Limit login attempts and add a lockout

Cap failed attempts at 5 per IP, lock out for at least 20 minutes, and extend the lockout on repeat offenders. Also enable generic login error messages so WordPress stops telling attackers “that username exists, wrong password”.

3.4 Handle XML-RPC and the REST API

xmlrpc.php allows hundreds of password guesses in a single request, which is why it is such a popular target. If you do not use the WordPress mobile app, Jetpack or a remote publishing tool, disable XML-RPC entirely. Every major security plugin has a toggle for it.

Separately, disable user enumeration via the REST API and author archives, so bots cannot harvest your usernames from /wp-json/wp/v2/users or /?author=1.

3.5 Change the login URL (useful, but not a security control)

Moving /wp-login.php to something custom cuts dashboard noise and bandwidth dramatically. It is obscurity, not security: treat it as spam reduction, never as a replacement for 2FA and rate limiting.

Step 4: Audit users and roles

Go to Users > All Users and sort by role. Most business sites we audit have two or three Administrator accounts that should not exist: a former freelancer, an old agency, a plugin support login from a ticket in 2022.

The rules

1. Delete any account nobody can name. Reassign their content to an active user during deletion.
2. Keep the number of Administrators as low as possible. For most small businesses that is one or two people.
3. Apply least privilege. Someone who writes blog posts is an Author or Editor, never an Administrator.
4. Give yourself two accounts if you also publish content: one Administrator used only for maintenance, one Editor for day to day work. If the Editor session is hijacked, the attacker cannot install a plugin.
5. Never use “admin” as a username. Create a new Administrator with a different name, log in as that, delete the old one and reassign the posts.
6. Change the admin email to an address on a mailbox that itself has 2FA enabled. Email recovery is the route around every other login control.

Role reference

Role	Can install plugins / edit code	Give it to
Administrator	Yes	Owner, maintenance provider
Editor	No	Content manager
Author	No	Regular contributor
Contributor	No	Guest writer (needs review)
Subscriber	No	Customers, newsletter signups

Step 5: Delete every plugin and theme you do not use

The single largest source of WordPress compromises is vulnerable third party code. Deactivating a plugin is not enough: the files stay on disk and, in several documented cases, remain reachable and exploitable. Deactivate, then delete.

• Keep one inactive default theme (a recent Twenty Twenty-X) as a troubleshooting fallback, delete the rest
• Remove plugins that duplicate each other, for example two caching plugins or three SEO plugins
• Check each remaining plugin’s last updated date on WordPress.org. Anything untouched for over 12 months with no explanation is a liability, plan a replacement
• Be sceptical of nulled or “free premium” plugins and themes. A large share of them ship with backdoors. This is not a myth, it is one of the most common infection vectors we see on sites we clean

Ask one question per plugin: if this disappeared tomorrow, would anyone notice? If the answer is no, delete it.

Step 6: Set an update policy you will actually follow

“Keep WordPress updated” is the advice everyone gives and few systematise. Here is a policy that balances safety against the risk of an update breaking your site.

Component	Setting	Reasoning
Core, minor and security releases	Automatic	Very low breakage risk, patches known exploits fast
Core, major releases	Manual, after staging test	Can affect themes and builders
Security plugins, SEO, forms	Automatic	Frequently targeted, stable release cycles
Page builder, theme, WooCommerce	Manual, weekly window	Highest chance of visual or checkout breakage
Anything flagged as actively exploited	Immediately	Mass exploitation usually starts within 24 to 72 hours of disclosure

Get told before you get hit

Subscribe to a vulnerability feed so you are not relying on noticing a plugin update badge. Patchstack and Wordfence Intelligence both alert you when a component you actually run is affected, and Patchstack can apply virtual patches while the vendor prepares a fix. This is the difference between reactive and proactive maintenance.

Force minor core updates in wp-config.php:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Step 7: File permissions and wp-config hardening

These settings do not stop an attack starting, they limit what an attacker can do once inside. That is exactly why they matter.

7.1 Correct permissions

Target	Permission
Directories	755
Files	644
wp-config.php	600 (or 640)
.htaccess	644

Never use 777 on anything. If a plugin tells you to, that is a reason to stop using the plugin. Most security plugins include a permissions scanner that flags anything out of line. The piece Keeping WordPress Sites Secure makes a good next read.

7.2 Harden wp-config.php

// Block the built-in theme and plugin file editors
define( 'DISALLOW_FILE_EDIT', true );

// Force the admin area and login over HTTPS
define( 'FORCE_SSL_ADMIN', true );

// Hide errors from visitors
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

Disabling the file editor removes the most convenient way for an attacker with a stolen admin session to drop a backdoor. On sites where you never install plugins from the dashboard, you can go further with define( 'DISALLOW_FILE_MODS', true );, but be aware this also blocks updates from the dashboard.

7.3 Rotate your security keys

Generate fresh salts at api.wordpress.org/secret-key/1.1/salt/ and paste them into wp-config.php. This invalidates every existing login cookie, which is exactly what you want if you suspect anything odd. Everyone, including you, is logged out.

7.4 Stop PHP execution in the uploads folder

Attackers who find a file upload flaw will try to drop a .php file into /wp-content/uploads/. On Apache, create an .htaccess file in that folder containing:

<Files *.php>
deny from all
</Files>

On NGINX this has to be done in the server block, so ask your host. Most security plugins offer this as a one click option.

7.5 Disable directory browsing

Add Options -Indexes to your root .htaccess so nobody can list your folder contents in a browser.

Step 8: Install and configure one security plugin properly

Pick one. Running two overlapping security suites causes conflicts, duplicated firewall rules and false positives that make you ignore alerts. Reasonable choices:

• Wordfence: strong malware scanner, endpoint firewall, detailed live traffic view. Heavier on resources.
• Solid Security (formerly iThemes): clean interface, excellent login hardening, light footprint.
• All-In-One WP Security (AIOS): free, very broad feature set, good graded settings for beginners.
• Patchstack: vulnerability-first approach with virtual patching, pairs well with an edge WAF instead of a heavy scanner.

The settings that actually matter

1. Firewall in enabled / extended protection mode, not learning mode forever
2. Login attempt limiting with escalating lockouts
3. Two-factor authentication enforced for Administrators and Editors
4. Daily malware and file integrity scan, comparing core, plugin and theme files against the official repository versions
5. Email alerts for: admin logins from new IPs, new user creation, plugin or theme activation, file changes
6. Country blocking only if your audience is genuinely regional, and never applied to the whole front end of an e-commerce site
7. An activity log, so you have an audit trail of who changed what and when

Then do the important part: make sure the alert emails go to an inbox a human reads. Alerts routed to an unmonitored address are the most common reason a compromise runs for months.

Step 9: Add an edge firewall

A plugin firewall runs after WordPress has already loaded PHP. An edge or DNS level WAF filters requests before they ever reach your server, which protects both security and performance.

• Cloudflare (free tier is enough for many sites): enable the WAF managed rules, bot fight mode, and a rate limiting rule on /wp-login.php and /xmlrpc.php
• Sucuri or Cloudflare Pro if you need a full managed ruleset and DDoS mitigation
• Many managed WordPress hosts include a server level WAF. Check before paying twice

While you are at it, add security headers (HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy and a Content-Security-Policy if your setup allows it). Cloudflare or your host can inject most of these without touching code.

Step 10: Build a backup strategy, then test the restore

Back to where we started, but now properly. Apply the 3-2-1 rule: three copies, on two types of storage, one of them off-site.

Site type	Files	Database	Retention
Brochure site, rare updates	Weekly	Weekly	30 days
Active blog	Weekly	Daily	30 to 60 days
WooCommerce / membership	Daily	Hourly or real time	60 to 90 days

Three rules that turn a backup into insurance:

• Store copies away from the web server. Ransomware and attackers with file access will target backup folders sitting in /wp-content/
• Keep enough history to go back before an infection. Seven days is often not enough
• Test a full restore once a quarter on staging. Put it in the calendar. An untested backup is a hypothesis

Your monthly WordPress security checklist

The initial hardening is a one-off. Staying secure is a habit. Block 20 minutes on the first Monday of each month.

Check	What you are looking for
Users list	Any account you did not create, any role that was elevated
Pending updates	Core, plugins, themes, and PHP version still supported
Plugin count	Anything installed and forgotten since last month
Abandoned plugins	Last update older than 12 months
Latest backup	Ran successfully, correct file size, stored off-site
Malware scan result	Zero unresolved findings, no modified core files
Lockout and firewall log	Unusual spikes, repeated attempts on a valid username
Google Search Console	Security Issues tab, plus any strange indexed URLs
SSL certificate	Valid, auto-renewing, more than 30 days left
Admin 2FA	Still active on every administrator account

Twice a year, add: rotate admin passwords, regenerate wp-config salts, review third party API keys and integrations, and run a full restore test.

Common mistakes that undo all of this

• Installing five security plugins. They conflict and you end up trusting none of them
• Treating a hidden login URL as protection. It reduces noise, nothing more
• Leaving staging sites public. An outdated, unmaintained clone on a subdomain is a free entry point. Password protect it at server level and block indexing
• Sharing one admin account across a team, which destroys your audit trail
• Ignoring the email account tied to the admin user. It bypasses every login control through password reset
• Buying a scanner but never reading its alerts

If you think you are already compromised

1. Do not just delete suspicious files. Take a forensic copy first
2. Put the site into maintenance mode and, if data was exposed, involve your legal or DPO contact for breach notification duties
3. Change every password: WordPress, hosting, SFTP, database, and rotate the wp-config salts to kill active sessions
4. Restore from a backup dated before the earliest sign of infection, then immediately patch whatever let them in, otherwise you get reinfected within days
5. Scan for leftover backdoors in uploads, mu-plugins, and modified core files
6. Request a review in Google Search Console if you were flagged for malware

If that sounds like more than you want to handle in-house, our team at itimap handles WordPress hardening, ongoing maintenance and incident cleanup for businesses that would rather focus on their own work. Get in touch and we will audit what you have.

Frequently asked questions

Is WordPress outdated in 2026?

No. WordPress still powers a large share of the web and remains under active development with regular core and security releases. What is outdated is the way many sites are run: unpatched plugins, PHP versions past end of life, no 2FA and no backup policy. WordPress itself is not the weak point, the maintenance around it usually is.

How do you know if your WordPress site has been hacked?

Common symptoms include: unexpected redirects to other domains, spam pages or Japanese keywords appearing in Google results for your site, admin accounts you did not create, files with recent modification dates you cannot explain, a sudden traffic or resource spike, browser or Search Console malware warnings, and outbound email suddenly landing in spam because your server is sending bulk mail. Run a file integrity scan first, it compares your core and plugin files against the official versions and quickly reveals injected code.

Can you password protect a WordPress website?

Yes, at three levels. For a single page or post, use the built-in Visibility > Password protected option in the editor. For the whole site, use a maintenance mode or membership plugin. For real protection, for example on a staging or pre-launch site, apply HTTP authentication at server level through your hosting panel, since that blocks requests before WordPress even loads.

Why does my WordPress website say Not secure?

That browser warning is about HTTPS, not malware. It means your site has no valid TLS certificate, or that your pages load some assets over plain HTTP (mixed content). Fix it by installing a certificate (most hosts provide free Let’s Encrypt certificates), updating the WordPress Address and Site Address to https in Settings > General, forcing a redirect from HTTP, and correcting any hard-coded http:// image or script URLs.

Do I need a paid security plugin?

Not necessarily. The free tiers of the main suites cover login hardening, scanning and basic firewalling well. Paid plans mainly add faster firewall rule delivery, real time malware signatures, virtual patching and support. If your site generates revenue or handles customer data, the paid tier and a managed maintenance plan are cheap compared to a week of downtime.

How often should I update WordPress plugins?

Check weekly, apply security-flagged updates the same day they appear. Enable automatic updates for core minor releases and for low risk plugins, and test major updates to your theme, page builder or WooCommerce on staging before pushing them live.

Is a security plugin enough on its own?

No. A plugin cannot fix an outdated PHP version, a reused admin password, a nulled theme with a backdoor, or a missing backup. Think of it as one layer in a stack: hosting, credentials, minimal attack surface, patching, permissions, detection, edge filtering and recovery. Each one covers a gap the others leave open.