The message that arrives two weeks after a new site launches is always the same: traffic dropped, what happened. The answer usually comes down to one thing: the old URLs were never properly connected to the new ones.
That loss is avoidable. The list below is the order we follow in migrations. Applied to the end, the drop either does not happen or recovers within a few weeks.
Before the move
1. Build a URL inventory. List every crawlable address on the current site. Three sources: a site crawl, the performance report in Search Console, and server logs. Do not trust the sitemap alone; pages that are not in it but do receive traffic always turn up.
2. Mark the valuable pages. Pages with traffic and inbound links come first. If a page has earned an external link, that link has to survive the move.
3. Record current performance. Write down organic clicks, impressions and conversions for the four weeks before the move. Without a baseline, arguing about whether there was a drop is pointless.
4. Prepare the URL map. Old address, new address, matched one to one. Redirecting everything to the homepage is the single biggest cause of loss; Google usually treats it as a soft 404.
5. Decide on pages with no equivalent. If a page has no counterpart on the new site, there are two options: redirect to the closest parent category, or deliberately return 410. Random redirects drop users onto irrelevant pages.
Launch day
6. Set up the 301s. Use permanent redirects, not 302s. Avoid chains: the old address should go straight to the final one, without two stops in between.
7. robots.txt and sitemap.xml. Make sure the new robots file does not block crawling. The sitemap should only contain addresses you want indexed that return 200. Keeping the old sitemap live for a while helps the crawler revisit old URLs and see the redirects sooner.
8. Check for staging noindex. One of the most expensive mistakes: a noindex tag carried from the development environment into production. Search the source of your main templates before going live.
9. Domain, SSL and the www decision. Choose one preferred version; http, https, www and non www should all resolve to a single address. Have the certificate ready on the day, because half finished SSL means direct loss of access.
After the move
10. Watch indexing in week one. Add the new site in Search Console and submit the sitemap. Monitor excluded pages in the coverage report, and use the change of address tool where it applies.
11. Hunt 404s. Scan server logs and analytics. Catch which old addresses crawlers and users are hitting and falling into nothing, and add the missing redirects in the first week. This step alone recovers most of the loss.
12. Compare performance and conversion. Measure against the baseline from step three. If traffic falls while conversion holds, the problem is elsewhere; if both fall, something is missing on the redirect or indexing side.
If the platform changes too
When the stack changes and not just the design, the list grows. On the e-commerce side we also check:
- Product data: whether stock codes, variant structure and the category tree map one to one on the new platform
- Channel integrations: marketplace and carrier connections get rebuilt, and nothing goes live before a test order passes through
- Customer accounts: if passwords cannot be migrated, the reset flow has to be ready or support gets buried on day one
- Order history: visibility of past orders is needed for returns and invoicing
- Payment provider: gateway settings and the 3D flow must be tested on the day of the move
None of these are SEO items, but if one fails the migration becomes a bigger problem than lost traffic.
The first 30 days
A migration is not a single day, it is a month long process. We plan the calendar like this:
- Day 1: redirects, sitemap, robots and noindex checks; first crawl
- Days 2 to 7: daily 404 checks, adding missing redirects, watching the indexing report
- Week 2: first comparison of organic clicks and conversion rate
- Week 3: page by page review of anything that has not recovered
- Week 4: closing report on what came back, what did not, and why
In migrations run without this calendar, problems tend to surface six weeks later, and by then finding the cause is far harder.
What gets lost most often
- Category filters: old filter URLs get forgotten and all return 404
- Blog posts: the URL structure changes and nobody maps the old ones
- Images: when image URLs change, traffic from image search disappears
- Pagination: second and third pages never make it into the map
- Language versions: hreflang tags keep pointing at old addresses
Who should own the migration
Migrations that go badly share one trait: nobody owned them. The agency waits for redirects from the developer, the developer waits for the list from the agency, and launch day arrives.
Give it a single owner. That person carries the list, writes down who does what and when, and makes the go live call. Content and campaign changes should also be frozen during migration week; if five things change at once, nobody can trace the drop.
One last suggestion: migrate midweek. Migrations done on a Friday evening get noticed on Monday, and two days are lost in between.
When it recovers
Depending on site size, it takes a few weeks for the crawler to see every redirect. Fluctuation in the first days is normal. If there is still no recovery in week three, the problem is not the migration itself but most likely a missing redirect or an indexing block.
Open this list a week before the move and tick the items one by one. A list prepared on launch day is not worth as much as one prepared before it.