Most WordPress sites get compromised not because of zero-day exploits, but because of neglected basics — outdated plugins, weak passwords, default table prefixes, and missing SSL headers. A monthly security audit takes under two hours and closes the gaps attackers count on. This checklist covers 20 actionable points: updates, user access, file permissions, login security, SSL configuration, HTTP headers, backup integrity, malware scanning, and two-factor authentication. Work through it every month and your site’s attack surface shrinks to a fraction of what most WordPress installs expose.
Why Monthly Audits Matter More Than One-Time Hardening
Security is not a project you finish. WordPress powers over 43% of the web, which makes it a permanent target. Plugin vendors release security patches every week. User accounts accumulate stale credentials. SSL certificates expire quietly. Bots continuously probe login pages. The threat environment changes faster than any static hardening guide can keep up with.
A monthly audit solves this by treating security as a rhythm rather than an event. You catch the outdated plugin before it gets exploited. You remove the old admin account before a former contractor uses it. You verify your backup before you need it in a crisis. The 20 checkpoints below are organized into eight categories that mirror how attackers actually approach a WordPress site: from the most obvious entry points (updates, login) to the deeper layers (file integrity, HTTP headers, malware).
Category 1: Core, Plugin, and Theme Updates (Checkpoints 1–3)
Outdated software is the single most common root cause of compromised WordPress sites. The WPScan Vulnerability Database logs thousands of known vulnerabilities every year, and the overwhelming majority affect plugins and themes that have available patches. The gap between “patch released” and “site updated” is where most attacks happen.
Checkpoint 1: Update WordPress Core
Navigate to Dashboard → Updates and confirm you are running the latest stable release. For most sites, enabling automatic background updates for minor releases (security and maintenance) is a safe default. Major version upgrades should be tested on staging first, but they should not sit pending for more than two to three weeks. Every day you delay is another day attackers can fingerprint your version through the readme.html file or meta generator tag and match it against known CVEs.
While you are here, remove or disable the readme.html file and the wp-generator meta tag output if your security plugin does not already suppress them. Both broadcast your exact WordPress version to automated scanners.
Checkpoint 2: Update All Plugins
Review every installed plugin — not just active ones. Inactive plugins still contain exploitable code. If a plugin has been inactive for more than 60 days and you have no concrete plan to use it, delete it rather than update it. Unnecessary plugins are unnecessary attack surface.
Pay particular attention to plugins that handle payments, form submissions, file uploads, or user authentication. These process sensitive data and are disproportionately targeted. Cross-reference your plugin list against the WPScan Vulnerability Database or Wordfence’s threat intelligence feed if you want deeper coverage beyond what the WordPress.org repository reports.
Checkpoint 3: Update Active Themes
Update your active theme and parent theme. Delete every inactive theme except the default WordPress theme (Twenty Twenty-Four or equivalent), which you keep as a baseline troubleshooting fallback. Inactive themes with unpatched vulnerabilities are a common vector because site owners forget they exist. A theme you stopped using two years ago still runs on your server.
Category 2: User Access Audit (Checkpoints 4–6)
User account hygiene is one of the least glamorous parts of WordPress security and one of the most frequently neglected. Most sites accumulate ghost accounts over time — former employees, test users, agency contractors, developers who finished a project two years ago. Any of these can become an entry point if credentials are reused or compromised in an unrelated breach.
Checkpoint 4: Audit Administrator Accounts
Go to Users → All Users and filter by the Administrator role. You should be able to justify every single account in that list. If you cannot immediately name who owns an account and why they need administrator access, that account should be deactivated or deleted. The principle of least privilege applies: most contributors, editors, and even some developers do not need full administrator access to do their jobs. Downgrade roles wherever possible.
Also rename or delete the default “admin” username if it still exists. Brute-force bots try “admin” as their first username on every attack. Eliminating it removes the low-hanging fruit.
Checkpoint 5: Review All User Roles
Scan through every user role level — Editors, Authors, Contributors, and Subscribers. Remove accounts that belong to people who no longer work with the site. For e-commerce sites with customer accounts, verify that customer registration is turned off if you do not need it, or that it is protected by rate limiting and CAPTCHA. An open registration page with no protections is an invitation for spam account creation and potential privilege escalation exploits.
Checkpoint 6: Verify Password Strength Requirements
WordPress enforces a strong password recommendation but does not require it. Confirm that your security plugin or a dedicated password policy plugin is enforcing minimum password complexity for all user roles, not just administrators. Require passwords of at least 12 characters with mixed case and special characters. More importantly, check whether any active user accounts have compromised passwords by running a check against the Have I Been Pwned API — several WordPress security plugins integrate this directly.
Category 3: File Permissions (Checkpoints 7–8)
Incorrect file permissions are a force multiplier for attackers. If a malicious actor can execute or write to your WordPress files — even without direct server access — through a vulnerability in a plugin or theme, correct file permissions can limit the blast radius or prevent exploitation entirely.
Checkpoint 7: Verify Core File and Directory Permissions
The WordPress Codex has published its recommended permission structure for decades and it remains the correct baseline. Directories should be set to 755 (owner can read, write, execute; group and public can read and execute). Files should be set to 644 (owner can read and write; group and public can read only). The wp-config.php file deserves special treatment: set it to 600 or even 440 so only the file owner can read it, and move it one directory level above the web root if your hosting environment supports this.
Permissions of 777 on any directory or file are a critical finding. They allow any process on the server — including compromised scripts from other accounts on shared hosting — to write to your files. If you find 777 permissions anywhere, treat it as an incident, not just a misconfiguration.
Checkpoint 8: Check for World-Writable Files
Run a sweep for world-writable files on your installation. On managed hosting, your security plugin’s file integrity scanner will flag these. On VPS or dedicated servers, you can run this check via SSH. The uploads directory (wp-content/uploads) is legitimately writable by the web server but should not be executable — ensure PHP execution is disabled in uploads by adding a blocking configuration in .htaccess (for Apache) or your Nginx config. This prevents attackers from uploading a PHP backdoor through the media upload form.
Category 4: Login Security (Checkpoints 9–10)
The WordPress login page (wp-login.php) is the most publicly known entry point on every WordPress site. Automated bots scan for it constantly and run credential stuffing and brute-force attacks against it around the clock. Hardening this single endpoint eliminates a large portion of your incoming threat volume.
Checkpoint 9: Enable Login Attempt Limiting and Lockout
If you have a security plugin like Wordfence, iThemes Security (now Solid Security), or Limit Login Attempts Reloaded installed, verify that brute-force lockout rules are active and configured appropriately. A reasonable baseline is to lock out an IP after five failed login attempts within five minutes, with a 20-minute lockout on the first offense escalating to longer lockouts on repeat offenses. Check the lockout logs monthly — a cluster of lockout events from varied IP ranges is a signal that a coordinated attack is underway and that you may want to consider additional measures like CAPTCHA, geoblocking, or a Web Application Firewall.
Also verify that XML-RPC is disabled if you do not use it. XML-RPC allows a single request to attempt thousands of username-password combinations by batching them, bypassing per-attempt lockout rules. Unless you specifically depend on XML-RPC for mobile apps or specific integrations, disable it entirely.
Checkpoint 10: Confirm the Login URL Is Non-Default or Georestricted
Changing the default login URL from wp-login.php to a custom slug reduces automated bot traffic significantly. This is security through obscurity and should not be your only defense, but as one layer in a stack it meaningfully reduces log noise and server load from brute-force attempts. If you have changed the login URL, verify it is still working correctly after recent updates — some plugin or WordPress core updates can reset customizations.
As an alternative or complement, consider geoblocking the login page to countries where your legitimate users are located, using your security plugin’s geolocation feature or Cloudflare’s WAF rules. For a business site serving only North American clients, there is no legitimate reason for a login attempt to originate from certain high-risk regions.
Category 5: SSL and HTTPS Configuration (Checkpoints 11–12)
SSL is table stakes for any website in 2025, but simply having a certificate installed is not enough. Certificates expire, misconfigurations introduce vulnerabilities, and mixed-content errors silently undermine trust signals. Your monthly audit should verify that SSL is working correctly, not just that the padlock icon appears in the browser.
Checkpoint 11: Verify SSL Certificate Validity and Expiry
Check your certificate expiry date and confirm you have at least 30 days remaining. If you are using Let’s Encrypt, auto-renewal should handle this — but auto-renewal can fail silently due to DNS misconfigurations, hosting control panel issues, or changes to your server environment. Test it explicitly by visiting your site and clicking the padlock in the browser, or use a tool like SSL Labs’ SSL Server Test to get a full grade and detailed report.
Also verify that your WordPress Address and Site Address in Settings → General are both set to the HTTPS version, and that your .htaccess or server configuration is redirecting all HTTP traffic to HTTPS. Mixed content warnings (page loads over HTTPS but references some resources over HTTP) affect both security and SEO — use the “Why No Padlock” tool or the browser’s developer console to find any remaining mixed-content issues.
Checkpoint 12: Confirm HSTS Is Enabled
HTTP Strict Transport Security (HSTS) is an HTTP response header that tells browsers to only connect to your site over HTTPS, even if a user types the HTTP URL. Without HSTS, a network attacker can perform an SSL stripping attack during the initial HTTP-to-HTTPS redirect. With HSTS enabled, the browser refuses the downgrade at the client level.
Verify that your server is sending the Strict-Transport-Security header with a max-age of at least 31536000 (one year). You can check this in your browser’s developer tools under the Network tab, or use Mozilla Observatory’s header scanner. Many managed hosts and Cloudflare enable this by default, but it is worth confirming explicitly each month since server configuration changes can inadvertently disable it.
Category 6: HTTP Security Headers (Checkpoints 13–14)
Security headers are a line of browser-side defense that most WordPress sites neglect entirely. They instruct browsers on how to handle your content — what scripts to execute, whether to allow framing, how to handle cross-site data. They cost nothing to implement and close real attack vectors including cross-site scripting (XSS), clickjacking, and cross-site information leakage.
Checkpoint 13: Audit Core Security Headers
Run your site through Mozilla Observatory (observatory.mozilla.org) or SecurityHeaders.com monthly. These tools grade your response headers and flag missing or misconfigured ones. The headers you should be sending on every response include:
- X-Content-Type-Options: nosniff — Prevents browsers from MIME-sniffing a response away from the declared content type, which blocks certain XSS vectors.
- X-Frame-Options: SAMEORIGIN — Prevents your pages from being embedded in iframes on third-party sites, blocking clickjacking attacks.
- Referrer-Policy: strict-origin-when-cross-origin — Controls how much referrer information is sent with requests, reducing information leakage.
- Permissions-Policy — Restricts which browser features (camera, microphone, geolocation) can be accessed, limiting the impact of injected malicious scripts.
Checkpoint 14: Review Your Content Security Policy
Content Security Policy (CSP) is the most powerful — and most complex — of all security headers. A properly configured CSP tells the browser exactly which domains can serve scripts, styles, images, and frames on your page. Any resource not on the allowed list is blocked, which prevents injected malicious scripts from loading even if an attacker manages to get one into your content.
CSP configuration on WordPress is notoriously difficult because many plugins and themes inject inline scripts. Start with a permissive reporting-only policy, review the violations in your browser console, then tighten the policy over subsequent months. A CSP of any strictness is better than none. If your security plugin manages CSP headers, verify the policy has not been overwritten or loosened since your last audit.
Category 7: Backup Verification (Checkpoints 15–16)
Backups are your last line of defense against ransomware, catastrophic malware infections, botched updates, and hosting failures. But a backup strategy you have never tested is not a strategy — it is wishful thinking. Monthly audit time is the right moment to verify that your backups are actually working, stored correctly, and restorable.
Checkpoint 15: Confirm Backup Completion and Storage
Check your backup plugin’s log or your hosting control panel and confirm that the most recent scheduled backup completed successfully. Many backup failures are silent — the job runs, encounters a file lock or timeout, and logs a partial success. Verify that both the database and the files were captured, not just one or the other. A database-only backup cannot restore your media library and theme customizations. A files-only backup cannot restore your content. If you are still evaluating which tool to use, the best WordPress backup plugins comparison covers UpdraftPlus, BlogVault, and Jetpack side by side.
Verify that backups are stored in at least two locations — your primary hosting environment plus a remote destination like Amazon S3, Backblaze B2, Google Drive, or Dropbox. A backup stored only on the same server as your site is destroyed along with your site in a ransomware attack or catastrophic hosting failure. Follow the 3-2-1 rule: three copies of data, on two different media types, with one copy offsite.
Checkpoint 16: Test Restore on Staging
Once per quarter at minimum — and ideally once per month — perform a test restore of your most recent backup to a staging environment. This verifies that the backup is not corrupted, that your restore process works under pressure, and that you know exactly what steps to take during an actual incident. Discovering that your backup file is corrupted or your credentials to the remote storage are expired is information you want during a calm monthly audit, not at 2 AM after a ransomware attack. For step-by-step setup guidance, see the complete guide on setting up automated WordPress backups that actually work.
Document the restore process and make sure at least two people on your team know how to execute it. A backup your team cannot restore is not a backup — it is false confidence.
Category 8: Malware Scanning (Checkpoints 17–18)
Malware scanning is about detecting compromise that has already happened. It complements preventive measures by catching infections that slipped through — injected backdoors, malicious redirects, SEO spam scripts, and cryptominers that load silently in your theme files or the database. Monthly scanning is the minimum cadence; weekly is better for high-traffic or high-value sites.
Checkpoint 17: Run a Full File Integrity Scan
Run a complete file integrity scan using Wordfence, Sucuri Security, or your security plugin of choice. These tools compare your core WordPress files against the official checksums from WordPress.org and flag any modifications. A modified wp-settings.php or functions.php in your theme is a strong indicator of compromise. Review every flagged file carefully — some flags are false positives from legitimate customizations, but never dismiss them without investigation.
Pay special attention to the wp-content/uploads directory, where PHP execution should be blocked. Attackers commonly drop PHP backdoors disguised as image files in the uploads folder, knowing many security scans focus on plugin and theme directories rather than uploads. A file named image001.php.jpg or shell.php hidden in a nested uploads subdirectory is a classic indicator of a backdoor upload.
Checkpoint 18: Check for Database Injections and Spam Links
Malware is not always in PHP files. Database-level injections can insert hidden spam links, malicious redirects, or JavaScript into your post content, widget data, or WordPress options table. Run a scan that includes your database — Wordfence’s scanner and Sucuri’s SiteCheck both include database checks. Look specifically for suspicious content in the wp_options table, particularly the siteurl, home, and active_plugins entries, which attackers commonly manipulate to establish persistent backdoors.
If you find any injected content, do not simply delete it without investigating how it got there. Removing the malware without closing the vulnerability means you will be reinfected within hours. Trace the infection to its source — whether that is a vulnerable plugin, a compromised admin account, or a file permission issue — and fix that first.
Category 9: Two-Factor Authentication (Checkpoints 19–20)
Two-factor authentication (2FA) is one of the highest-impact security controls available on WordPress. It transforms a compromised password from a full account takeover into a blocked login attempt. Even if an attacker purchases your credentials from a dark web data dump, 2FA prevents them from completing the login without the second factor — typically a TOTP code from an authenticator app or an email link.
Checkpoint 19: Enforce 2FA for All Administrator Accounts
Verify that every administrator account has 2FA enabled and actively configured. This is not a “strongly recommended” step — it is non-negotiable for anyone with admin access to a production WordPress site. Wordfence, Solid Security, Google Authenticator plugins, and WP 2FA all provide solid TOTP-based implementations. Many of them also allow you to make 2FA mandatory for specific user roles, which means users cannot skip setup or disable it after enrollment.
During your monthly audit, go to your 2FA plugin’s user management section and verify that no administrator accounts show 2FA as disabled or pending setup. If any do, send a reminder to the account owner and set a deadline. If they have not completed setup within 48 hours, temporarily disable the account until they do. The inconvenience of a disabled account is insignificant compared to the cost of a compromised administrator session.
Checkpoint 20: Extend 2FA to Editor and Author Roles
Once 2FA is solid for administrators, extend enforcement to Editors and Authors. These roles can publish content to your site, update existing posts, and in many configurations manage media uploads. A compromised Editor account is a platform for publishing phishing pages, SEO spam, or malicious JavaScript in your legitimate content — content that your existing visitors trust. Extending 2FA to editors is especially important for membership sites, multi-author blogs, and any site where the Editor role has broad content permissions.
Also verify that application passwords — the WordPress feature that allows external apps to authenticate via a per-application credential — are either disabled or closely monitored. Application passwords do not support 2FA, which means they are a bypass vector if an attacker knows a valid username. If you do not actively use application passwords for integrations (REST API clients, mobile apps, etc.), disable the feature entirely via your security plugin or a small code filter.
Building Your Monthly Audit Workflow
Twenty checkpoints sounds like a lot. In practice, a systematic monthly audit takes 60 to 90 minutes on a well-maintained site. The way to make it sustainable is to treat it as a scheduled operational task with a documented procedure, not a reactive scramble triggered by a security incident.
The Quick-Reference Checklist
Print or bookmark this summary and work through it from top to bottom each month. Check each item off as you complete it. If you find an issue, document it with a timestamp and resolution note.
| Category | Checkpoint | Pass Criteria |
|---|---|---|
| Updates | 1. WordPress core current | No pending major or security updates |
| Updates | 2. All plugins updated | Zero outdated plugins; inactive plugins deleted |
| Updates | 3. Active themes updated | Theme and parent theme current; unused themes deleted |
| User Audit | 4. Administrator accounts reviewed | All admins identified; no default “admin” username |
| User Audit | 5. All user roles reviewed | No stale or unrecognized accounts |
| User Audit | 6. Password policy enforced | Policy plugin active; no known-compromised passwords |
| File Permissions | 7. Core permissions verified | Directories 755, files 644, wp-config.php 600 |
| File Permissions | 8. No world-writable files | Zero 777 permissions; PHP disabled in uploads |
| Login Security | 9. Brute-force protection active | Lockout rules configured; XML-RPC disabled |
| Login Security | 10. Login URL hardened | Custom URL or georestriction in place |
| SSL | 11. Certificate valid, 30+ days | SSL Labs A or A+; all redirects to HTTPS |
| SSL | 12. HSTS enabled | Strict-Transport-Security header present, 1-year max-age |
| HTTP Headers | 13. Core security headers present | Mozilla Observatory grade B or higher |
| HTTP Headers | 14. CSP reviewed | Policy active; violations reviewed |
| Backups | 15. Backup completed, offsite copy exists | Latest backup successful; remote storage confirmed |
| Backups | 16. Restore tested | Staging restore verified this quarter |
| Malware | 17. File integrity scan clean | No unexpected file modifications |
| Malware | 18. Database scan clean | No injected links, redirects, or suspicious options |
| 2FA | 19. All admins have 2FA active | Zero pending or disabled 2FA setups for admins |
| 2FA | 20. Editors and Authors covered | 2FA enforced on content roles; app passwords reviewed |
Tools That Make This Audit Faster
You do not need to work through each of these 20 checkpoints from scratch every month. A well-configured security plugin automates several of them continuously and surfaces the status in a single dashboard view. Here is how to map common security plugins to the checklist categories:
- Wordfence Security — Covers file integrity scanning (Checkpoint 17), malware and database scanning (Checkpoint 18), login protection and brute-force lockout (Checkpoint 9), 2FA (Checkpoints 19–20), and firewall rules that address multiple header issues. The dashboard summarizes all findings in one view.
- Solid Security (formerly iThemes Security) — Strong on user security auditing (Checkpoints 4–6), 2FA enforcement (Checkpoint 19), file permission checks (Checkpoint 7), and brute-force protection (Checkpoint 9).
- Sucuri Security — Excels at malware scanning (Checkpoints 17–18), security header auditing (Checkpoint 13), post-hack recovery, and external blacklist monitoring.
- WP 2FA — Dedicated 2FA plugin with role-level enforcement and grace period management (Checkpoints 19–20).
- UpdraftPlus or BlogVault — Reliable backup solutions with offsite storage and test-restore functionality (Checkpoints 15–16).
Using two or three of these in combination gives you automated coverage of at least 14 of the 20 checkpoints. Your manual monthly audit time then focuses on the items that require human judgment: reviewing who should have administrator access, deciding which old accounts to remove, and interpreting ambiguous scan results.
What to Do When You Find a Problem
Finding an issue during a security audit is a success, not a failure. The audit is working. The question is how to respond systematically rather than reactively.
For configuration issues — wrong file permissions, missing security headers, an expired certificate — fix them immediately during the audit session. These are known-good states with clear remediation paths. Document what you found, what you changed, and when.
For malware or active compromise indicators — modified core files, injected database content, unrecognized administrator accounts — escalate to incident response mode. Take the site offline or put it in maintenance mode to prevent further damage or harm to visitors. Preserve logs before cleaning anything. Identify and close the root cause vulnerability before restoring clean files. Reset all passwords and regenerate security keys in wp-config.php. Consider engaging a professional malware removal service (Sucuri, Wordfence Care, Kinsta Security) if the infection scope is unclear.
For borderline issues — plugins with no update for 18 months, a CSP that blocks some legitimate resources, a backup that completed but took longer than usual — log them as items to investigate further and set a deadline. Not everything found in an audit requires immediate action, but everything should be triaged and tracked.
Security Audit as Business Operations, Not Just IT
The frame matters. Teams that treat WordPress security audits as an IT chore tend to skip them when time gets tight. Teams that treat them as business operations — protecting revenue, protecting customer data, protecting brand reputation — tend to run them consistently.
A compromised WordPress site costs far more than 90 minutes of monthly audit time. Google blacklisting your domain removes you from search results and kills organic traffic. A data breach affecting customer information carries legal exposure and notification costs. A ransomware infection can destroy years of content and require paid malware removal services. A phishing page served from your domain burns your sender reputation and alienates your email list.
The 20-point monthly checklist in this guide is not a comprehensive security hardening guide — it is a maintenance rhythm. One-time hardening establishes a baseline. Monthly audits protect that baseline against the ongoing entropy of updates, user changes, and an evolving threat landscape. Both are necessary. Neither replaces the other.
Start this month. Block 90 minutes on your calendar, work through all 20 checkpoints, and document every finding. Repeat next month. The compounding effect of consistent security hygiene over 12 months is a dramatically harder target than your competitors running the same WordPress stack without any regular review.
Frequently Asked Questions
How long does a full WordPress security audit take?
For a well-maintained site with a security plugin already installed, 60 to 90 minutes per month is realistic. The first audit on a site with no prior hardening may take three to four hours as you establish baselines, configure tools, and remediate any findings. Subsequent audits are faster because you are maintaining a known-good state rather than building one from scratch.
Do I need a dedicated security plugin, or is the WordPress core enough?
WordPress core provides the infrastructure but does not implement the security controls this checklist requires. You need at minimum a security plugin for login protection and file integrity scanning, a 2FA plugin, and a backup plugin with offsite storage. Most of the items in this checklist cannot be verified or enforced without these tools. The good news is that the free tiers of Wordfence, Solid Security, and UpdraftPlus cover the majority of this checklist without any paid subscriptions.
What is the most common vulnerability pattern on WordPress sites?
Outdated plugins, particularly those that handle forms, file uploads, e-commerce transactions, or user authentication. These plugins process external input and are high-value targets. The WPScan database consistently shows that plugin vulnerabilities account for over 90% of known WordPress CVEs in any given year. Keeping plugins updated (Checkpoint 2) and deleting unused ones is the single highest-return security action you can take.
Start Your Audit Today
You now have a complete, actionable WordPress security audit checklist covering all 20 monthly checkpoints across updates, user access, file permissions, login hardening, SSL, HTTP headers, backup verification, malware scanning, and two-factor authentication. Bookmark the table in the “Building Your Monthly Audit Workflow” section and use it as your working document each month.
If you want to go deeper on the structural hardening side — server configuration, wp-config.php tweaks, database prefix changes — the WordPress security hardening checklist covers 17 one-time lockdown steps that complement this monthly audit rhythm.
Security is not a destination. It is a practice. Run the audit, document the findings, fix the issues, and repeat. That rhythm is what separates sites that get compromised from sites that do not.
Malware Scanning Site Security Two-Factor Authentication wordpress security WordPress Security Audit
Last modified: April 10, 2026
