If you are wondering whether your WordPress site is really secure, a WordPress security audit gives you a practical place to start. Maybe you have spotted spammy links, an unfamiliar login, an unexpected charge, or a search warning. Maybe nothing looks wrong and you simply want a reliable baseline. Either way, you can turn that uncertainty into a clear list of checks and next steps.
A useful audit brings together software, accounts, login controls, settings, activity, hosting, and backups. We will walk through those checks in an order that helps you handle what you control and know when to ask your host or developer for help. By the end, you should have prioritized fixes and a recovery path you have actually tested.
TL;DR: A WordPress security audit checks software, access, settings, activity, and backups. A security plugin can scan for malware and known weaknesses, but it does not replace the full review. Start with signs of compromise and follow a WordPress hacked website recovery process if the evidence points to an intrusion, fix the highest-risk gaps, and restore a backup in a safe test location to prove you can recover.
What a WordPress security audit covers
Before checking individual settings, define the finish line. An audit combines automated checks with manual review. It looks for malware and WordPress security issues, then reviews accounts, login protection, site behavior, files, hosting, logs, and backups.
That is why an audit is broader than a malware scan. A file integrity monitoring check compares files with a trusted version. A penetration test uses authorized attacks to find exploitable weaknesses, while a compliance review checks a rule or standard. A plugin scan is neither.
Check for signs of an active incident
Start with the signals that made you concerned. These deserve investigation:
- Spam links, unexpected redirects, or search warnings.
- New administrators, unfamiliar logins, or sudden failed-login bursts.
- Unexplained charges, content changes, or traffic from an unfamiliar pattern.
Unexpected content changes can be a sign of a website defacement attack.
None of these proves a hack by itself. A campaign, crawler traffic, a misconfiguration, or a billing error can look similar.
If you suspect a website compromise, save a snapshot or copy of the site when feasible. Record the time, affected URLs, alerts, accounts, and visible changes. Do not delete suspicious files or edit code blindly because you may destroy useful evidence.
Use a controlled cleanup process, or follow a hacked website repair guide before using a known-good restore path. After remediation, change exposed passwords, patch the weakness that allowed access, and scan and inspect the site again. If visitors are being redirected or harmed, ask your host or a qualified security professional to help contain the problem.
🛡️ Note: A search warning or redirect needs prompt attention, but it does not identify the cause. Preserve the site state before making broad changes.
Complete the nine audit checks
Start with a connected security scan
Once urgent signs are recorded, run both a malware scan and a vulnerability scan. A public URL checker sees what an anonymous visitor can reach. A connected scanner can inspect private files and database content.
Record enough detail to act on each result:
- The affected file, database item, plugin, theme, version, or URL.
- Why it was flagged and when it was checked.
- Whether the result is confirmed, suspicious, or unresolved.
A clean result lowers uncertainty, but it cannot verify credentials, hosting, custom code, or every setting.
A security plugin can make this detection work easier and repeatable. MalCare, for example, offers a WordPress malware scanner and vulnerability scanning for WordPress sites. Use it as one part of the audit, not as a replacement for reviewing users, hosting, custom code, settings, and backup recovery.
Review every WordPress component
The scan gives you a starting point. Next, list WordPress core, plugins, and themes, then check for WordPress security updates and other maintenance updates. Include inactive software because it remains on the server. Remove what you do not need, and investigate anything abandoned, poorly maintained, or from an untrusted source.
When compromise is suspected, compare core files with the official WordPress version and investigate unexpected changes. Take a usable backup before updating. Test important updates on a staging site, a private copy used to check changes, or during a maintenance window.
Updates reduce known risks but can cause compatibility problems. Do not postpone a critical security update indefinitely. Keep a rollback plan and verify the site afterward.
🛡️ Note: Do not treat a backup as tested until you have restored it and checked the pages and features that matter to your business.
Confirm users and permissions
With the software inventory in hand, review every account, its role, its need, and its access to connected services. Keep Administrator access only for people who need to manage nearly every part of the site. Give everyone else the lowest access that lets them work.
Remove idle accounts only after confirming they are no longer needed. Transfer content or ownership first, then review application passwords and outside integrations. Changing access may require coordination with the people managing content, code, payments, or hosting.
Check the WordPress setting Anyone can register. Turn it off when open registration is not a deliberate site feature. If registration is needed, confirm the default role, approval process, and spam controls.
Configuration and account reviews require authenticated administrator access. On a fresh HTTPS WordPress 7.0 site using PHP 8.4 and MySQL 8.0, an anonymous settings request returned HTTP 401 with the exact error rest_forbidden. Public posts and users requests returned JSON. This showed an access boundary, not that the settings were secure.
Protect every privileged login
User permissions show who can reach the site. Now protect how those users sign in. Use WordPress password security practices for privileged accounts and enable two-factor authentication, which requires a second proof such as an authenticator-app code.
Use a CAPTCHA, a check designed to separate people from automated programs, where it fits the sign-in or registration flow. Add rate limiting, which restricts repeated login attempts, to reduce password-guessing attacks.
Review recovery email addresses, password resets, application passwords, and outside login services. Test recovery without locking out the owner. A strong password does not protect an exposed recovery account, and two-factor authentication does not fix an unpatched plugin or infected computer.
Compare site behavior with expected activity
Authentication is only part of the picture. Compare traffic reports, search warnings, content changes, redirects, login attempts, and visitor locations with site releases, campaigns, outages, and known crawler activity.
Treat each signal as a prompt to correlate evidence with activity logs, scan results, user accounts, file changes, database content, and hosting logs. A traffic spike can be a successful campaign or bot traffic; a drop can come from an outage or search change. Analytics alone cannot show that a site was hacked.
Review files and key settings
Behavioral signals tell you where to look next. Ask your host or developer to review file ownership and permissions if you do not manage the server. WordPress documentation gives 644 for files and 755 for folders as examples, but the server and its ownership rules determine what is safe. Do not apply recursive permission changes or make files writable by everyone.
Review sensitive settings, unexpected executable files in upload folders, database access, debug settings, and secrets stored in files or environment settings. Guidance on how to secure your WordPress site with wp-config.php can help with the configuration review. Back up before editing configuration files, and test each significant change.
You can disable the built-in dashboard file editor with the DISALLOW_FILE_EDIT setting. This closes one way to change plugin and theme files. It does not stop a compromised administrator, an unsafe upload, a vulnerable plugin, or server access from changing files.
Rules for server files, PHP execution, remote login requests, security headers, and database permissions depend on the site. Ask a host or developer to review them and test changes because WordPress hardening can break forms, payments, embeds, or integrations.
🛡️ Note: The common 644 file and 755 folder examples are not a universal fix. Ownership and hosting setup determine what is safe.
Ask what your host protects
Some important controls sit outside WordPress. Ask the host about:
- Security updates, HTTPS certificate renewal, and traffic-flood protection.
- Monitoring, exposed services, database access, and account isolation.
- Backups, incident support, and who can access the hosting panel, server, domain records, release system, and live database.
This handoff is part of the audit, not a sign that you have failed to finish it.
Check HTTPS, the encrypted connection between a visitor and the site, across important pages. Look for redirect loops and browser warnings.
Review security headers with someone who understands the site’s scripts and integrations; a copied policy can break a working site.
During a deployment check on a fresh HTTPS WordPress site, /wp-json/ returned HTTP 301. The REST index returned JSON through index.php?rest_route=/ and listed wp/v2 and wp-site-health/v1 namespaces. This was normal behavior, not a security verdict. Record the actual redirects and access rules on the site being reviewed.
HTTPS protects data while it travels. It does not prove that the application, accounts, plugins, custom code, or server are safe.
Keep a usable activity log
Once the host boundary is clear, make sure you can reconstruct important changes. An activity log should record:
- Logins and role changes.
- Plugin and theme updates.
- File edits and content changes.
Check how long records remain, who can view or delete them, and how they are protected from tampering.
Assign someone to review alerts and define escalation. WordPress core does not provide a complete administrator log for every change. Plugin, host, deployment, web-server logs, and outside login-service logs may cover different events, so use them to track WordPress user activity and keep logging enabled, retained, protected, and reviewed.
Restore a backup before you need it
The final control is recovery. Confirm that backups include both site files and the database. Match the schedule to site changes, keep useful versions long enough to cover compromise discovery, and store copies away from or isolated from the live server when possible.
Restore a WordPress backup to staging or another controlled location, then check:
- The public site and administrator access.
- Forms, important integrations, and media.
- Critical records, expected content, restore time, and the steps required.
This is the point where a backup becomes evidence of recovery rather than just a file on a server.
A backup file is not a recovery plan. A WordPress backup plugin can help create and manage copies, but same-host backups can disappear with the live site, and an untested backup may be incomplete or impossible to restore with the access available.
Prioritize findings and verify every fix
Fix findings in this order:
- Active compromise, malicious redirects, exposed credentials, and unauthorized administrators.
- Exploitable outdated software, unsafe access paths, and serious configuration problems.
- Missing monitoring, incomplete logs, weak account processes, and untested backups.
- Hardening and maintenance work that lowers future risk.
For each item, record the evidence, affected component, risk, owner, planned fix, deadline, and verification test. Close it only after the relevant test passes, and keep the original incident evidence instead of recording only “fixed.”
Know when to run another audit
Run an audit after an incident, host or domain change, major WordPress or plugin update, new feature, significant user or data change, or before an important launch.
A monthly or quarterly review may suit a low-change site. Sites with frequent deployments, sensitive data, or high business impact need more frequent checks. Schedule deeper host and restore reviews based on change rate and downtime cost.
Conclusion
A WordPress security audit is complete when it gives you clear priorities and a recovery path you have tested. Scanning matters, but so do updates, account access, login controls, hosting, activity records, and backups.
Run the checks after meaningful changes and whenever site behavior raises a question. Fix urgent findings first, document what you changed, and verify the result so security becomes a repeatable part of maintaining your WordPress site.
