What to Check When You Inherit a WordPress Site

Short answer: check who still has access, whether anything is updated, whether backups exist, and whether the code has been modified. An hour of this tells you whether you have a maintainable site or a rebuild.

I do this regularly — it is most of what inherited-site work involves, and the order matters because the first checks are the ones that can bite you while you are still looking.

1. Who can get in

Do this first. Everything else can wait an hour; this cannot.

Users → All Users. Look at every Administrator. For each one, ask: do I know who this is, and should they still have access?

What turns up:

• The previous developer, still an admin
• Staff who left
• An agency account from a project years ago
• Accounts with names like admin1 or wp_user that nobody recognises

Remove the ones that should not be there. Do not delete accounts that authored content — WordPress offers to reassign their posts, and you want that rather than deleting the posts with them.

Then change the hosting and FTP passwords too. Site access is not the only access.

2. What is out of date

Dashboard → Updates, then the plugin list.

You are looking for two different things:

Out of date is a maintenance job. Update on a staging copy first, not live.

Abandoned is a real problem. A plugin last updated three years ago has no security fixes coming and may break on the next WordPress release. WordPress flags these on the plugin page.

Also check the PHP version under Tools → Site Health. A site on an unsupported PHP version is not receiving security patches at the language level.

3. Whether a backup exists

Ask the question properly: if this site vanished right now, what would we restore from, and when was it last tested?

Common answers:

• Nothing. More often than you would hope.
• The host takes them — find out how far back and how to restore. Some only keep a few days.
• A plugin does — check where it sends them. Backups stored on the same server as the site are not backups.

Before changing anything, take one yourself.

4. Whether the code has been modified

This is where inherited sites surprise you.

Is the theme a child theme, or has a parent theme been edited directly? If the parent was edited, updating it destroys the work — which is usually why it was never updated.

Check functions.php for code added by the last developer, and wp-config.php for anything unusual — especially WP_DEBUG left on, or credentials in plain sight.

Look for a plugin that is not in the WordPress directory. Custom plugins are fine, but note that nobody but you will be maintaining them.

5. A quick security pass

Not a full audit — the obvious things:

• Is there a security plugin, and is it actually configured?
• File permissions — files should not be world-writable
• Is wp-config.php readable from a browser? It should not be
• Does the site load over https:// with a valid certificate, and does http:// redirect to it?
• Search for suspicious code. A site compromised in the past often has leftovers. Look for eval( and base64_decode( in theme and plugin files — both have legitimate uses but are worth understanding.

If you find a password column storing MD5 hashes on a custom login system, there is a way to upgrade it without forcing everyone to reset.

6. Whether email works

Submit the contact form and see whether anything arrives.

This fails on inherited sites more than anything else — the notification address often still belongs to someone who left. Here is why it usually breaks.

While you are there, check whether enquiries are also stored in the database. If they are not, nobody knows how many have been missed.

7. Speed and search

Last, because they are improvements rather than risks.

Run PageSpeed Insights. Check Search Console if you have access — and if nobody does, set it up, because you cannot see indexing problems without it.

What to tell the owner afterwards

Separate what you found into three lists. It makes the conversation straightforward:

1. Fix now — unknown admin accounts, no backups, known vulnerabilities
2. Fix soon — out-of-date plugins, unsupported PHP, email not delivering
3. Improve later — speed, SEO, the modified parent theme

Most owners have never been told any of this. Being specific about which list something belongs in is more useful than a long report, and it is usually the point at which they understand what they have been paying for.

---

Taken over a site and not sure what you have got? Tell me what you are looking at — auditing and fixing other people’s WordPress is a large part of my work.