To secure a WordPress site, start where the attacks actually come from. Delete every plugin you do not use and update the ones you keep, put two-factor authentication on every admin login, run updates on a fixed schedule, and keep off-site backups you have tested. Those four moves stop the overwhelming majority of automated attacks.

Most WordPress security guides give you twenty steps in a flat list, which quietly implies that hiding your WordPress version number matters as much as patching a vulnerable plugin. It does not. One of those steps closes the door that almost every real breach walks through. The other slightly inconveniences a bot that was never reading your version number anyway.

At Survyc we handle white label WordPress development and security work for agencies, which means we see the same compromised sites that fifteen-point checklists were supposed to protect. The checklist was rarely the problem. The problem was that nobody knew which two items on it carried the weight, so the easy cosmetic ones got done and the hard structural ones did not. This guide fixes the order.

Why do WordPress sites get hacked in the first place?

WordPress sites get hacked by bots, not by people who chose you. Automated scanners crawl the web looking for known vulnerable plugin versions and weak login credentials, then exploit whatever they find, regardless of site size or traffic. You cannot secure a WordPress site sensibly without accepting this, because it decides what deserves your attention.

Two numbers shape everything below. Patchstack’s 2026 annual report found that 96% of WordPress vulnerabilities originate in plugins, with themes and core making up the small remainder. In the same report, 43% of those vulnerabilities needed no authentication at all to exploit, and 33% were still unpatched when they were disclosed publicly. Separately, Wordfence’s 2025 annual report put brute-force login attacks at roughly 40% of attempted breaches.

Read those together and the priority list writes itself. Your plugins are the front door. Your login page is the window next to it. Everything else is further down the wall.

WordPress core itself is not the weak point. The core team patches quickly and the code is scrutinised heavily. Compromises come from what gets bolted on and how the site gets maintained afterwards, which is good news, because both are within your control.

What should you secure first?

Work in this order: plugins, logins, updates, backups. Each one addresses a larger share of real attacks than anything in the second tier, and the first two alone cover the two channels the data points at.

How do you secure a WordPress site against plugin vulnerabilities?

Start by deleting plugins, not by adding one. Open your plugins screen and remove everything you are not actively using, including the deactivated ones. This is the highest-value security action available to most sites, and it costs nothing.

Deleting unused plugins pays twice, since their code, queries, and scripts also load on pages that never use them, which is why plugin bloat features heavily in our guide to fixing a slow WordPress website.

Deactivating is not removing. A deactivated plugin’s code still sits on your server, and a vulnerability in a file that WordPress can still reach remains exploitable. Delete it properly. Do the same with unused themes, keeping one default theme as a fallback for troubleshooting.

Then audit what survives. For each remaining plugin, check the last-updated date and the “tested up to” WordPress version on its listing. A plugin with no update in the last year or two is not stable, it is unmaintained, and unmaintained code never gets a patch when a vulnerability appears. One plugin vendor’s analysis reports that 59% of plugins in the directory are abandoned or unmaintained, including well over a hundred with more than 10,000 installs each. Treat that figure as one company’s count rather than a settled number, but the underlying risk is real and easy to check yourself.

Here is the loop nobody selling security software will write down for you: plugins cause 96% of vulnerabilities, and the standard advice for securing WordPress is to install another plugin. Fewer plugins is a security strategy. More plugins is a feature list.

How do you protect the WordPress login page?

Two-factor authentication on every administrator account is the single highest-impact login step, because it makes a stolen password useless on its own. Passwords leak in breaches that have nothing to do with your site, and credential-stuffing bots test those leaked pairs against WordPress logins all day.

After 2FA, do three things. Give every admin a unique password used nowhere else. Remove or rename any account still called “admin,” since that username is the first guess in every brute-force list. Limit login attempts so repeated failures from one address get blocked, which turns a brute-force run into an expensive waste of the attacker’s time.

Audit who actually holds administrator access while you are in there. Old contractors, former staff, and a developer who “just needed access for a week” three years ago are all live keys to your site. Downgrade anyone who does not need the role and delete accounts nobody uses.

Why do updates need a schedule rather than good intentions?

Updates fail as an intention and work as a calendar entry. The gap between a vulnerability being disclosed and bots scanning for it is short, often measured in days, so “I update when I remember” leaves a window that automated attacks are built to find.

