Website Migration SEO Checklist: Protect Rankings Through a Relaunch

Twenty of the 35 tasks in the table at the end of this page happen before launch. In that stretch the team records how the old site performs and maps every URL that matters to its new address. On launch day, permanent redirects go live and someone confirms that nothing blocks crawlers. The weeks after are spent watching indexing, with rankings and traffic held against the baseline, until the old URLs fade out of the reports. This website migration SEO checklist runs in that order. A third column in the table says how to verify each task.

A missing redirect is a loss the team causes itself, and so is a staging noindex tag that stays live after launch. This checklist is aimed at losses of that kind. Google's site-move guide also tells owners to expect temporary fluctuation in rankings during a move. A dip while the move settles does not by itself mean something broke.

Which kind of migration are you running?

A CDN switch and a domain rebrand are both called a migration, yet they put very different parts of the site at risk.

A redesign built on a new CMS with new URL paths fills three rows of this table at once. Many relaunches fill three or four. We list every type that applies before any other planning starts, because each row brings its own tasks into the plan.

For a hosting move with unchanged URLs, Google's guide asks for less, because this is the lightest kind of migration. The first setting we change is the DNS TTL. Lowered before the switch, it makes cached DNS answers expire quickly, and visitors reach the new server sooner. We watch crawling in Search Console while the move runs, and the old host keeps running until its server logs show that its traffic has reached zero.

Before launch: crawl, benchmark and build the URL inventory

Each check later on this page compares the new site with a record made at this stage.

Crawl the old site. Save a full crawl with status codes, titles, canonicals, internal links and word counts. You will need it to compare against the new site, and you cannot get it back once the old site is gone.

Back up the old site in full. A crawl records what search engines saw, while a backup lets you put the old site back. Google's site-move guides do not mention backups, so this step comes from general practice rather than from Google. For a host move, Google does say to upload a copy of the site to the new host. On many CMSs, that copy is a database export. Keep a separate backup outside the hosting you are about to change, because the copy you upload belongs to the move.

What a full backup holds depends on the CMS. In the WordPress documentation, a full restore needs both the database and the files. It also advises a database backup before any move. For SEO, the backup also needs the server or CDN configuration, because redirect rules usually live there or in an .htaccess file. The robots.txt rules belong in the backup as well. Some sites keep them in a file in the web root, and on others the CMS generates them. The backup has to capture whichever form the site uses. Then restore the backup once on a separate environment to prove it works. Without that test, the rollback option described later on this page may not exist when you need it.

Export a baseline from Search Console and analytics. We export Search Console clicks, impressions and average position by page and by query over at least the last few months. Analytics adds organic landing-page sessions and conversions over the same period. A seasonal business marks its slow months on the baseline, so that a quiet month after launch is not blamed on the migration.

Build the URL inventory from more than one source. Google suggests drawing on sitemaps, server logs, analytics and your CMS. Add URLs with external backlinks and any URL that got impressions in Search Console. A crawl alone misses orphaned pages that still rank.

Mark the pages that matter most. Sort the inventory by organic traffic, conversions and backlinks. The top of that list becomes your set of priority pages. Someone checks each of them by hand on staging, on launch day and in the weeks after.

Pick a launch window and freeze content. Avoid your busiest season, and stop content edits on the old site once the map is final, or the map goes stale.

Large sites: move in sections

On small and medium sites, Google recommends moving all URLs at the same time. Users then meet the new site as a whole, and Google can detect the move and update its index faster. Large sites can move one section at a time. Google says this makes problems easier to monitor, detect and fix. Where it is technically possible, Google recommends a test move of one section first.

Google advises a test section that changes less often and is not shaped by frequent or unpredictable events. That section gets the full launch checks below. We compare its clicks in Search Console and its sessions in analytics with the baseline before the next section moves.

A clean test section does not clear the rest of the site. Google notes that moving one section is not necessarily representative of how a whole-site move behaves in Search. It also warns that a larger move is likely to raise more problems, so every later section gets the same checks as the first.

Google also crawls a moved site more heavily than usual for a while. On a very large site, give the hosting provider notice of the move so the server has the capacity to handle that extra crawling.

The redirect map

We treat the redirect map as the most important document in a migration, because every redirect test on this page is run against it. It is a spreadsheet with one row for each old URL. Next to each old URL sits the exact new URL it should reach.

