When a site is worth replacing instead of repairing

The platform owns your top problems — can you fix it without changing platform? If not, replace. The business changed shape: new services, new areas, new buyer — replace or extend. Nobody can safely update it, because the dependencies are too old to patch in place — replace. Or it was never indexed properly, checked in the page indexing report — repair first.

In our experience the fourth row is the one that stops rebuilds from being necessary. A site whose pages are not indexed does not have a design problem, and replacing it without fixing the cause reproduces the cause at new URLs.

Whatever the trigger, the URLs are the asset. Google's guidance on site moves with URL changes treats mapping old addresses to their new equivalents as the baseline of a migration.

Three things to insist on before anything is switched off: a crawl of the live site, because it is the only record of what existed; a URL map, old to new, one to one rather than everything to the homepage; and verification after deploy, in Search Console rather than by eye.

And a rebuild does not reset the content problem. If the old site ranked badly because it answered less than the competition, a new one answers the same amount in a better typeface.