Site Migration SEO Checklist: Keep Rankings and AI Citations

A site migration SEO checklist is the ordered set of tasks that moves a website to new URLs, a new domain, or a new platform without losing rankings: map every old URL to its closest new equivalent, serve one-hop permanent redirects, update every internal signal, tell search engines about the move, and monitor until traffic settles.

Most migrations that lose traffic do not fail on launch day. They fail weeks earlier, when nobody built a complete URL inventory, or weeks later, when nobody checked that the redirects still work after the next deploy. In 2026 there is a second audience to protect as well: AI answer engines that cite your pages by URL and keep citing the old ones long after you moved. This checklist covers the before, during, and after phases, which redirect to use, and how to keep both rankings and citations intact. To verify individual URLs as you go, use the Redirect Chain Checker and the walkthrough in how to use the Redirect Chain Checker.

What counts as a site migration for SEO?

Any change that alters the URLs search engines have indexed. Google’s guide to site moves with URL changes is the canonical reference. In practice migrations fall into five types, and many projects combine several:

• Domain change. A rebrand or consolidation from one domain to another. The highest-risk type.
• Protocol or host change. HTTP to HTTPS, or www to non-www. Low risk if every variant resolves in one hop.
• URL structure change. New folders, removed dates, flattened categories, a blog moved under a resources path.
• Platform change. Moving CMS or framework. URLs often change as a side effect nobody planned for.
• Content consolidation. Merging sites or folding thin pages into stronger ones, which means many-to-one redirects.

A redesign that keeps every URL identical is not a migration in this sense, but it still deserves the template checks below, because changed titles, removed content, and broken internal links cause the same symptoms.

What should I do before a site migration?

The pre-launch phase decides most of the outcome. Give it at least as much time as the build itself.

1. Build a complete URL inventory. Combine a crawl of the current site, your XML sitemaps, Search Console page reports, analytics landing pages, and any URL with external links. The crawl alone misses orphaned pages that still earn traffic. The XML Sitemap Generator gives you a crawled list to start from.
2. Record a baseline. Positions for your top queries, organic sessions per landing page, indexed page counts, and which questions AI assistants currently cite you for. Track positions with the Google Ranking Tracker and assistant presence with the AI Visibility Score. Without a baseline you cannot tell a migration problem from seasonality.
3. Build the redirect map. One row per old URL, covered in detail in the next section.
4. Protect staging. Keep the new site behind authentication so it is not indexed early. Do not rely on a blanket Disallow: / in robots.txt that someone has to remember to remove. If you do use one, put removing it on the launch checklist by name.
5. Audit templates on staging. Titles, meta descriptions, canonicals, hreflang, structured data, and headings should carry over for every template. Content removed during a redesign is ranking removed.
6. Pick a quiet launch window. Avoid your peak season and avoid Fridays. You want engineers available for the first seventy-two hours.

How do I build a URL redirect map?

A redirect map is a two-column table: old URL, new URL. Every indexed or linked old URL needs a row. The rules that keep it useful:

• Map to the closest equivalent. A product page goes to the same product, a guide to the same guide. Pointing many unrelated URLs at the homepage tends to be treated like a soft 404, and the signals you hoped to keep are lost.
• Use patterns, then exceptions. A rule such as “everything under /blog/ moves to /resources/blogs/” covers most rows. List the exceptions explicitly and test them first.
• Fold in old redirects. Earlier migrations left redirects that now point at URLs you are about to move. Rewrite those to the new final URL so they stay one hop.
• Decide what is genuinely gone. A page with no equivalent, no links, and no traffic can return 404 or 410. That is a legitimate choice, not a failure.
• Preserve query strings deliberately. Decide whether campaign parameters carry through. Dropping them silently breaks paid and email attribution on day one.

Should I use a 301, 302, 307, or 308 redirect?

For a migration, use 301 or 308. The difference between them is HTTP method handling, not SEO. The status codes are defined in RFC 9110, MDN’s guide to HTTP redirections explains browser behavior, and Google’s redirects documentation explains how Search treats each one.

