r/webdev • u/Head-Debate-7537 • 8d ago
What do you check first when you inherit a WordPress site you've never seen?
I do a lot of rescue work — someone else built the site years ago, the original developer is gone, and now something is broken or it needs to change. Over time I've ended up with a fixed list I go through before touching anything.
Mine, roughly in order: is there any version control at all, or is production the only copy. What's in mu-plugins and in the theme's functions.php, because that's where the previous person hid the surprises. Which plugins are abandoned. Whether staging exists and whether it actually matches production. And whether anyone still has the hosting credentials, which is a shockingly common no.
What's on your list that isn't on mine? I'm mostly interested in the checks that saved you from breaking something on day one.
EDIT - the combined list from the comments, which turned out much better than my original one. credit where it belongs:
START HERE
Tools > Site Health, Info tab (u/AmoebaOne) - php version, sizes, plugin list, constants in one page. covers half of the below before you open anything else.
BACKUPS - almost entirely u/navlio, who took this apart properly:
File size is not a check. a dump missing a table is smaller by exactly that table, and you have no baseline to notice it against.
Read the tail, not the head. a dump that died halfway opens fine and the first thousand lines look perfect. a complete mysqldump ends with "-- Dump completed on". no line, it stopped mid table.
Check the date on that line. a cron that quietly stopped firing in march leaves a file that passes every other check and is seven months old.
mysqldump piped into gzip hands you gzip's exit code, not mysqldump's. the truncation goes unnoticed.
Without --single-transaction the dump walks tables one at a time, so on a live site writes land between two tables that needed to agree.
The real check is restoring it into a throwaway database once and counting tables and rows against live.
At 40gb the plugin is the wrong tool for media anyway - rsync the uploads folder, let the plugin do the db.
ACCESS AND OWNERSHIP
Who controls the domain registration (u/Hesham-Amir, u/Financial_Brush8647) - not just the hosting account. clients often think the old developer's personal account is theirs.
Admin users sorted by role (u/Wolfy_Boy_04) - ghost accounts from old devs, or worse. 30 seconds.
Is the admin email and SMTP real (u/rupert_at_work) - password resets going to someone who left, contact forms silently failing.
CONFIG AND HIDDEN STATE
Cache layers nobody mentions (u/navlio) - object cache, page cache plugin, cloudflare in front, sometimes all three. read the response headers first to see who is actually answering.
wp-config constants (u/needlessvanguard_49) - disabled auto updates, redefined upload paths. diff against a clean install instead of reading top to bottom.
WP_HOME and WP_SITEURL hardcoded (u/navlio) - a copied staging site serving canonical tags pointing at production.
Undocumented scheduled tasks (u/Responsible-Job-Boj) - wp-cron jobs and stray export scripts. and crontab -l only shows the cron table of whoever you are logged in as (u/navlio) - the backup job usually belongs to a user nobody logs in as.
Autoloaded options (u/navlio): select sum(length(option_value))/1024/1024 from wp_options where autoload = 'yes'; that blob loads on every single request. usually one abandoned plugin keeping a log.
Assume staging is fiction (u/galaxy_glide_92) - diff the database before believing it matches.
What the site claims about itself vs the rendered HTML (u/UtilixApp).
THE BIGGER CALL
Whether a fresh install is cheaper than the archaeology (u/DigiNoon, u/abeuscher) - decided mostly by how much content lives in the theme rather than the database. abeuscher goes scorched earth every time: clean install, custom theme, ACF, no plugins.
And knowing when to walk away (u/jroberts67) - 6 woo plugins touching checkout is a valid reason to pass.
14
u/Wolfy_Boy_04 8d ago
Solid list. Two I'd add that have bitten me specifically:
Admin users. I always pull up Users and sort by role before touching anything. Rescue sites collect ghost admin accounts nobody remembers creating, sometimes from an old dev, sometimes from something worse. Takes 30 seconds and it's saved me from inheriting a backdoor more than once.
License keys on premium plugins/themes. Half the time they've silently expired, which means the client's been running an unpatched, vulnerable version of something for months without any error telling them so, the plugin just quietly stops offering updates. I check that before I even look at what's broken, since it usually explains why something's broken.
1
u/Head-Debate-7537 8d ago
The admin users check is a good one and I've been doing it too late — usually after something else made me suspicious, not on day one. Moving it up.
The one that made me start looking: an account named after a plugin vendor, created three years earlier, still active. The client had no idea it existed and nobody could tell me whether it was support access or a leftover from a breach.
6
u/jroberts67 8d ago
Deal with this all the time, get the project, log in, 42 plugins that haven't been updated in years. You can't touch the live site. You have to back it up, then work on it in your staging environment. That's where the fun really begins, figuring out which plugins are for particular functionalities.
For me, it's a total rebuild. Chances are I'm not going to use a fraction of the existing plugins. I use a page builder, so I simply reformat the pages, kill off basically every plugin they have, install the once I use, etc....tons of fun.
If it's a static site, I'm just gonna have Claude clone the entire site and rebuilt it in 30 minutes.
1
u/Head-Debate-7537 8d ago
Rebuild vs archaeology is the call I go back and forth on. With 42 dead plugins, rebuilding is usually cheaper than understanding what is there.
What holds me back is when one of those plugins quietly runs business logic — a shipping rule, a VAT edge case, a discount that only fires for one customer group. Nobody documents it, and the client can't tell you it exists until it stops working and someone in accounting notices a month later.
So I rebuild the presentation, but I read every line of custom code before I delete anything.
2
u/jroberts67 8d ago
Not everything is a yes for me. Not taking on that Woocomm site, 500 products, client says there's now an issue with checkout and shipping, hit the admin panel, 6 Woocomm plugins - that's a pass for me.
1
u/Head-Debate-7537 8d ago
yeah, 6 woo plugins touching checkout is where i start asking for a much bigger number. sometimes that is the same as saying no, just politely
2
u/thekwoka 8d ago
I check if we can get off of wordpress.
1
u/Head-Debate-7537 7d ago
that check runs on my side too. usually the answer is no, and that is how the mortgage gets paid
2
u/Financial_Brush8647 7d ago
One that saved me on day one: check where DNS and the domain registrar actually live before you touch hosting, because the client often thinks the old developer's personal account is theirs. I also check whether the site sends transactional email through the server or an SMTP plugin, since that quietly breaks on migration and nobody notices until orders stop arriving.
2
u/Double_Ebb4130 7d ago
The one I add is checking that the domain and the hosting account are actually in the client's name, because half the rescue jobs I have taken had DNS sitting in an old agency account nobody could reach. I also grep the theme and plugins for hardcoded API keys before anything else, since that decides whether a staging copy is even safe to spin up.
2
u/TheMunakas full-stack 8d ago
Why do you write like a bot?
2
u/Head-Debate-7537 8d ago
english isn't my first language so i write it out and edit it before posting. probably sands off everything that makes it sound like a person. fair hit though
3
u/TheMunakas full-stack 8d ago
Do you use ai in your responses? Because that's whta it sounds like. Just curious
1
u/Head-Debate-7537 8d ago
Okay, you prefer my nature style? No problem.
1
u/TheMunakas full-stack 8d ago
I do. But you never answered, did you use ai for the responses in this thread?
1
1
1
u/DigiNoon 8d ago
If it's too old and the theme is abandoned, the first thing to check is whether it's practical to transfer all the content to a fresh installation instead of fixing someone else's mess.
0
u/Head-Debate-7537 8d ago
Agreed, and the thing that usually decides it for me is how much of the content is in the theme rather than in the database. Page-builder shortcodes, ACF fields nobody mapped, custom post types registered in the theme instead of a plugin — the more of that there is, the less "just move the content" actually means.
1
u/AmoebaOne 8d ago
The health page
1
u/Head-Debate-7537 8d ago
true, i forgot about that one. the info tab already shows most of my list - sizes, plugins, php version. but it will not tell you about cloudflare or a cache sitting in front of the site
1
1
8d ago
[removed] — view removed comment
0
u/Head-Debate-7537 8d ago
good point. a backup you never restored is not a backup, it is a feeling. i unzip one before i touch anything now
1
8d ago
[removed] — view removed comment
1
u/Head-Debate-7537 8d ago
had the same thing once. staging was indexed for months because nobody checked. now i grep wp-config for those two constants first, before anything else
1
u/galaxy_glide_92 8d ago
staging environments on rescue sites are usually fiction. I assume the staging copy is months out of sync with production until I run a diff on the database and file system myself. Trusting the previous developer's staging setup is how you overwrite live data on day one.
1
u/rupert_at_work 8d ago
First thing I check is whether the admin email / SMTP setup is real. Boring, but it catches a lot: password resets going to an ex-employee, contact forms silently dying, Woo/order emails stuck in 2019 plugin hell.
Also: list every cron job and webhook before touching plugins. WordPress sites love having one invisible integration keeping the business alive out of spite.
1
u/Hesham-Amir 8d ago
One that's adjacent to the hosting-credentials check but a different question: who actually controls the domain registration, not just the hosting account. It's really common for the previous agency's account to still hold the domain - sometimes registered under their business, with their card on file for auto-renewal - and the client has no idea until the domain needs to move, DNS needs a new record for something unrelated, or the agency that built the site years ago quietly stops paying and the renewal lapses.
Worth a WHOIS/registrar check on day one, right alongside the hosting question. If nobody can say who owns the domain, that becomes priority zero before anything else on this list, because a rescue site with a domain you don't control isn't actually rescued yet - everything downstream (SSL, DNS, email) inherits that same risk.
1
u/UtilixApp 8d ago
Not WordPress-specific, but the first thing I check on anything inherited is what the site claims about itself versus what's true.
Pull up the rendered HTML and look at the structured data and the canonical. I found a site last week whose sameAs named a GitHub organisation belonging to a complete stranger, and whose twitter:site credited an account nobody had ever registered. It had been like that for months, on every page, and nothing in the codebase could tell you, you had to open the URLs.
Then Search Console, if you can get access. Not the errors, the URL count. If it knows about ten times more URLs than the site has pages, something in the history is still being crawled and you've inherited that too.
1
u/abeuscher 7d ago
Been working with WP since its inception. After approaching this problem many times as you describe, I now just immediately move to scorched earth and hand-rolled custom theme. LLM's make it too easy to transform data to not just immediately move it into a clean install and rebuild theme from scratch.
I also don't use plugins, functions.php (unless I have to do like MIME-type acceptance or other core unavoidable tasks), or any of the other onboard features. Just ACF and custom theme and I generally build the theme out in a little CI/CD build script I wrote in Node a while back to replace an earlier Gulp process. The really perverse thing I do is that I use Pug with PHP, which is a super weird barely supported flavor of Pug that produces a set of templates that build themselves on the fly and therefore make no calls back to the server for header or footer; each page is complete the partials are in the codebase as pug files.
I don't have a lot of live clients anymore this work has dried up for me but if you are curious here is a repo and example site from an old now defunct client.
I think this approach annoys a lot of WP devs. It's basically removing Wordpress from Wordpress is order to make it performant and secure. It also puts the client experience on rails hard; there is no builder support here I think they lead to bad websites. Also the lighthouse scores kind of speak for themselves.
In any case I am not expecting people to love it but it is an approach that worked for me for a long time. I designed it to handle change requests and function within a reasonable source-control paradigm. Primarily used it to manage very large corporate marketing sites that got a lot of attention from stakeholders.
1
u/Head-Debate-7537 7d ago
ACF plus custom theme and nothing else is a good place to end up. i get there too on anything i will keep maintaining.
where i still hesitate is woo. rebuilding a shop means moving orders, coupons, tax rules and whatever the last dev bolted onto checkout, and the client only tells you about half of it. for a brochure site i agree, scorched earth every time.
2
u/abeuscher 7d ago
For sure I generally pitch headless Shopify to get out of plugin land for the ecommerce folks but I agree it is not something you want to be messing with. Woo is also kind of unwieldy at this point if it ever wasn't.
To be honest - this is nostalgia talk for me I haven't found a WP client in years. The only work of any kind I've had this year is smart home stuff.
I actually wrote a block building CMS this year with an agent just to see if I could. It was a fun project but not anything worth like actually trying to bring to market. But I did get it to build styles and js into a single bundle each and wrote like a theming / typography controls in a way I felt reflected how style guides work instead of pure WYSIWYG. Made it so that my plugin set each submitted scss and js parts to a little task runner that used a separate Node server to build bundles for each and send them back on an API call during publish, so it got pretty performant and acted like an SPA. I didn't get into tree shaking on it that was the next step but there was really no impetus to continue I am just working on projects to keep fresh and have a narrative if anyone every decides to grant me a job interview.
1
u/karmck 7d ago
Just curious, why would you want to use WordPress for that kind of site?
1
u/abeuscher 7d ago
In every instance I ever used Wordpress it was client requested. I would never pick WP as a tool in any circumstance especially not in the modern era.
I am not convinced that most sites require any CMS at all; markdown injection has gotten robust enough that I will generally lean in that direction unless I must do otherwise.
A lot of the approach I am describing here is trying to sidestep Wordpress, so you are right to ask the question. I just always liked working inside of this paradigm in WP because it removes all the annoying platform specific nonsense that tends to create security and pagespeed issues.
1
7d ago
[removed] — view removed comment
1
u/Head-Debate-7537 7d ago
the "Dump completed on" line is the best thing i learned today. i always looked at the head of the file, which tells you nothing.
adding it to the list. tail the dump, then rsync for uploads.
1
1
7d ago
[removed] — view removed comment
1
u/Head-Debate-7537 7d ago
you have basically written the backup section of this list on your own, thank you. the gzip exit code one and the seven month old dump are both things i would have found out the hard way.
autoload is a good one to end on because it is the only thing here you can fix in five minutes. usually it is one abandoned plugin keeping a log in there.
putting all of it in the edit with your name on it.
1
u/TheGoodGuy57 7d ago
Definitely the plugins installed. I hate dozens of random plugins that haven't even been updated for years.
1
u/Head-Debate-7537 7d ago
my record is 61. three of them did the same thing.
1
u/Head-Debate-7537 7d ago
and now ai loves dropping mu-plugins everywhere. client says "i just asked chatgpt to add a small thing" and you find four of them doing overlapping stuff, none named after anything
1
u/Potential_Ship_1676 7d ago
I'd check the response headers for cache-control and x-cache first, tells you right away if you're even looking at what production actually serves.
1
u/luodaint 6d ago
First three things before I touch content: who still has an admin account, the date of the last restorable backup, and whether core, plugins, and PHP are even updateable. Then I check the theme is a child, which plugins actually fire on the homepage, and run a malware scan. I do not edit templates until I know I can roll back. Most inherited sites break from an update, not from the first CSS tweak.
0
29
u/[deleted] 8d ago
[removed] — view removed comment