How to Secure a WordPress Site: 20 Steps That Matter

Securing a WordPress site means closing the doors attackers actually use. In practice, you keep core, plugins and themes updated, delete what you don’t use, protect every login with a strong password and two-factor authentication, give people the lowest role they need, and turn off the dashboard file editor. Then set file permissions the way WordPress recommends, keep tested backups off the server, add a firewall, and watch for changes.

That’s the short answer to how to secure a WordPress site. Below are the 20 steps I use, in the order I’d do them, plus a copyable checklist at the end.

This guide is about prevention. If your site is already hacked, stop here and follow how to fix a hacked WordPress site first, because hardening an infected site just locks the attacker in with you.

What Decides How Far You Should Harden?

Every site needs the basics. How far past them you go depends on four things.

1. Who logs in. A solo blog with one admin is a small target. A site with ten editors, an agency login and a freelancer from 2022 has ten doors.
2. What the site handles. A brochure site loses some time when it’s hacked. A shop or membership site with customer data can trigger legal duties.
3. Where it’s hosted. Managed WordPress hosts often handle updates, backups and a firewall for you. Cheap shared hosting usually leaves all of it to you.
4. Who maintains it. The best settings in the world won’t help if nobody applies updates for six months.

Why Do Updates Matter More Than Any Security Plugin?

Because that’s where the holes are. Patchstack’s State of WordPress Security in 2026 report counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025. 91% were in plugins, 9% in themes, and only 6 were in WordPress core.

The same report found a weighted median time to first exploit of 5 hours for heavily targeted vulnerabilities. That number changed how I think about update schedules. A plugin you update “next month” is a plugin that’s exposed for weeks.

Step 1: Know what updates itself. WordPress has auto-updated minor core releases since version 3.7. Since 5.6, new installs auto-update major releases too, while older sites keep the old behaviour until an admin turns it on. Plugin and theme auto-updates arrived in 5.5, set one by one on the Plugins and Themes screens, and WordPress runs them twice a day.

Step 2: Set an auto-update policy, not a blanket rule. My default is auto-updates on for small, well-maintained plugins and off for the big ones that touch the whole site, such as page builders and WooCommerce. Those get updated by hand, after a backup, ideally on staging first.

Step 3: Update PHP too. WordPress recommends PHP 8.3 or greater and warns that end-of-life versions may expose your site to security vulnerabilities. Your host’s control panel usually has a version switcher.

Which Plugins and Themes Should You Delete?

Step 4: Delete anything inactive. The WordPress hardening guide says it plainly: if you’re not using a plugin, delete it. Deactivated isn’t enough. The files still sit on the server, and some vulnerable files can be reached directly.

Keep one default theme as a fallback and remove the rest. I’ve cleaned sites where the hole was a theme nobody had activated in years.

Step 5: Only install from trusted sources. The same guide says to stick to the WordPress.org repository or well-known companies. Nulled (pirated) premium plugins are the worst offenders. In my experience, many of them ship with a backdoor already inside, so the “free” licence costs you a cleanup.

How Should You Lock Down WordPress Logins?

Step 6: Use strong, unique passwords. The hardening guide warns against dictionary words, usernames, real names and short numeric passwords. A password manager makes this painless.

Step 7: Rename obvious admin accounts. The guide also says to avoid easily guessed usernames like “admin” or “webmaster.” If yours is called admin, create a new administrator, log in as it, and delete the old one, assigning its content to the new account.

Step 8: Turn on two-factor authentication. WordPress core doesn’t ship 2FA, so you add it with a plugin. The free Two Factor plugin from WordPress.org supports authenticator apps, email codes and backup codes, and most security plugins include 2FA too. I make it mandatory for every administrator and editor.

Step 9: Limit login attempts. Core WordPress doesn’t rate-limit logins at all. WordPress’s own brute-force guidance prefers doing this at the server or firewall level and falls back to a security plugin when your host can’t. Either way, something should block an IP that fails 20 logins in a minute.

Who Should Have Admin Access?

Fewer people than you think. Most sites I audit have more administrators than they need, and old accounts are one of the entry points I check after every hack.

Step 10: Give people the lowest role that works. Writers get Author or Contributor. Your content manager gets Editor. Only people who install plugins or change settings get Administrator.

Step 11: Remove old accounts every quarter. Former staff, past freelancers, agencies you no longer pay. If you can’t name who an account belongs to, it goes. I also check the hosting panel for old FTP and database users while I’m there.

Step 12: Give the database user only what it needs. The hardening guide notes that normal WordPress use only needs SELECT, INSERT, UPDATE and DELETE. Some plugins and major updates need more, so test this on staging before you restrict it on a live shop.

Which wp-config.php Settings Should You Change?

Step 13: Turn off the file editor. The theme and plugin editor lets anyone with admin access edit PHP from the dashboard. The hardening guide calls it “the first tool an attacker will use if able to login.” Add this line to wp-config.php, above the “stop editing” comment:

define( 'DISALLOW_FILE_EDIT', true );

There’s a stricter option, DISALLOW_FILE_MODS, which also blocks installing and updating plugins and themes from the admin area. I only use it when updates run through a deployment process or WP-CLI. On a normal site it just means updates stop happening, which is worse than the risk it removes.

Step 14: Force HTTPS for logins and admin. Your whole site should run on HTTPS anyway. If it does, define( 'FORCE_SSL_ADMIN', true ); makes sure admin passwords and cookies are never sent unencrypted.

What File Permissions Does WordPress Recommend?

Step 15: Set permissions per the hardening guide. The guide’s baseline is 755 for folders and 644 for files. Only wp-content should be writable by the web server. For wp-config.php it suggests 440 or 400, which some hosts allow and some don’t.

