Website Migration SEO Checklist: Relaunch Without Losing Traffic

Will we lose our Google rankings if we relaunch our site? That's the first question nearly every business owner asks when planning a new design, a platform change, or a domain migration. The clear answer: a properly planned migration doesn't cause permanent traffic loss. Google states plainly in its official documentation that 301 redirects pass ranking signals to the new addresses, and on a mid-sized site, temporary fluctuation typically recovers within a few weeks. Permanent losses almost always come not from the migration itself, but from skipped steps: forgotten redirects, noindex tags that slip into production, content quietly deleted along the way.

In this article you'll find the checklist for completing a site migration without losing traffic, step by step: pre-migration prep, the 301 redirect map, launch-day actions, and the monitoring calendar afterward. The list covers all three scenarios: domain changes, platform migrations, and full design relaunches.

Why does a site migration cause traffic loss?

First, it helps to define migration, because the size of the risk depends on the type of change:

• Design relaunch: URLs stay the same; the template, internal linking, and content layout change. This looks like the safest scenario, but if heading hierarchy breaks or page content gets trimmed, rankings can still drop even without a URL change.
• Platform migration: moving from an off-the-shelf e-commerce platform to custom software, for example. URL structure usually changes, and every changed URL needs a redirect.
• Domain change: a rebrand or a move to a new domain. All signals need to transfer to the new domain; this is the highest-risk type and the one that demands the closest monitoring.

According to Google's Search Central documentation, a migration involving URL changes typically takes a few weeks to process on a mid-sized site, and longer on larger ones. Fluctuation during this window is normal and doesn't call for panic. Loss becomes permanent when one of the following happens:

• Missing redirects: every old URL left out of the map returns a 404, eventually drops from the index, and the backlinks pointing to that page lose their value.
• Bulk redirects to the homepage: sending thousands of old URLs to the homepage under a single rule. Google can treat these irrelevant-target redirects as soft 404s; page-level signals don't transfer, and the result is no different from a missing redirect.
• Staging blocks leaking to production: a noindex tag or robots.txt block added to hide the test environment goes live with the new site. If nobody catches it, the site starts disappearing from the index within days - one of the simplest but most damaging mistakes.
• Content trimming: deleting blog posts and sub-pages that look outdated during a relaunch. Long-tail traffic comes from exactly these pages; when hundreds of small sources close at once, the combined effect is large.
• Redirect chains: adding new redirects on top of ones left over from past migrations creates A-to-B-to-C-to-D chains. Googlebot follows at most 10 hops; every extra hop adds delay and risk of failure.
• Performance regression: if the new, visually richer design loads slower than the old one, Core Web Vitals metrics worsen, and migration fluctuation compounds with a speed-driven drop.
• Broken tracking: analytics and conversion tags not carried over to the new template is a separate scenario - even if traffic holds steady, the data stops flowing, it looks like a loss happened, and the false alarm gets in the way of investigating real issues.

Step 1: The pre-migration checklist

A migration's fate is decided weeks before launch day, not on it. Complete the following at least 3-4 weeks before the migration date:

1. Build a complete URL inventory. Combine four sources: URLs found by a site crawler, indexed addresses from Search Console's page report, pages that received traffic in the last 12 months according to analytics, and URLs with external links according to your backlink tools. Don't rely on crawling alone - orphan pages with broken internal links that still get traffic only show up in analytics and Search Console data.
2. Record your performance baseline. Export the last 3 months of organic traffic, your top 100 queries by clicks, and page-level click and impression data. This baseline is the only way to answer whether you lost anything, and where, after the migration.
3. Prioritize pages. On most sites, a small fraction of pages generates most of the organic traffic. Example scenario: on a 5,000-URL site, if 85% of traffic comes from 400 pages, those 400 pages should be mapped and verified by hand, one by one; the rest can be handled with rule-based redirects.
4. Audit the new site in staging. Titles, meta descriptions, canonical tags, internal links, structured data, and mobile compatibility should all be tested before launch. You can use our technical SEO checklist as the basis for this audit.
5. Set a speed target. Measure the new design's key pages in staging and set the current site's Core Web Vitals as the floor. Launching first and optimizing speed later stacks a second negative signal on top of migration fluctuation.
6. Lock down the timeline and a rollback plan. Don't schedule the migration during a campaign period or peak season; pick a low-traffic day of the week. If something goes wrong, how to roll back to the old system and who decides should already be written down. Where possible, avoid the middle of a major Google core update rollout too - it becomes very hard to tell the two effects apart.

Step 2: The 301 redirect map

The redirect map is the table matching every old URL to its new counterpart, and it's the single most critical deliverable of the migration. Google confirms that a permanent (301) redirect passes ranking signals to the target page - but only when the redirect is set up correctly.

Build the map as a spreadsheet with columns for old URL, new URL, priority, and test status, and version it as the single source of truth shared with the development team; the redirect rules applied on launch day should be generated directly from this table.

The one-to-one mapping rule

The ideal map is one-to-one: the old product page goes to the new product page, the old category to the closest new category. For pages with no exact equivalent, pick the closest topical match. If there's genuinely no equivalent, be honest about it: returning a 404 or 410 is better for both user experience and Google than sending visitors to an irrelevant page. For content that's genuinely removed, a 404 isn't an error - it's the correct answer.

Example scenario: managing a 5,000-URL map

