Skip to main content
.com domains from $2.99 — free WHOIS privacy on every name

Hardening runbook · Intermediate · an hour

How to secure WordPress — Close the Real Doors, and Prove the Restore Works

You want the actual entry points closed without adding a PHP firewall that inspects every request your visitors ever make.

View Web Hosting plansBrowse more How-To Library

The short answer

Four routes account for nearly everything: a reused administrator password, an abandoned plugin with a known vulnerability, an exposed endpoint being brute-forced, and a PHP version that stopped getting security fixes. Close those four and you have done most of the available work.

Then keep the hardening cheap. Rate limiting and malware scanning belong at the server layer, where ImunifyAV+ and Imunify360 already sit, rather than in a plugin that boots WordPress to inspect every request. And prove the restore, because a tested restore is the only control that works after everything else has failed.

By the HostingFast team · Reviewed 24 August 2026

Intermediate

Skill floor

5

Stages start to end

Free

Support, every tier

Proven

Run on the live stack

You need dashboard access, cPanel, and about an hour. A staging copy is useful for the restore test, and the managed WordPress plans allow up to 10 of them.

Nothing here is destructive, though two steps can lock you out if you rush them. Both are flagged, with the way back printed alongside.

The four routes that actually get used

A password reused from a breached service, tried against wp-login by a script. A plugin abandoned two years ago with a published vulnerability and no patch coming. An endpoint left open to unlimited automated attempts. And a PHP version past its security support window, so known bugs stay unfixed underneath everything else.

Notice what is not on that list: clever zero-days aimed at you specifically. Almost every compromise is opportunistic and automated, which is good news, because opportunistic attacks are stopped by unremarkable measures applied consistently.

Hardening that costs nothing per request

Two-factor authentication on every account that can install code. Unique administrator usernames. Least-privilege roles, so the person editing posts is an editor rather than an administrator. define('DISALLOW_FILE_EDIT', true) in wp-config.php, which removes the theme and plugin editor and with it the easiest path from a stolen session to executed code.

None of those cost a millisecond at runtime, which is the point. They are configuration rather than software, so they cannot slow the site down, cannot conflict with a plugin update and cannot stop working because a licence lapsed.

Security plugins are code on the request path too

A firewall plugin loads on every request, including cached-miss traffic and admin-ajax, so its inspection cost is paid by your visitors. It also cannot protect anything that happens before PHP starts, which is where most automated traffic is best stopped anyway.

Prefer the server layer. ImunifyAV+ sweeps sites for malware on every plan and Imunify360 sits in front on the Nitro tiers; DDoS filtering is absorbed at the network edge. Rate-limit the login endpoint at the web server or with a .htaccess rule rather than counting failed attempts inside PHP, and keep the plugin count for security work as close to zero as the job allows.

The restore is the control that matters

Every other measure reduces the chance of a bad day. A tested restore is what determines how long the bad day lasts. Backups run daily on every plan, every 6 hours on the Nitro tier, with restores you trigger yourself from the panel rather than through a ticket.

Untested backups are a belief rather than a control, so restore last night's copy to a staging site and time it. Knowing the number — twenty minutes, an hour — changes how you handle an incident, because you stop negotiating with the problem and start executing a plan.

The network filtering that soaks up attacks before they reach a site

The stack these steps were measured on

Every walkthrough here is run against the platform we operate — cPanel, LiteSpeed in front of NVMe, Softaculous, WP-CLI over SSH — so the field names in the instructions are the field names on your screen.

Backups run daily on every plan, and restoring a file or a database is one action in the panel rather than a support ticket.

  • Four real routes, closed in order
  • Hardening kept off the request path
  • Server layer preferred to a PHP firewall
  • Engineers on support at any hour

Why HostingFast

Standard on every plan

Prioritised by what happens

The four routes that account for most compromises come first, so the hour you spend goes where the risk actually is.

No runtime cost

The core measures are configuration rather than software, so they cannot slow a request down or conflict with an update.

Server layer preferred

Rate limiting and malware scanning belong below PHP, and the page says why a firewall plugin cannot cover what happens before it loads.

5 steps, no padding