One trap worth knowing: once a browser has seen an HSTS header, it upgrades HTTP to HTTPS itself and shows a “307 Internal Redirect” in developer tools that the server never sent. Browsers also cache 301s. Check what the server actually returns with a server-side tool, not a browser that has already cached the answer.

How do I avoid redirect chains and loops during a migration?

Chains appear when rules stack. The old blog URL redirects to HTTPS, then to www, then to the new folder: three hops where one would do. Googlebot follows up to ten hops, but every extra hop costs latency and crawl requests, and some clients give up sooner. Loops appear when two rules point at each other, which is common when a CDN, a server config, and a CMS all try to enforce the same canonical host.

• Write every rule so it sends the old URL straight to the final URL, including protocol and host, in a single response.
• Own each canonical rule (protocol, host, trailing slash, case) in exactly one layer.
• Before launch, test a sample from every pattern in the map plus every top-traffic URL through the Redirect Chain Checker. Each should show one redirect followed by a 200.
• Test the four host variants (http and https, with and without www) of the homepage and of one deep URL.

What should I update on migration launch day?

Redirects are the safety net. Everything else should point at new URLs directly, so search engines see consistent signals instead of having to infer the move from redirects alone.

1. Ship the redirects with the site. Not an hour later. Every minute the old URLs return 404 is a minute crawlers can record it.
2. Update internal links. Menus, footers, in-content links, and breadcrumbs should all use final URLs. Internal links that rely on redirects slow crawling and blur signals. The Internal Linking Optimizer helps plan the pass, and internal linking for AI search explains why it matters beyond Google.
3. Update canonical tags. Every new page should carry a self-referencing canonical with the new URL. A canonical still pointing at an old URL tells Google the old one is preferred. Verify with the Canonical Checker.
4. Publish new sitemaps. List only new, final, indexable URLs and submit them in Search Console. Validate them with the Sitemap Validator; see how to use the XML Sitemap Generator for building them.
5. Update hreflang. Every language or region variant must reference the new URLs of every other variant, reciprocally. Annotations that are not reciprocal can be ignored.
6. Check robots.txt. Remove any staging block, keep old URLs crawlable so their redirects can be seen, and point the sitemap line at the new sitemap. How to use the Robots.txt Generator covers the syntax.
7. Update structured data and external profiles. Organization URLs in schema, social profiles, business listings, and the backlinks you can actually influence, such as partners and directories.

How do I use the Search Console Change of Address tool?

The Change of Address tool tells Google that a whole domain or subdomain has moved. It is only for domain-level moves. It does not apply to HTTP to HTTPS changes or to restructuring URLs on the same domain. The sequence:

1. Verify both the old and new properties in Search Console under the same account.
2. Put the 301 redirects live first. The tool checks that the old homepage redirects to the new one.
3. Open the old property, go to settings, choose Change of Address, and select the new property.
4. Keep the old domain registered and its redirects running. Letting it expire throws away every link pointing at it.

Bing Webmaster Tools has its own site move feature. If a meaningful share of your traffic or assistant visibility comes through Bing-backed surfaces, submit the move there too.

How long should I monitor SEO after a site migration?

Monitor closely for four to eight weeks, then keep a lighter watch until traffic has matched the baseline for a full month. Google notes that a medium-sized site can take a few weeks for most pages to move, and larger sites take longer. A workable rhythm:

• First 72 hours. Spot-check redirects on top pages, watch server logs for 404 spikes and crawler activity on old URLs, and confirm the new sitemaps were fetched.
• Weeks one to two. Watch Search Console for crawl errors, redirect errors, and pages excluded as duplicates. Fix 404s on old URLs that turn out to have links you missed.
• Weeks two to eight. Compare positions and landing-page traffic against the baseline. Some fluctuation is normal; a page still well below baseline at week six needs a diagnosis, not more patience. Do Google rankings still matter covers which numbers deserve your attention.
• Ongoing. Re-run redirect checks after every deploy that touches routing. Redirect maps are config, and config regresses.

If new URLs are slow to appear in the index, the problem is usually crawl discovery rather than the redirects themselves; how to get pages indexed faster covers the fixes.

What usually goes wrong in a site migration?

