Best way to secure WordPress from hackers

Security is layers, not a switch

There’s no single setting that makes WordPress “secure”. What keeps a site safe is several ordinary measures working together, each closing a door. Skip one and you leave a gap; do them all and you’re a much harder target than the automated attacks that hit most sites.

The essentials, in priority order

Update everything, fast. Core, plugins, themes. The majority of hacks exploit a vulnerability that was already patched. Strong, unique passwords + two-factor on every admin account — reused passwords are one of the top ways in. Remove what you don’t use. Every inactive plugin and theme is still code that can be exploited.

Put a wall in front of it

A web application firewall blocks most malicious traffic before it reaches WordPress at all — brute-force login attempts, known exploit patterns, bad bots. It’s one of the highest-value single additions you can make.

Harden the basics and plan for the worst

Tighten file permissions, disable the built-in file editor, limit login attempts, and hide the obvious targets. Then take regular off-site backups and keep an eye on the site, so if anything ever does get through, it’s a five-minute recovery instead of a week of downtime.

What this means for you

If that list feels like a lot to keep on top of, that’s exactly what a care plan is for — the updates, firewall, backups and monitoring handled quietly every month so you don’t have to think about it. The sites that never get hacked twice are the ones someone is actually watching.

How attackers actually find your site

Most people picture a hacker sitting at a keyboard, choosing targets one at a time. That's not how it usually works. Attackers run automated bots that scan millions of sites every day. These bots look for known WordPress signatures. Version numbers, plugin slugs, exposed theme folders. They don't care who you are. They care what software you're running. They care if it's out of date. A scan like this can check thousands of sites while you read this paragraph.

This is why "I'm too small to be a target" is the wrong way to think about it. Nobody targeted you specifically. A scanner found an outdated plugin somewhere on your site. It tried a known exploit automatically. That's the entire attack, start to finish. If you want to secure WordPress from hackers, the goal is simple. Don't be the site a scanner flags as vulnerable. Most successful attacks never involve a human at all, until after the damage is done. The bot moves on to the next thousand sites within seconds either way.

Lock down wp-config.php and the database

wp-config.php holds your database credentials and secret keys. It's the single most valuable file on your server. If your host allows it, move it one directory above your WordPress root. WordPress still finds it there automatically. An attacker with partial file access often can't reach it. It's a small step. But it removes one of the easiest wins available to an attacker who already has some access.

Change the default table prefix from wp_ to something random. On its own, this won't stop a determined attacker. It does stop generic SQL injection scripts. Those scripts assume the standard prefix. They fail quietly and move on. Rotate your secret keys and salts every so often too. WordPress.org's key generator makes this a two-minute job. Small moves like these are exactly what it takes to secure WordPress from hackers running automated tools. A real person studying your site by hand is rarer than you'd think. The automated tools are what most sites actually face. None of this takes more than an afternoon to set up properly.

Turn off what you don't need

XML-RPC is a legacy interface built for remote publishing. Most sites never actually use it. It's also a favourite for brute-force amplification attacks. One request can attempt hundreds of password guesses at once. If you don't use the WordPress app or a service that needs it, turn it off. It's an easy way to secure WordPress from hackers running bulk login attempts. You lose nothing you're actually using.

Directory listing is another quiet risk worth closing. If your uploads or plugin folders can be browsed directly in a browser, that's a problem. An attacker can map your entire file structure fast. Most hosts let you block this with one line in .htaccess. The REST API is genuinely useful, but by default it can leak usernames. None of these fixes take long on their own. Together, they close the doors a scanner checks first when it goes looking for a way in. It's worth going through this list once a year. Plugin updates sometimes quietly turn a setting back on. A setting you disabled last year can silently reappear after a routine update.

Add security headers at the server level

Security headers are instructions your server sends to the browser. Visitors never see them, but they matter a great deal. A Content-Security-Policy header restricts where scripts can load from. That limits the damage if malicious code ever gets injected. X-Frame-Options stops your site loading inside someone else's frame for clickjacking. Getting these right is a quiet way to secure WordPress from hackers probing for easy mistakes. It costs nothing and takes an hour at most.

Strict-Transport-Security forces browsers to only connect over HTTPS. It does this even if a link points to the old, unencrypted version. Headers like these won't stop an attacker getting in on their own. What they do is limit the damage once something else goes wrong. They're a cheap, mostly one-time addition to your setup. Most managed hosts let you set them without touching a line of code. It's a good example of a supporting step. It doesn't directly secure WordPress from hackers on its own. But it makes every other layer stronger.

Login and access hardening beyond passwords

Two-factor authentication and strong passwords cover the front door. The side doors matter just as much. Look at every admin account on your site right now. Old contractor logins. A developer who moved on years ago. A test account nobody remembers creating. Each one is a working key to your site. It's an easy list to forget once a site has been running quietly for years.

