Most ranking loss after a migration does not come from the migration. It comes from the fact that nobody wrote down what the site looked like before it moved. Within 48 hours of launch the old URLs are gone from staging, the redirect map is half-finished, and nobody can answer the question "did we used to have a page for that?"

This checklist covers the three migration types that cause real damage: a new domain, a redesign or re-platform, and a URL structure change. The order below is deliberate. The inventory step comes before any code is written, because it is the only step you cannot reconstruct later.

Inventory the current site before anything moves

Export every URL that has ever earned anything. Pull at least these five lists:

All URLs with impressions or clicks over the last 12 months, exported from Search Console performance.
All URLs currently in your XML sitemap.
All internal URLs from a full crawl of the live site.
All URLs pointing at you from your backlink profile.
All URLs that return 200 today, from a complete status sweep. Our bulk status code checker runs a list and exports the results to CSV.

Merge them, deduplicate, and build one sheet with columns for old URL, current status, organic clicks, referring domains, and destination. Every URL with traffic or links gets a mapping. Everything else gets an explicit decision: map it, consolidate it, or drop it to 410. Silence is the one option that is never correct. A URL you forgot is a URL that 404s on launch day, and you will not learn which one until traffic reports arrive.

Map old URLs to new URLs one to one

The default answer to "where should this old URL go?" is the closest equivalent new URL, not the homepage. Bulk redirecting everything to the homepage looks tidy in a spreadsheet and reads to Google as a soft 404 for every single mapping.

Rules that keep the map honest:

One hop only. Old URL goes directly to the final URL. Chained redirects waste crawl and dilute signal; see how to fix redirect chains, and spot-check mappings with the redirect checker.
301 permanently, except during testing. Use 302s only on staging where you will forget to swap them, never in production.
Consolidate deliberately. When three old pages become one, redirect all three and keep the combined page's content genuinely comprehensive, or you are throwing away ranking relevance you already had.
Cover asset classes too. Images, PDFs, download links, and legacy blog slugs all have inbound links pointing at them. They need mappings just like HTML pages do.

The cleanest version of this map also follows URL structure best practices, so the new pattern is one you will not want to change again next year.

Preserve titles, meta descriptions, and headings, or improve them on purpose

During a migration, the safest on-page decision is the boring one: carry over titles, meta descriptions, and heading structure exactly as they are. This isolates the variable. If you rewrite every title at the same time you change the platform, you will never be able to tell whether a ranking change came from the migration or the copy.

Export your current titles and descriptions before the move and diff them against the new site with the meta tags checker. The goal is a diff you can explain line by line. Where you do rewrite, do it because you have data showing the old version underperformed, and note the change so you can evaluate it separately from the migration itself.

Headings deserve the same treatment. Keep the H1 pattern stable, keep heading hierarchy intact, and do not let a new template silently demote every H1 to a styled paragraph.

Control the staging environment correctly

Staging must not be indexed, but the method you choose determines whether launch day goes smoothly. The correct pattern is:

Allow search engines to crawl staging normally.
Serve a noindex meta tag on every staging page.
At launch, remove the noindex and flip the site live in the same window.

Do not block staging with robots.txt instead. If you block crawling, Google can never read the noindex directive, and once you remove the block the pages can be indexed without content, title, or meta information ever being processed. You end up with index entries pointing at pages you have already deleted. The mechanics are covered in our robots.txt guide, which also explains why robots.txt and noindex are not interchangeable.

Whichever method you pick, verify it explicitly the day before launch: fetch a staging URL, confirm the directive is present, and confirm it is the directive you intend to remove.

Launch-day checklist

Work down this list before you announce anything:

Sample 50 to 100 high-value old URLs and confirm each returns a single 301 to the intended new URL.
Confirm the XML sitemap is live, contains only new canonical URLs, and returns 200.
Confirm robots.txt on the new host allows crawling of the paths you want indexed.
Check canonical tags on representative templates point to new-domain URLs, not the old host. The canonical tag checker makes this a two-minute pass.
Verify analytics, tag manager, and conversion tracking are firing on the new platform.
In Search Console, submit the new sitemap and, for domain moves, run the change of address tool. The full sequence is in our Search Console guide.
Resubmit the new sitemap through the steps in the XML sitemap guide so discovery is not left to chance.

If your migration crosses to a new domain, treat steps 6 and 7 as non-negotiable. Without the change of address signal you are asking Google to rediscover the entire site from scratch while your old links still pass equity to redirects nobody has verified.

The first 48 hours

This is the window where cheap fixes still work. Check the following at least twice a day:

Server logs for Googlebot activity on the new host — confirm crawlers are arriving at all.
Search Console coverage for spikes in "submitted but not indexed" or new 404s.
The 404 report for old URLs that received traffic and have no mapping. Fix these immediately; a 404 discovered in hour 6 is much cheaper than one discovered in week 3.
Analytics for tracking gaps caused by template changes.

Keep a running list of every anomaly with its URL and timestamp. Memory degrades fast during a launch, and you will want the raw list when you evaluate what happened in two weeks.

The first two weeks

Move from twice-daily to a fixed daily slot, then every other day after the first week. What to watch:

Indexed page count on the new host against your pre-migration inventory.
Position and click trends for your top 50 queries, compared to the two weeks before launch rather than to the launch day itself.
Whether old URLs are still showing in the index. Persistence beyond a week or two usually means a redirect or canonical is wrong.
Any template-level title or content change flagged in your meta diff.

How migrations actually fail

The failure modes are boringly consistent:

Missed URL classes. Faceted pages, pagination, archive indexes, PDFs, images, and legacy campaign URLs are left out of the map because the inventory came from one source instead of five.
Blocked staging. The noindex never gets removed, or robots.txt rules from staging survive into production and quietly block whole sections of the site.
Forgotten redirects on non-HTML assets. Image and PDF URLs keep inbound links and keep 404ing, and the loss shows up as broken links rather than as a migration problem.
Lost backlinks. High-authority old URLs redirect to a 404, or to the homepage, and the equity never reaches the page that replaced them.
Redirect chains built by the platform. New CMS routing stacked on top of old redirects creates two- and three-hop paths within a day of launch.
Tracking failures. You lose visibility and cannot tell a real decline from a measurement bug.

Every one of these is detectable with a crawl plus a log check. None of them require luck.

Expect a dip, and know what is normal

A ranking dip after migration is normal, and you should plan for it rather than panic about it. Positions fluctuate while Google reprocesses redirects, reassigns canonicals, and re-evaluates titles. Temporary movement for days to a few weeks is common on a domain change or a large URL restructuring, and rank trackers will show noise before they show signal.

What is not normal: a steady decline that continues past the two- to three-week mark, or a permanent loss concentrated on specific sections. That pattern points to a bug, not to a migration penalty. Work the list in order: missing mappings, wrong canonicals, blocked paths, then content changes. Migrations rarely fail for mysterious reasons.

Related Tools

Reviewed by TheLinksMaster

SEO Editorial Team

Our editorial team tests every tool and guide on this site against real websites. We update content when search algorithms change so you always get current, practical SEO advice.