Your site works, nothing looks wrong, and yet you have a nagging feeling that nobody has properly looked at it in a long time. A developer built it a few years ago, plugins have piled up, and you are not sure who still has a login. That is exactly the situation a security audit is for.
An audit is a structured look at everything that decides how easy your site would be to break into, and how quickly you could recover if it were. Here is what a real audit of a small business WordPress site checks, item by item, and what you should have in your hands at the end.
Audit or malware removal: which one you need
These are two different jobs. An audit is prevention. It assumes the site is currently clean and asks where the weak points are. Malware removal is cleanup. It starts from a site that is already infected, removes the malicious code, and closes the way in.
If you are seeing redirects to strange sites, spam pages in Google, a warning in the browser, or a suspension notice from your host, an audit is the wrong starting point. You need a malware removal service first, and the hardening comes afterwards.
1. Users and roles
The first thing to open is the Users screen. An auditor lists every account and its role, and asks who each one belongs to.
- Administrator accounts that belong to former staff, old agencies or freelancers who finished years ago.
- Accounts nobody recognises. These are sometimes the first sign of a past compromise.
- One login shared by several people, which makes it impossible to tell who did what.
- People with Administrator rights who only ever write posts or process orders and would be fine as Editor or Shop Manager.
- Weak or reused passwords on admin accounts, and usernames that are easy to guess.
The fix is usually simple: remove what is not needed and give everyone else the smallest role that fits their work.
2. Plugins and themes
This is where most real risk lives on a typical site, so it gets the most time.
- Outdated plugins and themes, checked against public vulnerability databases to see whether the installed version has a known, published flaw.
- Abandoned plugins that have not been updated by their developer for a long time, or that have been closed on WordPress.org. They may work today, but nobody will patch them if a hole is found. Our guide on what to do about an abandoned plugin covers the choices.
- Inactive plugins and spare themes. Deactivated code is still on the server and can still be reached. If it is not used, it should be deleted, keeping one default theme as a fallback.
- Where premium plugins came from. A paid plugin installed from an unofficial download site is a serious finding on its own.
3. WordPress core and PHP version
The auditor confirms that WordPress core is current and that automatic minor updates have not been switched off without a reason. They also check which PHP version the server runs. PHP versions reach an end of life after which they get no security fixes, and many sites sit on old versions simply because nobody changed the setting in the hosting panel. Moving up needs a test first, because older plugins can break on newer PHP.
4. File permissions and stray files
Permissions decide who on the server can read and change your files. Folders and files that are writable by everyone are a common finding, often left behind after someone “fixed” an upload error the quick way. The auditor also looks for things that should not be in the public web folder at all: old copies of the site in folders like /old/ or /test/, backup archives, database exports, and leftover installer scripts.
5. wp-config.php
This file holds your database password and security keys, so it is checked carefully.
- Debug mode should be off on a live site, so errors are not shown to visitors.
- The built-in file editor in the dashboard should usually be disabled, so a stolen admin login cannot be used to edit plugin code directly.
- The security keys and salts should be set and unique.
- The file should have tight permissions and should not be readable from the web.
6. Backups, and an actual restore test
An audit asks more than “are backups running?” Where are the backups stored? If they sit on the same server as the site, a server problem or a hack can take out both. How far back do they go? Do they include the database as well as the files?
Then the part that matters most: a backup is restored to a staging copy to prove it works. A backup that has never been restored is a hope, not a plan. The 3-2-1 backup rule is the standard the findings are measured against.
7. SSL and security headers
The certificate is checked for validity, coverage of both the www and non-www addresses, and expiry, and the site is tested to make sure every HTTP address redirects to HTTPS. You can run the certificate part yourself with our SSL checker. Mixed content warnings, where a secure page still loads images or scripts over plain HTTP, are noted too. The auditor also reviews which HTTP security headers the server sends, since missing ones are cheap to add.
8. Login protection
This covers how the front door is guarded: whether two-factor authentication is on for administrators, whether failed login attempts are limited, whether XML-RPC is open when nothing on the site needs it, and whether login activity is being logged anywhere so you would notice a problem.
9. Malware and blocklist status
Even a preventive audit starts with a check that the site is clean right now. That means a file scan, a look at the database for injected scripts or spam links, and a check of the site’s reputation: the Security Issues report in Google Search Console, Google’s Safe Browsing status, and common blocklists. A site can be flagged without the owner noticing, especially when the problem affects only some pages and the owner mostly sees the homepage or the dashboard.
10. Hosting and server basics
The auditor looks at the hosting account itself, not just WordPress:
- Whether other old or unused sites share the same hosting account. One neglected site can infect its neighbours.
- Whether file access uses SFTP rather than plain FTP, and who has those credentials.
- Whether the hosting control panel login has a strong password and two-factor authentication.
- Whether the host provides a firewall, malware scanning or isolation between accounts.
11. DNS and email records, briefly
This is a short check, but it catches real problems. The domain registrar account should have a strong password and two-factor authentication, because whoever controls the domain controls the site and the email. SPF, DKIM and DMARC records are checked, since missing or broken ones make it easier for someone to send email that looks like it comes from your business.
What you get at the end
The output of a proper audit is a written list of findings, each with a priority and a plain-language note on what to do. A typical structure looks like this:
| Priority | What it means | Example finding |
|---|---|---|
| Critical | Fix now, it is open today | Plugin with a known, published vulnerability |
| High | Fix this week | Former developer still has an Administrator account |
| Medium | Plan it in | Backups stored only on the same server |
| Low | Good practice | Missing security headers |
The report should also say what was already fixed during the audit and what is left for you or your developer. If all you receive is a scanner screenshot with a green tick, that was a scan, not an audit.
Getting an audit done
You can work through much of this list yourself in an afternoon if you are comfortable in the dashboard and hosting panel. If you would rather have someone go through it and leave you with a prioritised list, our Website Security Audit starts at ₹1,999 and covers a one-time audit plus basic hardening. The details are on our website security maintenance page.
Next in this series: WordPress Security Myths That Waste Your Time