Give people the lowest role that lets them do their job. An author writing posts doesn't need administrator access. A shop manager doesn't need the ability to install plugins. Review this list every few months, not just when something feels wrong. Attackers who compromise one weak account often use it quietly. They explore the rest of your site while looking completely legitimate. Tightening access like this is a slow habit, not a one-time task. It's still one of the most effective ways to secure WordPress from hackers. This matters most against someone who already has a foot in the door.

Choosing a security plugin — and its limits

A security plugin genuinely helps. It can scan files for known malware signatures. It can log login attempts and alert you to changes. Pick one that's actively maintained, with a clear changelog. Avoid ones that try to do everything at once. Bloated plugins with a dozen features you'll never touch are their own liability. They also slow the site down for no real benefit. A slower site is its own kind of cost, even before you count the security angle.

Here's the part plugins won't tell you. A scanner only knows what it's been taught to look for. New malware variants slip past signature-based detection all the time. A plugin can't patch a vulnerable theme for you. It usually can't spot a backdoor hidden inside a file that looks legitimate. A plugin is one layer, not the whole wall. Relying on it alone is the single most common mistake I see. It's not enough by itself to secure WordPress from hackers who know how to stay hidden. This doesn't mean plugins are useless. It means they need company.

What monitoring actually looks like, day to day

"Monitoring" sounds abstract until you break it into what actually happens. It means checking file integrity. Did any core file change outside of a normal update? It means reviewing login logs for repeated failures. It means watching uptime closely, too. A sudden outage is sometimes the first sign of trouble, not just a server hiccup. None of this requires expensive tools. It just requires consistency, week after week.

It also means reading plugin changelogs before updating. Not clicking "update all" on autopilot every time. Some updates fix vulnerabilities. Others quietly introduce new ones. This kind of checking happens weekly, quietly, in the background. It's built into every site I manage under a care plan. It isn't glamorous work. It's the difference between catching something within hours. Or hearing from a client weeks later that their site is quietly serving spam links. This is the real, unglamorous work behind the phrase. It's what it actually takes to secure WordPress from hackers over the long term. Not just on the day it's first set up.

The first hour after you suspect a hack

Speed matters more than perfection here. First, don't panic and don't delete anything yet. You might destroy evidence you need later. Change your admin passwords immediately. Change your hosting account password too. Attackers who get in once often leave more than one way back in. This is the moment good preparation pays off. It's not the moment to start improvising a plan.

Put the site into maintenance mode if you can. That way visitors aren't served malware while you work. Pull a fresh backup of the current, infected state first. You'll want it later for comparison. Then start looking for what actually changed. New admin users you didn't create. Unfamiliar files sitting in your uploads folder. Scheduled tasks you don't recognise. If this feels beyond you, that's the moment to call in help. Don't experiment on a live site while customers are still visiting it. A rushed fix applied under pressure often causes more damage than the original hack.

Your hosting environment matters more than people think

Shared hosting puts hundreds of sites on the same server. If one site gets compromised, a poorly isolated setup can let an infection spread sideways. This isn't a reason to panic about shared hosting. It's a reason to check how your host actually separates accounts from each other. This one detail can secure WordPress from hackers moving sideways. That includes threats from a neighbouring, less careful account on the same server.

Keep PHP itself updated too, not just WordPress. An old PHP version can carry its own unpatched vulnerabilities. A good host handles this quietly in the background. A cheap one often doesn't, until you ask. Where your site lives is part of the equation. It sits right alongside the plugins and the passwords. All of it matters if you actually want results. Ticking a box on a checklist isn't the same as being able to secure WordPress from hackers. Ask your host directly how accounts are isolated from one another before you assume the answer.

Test your defences instead of assuming they work

Most people set up their security once and never look at it again. A staging copy of your site is useful for more than testing new features. Try logging in with a wrong password ten times in a row. See whether anything actually blocks you or alerts anyone.

Run a free malware scan every so often, even if nothing seems wrong. Check that your backups actually restore, not just that they exist. A backup nobody has tested is a hope, not a plan. Testing like this is the difference between assuming you secure WordPress from hackers and actually knowing it. It's a habit we've built into how we look after the 573+ businesses on our care plans. Most owners are surprised how often a small gap turns up once someone actually checks.

The DIY mistakes that make things worse

The most common mistake is treating a hack as a one-time cleanup. It isn't. It's an ongoing problem until the entry point is closed. Someone removes the obvious malware and feels relieved. Then they get reinfected within days. Finding the malware isn't the same as finding how it got in. It's a pattern I see often enough to name directly. The fix is rarely complicated once you know where to look.

The second mistake is restoring from a backup without checking its age. If that backup is already compromised, you've just reinstalled the same problem. The third is assuming a clean scan means a clean site. Scanners miss things, especially custom, hand-placed backdoors. Trying to secure WordPress from hackers alone, at 11pm, under pressure, rarely goes well. It's exactly the situation a second, experienced pair of eyes is built for. We've cleaned more than 10,000 WordPress sites at this point. Almost every one had already been "cleaned" once by the owner before we saw it.