What do you check first when taking over an unfamiliar WordPress site?
Asked by
MellowPine47
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 change, so I've developed 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. Missing access is surprisingly common. What checks have saved you from breaking something on day one?
Answers
Before touching anything, inspect wp-config.php for every define(), especially WP_HOME, WP_SITEURL, custom upload paths, disabled updates, database settings, and unusual constants. Hardcoded URLs can make a staging copy point back to production or even get indexed under the wrong hostname. I also compare the staging database and files with production instead of assuming the copy is current.
Reply to this answer
Find out who controls more than just the hosting account: domain registrar, DNS, SSL, email delivery, SMTP, scheduled tasks, cron jobs, webhooks, and third-party integrations. Password resets, contact forms, store notifications, exports, and other business-critical processes may depend on accounts nobody documented. I also review recent cron activity before disabling plugins.
SilverNook27: Domain ownership deserves priority status. If the former agency still controls the registrar or renewal, the site isn’t truly under the client’s control, no matter how well the hosting account is documented.
Reply to this answer
Finally, determine whether the site should be repaired or rebuilt. An abandoned theme with dozens of obsolete plugins may be safer to migrate than to keep patching, but first read the custom code and map the hidden business logic. Page-builder content, custom post types, fields, shipping rules, discounts, and tax behavior can be buried in the theme or plugins. I also inspect the rendered HTML, structured data, canonical tags, and search indexing, because inherited SEO mistakes may not appear anywhere in the admin screens.
Reply to this answer
Check every caching layer before assuming an edit didn’t work. There may be a page-cache plugin, object cache, a CDN, or several stacked together, and some of them won’t be visible in the admin area. I also inspect response headers to see what is actually serving the request. Before promising a backup, check the database and uploads size, then download and open an archive or test a restore. A backup that has never been verified is mostly just optimism.
MellowPine47: The restore test is a great addition. I’ve started unpacking at least one archive before making changes, since a successful backup message doesn’t prove the job completed.
Reply to this answer
I review all administrator accounts immediately, including old vendor or developer accounts. Rescue sites often contain forgotten access that could be a security problem. I also check license keys and update availability for premium plugins and themes; expired licenses can leave a site running vulnerable, outdated code without any obvious error.
MellowPine47: I used to check admin accounts only after something seemed suspicious. Moving that near the top of the list now—an unexplained vendor account can be either legitimate support access or something much worse.
Reply to this answer
Add your answer
Answers are reviewed before publication.
MapleCrown5: Canonical URLs and staging indexing are easy to miss because the site can look completely normal. Checking those constants and the rendered HTML early prevents a lot of delayed surprises.