Site migration checklist for SEO: before, during, after

Short answer: Before the move, crawl the old site and map every old URL to the one new URL that best replaces it. On move day, remove staging blocks, turn on server-side 301 or 308 redirects that go straight to the final URL, and, if the domain changes, file Change of Address in Search Console. Afterwards, submit sitemaps, update links and watch Search Console. Google says a small to medium site can take "a few weeks for most pages to move" and that you should keep redirects for at least a year.

This checklist covers the moves founders make: a new domain, a URL restructure, a platform change, a move to HTTPS and a hosting change. It follows Google's site move guide (last updated 20 August 2026) and adds the free tools we'd use at each step. For the vocabulary, see our glossary entries on site migration, 301 vs 302 redirects and redirect chains.

Which kind of move is it?

One rule applies to all of them: change one thing at a time. Google's example is a site that wants a new domain, a new CMS and a new layout. Do them "one at a time". The Change of Address help adds the reason: if you combine a move "with a redesign of the site's content and URL structure in the new location, you will probably see some traffic loss as Google might need to relearn and reassess the individual pages."

What's different for each kind of move

• New domain. Keep the site's structure the same if you can: Google says that "keeping the same site architecture in the new location helps to pass the signals more directly to the new site." Don't chain moves, because after a change of address from site A to B you "can't immediately submit another change of address from site B to site C." If you're merging several sites into one, move them one at a time and wait for traffic to settle between moves. If you bought the new domain, check its Manual actions and URL removals for leftovers from the previous owner.
• URL restructure on one domain. No Change of Address. Google's advice for moving pages inside a site is to "just add redirects, and update your sitemaps as appropriate." Every URL you rename is a redirect you must keep for a year, so rename only what you must.
• HTTP to HTTPS. Get the TLS certificate working first, then redirect every HTTP URL to its HTTPS twin and update canonicals, sitemaps and internal links. A Search Console Domain property already covers both protocols.
• Platform change. A new platform often changes more than URLs: titles, headings, canonicals, structured data, internal links and what's rendered on the server. Crawl the old and new versions and compare them before launch. If the new platform can keep your old URL pattern, keep it, and there's nothing to redirect.

Before the move

1. Benchmark the old site. Google's guide: "Use web analytics to analyze usage on both the old and new sites." Export Search Console's Performance data (top pages and queries) and note where your money pages rank. Without a baseline you can't judge the result.
2. List every old URL. Google's sources: your sitemaps, server logs or analytics for pages with traffic, Search Console's Links report for pages with links, and your CMS's content list. Include images, videos, JavaScript and CSS files. Our sitemap URL extractor exports a sitemap to CSV, and Google's guide names Screaming Frog for crawling. Save the list of sites that link to your old URLs.
3. Build the redirect map. One old URL to the one new URL that replaces it. Google says not to send many old URLs to a single irrelevant page such as the new home page, because that "might be treated as a soft 404 error." Merged pages can share a destination. Content you're dropping should return 404 or 410 on the new site. Our redirect generator turns the list into rules for Apache, Nginx, Vercel, Netlify, Next.js and Cloudflare, checked for loops, chains and duplicates.
4. Use permanent, server-side redirects with no chains. Google recommends 301 or 308, with client-side redirects only "as a last resort." Googlebot follows up to 10 hops, but Google advises "redirecting to the final destination directly," and if that's impossible, "no more than 3 and fewer than 5." Flatten chains in the map, not after launch.
5. Prepare the new site. Each new URL needs a self-referencing rel="canonical", and any hreflang annotations must use the new URLs. Update internal links in the new copy. Move the images and downloads, and set up TLS for an HTTPS move. Plan the server for load too: "after a migration, Google will temporarily crawl your new site more heavily than usual."
6. Plan the robots.txt and noindex switch. Many teams block staging. Write down what robots.txt must say at move time and list the pages where noindex has to come off.
7. Set up Search Console. Verify the old and new sites, every variant. Make sure your verification method still works on the new copy, and re-upload any disavow file to the new property.
8. Pick the timing and scope. Move when traffic is low. Google recommends that small and medium sites move all URLs together because it helps "our algorithms detect the site move and update our index faster." Large sites can move in sections. For a hosting-only move, lower your DNS TTL "to a conservative low value (for example, a few hours) at least a week in advance."

