Migrations lose traffic for two reasons, and neither is the new design. Either the redirect map is incomplete, or several changes shipped at once and nobody can tell which one caused the drop. Everything below exists to prevent those two.
If you are already choosing a contractor rather than reading up: here is what we do for adult hosting and infrastructure.
Change one thing at a time
A replatform, a redesign, a URL restructure and a host move are four migrations. Shipping them together turns a recoverable problem into an unreadable one. Sequence them, with two to three weeks between, and each step is diagnosable.
If the calendar does not allow that, at minimum separate the URL change from everything else. URLs are what search engines hold; the rest they re-crawl.
Build the redirect map from data, not from the sitemap
The sitemap lists what you think exists. The redirect map must cover what actually earns:
- Every URL with impressions in the last twelve months, from Search Console.
- Every URL with an inbound link, from any backlink source you have.
- Every URL in server logs that returned 200 in the last ninety days - this catches the pages nobody remembers.
- Both the extensionless and legacy forms if the site ever served both.
Deduplicate, map each to its closest equivalent, and refuse the temptation to point everything at the homepage. A redirect to an irrelevant page is treated as a soft 404 and passes nothing.
Freeze list
Things that must not change in the same release as the URLs: title patterns, the internal linking structure, the age gate implementation, and robots rules. Each is a variable that will confound the reading afterwards, and the age gate in particular has taken sites out of the index during migrations that were otherwise clean.
Order of operations
- Crawl the old site fully and store the result. This is the baseline you will diff against.
- Build and test the redirect map on staging, asserting one hop to a 200.
- Ship, keeping the old host reachable until DNS has fully propagated.
- Submit the new sitemap; leave the old one available for a few days rather than deleting it.
- Crawl again and diff against the baseline. Every URL that changed status needs an explanation.
- Watch index coverage daily for two weeks, then weekly.
Adult-specific traps
The age gate. If the new implementation renders before content, the crawler sees a splash screen on every URL and the site drops out within weeks. Fetch as the crawler on staging and read what comes back.
Payment webhooks. Processor callbacks point at absolute URLs. Miss one and rebills fail silently - a revenue outage that is invisible in analytics and shows up as churn a month later.
Host suspension mid-migration. If the new host has not been told what the content is, the migration can end with a suspension. Confirm the abuse policy in writing before moving, not after.
What normal looks like afterwards
Expect a dip. A clean migration on a site of a few hundred URLs typically loses ten to twenty per cent of impressions for two to four weeks and recovers. What is not normal is a drop that keeps deepening in week three, or index coverage falling rather than churning - both point at the redirect map or the gate, and both are worth stopping to fix rather than waiting out.
Testing the redirect map before it ships
A map that has not been tested is a hypothesis. Assert three properties across every entry, mechanically rather than by sampling:
- One hop. Old URL returns 301 straight to a 200. Chains lose a share of the signal at each step, and chains appear whenever two migrations overlap.
- Right target. The destination is the closest equivalent page, not a category page and not the homepage. An irrelevant destination is treated as a soft 404.
- No loops. Trivially created by a trailing-slash rule meeting a case rule, and they take a page out of the index entirely.
Run the assertion on staging, then again in production within the hour of going live. Both runs matter: the second catches rules that behave differently behind the real edge configuration.
What to keep from the old site
Three assets are easy to lose and expensive to rebuild. The URL inventory with its performance history, which is the only record of what the site actually earned. The old sitemap, which stays useful for weeks while the engine reconciles. And a full crawl of the old site stored offline - the baseline you diff against when something looks wrong three weeks later and nobody remembers the previous structure.
Communicating with the crawler afterwards
Submit the new sitemap and leave the old one reachable rather than deleting it - a 404 on the old sitemap removes the map the engine is still working through. Where the platform offers a change-of-address signal for a domain move, use it; it is the only direct way to say what happened. And keep robots.txt unchanged during the migration window, because a rule that widens during a URL change produces exactly the symptom everyone panics about.
A realistic timeline
| When | What is normal | What is not |
|---|
| Days 1-3 | Crawl spike, mixed old and new URLs in reporting | Indexed count falling sharply |
| Week 1-2 | Impressions down 10-20%, positions unstable | Impressions near zero on the main pages |
| Week 3-4 | Recovery begins, new URLs replace old in reporting | The drop still deepening |
| Week 6-8 | Back to baseline or better | Flat at the reduced level |
The right-hand column is the point of the table. Waiting out a normal dip is correct; waiting out an abnormal one costs months, and the two are distinguishable within a fortnight if somebody is actually looking.
Common questions
How long should a migration dip last?
Two to four weeks on a site of a few hundred URLs, with impressions ten to twenty per cent down before recovery. A drop that deepens in week three is a redirect or crawlability problem, not a normal dip.
Can we redesign and change URLs at the same time?
You can, and then you cannot diagnose what went wrong. Separate the URL change from everything else by two to three weeks; URLs are what search engines hold, the rest they simply re-crawl.
What is the most commonly missed item?
Payment webhooks. Processor callbacks point at absolute URLs, and a missed one makes rebills fail silently - invisible in analytics, visible as churn a month later.
Related reading