Deciding whether to migrate or rebuild

Default to moving the site as it stands. A straight move changes the machine underneath and nothing a search engine can see, so it has one class of failure and you can rehearse it. A rebuild changes URLs, markup, copy and internal linking at once, and if visibility falls afterwards you will not be able to say which change caused it. "It needs a refresh anyway" is a good reason to schedule a rebuild. It is not a reason to run one inside a move.

Five questions that decide it

Count the columns. Four or five on the left, move it and leave the refresh for later. Four or five on the right, rebuild, but treat that as its own project with its own launch date. A split verdict, which is the common case, means move now and rebuild after.

The two risks are not the same size

Migration risk is operational and short lived. A path breaks, mail stops, a certificate does not cover a hostname. You find those within hours if you check properly, and each is fixable the same day. Rebuild risk lands weeks later, as a slow decline rather than an error, and is ambiguous by nature. What a rebuild puts in play:

• The URL set itself, including pagination, parameters and old paths that still receive links.
• Body text that already earned its position, replaced with copy that reads better to you and matches fewer queries.
• The internal link graph, which usually shrinks when navigation gets tidied.
• Image filenames, alt text and any structured data that survived by accident.
• Rendering: a front end that defers content into scripts is a different page to a crawler than the flat markup it replaced.

Run both at once and every one of those becomes a candidate explanation for whatever the numbers do next.

Keeping them separable

1. Move the site unchanged and verify it against the checks under launch playbooks before anything is public.
2. Let it run two to four weeks. That period is your baseline, and it also proves the destination behaves.
3. Build the replacement on staging at the new host, with a URL map drawn from real logs rather than from the sitemap.
4. Launch the rebuild on its own day, redirects in place one to one, watched with the same measurements you used for the move. Anything that then goes wrong belongs to diagnostics with a short suspect list.

When rebuilding first is the honest answer

• The current site cannot run at any destination you would accept, so copying it forward is not actually available.
• It has been compromised and you cannot state with confidence what is in the files.
• Restoring it would mean recreating a build environment that no longer exists.
• Organic history is thin enough that there is little to protect, as with a young site or one that lived on paid traffic.

The uncomfortable version: a site can be genuinely bad and still be earning, and the earnings usually sit in the parts a rebuild is most likely to discard. The cruft argument feels decisive because the plugin list is visible and the value is not, so audit against real traffic before accepting it. If you do rebuild, pick the destination for what the new build needs rather than what the old one tolerated, starting from platform requirements and not from the current bill.