I do a lot of rescue work on WordPress sites that were built years ago by developers who are no longer available. Usually something is broken or the site needs a major change, so I follow a checklist before touching production: look for version control, inspect mu-plugins and functions.php, identify abandoned plugins, verify whether staging exists and matches production, and confirm that someone still has the hosting credentials. What other checks have saved you from breaking an inherited site on day one?
4 Answers
Inspect wp-config.php line by line, especially every define(), along with cron jobs, webhooks, scheduled exports, and SMTP settings. Hardcoded WP_HOME or WP_SITEURL values can make a staging copy use production URLs and even become indexed. SMTP problems can send password resets to former employees or leave contact and order emails silently failing. Also verify who controls the domain registrar—not just the hosting account—because DNS, SSL, email, and renewal all depend on it.
Review the Users screen before changing anything. Old rescue sites often contain forgotten administrator accounts, including accounts created for former developers, vendors, or support access. I also check license keys for premium plugins and themes, because expired licenses often mean the site has quietly missed security updates for months.
I usually checked admin accounts only after something looked suspicious, but that is too late. An unexplained vendor-style administrator account can remain active for years, so I am moving the user audit to day one.
Check every caching layer before assuming an edit failed. There may be a page-cache plugin, object cache, a CDN, or several of them stacked together. Response headers can reveal which system is actually serving the request. I also check the database and uploads size before promising a backup, then download and open one backup archive—or better, test a restore. A backup job that times out can still report success.
The restore test is a great addition. A backup you have never restored is really just a feeling, so I am moving that much earlier in my checklist.
Do not assume the existing staging environment is trustworthy. Treat it as out of date until you compare the database and filesystem with production. Before deleting old plugins or rebuilding the theme, map what they actually do: business rules, custom post types, page-builder content, ACF fields, shipping logic, discounts, and integrations may be hidden in places nobody documented. Rebuilding the presentation can be sensible, but read the custom code and identify the real dependencies first.
The decision between rebuilding and preserving the site usually comes down to how much functionality is embedded in the theme or obscure plugins. Moving content sounds simple until those hidden fields and rules are involved.
I have seen staging sites indexed for months because those URL constants were never checked. A ten-second config review can prevent a surprisingly expensive cleanup.