Domain migration is one of the riskiest SEO operations. One wrong step and traffic falls 60β80% for months, recovery taking half a year. Done right, migration causes a 5β10% dip for 2β3 weeks, after which the site returns to prior positions and often outperforms them. The gap between "disaster" and "routine" comes down to one thing: 301-redirect quality and how fast search engines are informed. This article is a 30+ point checklist: what to do before, during and after migration, how to monitor it and how to roll back if needed.
Preparation: 2β4 weeks before migration
- Full crawl of the old site with Screaming Frog or Sitebulb β record every URL currently returning 200.
- Export all keywords from GSC and Yandex Webmaster for the last 90 days β your post-migration baseline.
- Top-100 pages by organic traffic β track these especially closely.
- Redirect map: every old URL β its new URL. In Excel or CSV. Each row: old_url, new_url, http_status_target.
- Verify the new domain in GSC and Yandex Webmaster in advance β ownership verification can take a few days.
- Prepare an updated robots.txt and sitemap.xml on the new domain β but don't let engines into the index until the actual switchover.
URL map: the core migration document
The redirect map is the single most important artefact of the entire migration. Every old URL must map to a precise counterpart on the new domain, and the redirect must be 301 (permanent, passes link equity). Not 302 (temporary, no equity), not 307 (engines don't treat it the same), not meta-refresh (SEO disaster). If URL structure changes (e.g., /category/product becomes /shop/category-product) the map gets more complex but stays 1:1. You absolutely cannot bulk-redirect old URLs to the new homepage β that signals engines that pages lost meaning and link equity zeros out. If an old URL has no logical new counterpart, return 410 Gone, not a 301 to the homepage.
Server-side technical setup
At the nginx (or Apache) level you set up a `return 301 https://newdomain.com$request_uri;` rule or a more detailed `map { ... }`. Test with `curl -I -L https://olddomain.com/some-page` β expect one redirect to the final new-domain URL, no redirect chains (old β redirect β redirect β new). HSTS stays on the new domain with the same parameters. SSL on the new domain must be valid before switchover, not "in progress". You cannot disable SSL on the old domain β the redirect must run for at least 6 months, ideally 12. Engines keep visiting old URLs for a long time.
Migration day: step by step
- Turn on 301 redirects from the old domain to the new one. Pick a low-traffic window.
- Open access for engines on the new domain β remove Disallow: / from robots.txt, set meta robots index, follow.
- Submit the updated sitemap.xml to GSC and Webmaster for the new domain.
- In GSC: "Change of address" β officially notify Google of the move. Settings β Change of address. Without this, indexing is slower.
- In Yandex Webmaster: Main mirror β point to the new domain. Critical; without it Yandex may treat the old domain as "real" for months.
- Run a Screaming Frog crawl of the new domain β all URLs return 200, no accidental 404s.
Monitoring: the first 4 weeks
What to track: positions on the top 100 commercial queries, organic traffic in GA, indexed-page counts in GSC and Webmaster, 404 errors in crawl reports. Normal picture: days 1β7 positions "wobble", some drop 5β15 places, week 2 they start recovering, by week 4 they're at or above pre-migration levels. Red flags: traffic > 30% down and not recovering; a massive "Soft 404" series in GSC β Google doesn't trust your redirects; a Webmaster main-mirror change warning that doesn't self-confirm β you need to upload a verification file manually. Site Metrics Tool tracks all of this and alerts on deviations > 15%.
If things go wrong: rollback
A rollback is technically possible but expensive: after 7+ days of redirects, engines have started treating the new domain as canonical. Fully reverting takes 4β8 weeks. If traffic crashed and rollback is needed: disable the 301s; on the new domain set up 301s back to the old (double rollback); file another "Change of address" in GSC/Webmaster in the reverse direction; accept 6β8 weeks of "transition" status. This is an emergency procedure β avoid it by doing the migration right the first time.
Frequently asked
How long to keep redirects from the old domain?
Minimum 6 months, ideally 12. Engines keep indexing old URLs for a long time; external links to the old domain also depend on the redirect to keep working.
What if I can't preserve URL structure?
The 1:1 map still gets built, just every mapping written manually. For a large site (1000+ URLs) this takes time but is critical β without an exact map you lose rankings.
Can I migrate to HTTPS separately from changing the domain?
Better separately. HTTPβHTTPS on the same domain is simpler and less risky; changing the domain is a separate process. Doing both at once multiplies the risk.
Does Site Metrics Tool help with migration?
Indirectly β we track positions and alert on deviations. There's no "migration module" per se, but the "redirect map + our position monitoring" combo gives you an early signal if migration is off-script.