Fix Once: The Settings That Close the Common Doors
A WordPress security checklist comes down to two groups of work: settings you correct once, and checks you repeat on a schedule. The first group stops the common automated attacks, which go after outdated plugins, guessable logins, and files that should not be writable. This one is written for owners of live sites who want to know what is covered and what is not, and for anyone deciding whether to keep doing it by hand.
Update Core, Plugins, and Themes on a Schedule
Outdated software is where most compromises start, and the fix is dull. WordPress documentation says minor and security releases of core update on their own, and that by default plugins and themes only update automatically in special cases the WordPress security team controls for critical vulnerabilities (WordPress upgrade documentation, checked October 2026). Everything else waits for a person to click.
That gap is the one to close. Turn on automatic updates for the plugins you trust, and for the rest set a recurring time to apply them, not a vague intention. Updates are also what break sites, which is why a staging copy matters before a large batch. If an update does take a site down, the white screen of death guide walks through finding the fatal error.
Delete What You Are Not Using
A deactivated plugin still sits on disk, and its files can still be requested directly if they contain a vulnerability. The same goes for a theme you switched away from. Delete both rather than leaving them inactive. Look for plugins that have not had an update in a long time or have been closed in the WordPress.org directory, because a plugin nobody maintains will never receive the patch you are waiting for.
Paid plugins add a second risk. When a license lapses, the plugin stops receiving updates, often without any warning on the site, and a security patch silently fails to arrive. Keep a list of every paid plugin with its renewal date, or have it managed for you.
Tighten Accounts and Logins
The WordPress hardening guide advises against easily guessed usernames such as admin and recommends two-step authentication (WordPress hardening guide, checked October 2026). Add to that a unique password per person, a password manager so that rule is realistic, and the lowest role that lets each person do the job. An author does not need the Administrator role to write posts.
Then audit the list of users. Former employees, old agency logins, and the account someone created for a one-off task are the accounts that outlive their purpose. Every Administrator should be a person you can name.
Lock Down File Editing and Permissions
By default an administrator can edit plugin and theme PHP from the dashboard, which means a stolen login can become code running on your server in one step. The hardening guide's fix is a single line in wp-config.php: define( 'DISALLOW_FILE_EDIT', true );.
The same guide gives file permissions of 755 for directories and 644 for files, and says wp-config.php should be readable only by you and the web server, which generally means 400 or 440. Check what your host actually sets rather than assuming.
Use SFTP and HTTPS, Not Their Older Cousins
Plain FTP sends your password in the clear. The hardening guide recommends SFTP for an encrypted connection, and it takes a single setting change in most clients. The same reasoning applies to the site itself: serve every page over HTTPS, redirect the HTTP version, and keep the certificate renewing on its own. A certificate that lapses puts a browser warning in front of every visitor until someone renews it.
Protect Wp-config.php and the Database
wp-config.php holds your database credentials and secret keys, so it deserves more care than any other file. The hardening guide offers two options: move it to the directory above the WordPress install, or deny web access to it with a rule in .htaccess, such as <Files "wp-config.php"> Require all denied </Files>. Which fits depends on your server, and a host running something other than Apache will need the equivalent rule in its own syntax.
The same guide suggests changing the default wp_ database table prefix, which it says can block at least some SQL injection attacks. It is a small gain on a new install and a risky change on an old one, so treat it as something to do at build time rather than a task for a live site with years of data in it. Whatever you decide, keep a database backup from just before the change.
Put a Filter in Front of the Site
A web application firewall at the network edge screens requests before they reach WordPress. That stops much of the automated probing, such as scanners looking for known vulnerable plugin paths, before it reaches your server. It also does nothing about a stolen password or a plugin flaw that is exploited through a normal-looking request, which is why it sits beside the settings above rather than replacing them. Edge protection covers the firewall, bot, and cache rules for a domain.
Keep Checking: What Needs a Calendar
Settings drift. A plugin update changes a default, a developer adds an account, a host moves a PHP version. The second half of the list is about noticing that.
Backups You Have Restored
A backup you have never restored is a guess. Check that the backup includes the database as well as the files, that it is stored somewhere other than the server it protects, and that you know how long it keeps history. A site infected three weeks ago needs a copy from before the infection, and a seven-day window will not reach it. Practice a restore onto a staging copy once, so the first time you do it is not during an outage.
Retention is the number people forget. Daily backups that are overwritten after a week protect you from a bad update and from nothing slower. Ask how many days of history exist, whether the database is in every copy, and who restores it when you cannot reach the dashboard. If the answer to the last question is you, with no instructions written down, fix that before the day you need it.
Scans and File Change Checks
Malware scanning compares your files against known-good copies and known-bad patterns. Run it daily, not monthly, because the useful window is the gap between a file changing and anyone noticing. A scan that only reports is half the job. Someone has to read the report, remove what is found, close the way in, and scan again.
Checks That Look at the Page, Not the Server
An uptime monitor answers whether the server responded. It will report a healthy site while a contact form has vanished or a checkout button stopped rendering. Add a check that loads key pages and compares what is on them, and a test that submits the form. These catch the quiet breakage that follows a plugin update, the kind that costs weeks of leads before anyone looks.
PHP Versions and Host Changes
Hosts retire old PHP versions on their own timetable, and a plugin that has not kept up can fail the day the change lands. Check the PHP version your site runs on every few months, and test an upgrade on staging before the host forces one. Older, unsupported versions also stop receiving security fixes from the PHP project, which is its own reason to move.
A One-Hour Review Every Quarter
Put an hour in the calendar four times a year and walk the same list. List every plugin and theme and delete anything unused. List every user and remove anyone who should not be there. Confirm that the last backup exists and is recent, and run a restore to staging if it has been a year. Check the PHP version, the certificate expiry date, and the renewal date of each paid plugin. Open the contact form and submit it yourself, then confirm the message arrives.
Write down what you find, even when the answer is nothing. A dated note that says the review happened and which items changed is what lets the next person, or you in a year, trust the list instead of redoing it from scratch.
What to Do the Day You Find a Compromise
Work in this order. Put the site into maintenance mode so visitors are not served the infection. Take a backup of the infected state for later study. Change every administrator password and the secret keys and salts in wp-config.php, which signs everyone out. Restore from a copy that predates the problem, update everything, and look for the account or file that let the attacker in. Cleaning a symptom while leaving that entry point is how the same infection returns two weeks later.
Handing the Checklist Off
Our WordPress maintenance plans run updates for plugins, themes, and core on a schedule, take backups every 24 hours with 180 days of cloud retention, scan for malware every 24 hours, and monitor uptime around the clock. Visual checks on key pages and form checks twice a day cover the quiet breakage, and firewall protection and offsite activity logging are included. If you would rather have hosting and upkeep under one roof, managed WordPress hosting puts the site behind an enterprise firewall at the network edge, and WordPress Pro combines hosting, updates, speed, and security. The wider WordPress services page lists the rest.
