Website migration SEO: a checklist that protects your rankings

A website migration is any change to your domain, platform, URLs or hosting that search engines have to relearn. Done carefully, rankings dip briefly and recover. Done in a hurry, pages drop out of Google, and out of the AI answers built on it.

By AI Search Ranking. Published 6 November 2026. Last updated 6 November 2026. In Technical SEO and audits.

On this page

The short answer

Website migration SEO is the work that keeps your search visibility intact when your site changes address, platform, structure or hosting. Search engines have learned where every page lives. A migration asks them to learn it again, and anything you leave unclear gets lost.

The core of it is simple to state. Map every old URL to its new home and redirect each one permanently. Update everything that still points at the old addresses, then watch Search Console closely for the weeks after launch. Google says to expect temporary fluctuation in rankings during a move1. Planned well, that is all it is: temporary.

The rest of this guide is the checklist we use, in the order the work happens, plus the parts most migration guides leave out.

What counts as a migration

Not every move carries the same risk. The type of change decides which steps apply, so start by naming yours.

Type of change	URLs change?	Google's Change of Address tool?	Risk to rankings
New domain name	Yes	Yes	High
Moving to a subdomain or from one	Yes	Yes	High
New platform or CMS with new URL patterns	Yes	No	High
Redesign that changes page addresses	Yes	No	Medium to high
Moving from http to https	Yes	No, Google detects it	Low
New host or CDN, same URLs	No	No	Low
Redesign with the same URLs	No	No	Low to medium

The Change of Address tool is only for moves between domains or subdomains3. Google's help page says not to use it for a move from http to https, because Google detects that on its own3. A change of host or CDN with no visible URL change needs no special step from Google at all4.

A redesign that keeps every URL can still hurt. If it removes text, changes headings, drops internal links or hides content behind scripts, the pages are no longer the pages that earned their rankings.

Before launch: the groundwork

Most migration losses are decided before launch day. These steps are where the time should go.

Record a baseline. Export your Search Console performance data by page and by query, your top landing pages from analytics, and a full crawl of the current site. Without a before picture, you cannot tell a normal dip from a real problem.
List every URL that matters. Combine the crawl, your XML sitemaps, Search Console's indexed pages and the pages other sites link to. Pages with links or traffic that your crawler cannot reach still need a home.
Map old URLs to new ones. Google calls mapping old URLs to new URLs important1. Each old page should point to the closest equivalent new page, one to one wherever you can.
Decide what happens to pages you are dropping. Redirect them to a genuinely related page. If nothing is related, let them return a proper not found response. Google warns against redirecting many old URLs to one irrelevant destination, such as the new homepage1.
Keep staging out of search. Protect the test site with a password or a noindex rule, and write a launch-day reminder to remove it from the live site.
Check the new templates. Titles, meta descriptions, headings, canonical tags, structured data, image alt text and page copy should all carry across. Compare a sample of key pages side by side.
Prepare the new sitemaps and robots.txt. Google says to make sure your sitemaps list the new URLs1, and to set up a robots.txt file for the new site1.
Pick a quiet launch window. Avoid your busiest season, and make sure the people who can fix redirects are available for the week after.

Redirects: the part that decides the outcome

Redirects tell search engines, and people, where each page has gone. Getting their type and their destination right matters more than any other single task.

Use permanent, server side redirects wherever your platform allows. Google recommends a permanent server side redirect whenever possible2. Its migration guide says the same1.

The type matters because Google treats them differently. A permanent redirect is a signal that the new URL should be the canonical one, the version shown in results2. A temporary redirect is not used as that signal2. Many platforms quietly default to temporary redirects, so check the response codes yourself rather than trusting the settings screen.

If server side redirects are impossible, Google reads an instant meta refresh as permanent2. JavaScript redirects are the last resort, because Google might never see them if rendering fails2.

Then decide how long to keep them. Google's answer is as long as possible, and generally at least a year1. Old links, bookmarks and other sites' pages keep sending visitors to the old addresses long after search engines have caught up. Renewing the old domain and keeping its redirects running is cheap insurance.

Launch day

On the day, work through a short list, in this order.

Switch the redirects on and spot check the most valuable old URLs. Each should land on the right new page in a single hop.
Remove any staging noindex rule or password from the live site.
Check robots.txt on the new site does not block pages you want found.
Submit the new sitemaps in Search Console.
If you changed domain or subdomain, verify both properties in Search Console and submit a Change of Address for the old site1. You need to be an owner of both properties in Search Console3.
Confirm analytics and any conversion tracking fire on the new pages.
Inspect a handful of key URLs with the URL Inspection tool. For a hosting move, Google suggests using it to check that Googlebot can reach the new setup4.

