Every site migration checklist you can find covers the same ground. Map old URLs to new ones. Implement 301s. Update canonical tags. Resubmit the sitemap. Watch Search Console for crawl errors.
That checklist is correct and incomplete. It was written for a world with one crawler that mattered, and it assumes the thing you are protecting is a ranking position that will recover once the redirects are honored. AI citations do not work that way, and a migration that Google absorbs cleanly in two weeks can knock out citations on other engines for considerably longer.
Why Engines Notice a Migration at Different Speeds
This follows directly from the retrieval architecture differences covered in the parametric versus retrieval memory guide, and it produces a predictable staggered pattern.
An engine doing live retrieval on every query, like Perplexity, discovers your new URLs roughly as fast as it recrawls. Follow the redirect, find the content, cite the new address. This is the fast case.
Google's AI surfaces sit in the middle. They draw on the standard index, so migration recovery there tracks roughly with organic recovery, which is the timeline your existing checklist already accounts for.
Engines drawing heavily on training data are the slow case, and the one nobody plans for. If a model learned about your content at the old URL during a training run, that association does not update because you shipped a redirect. It updates when the model is next trained. You cannot accelerate this. No redirect, no sitemap ping, no indexing API call reaches into a model's existing weights.
So the honest expectation for a migration is: fast recovery on live retrieval engines, normal recovery on Google, and a genuinely long tail on training dependent engines where you may see reduced citation for months regardless of how well you executed the technical work.
The Part That Actually Causes Damage
Redirect chains. The content pruning guide touches on this, but migrations produce chains at a scale that consolidation projects rarely do.
Here is how it happens. You migrated in 2023 and mapped old to new. You migrate again in 2026 and map current to new. Now the 2023 URLs point at the 2026 URLs through two hops, because nobody went back and flattened the first migration's map. Add a trailing slash normalization rule and an HTTP to HTTPS rule and you can reach four hops without anyone doing anything obviously wrong.
Googlebot tolerates a few hops. AI crawlers vary in how many they follow, and some give up earlier. A chain that Google resolves fine can dead end for a different crawler, which means the content is simply gone from that engine's perspective.
Flatten every chain to a single hop. Old URL points directly at final destination, not at an intermediate that points somewhere else. This means going back through prior migration maps and rewriting them, which is tedious and is the step most teams skip.
Internal Links Are Not Optional Cleanup
Leaving internal links pointing at redirected URLs is the most common post migration failure I see, and teams treat it as a nice to have because the site still works. Users get where they are going. Nothing is visibly broken.
But every internal link pointing at a redirect is a hop you are forcing every crawler to make on every discovery pass, forever. It also muddies the signal about which URL is authoritative, exactly as covered in the internal linking guide. Rewrite them to point at final destinations. Navigation, in content links, footers, related post modules, and anything generated from a database field.
Keep Content Identical Through the Move
The strongest thing you can do for citation continuity is boring: change the address, not the content. If a page earns citations because a specific paragraph answers a specific question well, and the migration also rewrites that paragraph as part of a redesign, you have changed two variables at once and you will not be able to tell which one caused any drop.
Migrate first. Confirm stability. Rewrite later as a separate project. I know this is not how redesign timelines usually work, and I know a redesign is often the reason for the migration in the first place. But if there are specific pages you know are earning citations, argue to hold their content constant through the move even if everything around them changes.
What to Do Before You Migrate
Record a citation baseline while the old site is still live. This is the step that makes everything after it possible, and once you have migrated you cannot go back and capture it.
Run your tracked prompts across engines and record which URLs are being cited, on which prompts, with what text. Without that you will have opinions about whether the migration hurt you and no evidence.
Also export your full URL inventory including PDFs and other non HTML assets, which migration maps routinely omit. See the PDF guide for why those are easy to lose track of.
After Launch
Check the new site's robots.txt on day one. Staging environments are usually configured to block everything, and shipping that configuration to production is common enough that it deserves to be the first thing you verify rather than the last.
Verify redirects resolve in one hop, sample across your highest value URLs rather than trusting the map file. Confirm the sitemap lists only new URLs with no redirected entries. Then wait, and resist the urge to conclude anything for at least a few weeks, because the staggered recovery pattern described above means early data will look worse than the eventual outcome.
Tracking It
The staggered recovery is only visible if you are tracking per engine rather than in aggregate. An aggregate number blends fast recovery and slow recovery into one line that tells you very little.
The NotionCue Citation Tracker reports per engine, which is what makes the pattern in this post legible in your own data instead of something you have to take on faith. The AI Crawler Audit handles the day one verification, catching the staging robots.txt problem and rendering failures before they cost you weeks.
Start your free NotionCue trial and capture your baseline before the migration, not after. This is one of the few things in AEO where timing is genuinely unrecoverable if you miss it.
If you are mid migration and did not capture a baseline, capture one now anyway. A post launch baseline is worth less than a pre launch one but considerably more than nothing, and it at least lets you measure recovery from wherever you currently are.
Common Questions
How long before I can say a migration went badly?
Give live retrieval engines a few weeks and Google roughly a normal organic recovery window. Training dependent engines are a longer wait and a flat result there at eight weeks is not yet evidence of a problem.
Do 302s work if I plan to move back?
For a genuinely temporary move, yes. For a permanent migration, no. A 302 tells crawlers the old URL is still authoritative, which is the opposite of what you want when consolidating onto a new address.
Should I keep old URLs alive instead of redirecting?
No. Two live addresses serving the same content is the duplication problem covered in the canonicalization guide, and you will have split your signal across both rather than consolidating it.