Every week, thousands of WordPress sites get hacked. Not because WordPress is weak. But because site owners skip the basics. This WordPress security checklist covers everything you need to secure your WordPress website in 2026. From WordPress login security to WordPress database security, each step is practical and actionable.
You don’t need to be a developer to follow this checklist guide. You just need to follow the steps in order.
Let’s start from the top.
Why Do WordPress Sites Get Hacked?
Most people think hackers personally target their site. They don’t. Automated bots crawl the web 24/7, scanning for known vulnerabilities. If your site has one, they’ll find it.
Understanding how attacks work makes every WordPress security best practice in this guide make more sense.
The Three Layers of WordPress Security
WordPress security isn’t one thing. It works across three layers:
| Layer | What It Covers |
|---|---|
| Core Software | WordPress itself, updated regularly by the core team |
| Plugins & Themes | Where most vulnerabilities actually live |
| Hosting Environment | Server configuration, PHP version, firewall |
Most breaches happen at the plugin layer. Developers find a hole, release a patch, and announce it publicly. That announcement also tells every bot exactly what to look for on unpatched sites.
What Attackers Actually Want
People assume hacks are about destroying sites. Usually they’re not. Attackers want:
- SEO spam injection — your site ranks for their sketchy links
- Credential harvesting — stealing login data from your visitors
- Botnet enrollment — using your server to attack other sites
- Ransomware — locking your files and demanding payment
None of this requires a sophisticated attacker. Automated tools do the work.
The Attacker’s Path Into Your Site
To follow this WordPress security checklist properly, it helps to understand the attack sequence:
- Reconnaissance — attacker identifies your WordPress version, plugins, and usernames
- Initial Access — exploits a vulnerability or cracks a weak password
- Privilege Escalation — moves from a low-level account to admin
- Persistence — installs a backdoor so they can return even after cleanup
How Do You Secure Your WordPress Login Page?
Your login page is the front door. It’s also the most attacked part of any WordPress site. Bots run thousands of password attempts per hour against it. And most sites leave it wide open.
Here’s how to lock it down properly.
Use Strong Passwords Across Every Access Point
Most people secure their WordPress dashboard and stop there. That’s not enough. WordPress login security means covering every entry point:
| Access Point | Why It Matters |
|---|---|
| WordPress dashboard | Direct site control |
| Hosting account | Full server access |
| FTP/SFTP | Bypasses WordPress entirely |
| Database | Direct access to all your data |
| Email account | Used to reset every other password |
If any one of these is weak, the others don’t matter. Use a password manager like Bitwarden or 1Password to generate and store strong, unique passwords for each.
Disable the Default “Admin” Username
If your username is “admin,” you’ve already done half the attacker’s job. That’s the first username every bot tries.
To fix this in five minutes: create a new administrator account with a different username, transfer all content to it, then delete the old “admin” account.
Change Your Login URL
By default, every WordPress site uses /wp-login.php or /wp-admin. Every bot knows this.
Plugins like WPS Hide Login or Wordfence let you move the login page to a custom URL. This alone eliminates the majority of automated login attacks because bots can’t find the door.
Rate limiting helps. But hiding the URL is stronger.
Add Server-Level Protection to wp-login.php
For an extra layer, you can password-protect wp-login.php at the server level using HTTP authentication. This means attackers hit a second login prompt before they even reach WordPress.
This is done through your hosting control panel or .htaccess file. Most managed hosts make this straightforward.
Limit Login Attempts
Even with a hidden login URL, limit login attempts as a backup measure. Set a threshold of three to five failed attempts, and block the IP temporarily.
Most website security plugins for WordPress handle this automatically. Wordfence, iThemes Security, and Limit Login Attempts Reloaded all include this feature.
Block User Enumeration
Attackers use two methods to harvest valid usernames before they even attempt a login:
- yoursite.com/?author=1
- yoursite.com/wp-json/wp/v2/users
Both return real usernames by default. Blocking these is a one-line .htaccess rule, or handled automatically by most security plugins.
If an attacker doesn’t know your username, brute force attacks get significantly harder.
Consider Geo-Blocking for wp-admin
If your site has a known user base, say, all your customers are in one country, blocking WP-Admin access from unrecognized regions is a reasonable step.
This won’t work for every site. But for local businesses or regional services, it cuts out a large percentage of automated traffic before it reaches your login page.
Quick Reference: WordPress Login Security Checklist
| Step | Done? |
|---|---|
| Strong passwords on all access points | ☐ |
| “Admin” username removed | ☐ |
| Login URL changed | ☐ |
| Server-level protection on wp-login.php | ☐ |
| Login attempts limited | ☐ |
| User enumeration blocked | ☐ |
| Geo-blocking configured (if applicable) | ☐ |
What Is Two-Factor Authentication (2FA) and Do You Really Need It for WordPress?
Yes, you need it. For any website with an admin panel, 2FA is non-negotiable.
A strong password helps. But passwords get leaked in data breaches, phished, or cracked. Two factor authentication means even if someone has your password, they still can’t get in without a second verification step.
How It Works Under WordPress Security Checklist
After entering your password, WordPress asks for a second code. That code comes from an app on your phone, an email, or an SMS. It expires in 30 seconds.
An attacker sitting in another country with your password can’t log in without that code. That’s the point.
2FA Plugin Options for WordPress
Not all 2FA plugins work the same way. Here’s a practical comparison:
| Plugin | Free Tier | Method | Best For |
|---|---|---|---|
| WP 2FA | Yes | App, email, SMS | Most site owners |
| Wordfence Login Security | Yes | App-based (TOTP) | Sites already using Wordfence |
| Google Authenticator (miniOrange) | Yes | App-based | Developers, technical users |
| Two Factor (WordPress.org) | Yes | App, email | Minimalist option |
| Rublon | Yes | Email-based | Non-technical users |
App-based two factor authentication (TOTP) is the most secure option. SMS is better than nothing but can be intercepted. Email-based 2FA is the weakest of the three.
Use an authenticator app. Google Authenticator or Authy both work well.
Enforce 2FA for All Admin and Editor Roles
Site owners enable 2FA for their own account and stop there. But if an editor or contributor account gets compromised, an attacker can still inject malicious code into posts, harvest visitor data, or escalate to admin access.
WordPress admin security means enforcing 2FA across every role that can publish, edit, or install anything. Most 2FA plugins let you set this by user role.
Set Up Backup Codes
Every 2FA setup should include backup codes. These are one-time-use codes you can enter if you lose access to your phone.
Generate them when you set up 2FA. Store them somewhere offline, a password manager, a printed copy in a safe place. Not in your email.
Losing access to your own site because your phone broke is a real scenario. Backup codes prevent it.
How to Lock Down Your WordPress Admin Area?
Getting past the login page is one thing. But even after a successful login, there’s a second layer of risk, what someone can do once they’re inside.
WordPress admin security is about limiting what can be accessed, changed, or broken from inside the dashboard. Whether it’s a compromised account, a rogue contractor, or a disgruntled team member, the less damage any single account can do, the better.
Restrict wp-admin Access by IP
If you manage your site from a fixed location — an office, a home network — you can whitelist those IP addresses and block everyone else from reaching wp-admin entirely.
This is done through .htaccess:
<Files wp-login.php>
order deny,allow
deny from all
allow from YOUR.IP.ADDRESS
</Files>
Or through your hosting firewall. Some security plugins offer this as a setting too.
The downside: if your IP changes or you need to log in while traveling, you can lock yourself out. Have a backup plan before implementing this.
Disable File Editing in the Dashboard
By default, WordPress lets any administrator edit plugin and theme files directly from the dashboard. One compromised admin account means an attacker can inject malicious code without touching the server.
Turn it off. Add this single line to your wp-config.php:
define(‘DISALLOW_FILE_EDIT’, true);
Done. The Theme Editor and Plugin Editor disappear from the dashboard entirely. Files can still be edited via SFTP, but that requires server credentials, not just a WordPress password.
Understand and Apply User Roles Correctly
WordPress has five default user roles. Most sites assign too many people admin access out of convenience.
| Role | What They Can Do |
|---|---|
| Administrator | Full control — installs plugins, manages users, edits files |
| Editor | Publishes and manages all content, including others’ posts |
| Author | Writes and publishes their own posts only |
| Contributor | Writes posts but needs approval to publish |
| Subscriber | Reads content, manages their own profile only |
The rule is simple: give people the minimum access they need to do their job. A freelance writer needs Author or Contributor access. Neither Editor nor Admin.
When an attacker compromises a Contributor account, the damage is limited. When they compromise an Admin account, they own everything.
Remove Inactive User Accounts
End of every quarter, run a quick user audit. Ask:
- Are there old developer accounts still active?
- Do former employees or contractors still have logins?
- Are there accounts you don’t recognize?
Delete what you don’t need. For accounts you want to keep but restrict, downgrade the role. This is one of the most overlooked WordPress security best practices, and one of the easiest to action.
Set Up an Activity Log
You can’t protect what you can’t see. An activity log records every significant action inside your WordPress dashboard:
- Login attempts (successful and failed)
- Plugin installs and deletions
- User role changes
- Post edits and deletions
- Settings changes
Force Strong Passwords for All Users
Your password is strong. But what about the editor account you set up for a client two years ago?
Plugins like Password Policy Manager or the built-in features in Wordfence let you enforce minimum password strength across all user roles. You can also force password resets on a schedule.
One weak password on a low-level account is all it takes.
How Do You Secure Your WordPress Database?
Your database is where everything lives. Posts, pages, user credentials, settings, customer orders; all of it sits in your WordPress database. If an attacker gets in, they can extract data, create new admin accounts, or wipe your site entirely.
WordPress database security gets skipped in most checklists. That’s a mistake.
Change the Default Database Table Prefix
By default, WordPress names every database table with the prefix wp_. Every automated SQL injection tool knows this. It’s the first thing they target.
Changing the prefix to something like xk92_ or mb2026_ makes automated attacks significantly less effective. They’re looking for wp_users and wp_options. If those tables don’t exist by those names, most scripts move on.
When to do this: Ideally at installation, before your site goes live. Changing it on an existing live site is possible but requires careful database editing. If you’re not comfortable with phpMyAdmin or direct database access, get a developer to do it.
Most website security plugins for WordPress, including iThemes Security, include a table prefix changer that handles this safely.
Assign Minimum Database User Permissions
WordPress needs specific permissions to function. It does not need full database control.
| Permission | WordPress Needs It? |
|---|---|
| SELECT | Yes — reads data |
| INSERT | Yes — adds new data |
| UPDATE | Yes — modifies existing data |
| DELETE | Yes — removes data |
| DROP | No — deletes entire tables |
| ALTER | No — changes table structure |
| FILE | No — accesses server files |
| GRANT | No — assigns permissions to others |
Go into your hosting control panel or phpMyAdmin and remove any permissions WordPress doesn’t need. If an attacker exploits a vulnerability, limited permissions contain the damage.
Secure Your Database Credentials in wp-config.php
Your database name, username, and password all live in wp-config.php. This file needs to be protected.
Three steps:
1. Move wp-config.php above the public root WordPress automatically looks one directory above the public folder. Moving it there means it’s not accessible via a browser even if your server is misconfigured.
2. Set correct file permissions wp-config.php should be set to 600. This means only your server user can read or write it. No one else.
3. Remove debug mode on live sites If WP_DEBUG is set to true on a live site, error messages can expose your file paths, database structure, and plugin details to anyone who triggers an error. Set it to false.
php
define(‘WP_DEBUG’, false);
Update Your Security Keys and Salts
WordPress uses security keys and salts to encrypt data stored in cookies. If your site has ever been compromised, or if you’ve been using the same keys for years, regenerate them.
Go to: https://api.wordpress.org/secret-key/1.1/salt/
Copy the output and replace the existing keys in your wp-config.php. This immediately invalidates all active sessions, logging everyone out. Do this during low-traffic hours.
Prevent SQL Injection
SQL injection is one of the most common attack types against WordPress sites. An attacker enters malicious code into a form field or URL parameter. If the site doesn’t sanitize that input, the code runs against your database.
How to reduce this risk:
- Keep all plugins updated. Outdated plugins are the most common SQL injection entry point
- Remove plugins that haven’t been updated in over two years
- Use a website security plugin for WordPress with a web application firewall; it filters malicious input before it reaches your database
- Check any contact forms or search fields on your site. These are the most common targets
WordPress core uses prepared statements to prevent SQL injection. But third-party plugins don’t always follow the same standards. That’s the gap attackers exploit. And that’s a concerning point in a Wix vs WordPress debate.
Back Up the Database Separately
Most people think “I have a backup” and leave it there. But a full site backup and a database backup are different things.
Your database changes every time someone leaves a comment, places an order, or updates a setting. Your files don’t change nearly as often.
Back up the database daily for active sites. Store it off your hosting server. And test the restore at least once; a backup you’ve never tested is not a backup.
Are Your WordPress Files and Server Headers Configured Securely?
Most WordPress security checklists stop at plugins and passwords. File-level hardening and HTTP headers are where the technical gaps live where attackers look when the obvious doors are closed.
Set Correct File Permissions
Wrong file permissions are an open invitation. Here’s what they should be:
| Location | Correct Permission |
|---|---|
| WordPress files | 644 |
| WordPress directories | 755 |
| wp-config.php | 600 |
| .htaccess | 644 |
Permission 600 on wp-config.php means only your server user can read it. Nobody else, including other users on shared hosting, can access it.
Disable PHP Execution in the Uploads Folder
Your uploads folder should contain images and documents. It should never execute PHP. But attackers sometimes upload disguised PHP files through vulnerable plugins.
Add this to a .htaccess file inside your wp-content/uploads/ folder:
<Files *.php>
deny from all
</Files>
Disable Directory Listing
If directory listing is on, anyone can browse your folder structure in a browser. That exposes file names, plugin versions, and path information attackers can use.
Add this to your main .htaccess:
Options -Indexes
Add Security HTTP Headers
HTTP headers tell browsers how to behave when loading your site. The right headers block a range of common attacks like injection, clickjacking, and protocol downgrade.
| Header | What It Blocks |
|---|---|
| Content-Security-Policy | Script injection, XSS attacks |
| X-Frame-Options | Clickjacking |
| Strict-Transport-Security | Forces HTTPS, blocks downgrade attacks |
| X-Content-Type-Options | MIME-type sniffing attacks |
| Referrer-Policy | Controls referrer data leakage |
You can add these through your .htaccess file or via a security plugin. Cloudflare’s free tier also applies several of these automatically.
To check your current header score, run your site through securityheaders.com. It takes 10 seconds and shows exactly what’s missing.
Which WordPress Security Plugin Should You Use?
You don’t need five plugins. You need one good one that covers the essentials like New User Approve. Here’s how the main options compare.
What a Security Plugin Must Cover
Before picking a plugin, check it handles all five of these:
| Feature | Why It Matters |
|---|---|
| Web Application Firewall (WAF) | Filters malicious traffic before it hits WordPress |
| Malware scanning | Detects infected files and code |
| Login protection | Brute force blocking, 2FA support |
| File integrity monitoring | Alerts you when core files change unexpectedly |
| Activity logging | Records what happens inside your dashboard |
Add Cloudflare as an Extra Layer
Cloudflare’s free plan sits in front of your site and filters traffic at the network level. It handles DDoS protection, bot blocking, and several HTTP security headers automatically.
It doesn’t replace a website security plugin for WordPress. But it adds a meaningful layer that costs nothing.
Quick Reference: WordPress Security Plugin Checklist
| Step | Done? |
|---|---|
| One security plugin installed and configured | ☐ |
| WAF enabled | ☐ |
| Malware scan scheduled | ☐ |
| Login protection active | ☐ |
| Cloudflare connected (optional but recommended) | ☐ |
Are You Keeping WordPress Updated, Backed Up and Monitored?
These three things are the difference between a site you can recover and one you can’t.
Keep Everything Updated
When WordPress or a plugin releases a security patch, they also publish what the patch fixes. Every unpatched site becomes a target within hours.
| What to Update | How Often |
|---|---|
| WordPress core | Immediately for security releases, monthly otherwise |
| Plugins | Weekly check, immediately for security patches |
| Themes | Monthly |
| PHP version | Annually. Stay on supported versions only |
PHP 7.x is end-of-life. If your host is still running it, you’re on unsupported software with unpatched vulnerabilities. Check your PHP version in your hosting control panel and upgrade to PHP 8.2 or higher.
And never install nulled or pirated plugins. They’re a common vehicle for backdoors.
Back Up the Right Way
A backup you’ve never tested is not a backup. Follow the 3-2-1 rule:
- 3 copies of your site
- 2 different storage types
- 1 stored offsite (not on your hosting server)
| Plugin | Free Scheduled Backups | Cloud Storage | Database Backup |
|---|---|---|---|
| UpdraftPlus | Yes | Yes | Yes |
| BlogVault | No (paid) | Yes | Yes |
| Jetpack VaultPress | No (paid) | Yes | Yes |
UpdraftPlus free tier is sufficient for most sites. Set it to back up daily for active sites, weekly for static ones. And run a test restore at least once so you know it actually works.
Monitor Your Site
You don’t need an expensive tool. You need to know when something goes wrong. Three free steps that cover most scenarios:
- UptimeRobot — alerts you within minutes if your site goes down
- Google Search Console — sends security alerts if Google detects malware or manual actions
- WP Activity Log — tracks admin actions inside your dashboard
Set these up once. They run in the background and alert you when something needs attention.
What Should You Do If Your WordPress Site Gets Hacked?
Even with every WordPress security best practice in place, breaches happen. What you do in the first hour matters more than anything else.
Here’s the exact sequence to follow.
Step 1: Contain First, Clean Second
Don’t start deleting files immediately. Contain the damage first.
- Put your site in maintenance mode or take it offline
- Don’t log out of your current session
- Don’t install new plugins while the site is compromised
Step 2: Change Every Password Immediately
| Access Point | Action |
|---|---|
| WordPress admin accounts | Change all passwords |
| Hosting account | Change immediately |
| FTP/SFTP credentials | Change immediately |
| Database password | Change and update wp-config.php |
| Email linked to the site | Change immediately |
Do this before anything else. If the attacker still has valid credentials, cleaning the site is pointless.
Step 3: Identify the Infection
Run a scan from two sources:
- Wordfence — install and run a full scan from inside WordPress if your dashboard is still accessible
- Sucuri SiteCheck — external scanner at sitecheck.sucuri.net, no login needed
Look for:
- PHP files inside wp-content/uploads/
- Base64-encoded strings in plugin or theme files
- Unknown admin accounts you didn’t create
- Recently modified core files
Step 4: Remove the Malware
Three options depending on severity:
| Situation | Recommended Action |
|---|---|
| Isolated infected files | Delete or restore clean versions via SFTP |
| Multiple infected files | Restore from a clean backup |
| Full site compromise | Professional malware removal service |
Step 5: Harden After Cleanup
Cleaning removes the infection. Hardening prevents reinfection.
After cleanup, go through this immediately:
- Regenerate security keys and salts in wp-config.php
- Audit all user accounts, delete anything unfamiliar
- Update every plugin, theme, and WordPress core
- Check file permissions are correctly set
- Re-enable your WAF if it was disabled
Step 6: Request Google Review If Blacklisted
If Google flagged your site, traffic won’t recover until you request a review.
Go to Google Search Console → Security Issues → Request Review. Be specific about what you found and what you fixed. Google typically responds within 72 hours.
Quick Reference: Hacked Site Response Checklist
| Step | Done? |
|---|---|
| Site taken offline or put in maintenance mode | ☐ |
| All passwords changed across every access point | ☐ |
| Malware scan run from two sources | ☐ |
| Infected files removed or site restored from backup | ☐ |
| Security keys and salts regenerated | ☐ |
| All user accounts audited | ☐ |
| Google Search Console review requested | ☐ |
Wrap Up
A WordPress security checklist isn’t a one-time task. It’s a system you maintain. Close the obvious doors first via strong passwords, 2FA, updated software. Then work through the technical layers including file permissions, database hardening, HTTP headers. Back everything up and monitor for changes.
If you want help securing your WordPress site or recovering from a hack, that’s what professionals are for. Don’t wait until it’s a problem.
