You already run a WordPress site, so skip the definitions. Here is the WordPress security checklist that keeps one out of trouble, and what to do about a neglected one.
Why WordPress gets attacked is covered on the website security page: it is common, and the risk arrives through the add-ons rather than the core. What follows is what to do about that, starting with knowing what the site runs.
Keep the list somewhere other than the site. For each plugin: the name, free or paid, where the licence key lives, when it was last updated, and which page stops working without it. Then the theme, whether a child theme sits on top, and every user account with a role and a person's name against it.
Two things usually surface: a plugin nobody can name a purpose for, and a paid plugin licensed to somebody who left, quietly no longer updating.
If a page builder made the layout, add three lines: who the builder and its add-ons are licensed to, whether the theme is the one it expects, and whether any template lives only in the builder's cloud library.
The order is how often each one turns out to be the cause.
| Way in | Why it sits here | What closes it |
|---|---|---|
| Out-of-date plugins | The most code, from the most authors, updated by the fewest owners. | Update them, and delete the ones no page depends on. |
| Out-of-date themes | Fewer, but a purchased theme often bundles plugins of its own. | Keep the theme current, and update what it bundled. |
| Out-of-date core | Lower than people expect. Core security updates apply themselves unless switched off. | Leave automatic core security updates on. |
| Weak or reused passwords | No code flaw needed. A password leaked elsewhere gets tried on your login. | A unique password per service, and two-factor authentication. |
| Admin accounts nobody removed | Old designers, former staff, a shared login. Valid keys no firewall questions. | Review the user list, and remove leavers that week. |
The top three rows say somebody did not press update; the last two, that somebody did not tidy the accounts. Neither is a product, which is why a site with a security plugin and no maintenance gets taken anyway.
Every plugin is a permanent dependency on somebody else's work. Fewer is safer, one per job beats two fighting over the same job, and the yearly question to ask of each is which page stops working without it.
Four things on its listing page tell you:
If two look wrong, choose something else. Replacing a plugin while the site is healthy is ordinary work; replacing one after it is exploited costs far more.
Updating fast closes vulnerabilities while scanning for them ramps up. It also occasionally breaks a layout, a form or a checkout.
Not a copy that exists somewhere. That is its own subject, covered on website backups.
The order to update in, and the pages to click through afterwards, are set out under staging on WordPress hosting.
If one refuses, or breaks the page every time, it is the oldest thing on the site and will not improve. Replace it, or pay to have it fixed.
A dropped connection can leave the site showing a scheduled maintenance message to everybody. WordPress writes a temporary file named .maintenance at the top level of the site while it works, so a run that never finished leaves the file there. Delete it over FTP and the site comes back.
Then find what the update was in the middle of. A plugin caught half replaced should be installed again from a clean copy, and if the site answers with a blank page, renaming its folder usually gets you back into the dashboard.
If nobody wants to own this, a managed WordPress hosting plan can take updating and staging off your desk. What is included varies by tier, so read the plan rather than the category name.
Most sites hand out Administrator because it always works. It is also the role that lets a stolen password install anything.
| Role | What it can do | Who should have it |
|---|---|---|
| Administrator | Everything, including plugins, the theme and new administrators. | The owner and whoever maintains the site. |
| Editor | Publish and edit any page or post, including other people's. | Whoever keeps the content current. |
| Author | Write and publish their own posts only. | Regular contributors to a blog. |
| Contributor | Write drafts, but not publish them. | Writers whose work someone reviews first. |
| Subscriber | Manage their own profile only. | Customers or members, if the site has that area. |
Hardening guides run to fifty items. Most of the value sits in a handful, and several popular ones do nothing an attacker notices.
If something on this side is already set up and causing no trouble, leave it alone.
Someone built it, it worked, they moved on, and nobody has logged in since. The instinct is to press update on everything. Do not.
The hosting login, the domain account and an administrator account, held by you rather than by somebody you cannot reach. Then build the inventory described further up.
Files and database, kept somewhere other than the hosting account, because an update on a site this far behind can fail badly.
A site nobody has watched for years may have been taken long ago and left working. Establish that first, or your fresh backup preserves the infection.
You, a member of staff with it in their calendar, or a maintenance arrangement.
Sometimes a site is too far behind to update safely and rebuilding costs less than repairing it. Better to reach that deliberately than after a compromise. AldoMedia has maintained websites for Western New York businesses since 1999, and is an independent authorised reseller for these products rather than the platform behind them.
If that scan finds something, cleaning the site comes before updating it, and that is a separate service. Malware removal covers what it involves; the button goes to what it costs.
No. The core is maintained carefully and security releases come out quickly. What makes WordPress a target is how many sites run it, and how much add-on code from other authors runs on a typical one. The add-ons nobody updates are the weak point.
For core security releases, yes, and they are usually on already. Automatic plugin updates suit a site with a working backup and someone who looks at it weekly. Without those, they break the site while nobody is watching.
One at most, and sometimes none. Two firewall or scanner plugins running together tend to conflict and bury the alerts that matter. If your hosting plan already includes scanning and a firewall, a plugin doing the same job adds duplication, not depth.
No. A deactivated plugin still has its files on the server, and some vulnerabilities can be reached whether it is switched on or not. Deactivate it to check nothing breaks, then delete it. Those are also the plugins nobody updates.
Not press update. Take a full backup off the server, run a scan to find out whether the site is already compromised, and write down what it runs and who has access. A site that far behind sometimes breaks when it catches up, so have the copy in hand first.
When updating and staging sit with the plan rather than with whoever remembers.
See what managed coversWhat to copy, where to keep it, and how to prove it restores.
Read the backups guideAlready flagged, or serving pages you did not write? Start here.
Get a site cleanedBack to the website security overview, what our support covers, or the other guides.
Hero photograph: cogdogblog, CC0, via Wikimedia Commons. Cropped.
Send us the address and we will tell you what state it is in, before anybody buys anything. Ring 716-771-2536 or use the contact form. If you would rather updating stopped being your problem, the managed hosting pricing is below.
.jpg){kind=link}