Pick a fixed window. A weekly check suits a small brochure site. Stores, membership sites, and client sites need it at least twice a week, because they carry more plugins, more transactions, and more consequences. Subscribe to vulnerability alerts from your host or security plugin so an urgent patch does not wait for your scheduled slot.

Enable automatic updates for WordPress core and for plugins you trust to behave. For anything that touches checkout, forms, or membership, test on a copy of the site first, and keep our guide to fixing a plugin that is not working handy for the times an update breaks something. That is the honest tradeoff with automation: it closes vulnerability windows fast, and it occasionally breaks a page at 2am with nobody watching. Testing first is how you get the benefit without the risk.

What makes a backup actually useful?

A backup counts only if you have restored it. Untested backups fail in the exact moment you need them, usually because they were incomplete, corrupted, or silently stopped running months ago and nobody checked the dashboard.

Store backups off-site rather than only on the same server as the site. A compromised server can take its local backups with it, and some ransomware specifically targets them. Keep enough history to reach back past a slow-burning compromise, because malware often sits quietly for weeks before anyone notices, and a backup from yesterday may already contain it.

Restore one to a test environment on a schedule, quarterly at minimum. Our WordPress backup guide covers the mechanics of setting this up properly. The rule to hold onto is simple: an untested backup is a hope, not a backup.

What can you harden in one afternoon?

Once the four priorities are handled, a single focused session covers the rest of the setup work. None of it takes long individually.

  • Force SSL site-wide so every page loads over HTTPS, with no mixed-content warnings
  • Disable the dashboard file editor by adding define(‘DISALLOW_FILE_EDIT’, true); to wp-config.php, which stops an attacker with admin access from editing theme files straight from the browser
  • Protect wp-config.php and .htaccess at the server level, and confirm your file permissions follow the official WordPress hardening documentation
  • Block direct PHP execution in the uploads folder, a common home for uploaded backdoors
  • Check your hosting: current PHP version, malware scanning, account isolation, and a support team that answers security tickets fast
  • Disable XML-RPC if nothing on your site needs it, with the caveat below

Form spam belongs in the same category of thinking. It is the visible end of the same automated traffic that probes your login page, and our guide to stopping contact form spam in WordPress covers the setup side of that.

XML-RPC deserves a sentence of explanation rather than a blanket rule. Its system.multicall method lets an attacker test hundreds of password combinations inside a single request, which defeats the per-request rate limiting that protects a normal login page. Wordfence’s explanation of the risk still holds up years later.

Two practical notes before you block it. Some remote publishing tools and older mobile app setups still rely on XML-RPC, so check what you use first. And block it at the server level with an .htaccess rule or your host’s firewall rather than with a dedicated plugin, since at least one penetration test found a popular disabling plugin left XML-RPC visible to scanners anyway. Server-level blocking also keeps you consistent with the fewer-plugins principle.

Your hosting choice is a security decision too, and it deserves an honest framing. Cheap shared hosting shifts the security work onto you. Managed WordPress hosting prices that work in and handles isolation, scanning, and patching at the server level. Neither is wrong, but know which deal you took, because the cheaper plan is only cheaper if you are doing the work it left out. The difference shows up on the worst day, which is why we wrote separately about how we handle emergency website downtime.

What must you keep doing every month?

Setup is the half that gets done. The monthly half is where security actually holds or fails, and it is where most sites quietly drift back into the state they started in.

Every month, run updates in your scheduled windows and confirm they applied. Review the plugin list for anything you stopped using or anything that has gone a year without an update. Test one backup restore. Check your administrator accounts and any connected services or API keys. Read your security plugin’s alerts instead of clearing the badge without looking, which is the most common way a real warning gets missed.

None of this is difficult. It is just relentless, and it competes with client work for attention every single month. That is the honest reason agencies hand it over rather than the reason vendors usually give.

Do you need a WordPress security plugin?

One good security plugin helps. Two actively hurt. A firewall, login limiting, malware scanning, and alerting are worth having in one package, and Wordfence and Sucuri both do this job well. Running two overlapping security plugins creates conflicts, duplicate rules, and a slower site without adding protection.

Be clear about what a security plugin does not do. It does not patch a vulnerable plugin for you, and it cannot make an abandoned plugin safe. It reduces the noise and catches some attacks in progress, which is worth real money, but it sits downstream of the plugin hygiene and update discipline above. Sites get compromised while running a security plugin all the time, usually because the plugin was doing its job and the site was three versions behind on something with a public exploit.