Six rules govern the map and the redirects built from it:

• Map one to one wherever possible. The destination for each old page is the one new page closest to it in content.
• Use permanent, server-side redirects. Google recommends a 301 or a 308 where possible, and Google interprets redirects set on the server most reliably. JavaScript redirects come last, because if rendering fails Google may never see them.
• Do not send everything to the homepage. Google warns against redirecting many old URLs to one irrelevant page such as the new homepage, and says this may be treated as a soft 404. If you merged several old pages into one new page, redirecting them all there is fine.
• Avoid chains. Old URL to new URL in one hop. If the site has been migrated before, update the earlier redirects to point straight at the final destination. Google's crawl guidance says long redirect chains hurt crawling.
• Keep redirects for a long time. Google says to keep them as long as possible, generally at least a year. For a domain move, a December 2020 guide that a guest author wrote for the Bing Webmaster blog asks for at least one to two years, preferably longer.
• Decide what gets a 404 or 410. Pages you are removing with no replacement can return a real "not found." That is better than a misleading redirect.

Staging: test before anyone outside sees it

Staging sits behind a password or a noindex rule while the team tests it, so it stays out of search results. We write down where that block is set. The server might send it as an X-Robots-Tag HTTP header, a CMS setting might add it, or the page template might carry the tag. Whoever removes it on launch day needs that note, because this is the setting most likely to slip into production by accident.

On your priority pages, compare the new site with the old one on each of these points:

• Content: redesigns often cut the copy that was doing the ranking, so check that the main text, headings and FAQs came across.
• Titles and meta descriptions: carried over, or changed on purpose. A template default in their place means they were reset.
• Canonicals: every page names its own new URL. A canonical that points at staging or at the old domain has to be fixed.
• Structured data: the same types as before, still valid.
• Internal links: any navigation or in-body link that passes through a redirect gets pointed straight at the new URL.
• Rendering: if the new site uses a JavaScript framework, key content and links are in the rendered HTML. Google only discovers links in <a> elements with an href.

A crawler or a short script requests every old URL in the redirect map once, either from the staging site or from a copy of the redirect rules. A pass is a single 301 or 308 that lands on the mapped destination. Rows that come back with a 404, with no redirect at all or with a second hop are fixed before launch. The same rules go to production, so an error left here goes live with them.

Launch day

Two of the seven steps below take blocks off the site. The others confirm that production matches what passed on staging, or tell Google and Bing about the move.

1. Remove staging protection. A CMS setting can show the site as open while a noindex still sits in a template or an HTTP header. That is why the check runs on the live pages' HTML and response headers.
2. Check robots.txt on every host. Make sure the new rules block only what you want blocked. Google notes that a page blocked by robots.txt cannot show its noindex to the crawler, so a blocked page can still appear in results.
3. Deploy redirects and test them live. The full old-URL list runs again against production. Every 404, 302 or chain in the results gets fixed.
4. Submit the new XML sitemap in Search Console. Google also notes the old-URL sitemap may show redirect warnings, which you can ignore.
5. Use Change of Address if the domain changed. Google says to submit it for the old site when you change domain names or subdomains. It is not used for HTTP to HTTPS moves or path changes on the same domain. For Bing, that December 2020 guest guide says to use the Site Move tool in Bing Webmaster Tools once the 301s are live. The tool requires a site you have verified with Bing.
6. Inspect your priority URLs in Search Console's URL Inspection tool with a live test. There is a daily limit on inspections and indexing requests, so spend them on the pages that matter.
7. Confirm analytics and conversion tracking fire on the new templates. A template without its tag shows up as lost traffic.

After launch: 30, 60 and 90 days

Google says small and medium sites can take a few weeks for most pages to move, and larger sites take longer. Expect old URLs to drop and new URLs to rise in Search Console, not all at once.

First week: we read the server logs and the Page Indexing report in Search Console every day. The signs to look for are a spike in 404s, any 5xx server errors and pages blocked from crawling. A broken redirect found that week gets fixed the same day, because until then it sends visitors and crawlers to an error page.

Links you control, also in week one: Google's site-move guide asks you to update as many links as you can once the move starts. Its list includes profile links on Facebook, Twitter and LinkedIn and the landing pages in ad campaigns. Profiles and listings you own come first, because you can change them without outreach. Redirects would carry visitors from the old links, but a direct link removes a hop and shows the current address to anyone who reads the listing.

