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

A developer outlines a workflow for auditing inherited WordPress sites, emphasizing the need to document the initial state, check all plugins, and verify settings like search engine indexing and debug mode before making changes. The developer also introduces Site Check and Pre-Launch tools from Noshi-Kanamer that automate plugin update checks and pre-launch audits.

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. 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. 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: 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. 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. 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. 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. 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. It's free on WordPress.org. If there's something you always check on an inherited site that I'm missing, I'd like to hear it.