On an example site with 5,000 URLs changing platform, the map can be split into three tiers. Tier one: the 400 priority pages where traffic and backlinks concentrate are mapped by hand and tested individually - roughly 2-3 days of work for a two-person team. Tier two: around 4,000 pages whose URL structure changes in a consistent pattern - say, /blog/post-name becoming /content/post-name - are redirected with a single pattern rule, then verified against a random sample of 50-100 URLs once the rule is written. Tier three: the remaining 600 low-value pages (parameterized URLs, empty tag pages, archive pages) get a merge decision or a deliberate 404. This approach keeps the workload manageable while protecting nearly all of the signal value.

Chains, status codes, and duration

• Shorten chains: every old URL should reach its final destination in a single hop. Update redirects left over from past migrations to point at the new targets too; the longer the chain, the lower the crawl efficiency.
• Use 301, not 302: sending a temporary-redirect signal for a permanent migration can needlessly extend how long Google keeps the old URL in the index.
• Keep the map live for at least a year: Google recommends keeping migration redirects in place for at least 12 months, ideally permanently. External links keep pointing at old URLs for years; removing the redirect early means writing off that accumulated value.

Step 3: Launch day - transition and technical checks

The order of operations matters on launch day; the list below is chronological:

1. Lower the DNS TTL in advance (for domain changes). Shortening the TTL 24-48 hours before migration lets the change propagate quickly and avoids hours of waiting if a rollback becomes necessary.
2. Activate redirects and test a sample. Run a bulk HTTP status check across all priority pages plus a random sample from the full inventory: the expected result is a single-hop 301 landing on the correct page, returning 200 there.
3. Remove staging blocks. Manually check robots.txt and the page templates for noindex tags. This is the simplest item on the list - and usually the most expensive mistake too.
4. Report the address change in Search Console (for domain migrations). Verify the new domain as a property beforehand, then formally notify Google of the move using the Change of Address tool.
5. Update sitemaps. Submit a sitemap containing the new URLs. Google notes that keeping a sitemap listing the old URLs accessible for a while helps redirects get discovered faster.
6. Update hreflang tags on multilingual sites. If hreflang references between language versions still point at old URLs, Google can lose the language match; every language pair should point at the new addresses on both sides.
7. Verify internal links and canonical tags. Links within the new site should go directly to new URLs, not through a redirect; canonical tags should point at the new addresses too.

Phased rollout for large sites

On sites with tens of thousands of pages, you don't have to change everything overnight. For URL structure or platform changes, migration can happen in sections: blog first, category pages two weeks later, then products. The value of a phased rollout is catching problems that surface in the first section before they spread site-wide. In an example scenario, a 50,000-URL content site migrates 10% of its archive first, monitors index and traffic data for two weeks, and if the metrics hold steady, migrates the rest in two-week waves. Two notes: Google processes a one-shot migration faster, so small and mid-sized sites don't need to phase it; and for domain changes, since the change-of-address notification covers the whole site, the migration should be done as a single move.

Step 4: The post-migration monitoring calendar

Going live is the middle of the process, not the end. Split monitoring into three windows:

First 72 hours

• 404 check: scan server logs and Search Console daily for old URLs returning 404; each one marks a gap in the map and should be closed immediately.
• Crawl activity: confirm Googlebot has started crawling the new URLs via the crawl stats report. Bot traffic rises noticeably during this window; make sure the server handles it without errors.
• Redirect sample: re-run the test list every day; redirect rules getting accidentally overwritten during new deployments is a common failure mode.
• Manual check of critical flows: walk through the homepage, top revenue-generating category and product pages, and contact and form pages like a real user; form submissions and checkout steps are the flows most often broken on launch day.

First month

• Index status: track the rise in indexed new URLs and the gradual drop in old ones. We covered how to read these reports in detail in our Google Search Console guide.
• Ranking comparison: compare your top 100 priority queries against the pre-migration baseline. A 10-15% fluctuation spread across the board is normal; a drop concentrated in a single site section instead points to a redirect or content-equivalence problem in that section. Watch clicks as well as position: on result pages where AI Overviews have become common, your position can hold steady while click-through rate shifts; to separate migration impact from broader SERP changes, compare the same period against the previous year too.
• Backlink targets: manually verify that your most valuable external links land on the correct pages; where possible, ask a few high-value sources to update their links directly to the new address.

First 3 months

According to Google, fully processing a mid-sized site's migration takes a few weeks; on large sites it can stretch into months. If traffic is still noticeably below the pre-migration baseline at the end of month three, you're no longer looking at fluctuation but a real problem: re-audit redirect coverage, index status, and content equivalence between old and new pages. You can apply the diagnostic process from our organic traffic drop guide to find the root cause.

Post-migration loss is managed by asking not how much traffic dropped overall, but which pages and which queries dropped. The total number leads to panic; page-level data leads to a solution.

Conclusion: the difference between relaunching and losing is planning

Site migration is one of the riskiest operations in SEO, but the risk doesn't come from uncertainty: nearly every loss scenario is a known, predictable, preventable mistake. To sum up the list in one paragraph: build a complete URL inventory and performance baseline weeks before migrating; prepare a one-to-one 301 map and manually verify priority pages; on launch day, check staging blocks, sitemaps, and the change-of-address notification; afterward, monitor 404s, index status, and rankings regularly for at least three months. Keep the redirects live for at least a year too.

The real difficulty in this process is less about technical complexity than coordination: design, development, and marketing all have to work off the same calendar, and a single missed item can erode organic visibility built up over years. Welda's SEO team takes on exactly this coordination for migration projects as part of our SEO consulting service: from inventory and map preparation through staging audits, launch-day checks, and three-month monitoring reports, the process is run end to end by one team. If you're planning a relaunch or a platform change, get in touch to review your migration plan together before going live - preventing a problem before launch is always cheaper than fixing it while live.