After launch: the first eight weeks

Google has to visit both the old and the new URLs before a move settles. Its guide says a small to medium site can take a few weeks for most pages to move, and larger sites take longer1. Plan to watch closely for at least that long.

Crawl the new site straight away. Look for broken links, redirect chains, missing titles and canonical tags pointing at old URLs. Every new page should carry a canonical tag pointing to itself1.
Update internal links. Change the links inside your own pages to the new URLs, rather than relying on redirects1. It also cuts wasted crawling.
Watch Search Console. Google calls Search Console your friend during a site move1. Compare indexed page counts on both properties, check the sitemap reports, and look for spikes in not found errors.
Compare against your baseline. Look at the pages and queries that mattered most before the move. A gentle dip that recovers is normal. A page that vanishes is a broken redirect or a blocked page until proven otherwise.
Ask for your links to be updated. Contact the sites that link to your most important pages and ask them to use the new addresses. Update your own profiles and directory listings too.
For a hosting move, check the old server. Google suggests keeping the old hosting running until its traffic reaches zero4. Crawling may slow briefly after the switch, which Google describes as normal4.

What most migration guides miss

AI answers depend on the same work

Google says there are no extra requirements to appear in AI Overviews or AI Mode beyond being indexed and eligible to show a snippet5. That cuts both ways. A page lost in a migration also disappears from the AI answers that cited it, and it can only come back once Google has indexed the new address. A migration is now an AI visibility risk as much as a ranking one, and the same checklist protects both. Our guide to AI Overviews explains how those answers choose their sources.

The AI answer for this topic skips Google's own advice

On 5 November 2026 we checked Google's AI Overview for "website migration seo" and "site migration seo" in the UK. Both showed the same answer, built from the same seven sources: four agencies, one industry publication, one video and one platform vendor. None was Google's own documentation.

The advice it gave was sound, but incomplete. It did not mention the Change of Address tool, how long to keep redirects, or the difference between permanent and temporary redirects. Those are three of the points most likely to decide whether a domain move recovers. When the stakes are high, read the primary source, Google's own site move guide, alongside any checklist, including this one.

Moving everything at once is often safer

It feels cautious to move one section at a time. For most sites, Google recommends the opposite: move a small or medium site all at once, and only consider moving section by section on larger sites1. Splitting a small move simply stretches the uncertain period.

A migration is a chance to fix things, not to change everything

The safest migrations change as little as possible at once. If you are moving domain, try not to rewrite every page and restructure every URL in the same week. When something goes wrong, you want to know which change caused it.

Common questions

How long does an SEO migration take to settle? Google says a small to medium site can take a few weeks for most pages to move, and larger sites take longer1. Plan for a period of uneven rankings and keep monitoring until the old URLs have dropped out of the index.

Will I lose rankings when I migrate my website? Some movement is normal, and Google says to expect temporary fluctuation1. Lasting losses usually come from missing or wrong redirects, blocked pages, removed content or new pages that are weaker than the old ones.

How long should I keep redirects after a migration? For as long as possible, and generally at least a year, according to Google1. Keeping them permanently costs little and protects links you may not know about.

Do I need the Change of Address tool? Only when moving to a new domain or subdomain3. It is not needed for a move from http to https, or for changes within the same site3.

Should I redirect deleted pages to the homepage? No. Google advises against redirecting many old URLs to one irrelevant page such as the homepage1. Send each one to the closest related page, or let it return a not found response if nothing fits.

Where to start

Start with the baseline and the URL list, weeks before launch, because those two documents make every later step checkable. Then build the redirect map and have someone other than its author test it.

If the move is complex, or rankings have already dropped after one, our technical SEO service covers migration planning, redirect mapping and post-launch monitoring. An SEO audit is the quickest way to find what a past migration broke.

What we've seen in real audits

On one migration we handled, the redirect plan started with an audit of the whole site, not with the new site's structure. From the Search Console performance report we listed every page that had earned a click or an impression in the previous sixteen months. We then added data from a Screaming Frog crawl and Ahrefs so no page with links pointing at it was missed.

Each page was checked against a set of criteria. The soft rules were traffic: more than ten organic clicks or a hundred impressions in that period meant a redirect, and we reviewed every page on that list by hand. The hard rule was links: any page with even one backlink was always redirected. Where the new site had no matching page, we created one before launch. Pages we chose to retire returned a 410 status, so search engines knew they had gone on purpose.

Every redirect was a one-to-one permanent redirect, switched on at the same time as the new pages. We also submitted the move through the Change of Address tool in Search Console. We monitored for redirect errors before and after launch. Within four to five weeks, traffic on the new site had grown well beyond what the old site had been getting.