The URLs do not move unless they need to.
An established site has a search footprint that took years to build. The migration treats it as something to carry rather than something to rebuild, and the work is inventory before anything else happens.
What is promised
Care, not rankings.
A migration can affect search performance. Anyone who tells you it cannot is either not being careful or not being straight with you, and the honest position is narrower than a guarantee: every part of the existing footprint is inventoried, carried deliberately and verified, so that nothing is lost by accident. Google still gets a vote.
What that buys you in practice is that when something does move, it moved because somebody decided it should, and there is a record of the decision.
Before the rebuild
Inventory first. Everything else depends on it.
-
Every URL the site answers on
Taken from the sitemap, the CMS, analytics and the server logs where they are available, because each of those knows about URLs the others do not. Paginated archives, tag pages and old campaign paths are usually where the surprises are.
-
Titles, descriptions and canonicals
Captured per URL as content, then carried across. Regenerating them from a template is how sites quietly lose a year of hand-written metadata.
-
Structured data already being emitted
Whatever the pages declare today is recorded and rebuilt to match, rather than replaced with a default set that happens to be easier to generate.
-
Internal linking
Which pages link to which. The rebuilt site should link the way the old one did unless there is a reason to change it, and re-pointing links is not something an export does.
-
Indexability as it stands
What is noindexed, what is blocked, what is canonicalized elsewhere. Some of it is deliberate, some of it is an accident nobody noticed, and the two get separated before the move rather than copied forward wholesale.
Around the cutover
The checks that happen while it is still cheap.
- Redirects are written for every URL that changes, including ones nothing links to any more, and tested against the real list rather than a sample.
- The new sitemap is compared against the old URL inventory before DNS moves, so anything missing is found while it is cheap to fix.
- Robots rules and canonicals are checked on the built output, not on intent.
- Analytics and consent are verified firing on the new site before the old one stops serving.
- After cutover, coverage and crawl behavior are watched rather than assumed, and the redirect map is corrected as real traffic finds the gaps.
Where sites actually lose traffic
It is rarely the thing people worry about.
Teams worry about the homepage and lose the long tail. The damage in a bad migration is usually a few hundred old URLs nobody inventoried, a rich text field that dropped its headings, or an entire paginated archive that stopped existing. None of those are visible on the pages anyone thinks to check on launch day, which is exactly why the inventory comes first.
Reach out and see if we are a good fit.
Currently booking two to four weeks out.