On move day

1. Remove staging blocks. Google lists "noindex or robots.txt blocks that were only needed for the migration" as the first common mistake. If the new site has no robots.txt, it should return a real 404. Check key pages in the robots.txt tester and the noindex checker.
2. Turn on the redirects. Server-side 301 or 308, straight to the final URL.
3. Test them. Google says: "We frequently see people redirecting to the wrong (non-existent) URLs on the new site." Use URL Inspection for single URLs. For samples from every template, trace them in the redirect checker, which shows each hop's status code. For many URLs at once, use the HTTP status checker.
4. Check canonicals. Once the redirects are live, canonicals on the new site must use the new URLs. The canonical checker reads the tag and the HTTP header.
5. File Change of Address, for domain moves only. Google says to use the tool "after you've moved and redirected your site." You must own both properties with the same Google account, and the tool works on domain-level properties, not paths. File it for every variant of the old domain, "including www and non-www," even unused ones. Search Console then shows a notice for 180 days.
6. Submit sitemaps. Add the new sitemap; Google says this "will help Google learn about the new URLs." To track the move, keep a sitemap of the old URLs too. Search Console may warn that those URLs redirect, which Google calls "normal." Compare the two lists with sitemap compare and check the files in the sitemap checker.
7. Update links. Internal links first. Then ask the sites that link to you to update theirs, starting with the ones that send the most visits, and fix social profiles and ad campaigns.

After the move: what to watch, and for how long

The recap row is an attendee's account of a Google talk, not a Google publication. Treat it as a range, not a promise.

Check these weekly for the first month:

• Sitemaps report. Google's picture: "Initially, the sitemap containing the new URLs would have zero pages indexed, while the sitemap of the old URLs would have many pages indexed." Over time the old count falls to zero as the new one rises.
• Page indexing report. Look for a jump in "Not found" errors, and for redirect errors or soft 404s. Our Search Console guide explains the report.
• Performance report. New URLs should start collecting impressions and clicks as the old ones fade.
• Server logs and analytics. Check Googlebot's crawling and any URL that "unexpectedly" returns an error. Old-site traffic should fall as new-site traffic rises.
• Broken links. The broken link checker finds 404s and redirects inside your pages. If you work with Claude, Cursor or Codex, the LaunchRanked MCP server has check_links, which checks up to 100 links on a live page for broken links and redirects, and its description says to use it after a migration. check_sitemap validates the sitemaps.

Mistakes that cost the most

• Staging blocks left on. A Disallow: / or noindex shipped to production. Google's list puts it first.
• Everything redirected to the home page. It reads as a soft 404, and visitors lose the page they wanted.
• Redirects that point to URLs that don't exist. Test the destination, not just the redirect.
• Chains left over from earlier moves. Collapse them. Google's crawl budget guide: "Avoid long redirect chains, which have a negative effect on crawling."
• Sitemaps and internal links still on old URLs. Google lists "Not updating sitemaps" as a common mistake.
• A redesign in the same release. See the Change of Address warning above.
• Redirects removed after a few months. Keep them at least a year.
• Forgotten files. Images, PDFs, CSS and JavaScript need moving and redirecting too, as do hreflang tags. The hreflang checker tests the return links.

What we'd do on a small site

This part is our advice, not Google's. Keep the redirect map in your repository, so it's reviewed like code. Test a sample from every page template, not only the home page. Put two reminders in the calendar: one at 180 days for the Change of Address window and one at 12 months for the redirects and the old domain's renewal. The full technical list for the new site is in our technical SEO checklist. We opened every source here on 8 October 2026.