A long-established business asked us to look at their website before deciding what to do with it. The site works. It has worked for years. Everything below was found by reading the server, not by browsing the site.
The web root had four WordPress installations in it
One live site, and three more sitting in subdirectories: an old staging copy, and two abandoned installs left behind by earlier rebuilds. Different WordPress versions, some pointed at databases that no longer exist.
The one that matters is the staging copy, because it answers on the public internet. A request to it returns a page. That is not hypothetical. It is a second, older, unmaintained WordPress that anybody can reach, sitting inside the same web root as the live one.
We reported exactly that and no more. We confirmed it responds. We did not confirm what it renders, and the distinction matters, because “there is a reachable install here” is a fact you can act on, while “there is a working second site” is a claim we had not earned.
Abandoned installs are one of the most common things we find on long-lived hosting, and they are almost never in anyone’s mental model of the site. Nobody decided to leave them there. Each one was simply the safest thing to do on the day.
The content estimate had been wrong for years
Everyone involved believed the site held far more articles than it actually did, and that belief had shaped every estimate anyone had made about migrating it.
The inflation came from revisions. WordPress saves one every time anyone touches anything, and after fifteen years there were tens of thousands of them, sitting in the same database table as the articles themselves. Count the table and you get a frightening number. Count what is actually published and you get a manageable one.
This is worth being blunt about. The difference between those two figures is the difference between a project worth doing and one that is not. A rebuild had probably been deferred for years on the strength of a number that was never real.
A second miscount, in the other direction
An earlier crawl had turned up pages that a database query said did not exist, which usually means the crawl is wrong.
It was not. They were custom post types, separate content types set up years ago for different service categories, and the query had only counted ordinary pages. The crawl had been right the whole time and had been quietly distrusted.
When two counts disagree, the useful question is what each one is actually counting. Usually neither is broken. They are answering different questions.
The page builder locked less than expected
The site was built with a page builder, and the working assumption was that this made the content unmovable, because builder markup is stored inside the content itself and does not survive leaving the builder.
Checking, rather than assuming, changed the picture. The markup appeared in roughly two thirds of the ordinary pages, and in none of the articles or the service entries. The bulk of the content is plain content.
That is a narrow finding and we kept it narrow. It shows where the markup is, not that a migration will be smooth. But “the articles are locked in” had been treated as settled, and it was not true.
Findings are only useful if they can be checked
Every finding here traces to a query or a screen we can point at. That mattered on this job, because two of our own early claims were wrong in checkable ways, and both were caught before the client saw them.
An audit that cannot be re-run is an opinion. The point of writing one down is that the next person can disagree with you using evidence.
None of this happens to a maintained site
Every finding above is what fifteen years of nobody owning the server looks like. The abandoned installs, the stale copy left publicly reachable, the database nobody has pruned, the version of WordPress that stopped moving because a plugin blocked the update. Each one was reasonable on the day it happened. Together they are a site that no longer matches what anyone thinks it is.
That is the job a Care Plan does. WordPress core, themes and plugins kept current, the server underneath them patched and hardened, backups taken and actually tested, old installs removed rather than left in place, and someone reading the results each month. Drift is not dramatic. It is just what happens by default.
We do discovery of this kind before any rebuild or migration quote, as project work. If you have a site nobody fully understands any more, get in touch. The audit is worth having even if you decide to change nothing.