Every migration checklist you'll find covers the Google side: redirects, canonical tags, Search Console, crawl budget. Almost none cover the layer where a growing share of your buyers now discover you, and the AI layer breaks by different physics. Engines keep citing URLs for weeks after they die. New stacks ship with crawler-blocking defaults nobody chose on purpose. And the entity familiarity a brand spent years accumulating doesn't follow a 301. Here's the AI search migration checklist, organized the way migrations actually run: before the cut, during, and the sixty days after.
Why AI Visibility Breaks Differently
The evidence worth internalizing before planning anything: AI citations are sticky, in both directions. One practitioner deliberately 404'd fifteen pages that carried active AI citations and watched what happened; nine kept appearing in answers after death, and the heavily-cited ones persisted for three to four weeks.
Read that as a migration planner and the implications stack up fast. For weeks after your cut, engines will keep sending buyers to your old URLs, so those URLs must redirect or every zombie citation becomes a 404 with your brand on it, served at the exact moment you're trying to look bigger and better. The same stickiness runs forward: your new URLs won't be cited instantly, so expect an overlap window where visibility appears to dip while caches refresh. And because staleness masks breakage, a migration that quietly killed your AI visibility can look fine for a month, which is exactly long enough for everyone to stop watching.
Add the two structural risks and the picture completes. New infrastructure, a different CDN or a stricter security layer, routinely blocks AI crawlers by default, and nobody notices because Googlebot still gets through. And if the migration includes a rebrand or domain change, the entity layer resets: models that learned your old name from years of text don't transfer that familiarity to the new one, which is a cost no redirect map can pay down. A same-domain replatform is a plumbing job; a rebrand is plumbing plus starting a reputation.
Before the Cut: T-minus 30 Days
Build the citation baseline. Run your fixed prompt panel, the 15-25 buyer questions that matter, across ChatGPT, Perplexity, and Gemini, logging two columns separately: where you're named and which URLs get cited. Without this you cannot distinguish "migration killed our visibility" from "we were never visible," and post-migration is too late to find out.
Inventory the protect-list. From the panel plus your analytics, list every URL carrying active AI citations or AI-referred traffic. This list gets first-class treatment in the redirect map, and its pages should move with URLs preserved wherever the migration allows.
Snapshot the crawler logs. Pull the last month of AI crawler activity, which bots fetch what, how often. This becomes your comparison set for confirming the new stack serves the same crawlers.
Export the dashboards. Search Console's Generative AI report, your GA4 AI channel data, Bing Webmaster Tools. Migrations reset enough reporting surfaces that the before-picture is worth thirty minutes of exports.
See your first AI citation report in under 5 minutes.
No setup calls. No onboarding meetings. Connect your domain and see where AI mentions your brand right now.
During the Cut
Redirect by citation priority. The protect-list redirects first and gets manually verified, one by one, the day of the cut. Everything else follows the normal 301 map. Hmm, one prioritization note that classic checklists get backwards: SEO logic prioritizes redirects by search traffic, but AI-cited pages deserve equal rank even when their referred traffic looks small, because a citation is a live recommendation being served to buyers right now, and a 404 behind it burns trust you can't see burning.
Audit the new stack's doors before launch. Fetch key pages as GPTBot, OAI-SearchBot, ClaudeBot, and PerplexityBot against the staging environment. New CDNs and security layers block first and ask never; find the block before the crawlers do.
Check what the fetchers actually see. If the replatform changed rendering, confirm the content survives without JavaScript: server-rendered pages with semantic markup are what AI fetchers parse, and a redesign that moved your pricing into a client-side component just removed it from every AI answer.
Regenerate the machine surfaces. New sitemap submitted everywhere, llms.txt regenerated if you keep one, structured data carried over and matching the visible content.
Keep the old domain alive. For domain changes: the old domain serves redirects for years rather than months. The 404 experiment says weeks of citation persistence at minimum; entity memory says longer.
After the Cut: The Sixty-Day Watch
Rerun the panel weekly. Same prompts, same logging. Expect the dip-and-recover shape: old URLs fading from answers, new ones appearing over several weeks. What you're watching for is the dip that doesn't recover, which means something structural broke and the staleness window hid it.
Hunt zombie and hallucinated URLs. Watch 404 logs for recurring paths arriving with AI referrers or matching your old structure. Engines will keep citing dead URLs, and sometimes cite URLs that never existed; practitioners increasingly redirect these hallucinated paths to the closest real page, converting dead ends into landings. You need the monitoring to know which URLs to catch, and each catch is recovered intent.
Verify crawler parity. Compare AI crawler activity on the new stack against your baseline snapshot. Missing bots mean a door is closed somewhere, and the traffic-drop checklist runs the diagnosis in order.
Re-verify the reporting surfaces. GSC on the new property, Bing Webmaster Tools re-verified, GA4 channel group patterns updated if the domain changed.
Your competitors are building backlinks while you read this.
Organic outreach, social mentions, and link exchanges, with managed backlinks available as an add-on. Grow your domain authority without running the campaign yourself.
The Recovery Curve, Annotated
Knowing the healthy shape in advance is what keeps week two calm. Days one through seven: answers still cite your old URLs heavily, redirects absorb the clicks, and nothing looks changed, which is the staleness window doing you a favor. Days seven through twenty: the mix shifts, old URLs fade from some answers, new ones start appearing in others, and your panel numbers wobble; this is the stretch where teams panic and start reverting things, and the wobble is normal. Days twenty through forty-five: new URLs carry a growing share of citations, engine by engine at different speeds, with the slowest engines still serving stale answers past day thirty. By day sixty: the panel should match or beat the T-30 baseline. The failure signature is different in kind, and it's why the weekly rerun matters: a curve that dips and flattens instead of recovering, or one engine going dark entirely while others recover, points at a structural break, a blocked crawler or a rendering gap, hiding behind what looked like normal cache lag.
Who Owns This
One organizational line, because it decides whether any of the above happens: migrations are run by engineering and project managers, and the AI checklist dies unless it has a named owner inside the migration plan. Give the SEO or growth owner three deliverables with dates, the T-30 baseline and protect-list, cut-day verification of redirects and crawler access, and the weekly panel through T+60, and make the protect-list a formal input to the redirect ticket rather than a side-channel Slack message. Checklists without owners are wishes.
The Condensed Checklist
Print this half, pin it to the migration ticket.
- T-30: fixed prompt panel baseline, citations and name-drops logged per engine
- T-30: protect-list of every AI-cited URL, flagged in the redirect map
- T-30: AI crawler log snapshot, dashboard exports
- Cut day: protect-list redirects verified manually; staging fetched as all four major AI user agents
- Cut day: rendering check without JavaScript; sitemap and machine files regenerated
- Cut day: old domain redirect policy set to indefinite
- Weekly to T+60: panel rerun, dip-and-recover watched per engine
- Weekly to T+60: 404 logs mined for zombie and hallucinated URLs, redirects added
- T+14 and T+45: crawler parity check against baseline
- T+60: full before-after readout against the T-30 baseline
The Special Cases
Three migration shapes, three risk levels. A same-domain replatform with preserved URLs is the gentle case: your work concentrates on crawler access and rendering, and citations mostly never notice. A URL restructure on the same domain is the middle case: the redirect map carries everything, and the protect-list discipline decides how much sticks. A domain change or rebrand is the hard case, because the entity layer resets no matter how clean the plumbing is; models learned your old name from the whole internet's text, and the new name starts from near zero. For that case, budget real earned-media effort in the quarter after the cut, since engines recommend what the web already talks about, and the fastest entity rebuild is other people's pages using your new name.
So which migrations go wrong? The ones where the AI layer was assumed to follow the Google layer automatically, and rarely the ones where someone owned this list. That assumption fails because the AI layer has its own caches, its own crawlers, its own refresh cadence, and its own memory. Baseline before, verify during, watch after, and the weekly per-engine tracking that makes the watching automatic is the difference between finding a broken door in week one and explaining a mystery in month three.
You're getting AI traffic. But do you know where it comes from?
RankControl credits every visit to the assistant that sent it: ChatGPT, Perplexity, Claude, Gemini, Copilot, or Grok. Full source attribution, next to your Google traffic.
