How to Secure WordPress: The Complete 2026 Checklist

To secure a WordPress site, start with the measures that stop almost all automated attacks: keep everything updated (core, plugins, themes and PHP), give every account a unique password plus two-factor authentication, delete what you no longer use, and keep backups off the server. Then harden wp-config.php, add a web application firewall and monitor the site.

Checklist current as of 22 October 2026 (WordPress 7.1). Every setting links to the official WordPress documentation; WP-CLI commands are for sites whose host gives SSH access, and each step also gives the equivalent without a command line (dashboard, file manager, FTP).

Why do WordPress sites get hacked?

Because they are everywhere and easy to fingerprint. Bots crawl the web non-stop looking for vulnerable versions of popular plugins and for login pages guarded by weak passwords. Most attacks are not aimed at you personally; they exploit the first hole they find.

WordPress core is maintained by a dedicated security team and installs maintenance releases automatically. The real risk sits elsewhere: outdated plugins and themes (or “nulled”, pirated copies of premium ones), reused or guessable passwords, forgotten accounts of former contractors, and PHP versions that no longer receive security fixes. The good news is that most of what follows is free, and the first five steps alone shut out the bulk of automated attacks.

The WordPress security checklist at a glance

Start with the “Essential” rows: they give the most protection for the least effort.

Step 1: how do you keep WordPress, plugins and themes updated?

Turn on automatic updates for plugins and themes from the Plugins screen, let WordPress apply its maintenance releases on its own, and check weekly that no major update is waiting. A plugin that has not been updated in a long time should be replaced.

Since WordPress 3.7, core installs minor (security) releases automatically; since WordPress 5.5, every plugin and theme has an “Enable auto-updates” link. How it works, and the constants that control it, is documented in Configuring Automatic Background Updates.

The Dashboard > Updates screen lists everything that is waiting. If your host gives you SSH access, WP-CLI runs the same full check in a minute:

wp core version                      # installed version
wp core check-update                 # is a newer version available?
wp plugin list --update=available    # plugins with pending updates
wp theme list --update=available     # themes with pending updates
wp plugin update --all && wp theme update --all

Two caveats. On a store or a plugin-heavy site, take a fresh backup before major updates and check the site right after. And don’t forget PHP: WordPress recommends PHP 8.3 or later, and a PHP branch past end of life gets no security fixes. At Hosterwise, WordPress updates are applied automatically and you pick the PHP version per site in CyberPanel.

Step 2: how do you protect user accounts?

Give each person their own account with the lowest role that does the job, a long unique password generated by a password manager, and two-factor authentication (2FA). Remove accounts belonging to former contractors and avoid the username “admin”.

• Administrators: list them and ask whether each one really needs that role. A writer only needs Author or Editor.
• Passwords: a different password for every site, at least 16 random characters, stored in a manager. WordPress 6.8 moved to bcrypt password hashing, but a password already leaked elsewhere stays dangerous whatever the algorithm.
• Two-factor authentication: the Two Factor plugin, maintained by WordPress contributors, adds TOTP codes from an authenticator app, security keys and backup codes. Security plugins such as Wordfence also include 2FA in their free version.
• Application passwords: introduced in WordPress 5.6, they let external services log in to the API. Revoke any you no longer use from your profile.

To take stock, filter the Users screen by the Administrator role; with SSH access, WP-CLI does it from the command line:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp user update 12 --role=editor          # downgrade an account
wp user delete 15 --reassign=1           # delete and reassign their content

If no external service relies on application passwords, you can turn them off entirely from a small custom or must-use plugin:

add_filter( 'wp_is_application_passwords_available', '__return_false' );

Step 3: how do you protect the login page?

Limit login attempts per IP address, require 2FA for privileged accounts and close XML-RPC if nothing uses it. Moving the login URL is only a bonus: it reduces log noise, not the actual risk.

Brute-force attacks try thousands of username and password combinations; the official docs have a full page on brute force protection. In practice:

1. Limit attempts: a security plugin (Wordfence’s free version includes login limiting, for example) temporarily blocks an IP after repeated failures.
2. Use generic error messages: “unknown username” tells an attacker which accounts exist.
3. Deal with XML-RPC: xmlrpc.php is used by some older mobile apps, parts of Jetpack and pingbacks. If you don’t need it, block it from your security plugin. The xmlrpc_enabled filter only disables methods that require authentication, which already stops password guessing through that endpoint.

add_filter( 'xmlrpc_enabled', '__return_false' );

Step 4: which plugins and themes should you keep?

Only the ones you need, downloaded from the official WordPress.org directory or the vendor, and actively maintained. A deactivated plugin is still executable code on the server: if you don’t use it, delete it from the Plugins screen (Inactive filter), or with WP-CLI if your host gives you SSH access.

Before installing, check the last update date, the tested WordPress version and how responsive support is. Never install a “nulled” copy of a premium plugin: it is one of the most common ways to smuggle a backdoor into a site.

wp plugin list --status=inactive
wp plugin delete hello akismet
wp theme list --status=inactive

Keep one recent default theme installed: WordPress falls back to it if your main theme throws a fatal error.

Step 5: how do you harden wp-config.php and file permissions?

Disable the built-in file editor with DISALLOW_FILE_EDIT, keep debugging off in production, rotate the security keys if in doubt and apply the recommended permissions: 644 for files, 755 for folders, 400 or 440 for wp-config.php.

These come from the official Hardening WordPress guide. Add this above the “That’s all, stop editing!” line in wp-config.php:

// Block plugin and theme editing from the dashboard.
define( 'DISALLOW_FILE_EDIT', true );

// Never display errors in production.
define( 'WP_DEBUG', false );

