Audit a New Client's Site Before You Sign Anything

Why this is worth doing before you say yes

When you take on a new client's site, you're not starting from a blank slate — you're inheriting whatever state it's already in. That includes the possibility that it's already compromised in a way nobody's noticed yet: a backdoor left over from a previous developer's account, a nulled plugin quietly phoning home, an admin user that shouldn't exist. If you sign on to maintain that site without checking first, you've just agreed to be responsible for a problem you didn't cause and don't yet know about — and the day it surfaces, it happens on your watch, not the previous maintainer's.

A short audit up front avoids that. It also gives you something concrete and useful to hand the client on day one, before you've done a single hour of billable maintenance work.

The checklist

1. Verify core file integrity

Confirm the WordPress core files match the official release for the version installed — a modified core file outside of an update is one of the more reliable signs of a past or ongoing compromise. If you have shell access:

wp core verify-checksums

Any mismatch is worth understanding before you move on — see what a core-file mismatch actually means if you land one.

2. Review every admin account

List every administrator on the site and ask, for each one, whether you can account for who it belongs to and why they have that level of access:

wp user list --role=administrator --fields=user_login,user_registered,user_email

A former developer's account that was never removed, an agency that no longer works with the client, or an account you simply don't recognize are all worth chasing down before you take over — see why a dormant admin account is a real, standing risk, not just clutter.

3. Check every plugin and theme for what it actually is

Go through the full plugin and theme list and flag anything abandoned (no updates in years, no longer in the WordPress.org repository) or, more urgently, anything that looks like a nulled or pirated copy of a premium product. This isn't a minor concern: independent research has found that more than 30% of nulled WordPress themes tested contained malware of some kind, and WP-VCD — one of the most widespread WordPress malware families ever documented — spreads almost entirely through pirated plugins and themes. If a previous owner or developer installed anything "cracked" to save on a license fee, treat it as a live suspect until proven otherwise.

4. Check file permissions

Overly permissive file and directory permissions (world-writable files, in particular) make it easier for an attacker who gets any foothold at all to modify or plant files. WordPress.org's own hardening guidance is specific about the baseline: directories at 755 (or 750), files at 644 (or 640), and no directory anywhere should ever be 777 — including upload folders, which is a common shortcut taken to "just make an upload error go away."

One file deserves special attention on every audit: wp-config.php. It's created at 644 by default, which means it's world-readable on a shared server — and it holds the site's database credentials and authentication keys, arguably the single most sensitive file in the entire install. Tightening it to 440 (or 400) is a five-second fix that closes a real exposure most site owners never think to touch. This whole check takes minutes but is rarely something a previous non-technical owner would have set correctly on their own.

5. Look at recent login activity

If the site has any login logging available, scan recent activity for anything that doesn't line up with who should actually be accessing the site — logins at odd hours, from unfamiliar locations, or immediately followed by unexpected changes. You're looking for a pattern, not a single data point; one unusual login is often nothing, but one followed by a role change or a new plugin install is a different story. Worth checking alongside this: whether xmlrpc.php shows signs of repeated brute-force attempts in the server logs, since it's a much more commonly abused login surface than the visible wp-login.php form, and a previous owner is unlikely to have been watching it at all.

6. Check whether the site is already flagged anywhere

Two free, official checks take a couple of minutes and cost nothing: run the domain through Google's Safe Browsing Transparency Report to see if Google has already flagged it as unsafe, and — if you have or can get access to the client's Google Search Console property — check Security & Manual Actions → Security Issues, where Google specifically categorizes any known problem as Malware, Unwanted Software, Harmful Downloads, or Phishing. Either one turning up something is a very different conversation to have with a prospective client than starting maintenance work and discovering it three months in.

7. Confirm backups actually exist — and actually work

This is the single most common gap in an audit like this: a site owner believes backups are running because a plugin was installed once, but nobody has ever confirmed a backup can actually be restored. Locate where backups are stored, confirm at least one is recent, and — if at all possible — actually test a restore to a staging environment rather than taking "it's configured" on faith. An audit that skips this step can miss the one thing that would have mattered most if anything above turns out to be a real problem.

8. Check the site and home URLs haven't been quietly changed

Two of WordPress's most basic settings — the site URL and home URL, stored in wp_options — are also a quiet, low-visibility redirect target for an attacker: change either one and every link on the site can start pointing somewhere else without a single file being modified. Confirm both match the domain you're actually looking at:

wp option get siteurl
wp option get home

This takes seconds and is easy to skip precisely because it's not a file or a visible page — it's a database value nobody thinks to double-check until something's already gone wrong.

Turning this into something the client can actually use

A raw list of technical findings isn't useful to a business owner, and it isn't a great way to start a relationship either. Summarize what you found in plain terms — what's fine, what needed fixing and has been fixed, and what still needs a decision from them — the same way you'd want to explain an actual incident to a non-technical client. Even when the audit turns up nothing alarming, "here's what we checked and confirmed is clean" is a genuinely reassuring thing to hand someone on day one.

This first audit is also the natural, non-awkward moment to introduce ongoing security monitoring as part of the relationship, rather than adding it later as a surprise line item — see what to actually charge for it once you're past the one-time audit and into the recurring part of the engagement.