Several hardening steps in the previous section need no plugin at all. Prefer the wp-config and server-level methods where they exist, and let the security plugin cover firewall, scanning, and alerts.

Some widely repeated advice is noise reduction dressed as protection. It is not harmful, and none of it will break your site, but it should never displace the four priorities.

Hiding your WordPress version number reduces how efficiently a scanner can fingerprint you. It does not secure a vulnerable site, because bots exploit the vulnerability directly rather than checking your version first and politely moving on. Changing your login URL cuts junk traffic in your logs and does nothing about attacks arriving through plugins, which is where 96% of the risk lives. Changing your database table prefix on an existing site carries a genuine chance of breaking the site during the change, in exchange for a marginal benefit.

The pattern is worth naming: obscurity reduces noise, and noise reduction is not security. Do these things if you enjoy them, after everything above is handled.

What if your site is already hacked?

Stop reading this article and switch to incident response, because hardening a compromised site does not remove what is already inside it. Confirm the signs your WordPress site is hacked, then follow our guide to what to do in the first hour before you change anything, since deleting files early destroys the evidence of how the attacker got in.

Cleanup comes after containment, and our WordPress malware removal guide covers it, including when to replace WordPress core files rather than clean them. Come back to this page once the site is clean. Closing the entry point is exactly the step that stops the same attacker returning next week, and everything above is that step.

Key takeaways

Securing WordPress is a prioritisation problem more than a technical one. Plugins carry 96% of vulnerabilities and logins absorb around 40% of attack attempts, so plugin hygiene and two-factor authentication buy more safety than the rest of a twenty-point checklist combined.

Delete what you do not use rather than deactivating it, update on a schedule rather than when you remember, and restore a backup occasionally so you know it works. Treat obscurity tips as optional garnish. The goal is not an unhackable site, which does not exist, but a site where common automated attacks cost more than they return and recovery is predictable when something does slip through.

Frequently asked questions

How do I secure my WordPress site without a plugin?

Most high-value steps need no plugin. Delete unused plugins and themes, use unique passwords with two-factor authentication, update on a fixed schedule, and keep tested off-site backups. Add DISALLOW_FILE_EDIT to wp-config.php, force SSL, block PHP execution in uploads, and set file permissions per WordPress documentation.

Do I need a security plugin for WordPress?

One is useful, two are counterproductive. A single plugin covering firewall, login limiting, malware scanning, and alerts adds real protection. Running several creates conflicts and slows the site without improving security. No plugin patches a vulnerable or abandoned plugin for you, so it supplements plugin hygiene and updates rather than replacing them.

Why do WordPress sites get hacked?

Almost always through outdated or vulnerable plugins and weak login credentials, not through WordPress core. Patchstack’s 2026 report attributes 96% of vulnerabilities to plugins, and Wordfence puts brute-force attempts at around 40% of attacks. The attacks are automated, so small sites get scanned and exploited exactly like large ones.

Should I disable XML-RPC in WordPress?

Usually yes, but check first. XML-RPC’s multicall method lets attackers test hundreds of passwords in one request, defeating normal rate limiting. Some remote publishing tools and older mobile setups still need it. If nothing on your site uses it, block it at the server level through .htaccess or your host’s firewall.

How often should I update WordPress plugins?

Weekly for a small brochure site, at least twice weekly for stores, membership sites, and client sites. Subscribe to vulnerability alerts so critical patches skip the queue. Enable automatic updates for core and trusted plugins, and test anything touching checkout, forms, or payments on staging before it reaches production.

Is WordPress secure out of the box?

WordPress core is well maintained and patched quickly, so a default install is reasonably secure. The risk arrives with what you add and how you maintain it. A site running ten plugins, no two-factor authentication, and updates applied whenever someone remembers is far more exposed than the core software ever was.

Let someone else run the monthly half

The setup work in this guide is a single afternoon. The monthly work is forever, and it is the part that competes with billable client work and loses. If you run an agency and site security keeps slipping down the list, that is the gap we fill. Survyc is an AI-first digital agency that handles WordPress security, updates, and monitoring white label as part of your team, so your clients get maintained sites under your name. Our WordPress care plans cover the recurring half, and if you want to know how to secure a WordPress site you have inherited from someone else, send it over. Get in touch or email info@survyc.com and tell us what you are working with.