// Always use HTTPS for logins and the admin area.
define( 'FORCE_SSL_ADMIN', true );

DISALLOW_FILE_EDIT won’t stop an attacker who can already upload files, but it prevents a stolen admin account from becoming code execution in two clicks. Set permissions from your FTP client or your control panel’s file manager (at Hosterwise, the CyberPanel one); for keys, replace the key block in wp-config.php with a fresh set from the official WordPress.org generator. With SSH access, these commands do both:

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 440 wp-config.php
wp config shuffle-salts      # new keys and salts (logs everyone out)

If PHP runs as a different user from the file owner, 440 may stop WordPress from reading wp-config.php: check the site right away and ask your host if it breaks. Changing the wp_ table prefix only makes sense on a fresh install; doing it on a live site is risky for little gain.

Step 6: why is HTTPS non-negotiable?

HTTPS encrypts everything between the browser and the server, including your password when you log in. Without it, anyone on the same Wi-Fi network can capture it. Certificates are free today, so there is no reason to go without.

Check that both addresses in Settings > General start with https://, that the old http:// address redirects to the new one, and that no “not secure” warning appears (a sign of mixed content). Since WordPress 5.7, Site Health flags a site without HTTPS as a critical issue. Every site hosted at Hosterwise gets a free SSL certificate, on every plan.

Step 7: what backups do you need?

Automatic, regular backups of files and database, with at least one copy off the server, and an occasional test restore. It is the one measure that saves you when everything else fails: a hack, a botched update or human error.

The best-known rule is 3-2-1, set out by the US cybersecurity agency in its Data Backup Options paper: three copies of your data, on two different media, one of them off-site. For WordPress, that usually means the live site, your host’s automatic backups and an external copy made by a plugin such as UpdraftPlus.

Keep several restore points over time: a compromise is sometimes discovered weeks later, and yesterday’s backup may already be infected. Hosterwise backups run automatically every day on every plan, are stored off the server that hosts your sites, and each one is kept for 30 days; that lets you go back to a version from before an intrusion discovered late, with our support team helping with the restore. As the 3-2-1 rule says, add your own copy outside our servers, for example on your Google Drive, a destination you set up yourself. For a brochure site or a blog, our Starter plan already includes these backups, a free SSL certificate and daily malware scans.

Step 8: how do you monitor the site and spot an intrusion?

Run a web application firewall with file scanning, verify core file integrity regularly, keep an eye on Site Health and log what users do. The goal is to detect a break-in within hours, not weeks.

• Firewall and scanner: Wordfence combines a firewall, malware scanning and login security. In the free version, new firewall rules and malware signatures arrive 30 days after paying customers get them, one more reason to keep everything updated.
• File integrity: WP-CLI compares your files with the official checksums. A modified or extra core file is a red flag. Without SSH, a Wordfence scan also compares core files with the official versions; at Hosterwise, our support team runs the checksum verification on request.
• Activity log: a logging plugin records logins, new accounts and settings changes, so you can reconstruct what happened.
• Server-side scans: every Hosterwise plan includes an automatic daily malware scan of your sites’ files.

wp core verify-checksums
wp plugin verify-checksums --all

What part does your host play in WordPress security?

Your host secures everything underneath WordPress: the server, the operating system, available PHP versions, isolation between accounts, SSL certificates and often backups and malware scans. You remain responsible for what lives inside WordPress: accounts, plugins, themes and settings.

Before you choose a host, ask which PHP versions it offers, whether SSL certificates are free and renewed automatically, how often backups run and whether support answers at night and at weekends. Our honest guide to the best WordPress hosting covers these criteria, and our WordPress hosting features page lists what is included with us.

What should you do if your WordPress site is hacked?

Contain the damage, change every credential, restore a clean backup or clean the site, then close the original hole, or the attacker will come straight back. If personal data may have leaked, you may have a legal duty to report it.

1. Put the site in maintenance mode and tell your host: server logs help identify what changed. At Hosterwise, our 24/7 support team can also run the WP-CLI commands in this procedure for you.
2. Change every password: WordPress accounts, database (then wp-config.php), FTP or SFTP accounts (at Hosterwise, the FTP accounts created in CyberPanel) and hosting panel, and rotate the keys (wp config shuffle-salts with SSH access, otherwise a fresh set of keys pasted into wp-config.php).
3. Restore a backup from before the intrusion, or reinstall core (wp core download --force --skip-content with SSH access, or by replacing wp-admin and wp-includes over FTP with the folders from an official package), reinstall plugins from their official source and look for PHP files in wp-content/uploads, where they have no business being.
4. Find the entry point: a vulnerable plugin, a compromised account, a reused password. Update or remove it.
5. Review accounts and delete any administrator you don’t recognise.
6. Assess the data exposure: in the EU and UK, the GDPR requires notifying your data protection authority without undue delay and, where feasible, within 72 hours, unless the breach is unlikely to put people at risk (see the European Data Protection Board’s guide on data breaches).
7. Request a review in Google Search Console if Google flagged the site as dangerous.

If you change hosts afterwards, only move a clean copy: our guide to migrating a WordPress site shows how to do it with zero downtime.

Start from a sound base with Hosterwise

WordPress security is a shared job. Your side: updates, protected accounts, a lean plugin list. Ours: maintained LiteSpeed Enterprise servers, no SSH access (one less door for attackers), a free SSL certificate for every site, daily automatic malware scans and backups on every plan (backups stored off the server that hosts your sites and kept for 30 days), automatic WordPress updates, and 24/7 support if something goes wrong.

To build on that base, compare our WordPress hosting plans: all include free migration of your site and a 30-day money-back guarantee. Questions first? Browse the FAQ or get in touch, and never send us a password by email.