Five actions in an hour, each with an observable result, and the two that can lock you out are flagged as such.

The restore timed

The last step is a real restore to staging with a stopwatch, because an untested backup is a belief rather than a control.

Engineers on call

Incidents do not keep office hours; support is staffed at any hour and can restore alongside you.

Quick Start

From order to online

  1. 1

    Inventory users, roles and plugins, then delete the unused

    List every account with an administrator or editor role and demote or remove the ones that do not need it. List every plugin and check each against its last update date. Deleting an abandoned plugin closes more attack surface than any setting you can toggle.

  2. 2

    Put two-factor on everything that can install code

    Every administrator, and anyone who can upload a plugin or edit a theme. Save the recovery codes somewhere outside WordPress before you enable it — this is one of the two steps on this page that can lock you out, and the recovery code is the way back.

  3. 3

    Pin PHP to a supported version and set updates to apply

    Choose a currently supported PHP version for the site in the control panel and confirm the site still works on it. Enable automatic updates for minor core releases and for plugins you trust; WordPress Toolkit will handle the rest and report what it did.

  4. 4

    Move rate limiting and scanning below PHP

    Rate-limit wp-login at the web server or in .htaccess instead of with a plugin that counts attempts inside PHP. Add define('DISALLOW_FILE_EDIT', true) to wp-config.php. Leave malware sweeping to ImunifyAV+ rather than to a scanner that runs on your visitors' requests.

  5. 5

    Restore last night's backup to staging, with a stopwatch

    Trigger a restore from the panel to a staging copy, time it end to end, and check the result actually works — log in, load a page, run a query. Write the number down. That number is your real recovery objective, and everything above it is prevention.

Built In

Loaded onto every plan

  • ImunifyAV+ sweeping every site for malware
  • DDoS filtering absorbed at the network edge
  • Daily backups with self-service restores from the panel
  • Staging environments for testing before you ship
  • Per-site PHP version switching in the control panel
  • Free SSL on every plan, renewed before it can lapse
  • WordPress Toolkit, with updates applied for you
  • Support staffed by humans, every hour of the day
  • Money back: 30 days on hosting, 7 on reseller
  • A renewal price identical to the one you signed up at

Frequently Asked

What people ask us most often

Where should login rate limiting actually live?

Below PHP. A plugin counting failed attempts has to boot WordPress and touch the database for every request it inspects, so an attacker's traffic costs you the same work as a real visitor's, and the cost rises exactly when you are under load. A rule in .htaccess or at the web server rejects it before PHP starts. Malware sweeping runs at the platform level here through ImunifyAV+ and DDoS filtering is absorbed at the network edge, which leaves the plugin layer for the few jobs that genuinely need application context.

Does disabling XML-RPC break anything I use?

It can. The mobile app, Jetpack and some publishing tools speak to it, as do pingbacks, and a few older integrations depend on it entirely. Check whether anything you own uses it before switching it off, and if nothing does, closing it removes a well-known brute-force amplifier — the multicall method lets an attacker test many passwords in one request. If you need it, rate-limit it rather than leaving it wide open.

How often should I actually test a restore?

Once a quarter, and after any significant change to the stack. The point is not whether the backup file exists — the panel tells you that — but whether a restore produces a working site and how long it takes. That number is your recovery time, and an untested backup gives you a number of unknown. Restoring to staging costs you twenty minutes and answers it properly.

Is hiding the login URL worth doing?

It is worth a little. Moving wp-login cuts the volume of automated traffic hitting it, which reduces noise and load, and that alone can be worth having on a busy site. What it does not do is stop a targeted attempt, since the endpoint is discoverable, so treat it as noise reduction rather than as a control. Two-factor and unique passwords are what actually close the door.

Keep reading

Changing hosts? Run through our checklist first.

A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.

You'll get the checklist email, then occasional pointers on keeping a site running fast. Unsubscribe the moment you want out — the privacy policy covers the rest.

Harden it, and keep it quick.

Malware sweeping and edge filtering included, NVMe behind a LiteSpeed cache, free SSL and migration, and a price that never moves.

View Web Hosting plans