Securing a WordPress business website comes down to a handful of habits done consistently: keep everything updated, give each user only the access they need, protect logins with two-factor authentication, keep tested off-site backups, and filter bad traffic before it reaches WordPress. None of this needs to be dramatic. It needs to be routine, and the checklist below covers what we set up and review on client sites.

Why do business WordPress sites get attacked?

Most attacks are automated, not personal. Bots scan the internet for known weaknesses such as outdated plugins, weak passwords and exposed files, and try them on every site they find.

That is useful to know because it means basic hygiene blocks the majority of attempts. You do not need to outsmart a determined attacker on day one. You need to avoid being the easy target a script finds.

1. Keep core, themes and plugins updated and vetted

Updates

Updates are the single most important security habit, because many updates patch publicly disclosed vulnerabilities that bots start scanning for soon after disclosure.

  • Allow automatic minor core updates, which WordPress enables by default for security releases.
  • Review plugin and theme updates at least weekly. For business-critical sites, apply them on a staging copy first.
  • Remove plugins and themes you are not using. Deactivated code still sits on the server and can still be exploited in some cases.
  • Keep PHP on a supported version so the server itself receives security fixes.

Vet every plugin and theme before installing

Each plugin you install is code from someone else running with full access to your site, so choose carefully.

  • Prefer plugins with recent updates, a healthy support forum and compatibility with your WordPress version.
  • Never install nulled or pirated premium plugins or themes. They are a well-known route for hidden malware and backdoors.
  • Avoid installing a large plugin for a tiny feature. Less code means fewer potential holes.
  • Keep a simple list of what each plugin does and who requested it, so unused ones get removed.

2. Control who can log in, and how

Access control has two parts: limiting what each account can do, and making each login hard to abuse.

Review users and apply least privilege

Every account is a possible way in, so each person should have the lowest role that lets them do their job, and old accounts should be removed.

WordPress roles exist for this reason. A content writer needs Author or Editor, not Administrator. An agency that finished a project last year should not still have an admin login. Check your user list quarterly and look for:

  • Former employees, freelancers or agencies who still have access.
  • Generic usernames such as admin, or shared logins used by several people.
  • More Administrators than you can name a reason for.

Shared logins also make it impossible to see who changed what. Give everyone their own account.

Two-factor authentication and rate limiting

Two-factor authentication (2FA) means a stolen or guessed password is not enough on its own, which neutralises most credential attacks.

Enable 2FA for every account with Editor rights or above, using an authenticator app rather than SMS where possible. Pair it with:

  • Login rate limiting. Lock out or slow down an IP address after repeated failed attempts. Many security plugins and firewalls offer this.
  • Strong, unique passwords. Encourage a password manager across the team.
  • Optional login URL protection. Changing or protecting the login page reduces noise in logs, but treat it as an extra layer, not a defence on its own.

3. Keep tested, off-site backups

A backup stored only on the same server as the website is not a real backup. If the server fails or is compromised, the backup goes with it.

A sound setup looks like this:

  1. Back up both the database and the files, including uploads.
  2. Store copies off-site, for example in separate cloud storage, with access credentials kept apart from the website.
  3. Match frequency to how often the site changes. A WooCommerce store taking daily orders needs more frequent database backups than a brochure site.
  4. Keep several restore points, so you can roll back to a date before an infection started.
  5. Test a restore on a staging site every few months. An untested backup is a hope, not a plan.

4. Put a web application firewall in front

A web application firewall (WAF) filters malicious requests before they reach WordPress. It blocks common attack patterns, known bad bots and abusive traffic.

Plugin-level firewalls

These run inside WordPress and understand it well, but they still use your server’s resources because PHP has already loaded when they inspect a request.

DNS or edge firewalls

These sit in front of your server at the network edge, so bad traffic is dropped before it costs you anything. Many also provide a CDN and basic DDoS protection. For most business sites, an edge firewall plus sensible WordPress settings is a strong combination.

5. Harden files and server settings

Correct file permissions and a few configuration changes close off common routes attackers use after they find a weakness.

  • File permissions. A common baseline is 644 for files and 755 for directories, with wp-config.php tightened further, as your host recommends. Avoid 777 anywhere.
  • Disable the built-in file editor. Setting DISALLOW_FILE_EDIT to true in wp-config.php removes the theme and plugin editor from the dashboard, so a stolen admin login cannot be used to edit code directly.
  • Block PHP execution in uploads. The uploads folder should hold media, not run scripts.
  • Use HTTPS everywhere and redirect all HTTP traffic.
  • Hide directory listings so visitors cannot browse folder contents.

Should you disable XML-RPC?

If nothing on your site uses it, yes. XML-RPC is an older remote access interface that can be abused for password guessing and amplified login attempts.

Some tools still rely on it, including certain mobile publishing apps and older integrations, so check before switching it off. Most modern integrations use the WordPress REST API instead. You can block XML-RPC at the server or firewall level, or with a security plugin.

6. Monitor and know what to do if something goes wrong

Monitoring tells you about a problem before your customers do. Set up uptime monitoring, an activity log that records logins and changes, and file change alerts where practical. If your business also runs sites outside WordPress, the same monitoring belongs in their website maintenance and support routine.

Also write down a simple response plan: who to call, where backups live, how to put the site into maintenance mode, and how to reset all passwords and security keys after a clean restore.

Key takeaways

  • Most attacks are automated, so consistent basic hygiene blocks the majority of them.
  • Update regularly, remove unused code and keep PHP on a supported version.
  • Apply least privilege, remove stale accounts and require 2FA for higher roles.
  • Keep off-site backups with several restore points, and test restores.
  • Use a firewall, harden file settings, disable XML-RPC if unused, and vet every plugin.

Next steps

Pick three items from this list you have not done yet and complete them this week, starting with backups and 2FA. If you would rather have the routine handled for you, our WordPress maintenance service covers updates, backups, monitoring and security reviews on a fixed schedule.