Google Business Profile lets you edit the website field from the profile on Search or from the Business tab in the Maps app. It takes the full new URL, including the https prefix. Google reviews the change before it goes live and does not say how long that takes, so the plan should allow for it. Google's link policy accepts links that redirect. We still point the profile at the final URL, so the listing does not depend on the redirect.

A Bing Places listing needs the same change. In October 2025, Bing announced that Bing Places for Business was moving from bingplaces.com to bing.com/forbusiness, so the listing is edited at the new address. Company social pages, directory listings and ad final URLs come next. Email signatures and saved sales and support templates often carry old URLs too.

Days 8 to 30: compare clicks and impressions for your priority page groups against the baseline. Count each group as described in the lessons from our own site, further down this page. Re-crawl the live site and fix any internal links still pointing at redirects.

Days 31 to 90: review queries that lost position and the pages behind them. Check whether the content on those pages changed during the redesign. Update important external backlinks to point at the new URLs where you can.

When to roll back, and when to fix forward

We fix specific problems forward on the new site. A group of broken redirects, a template that lost its content or a stray noindex tag can each be fixed in isolation. A full rollback rarely makes sense for these, because it starts a second migration.

Widespread server errors are one case for rolling back. A rendering failure across all key templates is another. Both mean the new site cannot serve its core pages, and a rollback is right only when that is true and nobody can fix it quickly. The backup restore tested before launch is what makes it possible. Before launch day, the launch plan names who makes the call and what evidence they need to see.

What we saw on our own site

Between 1 October and 3 November 2026, one redirected URL on our own site still recorded 481 impressions in Search Console, at an average position of 4.7. It was one of several old blog posts we had retired and 301-redirected to our SEO services page. Most of the others dropped out of the performance data fairly soon. This one kept drawing impressions for weeks.

Search Console files clicks, impressions and position under the canonical URL that Google selects, and that is the likely explanation. The old URL can go on collecting impressions under its own name until Google has processed the redirect and treats the new page as canonical.

We took two lessons from that URL, and each one is now a check:

• Check lingering old URLs in URL Inspection. An old URL that still collects impressions after its redirect is not necessarily a failure. URL Inspection shows which canonical Google has selected for it, and a live test shows whether the redirect is in place. Those two results show whether there is anything to fix.
• Compare page groups against the baseline. For each topic, add up the figures for the old URL and the new URL, then compare that total with your baseline. A single old URL can look like a loss while its traffic has already moved to the new address.

We are still tracking that URL in Search Console and have no recovery figure for it.

The full website migration SEO checklist

The third column, How to verify, names the evidence that a task is done: a crawl export, a Search Console status, a line in the server logs.

Who should run the migration

Drift between the redirect map and the server rules is how an old URL with traffic or backlinks ends up on the wrong page or a 404. To prevent it, one person owns the migration. That person signs off every SEO check in the table, and the engineers who write the redirect rules and templates build from the same map and checklist.

Our SEO migration services cover the URL inventory, mapping, pre-cutover testing and post-launch monitoring. If the migration is part of a rebuild, our website migration and replatforming work plans redirects, content models and staged cutover as part of the build. For SaaS sites with app and docs subdomains, see our guide to technical SEO for SaaS.

FAQ

How long does a website migration take to recover in search?

There is no fixed timeline. Google says small and medium sites can take a few weeks for most pages to move, larger sites take longer, and temporary ranking fluctuation is expected. Our guide on how long SEO takes after a site migration covers the wider timeline for SEO results.

Should I use 301 or 302 redirects for a migration?

Use permanent redirects, 301 or 308. Google uses permanent redirects as a signal that the target should be canonical; temporary ones are not used that way.

How long should I keep redirects after a migration?

Google recommends keeping them as long as possible, generally at least a year.

Why does an old URL still show impressions after I redirected it?

The likely cause is that Google has not yet treated the new page as canonical. Search Console reports data under the canonical URL Google selects, so the old URL keeps its impressions until then. URL Inspection shows which canonical Google has picked.

Do I need the Change of Address tool?

Only when you change domain names or subdomains. It is not used for HTTP to HTTPS moves, www changes or path changes on the same domain.

When the relaunch date is set, you can get a range for your migration SEO work. We need the site address, a rough count of its indexable URLs and who will ship the changes, and we scope the URL mapping and testing from those details.