Run these from the WordPress root over SSH, and check with your host first.

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 440 wp-config.php

Never “fix” a permissions error with 777. If an upload or update fails, the cause is usually file ownership, and that’s a conversation for your host.

Do You Need a Security Plugin or a Firewall?

You need a firewall somewhere. The hardening guide lists three kinds, and they work at different layers.

Step 16: Add a firewall, and don’t assume your host has you covered. Patchstack ran penetration tests against hosting defenses and reported that only 26% of total attacks were blocked by standard hosting security. My take: treat the host’s firewall as a bonus, not your plan.

Which layer should you pick? If you’re on cheap shared hosting, I’d add a cloud WAF in front, because it stops traffic before your server spends anything on it. If you’re on managed WordPress hosting with its own firewall, a security plugin for 2FA, login limits and alerts is often enough. These names come from WordPress’s own guide, and I’m not paid to mention any of them.

Are Your Backups Actually Safe?

Step 17: Keep backups off the server. A backup that lives in the same hosting account dies with it. Keep copies in cloud storage and on your own machine, and keep several dates so you can go back past an infection you didn’t notice right away.

Step 18: Test a restore every month. I restore to a staging site and click through the main pages and forms. My WordPress maintenance checklist puts this into the monthly routine with the rest of the upkeep.

How Do You Know If Something Changes?

Step 19: Set up monitoring. Verify the site in Search Console and check the Security issues report, because Google sometimes flags hacked content before you notice it. Add uptime alerts, and turn on file-change alerts in your security plugin, since new PHP files appearing out of nowhere are the clearest sign of trouble.

Step 20: Choose hosting that isolates your site. Good hosting gives you SFTP or SSH instead of plain FTP, isolates each site, runs a supported PHP version and keeps server-side backups. If you run several sites on one shared account, one infected site can reinfect the clean ones, which I see often after a hack.

How to Secure a WordPress Site Based on What It Does

If you run a one-admin blog, Steps 1 to 13 and off-site backups get you most of the way. Turn on auto-updates for most plugins, add 2FA, delete what you don’t use, and check Search Console monthly.

If the site takes payments or stores customer accounts, do all 20, update large plugins on staging first, and use a cloud WAF. Restrict the database user, review every admin account monthly instead of quarterly, and keep an activity log so you can see who changed what.

The Copyable WordPress Security Checklist

Copy this into your notes or task tool and tick it off.

WORDPRESS SECURITY CHECKLIST

UPDATES
[ ] 1. Confirm which updates run automatically (core minor, core major, plugins, themes)
[ ] 2. Auto-updates ON for small plugins; manual + backup for builders and WooCommerce
[ ] 3. PHP on a supported version (WordPress recommends 8.3+)

PLUGINS AND THEMES
[ ] 4. Delete inactive plugins and unused themes (keep one default theme)
[ ] 5. Only WordPress.org or well-known vendors; no nulled plugins

LOGINS
[ ] 6. Strong, unique passwords for every account (use a password manager)
[ ] 7. No "admin" or "webmaster" usernames
[ ] 8. 2FA on for every administrator and editor
[ ] 9. Login attempts limited (server, WAF or security plugin)

ACCESS
[ ] 10. Lowest role that works for each person
[ ] 11. Old WordPress, FTP and database users removed
[ ] 12. Database user limited to what WordPress needs (test on staging)

CONFIG AND FILES
[ ] 13. define( 'DISALLOW_FILE_EDIT', true ); in wp-config.php
[ ] 14. HTTPS everywhere + FORCE_SSL_ADMIN
[ ] 15. Folders 755, files 644, wp-config.php 440 or 400 if host allows

FIREWALL AND BACKUPS
[ ] 16. Firewall in place (plugin, server or cloud WAF)
[ ] 17. Backups stored off the server, several dates kept
[ ] 18. Restore tested on staging this month

MONITORING AND HOSTING
[ ] 19. Search Console Security issues, uptime and file-change alerts
[ ] 20. Host with SFTP/SSH, site isolation and supported PHP

When Should You Get Help Securing WordPress?

You can do every step here yourself if you’re comfortable with the dashboard, your hosting panel and a little SSH. I’d bring in help if you run a store with customer data, if nobody on your team has time for weekly updates, or if the site has been hacked before and you’re not sure the hole was closed.

That’s the work we do at Skyranko. Our WordPress care plans cover updates, backups, monitoring and hacked-site repair, quoted after a free audit. For the SEO side of running WordPress, start with my WordPress SEO guide.

Frequently Asked Questions

Is WordPress Secure Out of the Box?

Core WordPress is in good shape. Patchstack counted only 6 core vulnerabilities in 2025, all low priority. The risk comes from what you add: plugins, themes, weak passwords and missed updates. A fresh install with no plugins is fairly safe, and most real sites aren’t that.

Do I Need a Security Plugin for WordPress?

Not strictly, but most sites benefit from one. WordPress core has no 2FA and no login rate limiting, and a security plugin adds both, plus file-change alerts. If your host or a cloud WAF already covers login limits, a lighter 2FA plugin may be all you need.

Should I Hide or Move the WordPress Login Page?

It cuts down noise from bots, but I don’t count it as security. Anyone determined finds the new URL, and changing it can break plugins and confuse your own team. Strong passwords, 2FA and login rate limiting do the real work.

How Often Should I Check My WordPress Security?

Updates weekly, a restore test and a scan monthly, and a user and plugin review quarterly. Turn on alerts so the urgent things reach you between those checks. That rhythm matches the schedule in my maintenance checklist.

Last updated: October 2026 by Mizanur Rahman