Site migration SEO checklist: domain, platform or URL changes
A site migration keeps its rankings when every old URL 301s to its one new URL. The before, during and after checklist, built around the redirect map.
LLaunchScaler·Published ·8 min read
A site migration keeps its search traffic when every old URL redirects with a 301 to the one new URL that replaces it, the new site is crawlable and indexable on launch day, and you watch indexing and 404s for weeks afterwards. The checklist below runs in three phases (before, during and after), with the redirect map at the centre of all three.
The same checklist covers a domain change, a move to a new CMS or framework, and a new URL structure on the same domain. Only the Change of Address step is specific to domain moves.
What counts as a site migration for SEO?
For SEO, a migration is any change that alters the URLs Google has indexed or the signals attached to them: the domain, the subdomain, the protocol, the path structure, or the platform that renders the pages. A redesign that keeps every URL and all the content is not a migration, though it carries its own risks.
Migration type
Example
URLs change?
Redirects needed
Change of Address tool
Domain change
oldbrand.com to newbrand.com
Yes, every one
Yes, every URL
Yes
Subdomain change
shop.example.com to
Questions, answered
What people ask about this
01
What is the most important step in a site migration?
The redirect map. Every old URL should redirect with a 301 or 308 to the one new URL that replaces it, in a single hop. Google warns that redirecting many old URLs to one irrelevant page, such as the new homepage, can be treated as a soft 404.
02
How long should I keep redirects after a site migration?
What if only the hosting changes and the URLs stay the same?
A move to new hosting or infrastructure with identical URLs needs no redirects and no Change of Address, but it still needs a checklist. Google's guide for moves without URL changes is short: prepare the new host, "lower the TTL value for your DNS records," remove "any temporary blocks to crawling" such as robots.txt rules or noindex tags, then update DNS.
Afterwards, "keep an eye on the server logs on both new and old servers," and expect crawl rate to move for a while, because Google determines "crawl rate for a site based on many signals." Shut down the old host only "once the traffic to the old provider reaches zero." A platform change that keeps URLs but rebuilds the templates is different: compare titles, canonicals, structured data and server-rendered content page by page, because those can change even when every URL survives.
What should you do before the migration?
Before the move, capture the complete list of URLs that carry traffic or links, record a baseline you can compare against, and build the new site so it is ready to be indexed from the first minute. Every problem found here costs minutes to fix; the same problem found after launch costs weeks of rankings.
Crawl the old site and export every URL. A crawler such as Screaming Frog's SEO Spider (free up to 500 URLs) gives you the list with status codes, titles and canonicals.
Add URLs a crawl misses: every URL in your XML sitemaps, your top pages from the Search Console Performance report (export the Pages tab for the last 16 months), and the target pages in the Links report, which are the URLs other sites link to.
Record a baseline: clicks and impressions per page, the indexed count from the Page indexing report, and a copy of each key page's title, meta description and main heading.
Build the new site with self-referencing canonical tags, internal links that point at the new URLs directly, and a new XML sitemap listing only new URLs.
Check the new site's robots.txt. Google's site move guide says to make sure "the rules in the new site's robots.txt file correctly reflect the parts you want blocked from crawling."
Keep the staging copy behind a password, and write down every staging-only noindex so you can remove each one at launch.
How do you build the redirect map?
Map every old URL to the single new URL that serves the same purpose, and redirect it with a permanent status (301 or 308) in one hop. The map is a two-column table (old URL, new URL) that becomes your redirect rules and your test script. A URL with no equivalent should return 404 or 410, not a redirect to the homepage.
Google is direct about the homepage shortcut: do not "redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site. This can confuse users and might be treated as a soft 404 error."
Old URL
New URL
Status
Notes
/blog/2024/05/pricing-guide
/blog/pricing-guide
301
Same content, new path
/features/integrations.html
/integrations
301
Extension dropped
/pricing?plan=pro
/pricing
301
Parameter URL to its canonical
/old-webinar-2023
none
410
No replacement; do not send to the homepage
oldbrand.com/docs/setup
newbrand.com/docs/setup
301
Domain move, path kept
Rules that prevent most redirect bugs:
One hop only. Google's crawlers follow "up to 10 redirect hops," but every extra hop is a chance to break; redirect old URLs straight to their final destination, including the https and www variant you settled on. Redirect chains and loops shows how to trace them with curl -sIL.
Permanent, not temporary. Google treats a 301 as "a strong signal that the redirect target should be processed" and a 302 as a weak one. 301 vs 302 vs 307 vs 308 covers which to use.
Cover the variants: trailing slash and no trailing slash, uppercase paths, index.html, and old query strings that were indexed.
Keep path redirects on the server or edge, not in client-side JavaScript, so every crawler sees them.
Test the map before launch with a script that reads it line by line:
# map.tsv: old_url<TAB>new_url, one pair per line
while IFS=$'\t' read -r old new; do
result=$(curl -s -o /dev/null -w '%{http_code} %{redirect_url}' "$old")
[ "$result" = "301 $new" ] || echo "MISMATCH $old -> $result (expected 301 $new)"
done < map.tsv
What do you do on migration day?
On the day, switch on the redirects, remove every staging noindex and password from the new site, submit the new sitemap, and, for a domain move, file the Change of Address. Then check a sample of URLs by hand before announcing the move, because a missed rule is cheapest to fix in its first hour.
Deploy the redirect rules and run the test script against production.
Remove staging noindex tags, X-Robots-Tag headers and the password from the new site, then confirm with curl -sI and a view of the page source.
Submit the new XML sitemap in Search Console for the new property.
For a domain or subdomain move, open the Change of Address tool in the old property's settings. Google's prerequisites are that you are "an owner of both the old and new properties in Search Console" using the same Google account, and that 301 redirects from the old site to the new one are in place.
Run URL Inspection's live test on the new homepage and a few key pages, and request indexing for the most important ones.
Update the links you control: social profiles, directory listings, email signatures, app store pages and your own docs.
What should you monitor after a site migration?
Track indexing on both sites, 404s, and clicks per page, weekly for at least the first month. Google says that for medium-sized websites "it can take a few weeks or more for Google to gradually start showing the new URLs instead of the old ones," so rankings will move during that window. What you are looking for is a trend that stalls or reverses.
What to check
Where
Healthy pattern
Indexed pages on the old site
Page indexing report, old property
Falling, with the old URLs listed under Page with redirect
Indexed pages on the new site
Page indexing report, new property
Rising toward the old site's baseline
Not found (404)
Page indexing report, new property
Only URLs you retired on purpose
Clicks per page
Performance report, both properties
New URLs gaining what old URLs lose
Redirect behaviour
Your test script, run weekly
No mismatches
Keep the redirects in place. Google's guidance is to "keep the redirects for as long as possible, generally at least 1 year," because that time "allows Google to transfer all signals to the new URLs." For a domain move, keep the old domain registered for at least as long, or the redirects disappear with it. The Change of Address tool notes that "you will see these notifications for 180 days" in Search Console after you file the move.
If traffic falls and stays down, compare the old and new pages for what carries rankings: content, headings, internal links and rendering. Traffic drop after a redesign walks through that comparison.
What are the most common site migration mistakes?
The mistakes that cause lasting losses are the ones Google cannot see past: redirects that are missing or point to the wrong place, directives carried over from staging, and content that did not make the move. Every one of them is visible in the first days if you look.
Redirecting everything to the homepage instead of mapping one to one.
Leaving a staging noindex or Disallow: / on the new site at launch.
Blocking the old site in robots.txt after the move, so Google cannot crawl the old URLs and follow their redirects.
Using 302 redirects for a permanent move.
Leaving internal links, canonicals and the sitemap pointing at old URLs, so every internal click goes through a redirect.
Cutting copy, FAQs or comparison tables from pages that ranked because they did not fit the new design.
Moving content into client-side rendering during a platform change.
Letting the old domain expire a few months after the move.
Watch the new site after the move
The first weeks after a migration are when a missed redirect, a returning noindex or a broken template does the most damage, and a weekly script only checks the URLs you gave it. LaunchScaler Watch re-scans the new site every two weeks for $29/mo, including the scan's redirect, canonical, sitemap and noindex checks, emails a diff on every run with the evidence behind each change, runs uptime checks on your health endpoint in between, and alerts you when a check drops below the bar. Start watching.
Google says to keep redirects for as long as possible, generally at least 1 year, so it can transfer all signals to the new URLs. Keep the old domain registered for at least as long, because the redirects stop working the day it lapses.
03
Do I need the Change of Address tool?
Only when you move from one domain or subdomain to another, such as example.com to example.org. It is not for HTTP to HTTPS moves, www changes or path changes within a domain, and you must own both properties in Search Console and have 301 redirects in place.
04
How long does it take Google to process a site migration?
Google says that for medium-sized websites it can take a few weeks or more for it to start showing the new URLs instead of the old ones. Expect rankings to fluctuate during that time.
05
Will I lose traffic after a site migration?
Some fluctuation is normal while Google recrawls both sites. A lasting loss usually traces back to missing or wrong redirects, content cut from pages that ranked, a noindex or robots.txt rule carried over from staging, or internal links still pointing at old URLs.
