What I Check When I Inherit a WordPress Site I Didn't Build

Sometimes the site was built by another developer. Sometimes by an agency. Parts of it may also have been generated or changed with AI. But the handoff problem itself is older than AI.

However it was built, you're the one touching it now. You don't know what's actually configured under the hood. Not yet.

1. Record the current state before you change anything

Before you fix, add, or "clean up" anything, write down what you found. No one's checking your work here. But later, if something breaks, it helps to know whether it was already broken when you got there.

A quick note is enough: which plugins are active, whether the site is set to be indexed, whether debug mode is on. Later, that note gives you something to compare against when a problem shows up.

2. Look at the installed plugins

Open the plugins screen and look past the ones that are active. Look at all of them, active and inactive.

For each one, ask three questions:

Is this plugin still maintained? Check its last update date on WordPress.org. A plugin that hasn't shipped an update in a year or more is one worth reviewing before you rely on it, even if you didn't choose to install it.
Is this one inactive on purpose, or was it just never cleaned up? An inactive plugin sitting around for years may simply be a leftover, or someone may have kept it there on purpose. Either way, it's often worth asking about.
Should I keep touching a site that depends on this? Sometimes the answer is yes, and that's fine. The point is to ask that question before you start relying on the plugin.

I used to do this by opening each plugin's WordPress.org page one by one, which is tedious enough that I usually skipped the ones that "looked fine." Eventually, I automated that part of the process. I'll come back to that at the end.

3. Check the current state, not the assumed state

You assume noindex is off because "why would anyone launch a site that's hidden from Google." You assume debug mode is off because "it's a live site." Those assumptions are often right. But inherited sites are exactly where I don't want to rely on them.

Check whether the site is set to be indexed by search engines, and don't rely only on the visible setting. A theme or plugin can force noindex through code even when the visible setting looks fine. Check whether WP_DEBUG is on. Check whether the default admin username still exists. These aren't complicated checks, but they're easy to miss when you're focused on the actual task you were hired to do.

Ask yourself, for each setting: was this intentional, or is this just what came with the site? If you can't answer that, you can't safely assume it's fine.

4. Make your changes

Then you do the actual work: build the feature, fix the bug, make the requested changes. But now you're doing it against a baseline you actually understand, instead of a baseline you inherited blind.

5. Go through the site again before you hand it back

Once your work is done, circle back to the same questions from step 3. Indexing, debug mode, admin username, and anything you added along the way: test posts, temporary pages, anything meant only for your own reference during the work.

This is the same discipline you'd use before handing off a site you built yourself. The fact that you inherited the site doesn't change what you should leave behind when you're done. If anything, it's harder, because you're dealing with things you created during the job and things that were already there.

Noshi-Kanamer

This workflow is also why I added Site Check to Noshi-Kanamer. It scans every installed plugin, active or inactive, against WordPress.org and flags the ones that haven't been updated in 6 months or a year, so I don't have to open each plugin's WordPress.org page one by one. Then, before I hand the site back, I use Pre-Launch to check indexing, WP_DEBUG, debug.log, the default admin username, and a few other loose ends. It generates a plain-text report I can keep for myself or hand to whoever I'm delivering the work to.