• Incomplete inventory. Old PDFs, image URLs, paginated archives, and pages that only existed in an old sitemap were never mapped, so their links now land on 404s.
• Staging robots rules shipped to production. A Disallow: / or a sitewide noindex survives launch and the site drops out of the index.
• Everything redirected to the homepage. Quick to build, and most of the old pages’ relevance is lost.
• Temporary redirects left in place. A platform default issues 302s, and nobody checks the status code.
• Stacked chains. New rules layered on old ones, so legacy URLs go through three or four hops.
• Lost on-page content. The redesign shortened copy, dropped FAQ sections, or removed structured data, so the new page is weaker than the one it replaced even though the redirect works.
• Redirects removed too early. A cleanup a few months later deletes “old” rules that were still carrying links and citations.

Google’s site move guide recommends keeping redirects for as long as possible, generally at least a year. For pages with links or citations, keep them indefinitely.

Why do AI answer engines keep citing my old URLs after a migration?

AI assistants do not share a single, instantly updated index. Depending on the product, an answer may be grounded in a web search index, in the assistant’s own crawl, or in training data collected at an earlier date. Each of those refreshes on its own schedule, and training data does not refresh at all until the next model. So an old URL can keep appearing in answers long after Google has swapped it for the new one. How AI crawlers work explains the different fetchers involved.

You cannot force every assistant to update, but redirects make the lag harmless:

• Clicks still land. A reader who follows a stale citation hits the 301 and arrives on the new page instead of a 404.
• Live fetches still resolve. When an assistant fetches the old URL to ground an answer, it follows the redirect and reads current content. One hop matters here; you cannot assume every fetcher follows a long chain.
• Indexes converge. As the search indexes behind assistants process the redirects, new URLs replace old ones in grounded answers.
• The content has to survive too. A redirect only preserves a citation if the new page still answers the question the old one did. Keep the definitions, data, and FAQ sections that earned the citation.

Track which questions you were cited for before the move, re-check them at four and eight weeks with the AI Visibility Score, and treat a lost citation the way you would treat a lost ranking. The generative engine optimization guide covers how to earn citations back, and a content refresh strategy is a good way to use the migration as a reason to strengthen the pages that matter most.

Frequently Asked Questions

How long does it take for rankings to recover after a site migration?

A clean URL migration on a small or medium site usually settles within a few weeks, and larger sites can take several months. Expect some fluctuation in the first two to four weeks while Google recrawls and reprocesses old and new URLs. Judge the migration at eight weeks against your pre-migration baseline, and investigate any page still down after that.

Should I use a 301 or 302 redirect for a site migration?

Use 301 or 308 for every URL that is permanently moving. Google treats both as a strong signal that the new URL should be canonical. A 302 or 307 tells Google the move is temporary, so the old URL may stay indexed and signals consolidate slowly. Reserve temporary redirects for moves you genuinely intend to reverse.

How long should I keep redirects after a migration?

Google’s site move guidance says to keep redirects for as long as possible, generally at least one year. In practice, keep them indefinitely for any URL with backlinks, bookmarks, or a history of being cited by AI assistants. Redirects cost almost nothing to maintain, and removing them turns earned links and citations into 404s.

Do I need the Search Console Change of Address tool?

Only when you move to a new domain or subdomain, such as old-brand.com to new-brand.com. It does not apply to HTTP to HTTPS moves or to URL changes within the same domain. Set up the 301 redirects first, verify both properties in Search Console, then submit the change from the old property.

Why do ChatGPT and other assistants still cite my old URLs?

Assistants draw on search indexes, their own crawls, and training data collected at an earlier date, and each of those updates on its own schedule. Old URLs can keep appearing in answers for weeks or longer. A permanent redirect is what makes those citations still work: anyone who clicks, and any system that fetches the old URL live, lands on the new page.

Should I block old URLs in robots.txt after a migration?

No. Crawlers have to fetch an old URL to see its redirect. Blocking old URLs in robots.txt hides the redirect, so search engines cannot transfer signals to the new address and the old URLs linger in the index. Leave old URLs crawlable and let the 301s do the work.