Site Migrations Without Losing AI Citations: The AEO Playbook for Domain Changes

A site migration handled by the traditional SEO playbook alone will cost you AI citations for months. The reason is structural: 301 redirects tell crawlers where you moved, and retrieval-backed engines like Perplexity and ChatGPT's browsing mode follow them within weeks. But a large share of AI answers are generated from model weights trained on a snapshot of the web where your old domain was the truth. That memory does not follow a redirect. It updates only when the model is retrained, and you do not control that schedule.

So the goal of an AEO-aware migration is different from a rankings-preservation project. You are managing two clocks at once: the crawl clock, which you can accelerate with clean redirects and parity, and the training clock, which you can only wait out while keeping the old domain resolving so stale mentions still land somewhere useful.

This playbook covers both clocks: the redirect map, parity on the new stack, entity reference updates, and what to monitor after cutover.

Why AI citations lag months behind redirects

AI engines produce answers through two distinct paths, and a migration affects them differently.

Retrieval-grounded answers. When an engine fetches live pages before answering - Perplexity's default behavior, ChatGPT with search, Gemini grounding on Google's index - it inherits the freshness of the underlying index. A clean 301 map consolidates your new URLs in those indexes on roughly the same timeline as a traditional migration. This path recovers first.

Parametric answers. When the model answers from its weights, it reproduces what the web said at training time. If your brand lived at oldbrand.com for five years, the model has seen thousands of pages, forum threads, and directory listings asserting that association. It will keep saying oldbrand.com in answers, keep linking it when asked for your site, and keep associating your product's reputation with the old name. No redirect reaches inside a model checkpoint.

This is the same staleness mechanism we describe in the anatomy of a lost citation, except triggered deliberately by you. The practical consequence: even a flawless migration shows a period where retrieval-based citations point to the new domain while parametric mentions still name the old one. Plan for that split instead of being surprised by it.

Build the full 301 map before you touch DNS

Redirects are the one lever that works on every consumer of your site - Googlebot, GPTBot, ClaudeBot, PerplexityBot, and every user who clicks a stale link inside an AI answer. Get them right at page level, not just at the domain level.

• Map every URL, not just the top pages. Export the old site's full URL inventory from your sitemap, server logs, and analytics. AI engines cite deep pages heavily - Ahrefs found that 38% of AI Overview citations in their 2026 update came from pages outside the top 10 organic results (down from 76% in the earlier 2025 finding), so the long tail of your site is citation inventory, not dead weight. See the AI search statistics roundup for the full context on that number.
• One hop, status 301. Chains and 302s waste crawl budget and blur the permanence signal. Old URL to final new URL, one hop, permanent.
• Redirect the assets too. Images, PDFs, and your old /llms.txt path all get fetched by AI crawlers. A 404 on the old llms.txt is a silent gap.
• Keep the old domain registered and serving redirects indefinitely. This is the AEO-specific rule. Models will emit the old domain in answers for months or longer. Every one of those stale mentions is a user landing on oldbrand.com. If the domain lapses or the redirect layer gets decommissioned after "the migration is done," those users hit a parked page - or a squatter. The old domain is now permanent infrastructure.

Ship parity on the new stack, not just the new pages

Replatforms are where AEO signals quietly die, because the new stack has different defaults. Before cutover, verify each of these exists on the new origin and matches or improves on the old one.

robots.txt. New frameworks and hosts ship their own defaults, and some CDN onboarding flows enable AI-bot blocking out of the box. Confirm the AI crawlers you previously allowed - GPTBot, ClaudeBot, PerplexityBot, Google-Extended - are still allowed. OpenAI documents its crawlers at platform.openai.com/docs/bots, and our robots.txt guide for AI crawlers covers the full roster. The AI crawler access checker verifies the live file in seconds.

llms.txt. Regenerate it for the new domain - every URL inside it must point at the new host, not redirect through the old one. Validate with the llms.txt checker after cutover.

Schema parity. Diff the JSON-LD output of old and new templates. Replatforms commonly drop Organization, BreadcrumbList, or Article markup because the new theme "handles schema differently." Your Organization node needs special care during a migration; the Organization schema deep dive explains why it anchors entity identity, and a migration is exactly when that anchor matters most.

Rendering parity. If the new stack is client-side rendered where the old one was server-rendered, AI crawlers that do not execute JavaScript will see an empty shell. Fetch key pages with curl and confirm the answer content is in the raw HTML.

Content parity. Resist the urge to rewrite everything during the move. Pages earn citations partly through specific extractable passages. Migrate first, measure, then revise - so you can tell migration effects apart from content effects.

Update every external assertion of your entity

Models learn your domain from the whole web, not just from you. After cutover, the web is full of third-party pages asserting the old association, and each one you update shortens the training-clock lag.

• Organization schema. Set url to the new domain and keep the sameAs array accurate on day one. Keep the same @id strategy if you can, so the entity graph reads as "same organization, new address" rather than a new entity.
• Wikidata and Wikipedia. If your organization has a Wikidata item, update the official website property (P856). Knowledge graphs and grounding pipelines read Wikidata directly.
• Directories and profiles. Crunchbase, G2, Capterra, GitHub org, LinkedIn, X, product directories, package registries - anywhere the old URL appears as your canonical home. Prioritize the ones that rank for your brand name, because those are what retrieval fetches when someone asks an engine about you.
• High-authority backlinks. You will not get every link updated, and redirects cover the click. But partners, integration pages, and press outlets that actively maintain content are worth an email, because the visible text of a link ("find them at oldbrand.com") feeds future training data even when the href redirects.

Monitor old-domain mentions after cutover

Post-migration monitoring is where AEO diverges most from classic SEO. Rankings dashboards will show recovery; AI answers need their own watch.

Run a fixed prompt set weekly across ChatGPT, Claude, and Gemini: your brand name, your category head terms, and "what is [brand]'s website." Track three things - whether you are cited at all, which domain the citation points to, and whether the engine narrates the migration correctly or describes the old brand as current. Expect retrieval-heavy engines to flip to the new domain first and parametric answers to trail. A model release or index refresh is often visible as a step change in your numbers rather than a gradual drift.

Citevera's bundled citation monitoring runs exactly this loop across all three engines on every paid plan, which turns "are we still dark on Gemini" from a guess into a chart. Manual spot checks work too; the discipline that matters is a consistent prompt set and a weekly cadence.

Timeline expectations: what recovers when

Treat these as phases driven by mechanism, not as promised durations - every index and model updates on its own schedule.

Cutover week. Traffic follows redirects immediately. Live-retrieval engines may cite the old URL with the old title until they recrawl.

The following weeks. Search indexes consolidate to the new URLs, and retrieval-grounded citations follow. This is where clean one-hop redirects and parity pay off fastest.

The following months. Parametric mentions of the old domain persist until affected models retrain or refresh grounding data. Third-party reference updates (Wikidata, directories, active backlinks) are your main lever here.

Long tail. Occasional old-domain mentions can surface indefinitely from older model checkpoints. This is why the old domain stays registered and redirecting permanently.

Frequently asked questions

How long until AI engines cite my new domain?

Retrieval-grounded engines typically follow within their normal recrawl cycle once redirects and sitemaps are clean - a timeline comparable to a traditional migration. Parametric answers from model weights lag until the models behind each engine retrain or refresh, which can take months and is outside your control. Monitor weekly rather than assuming a date.

Should I keep the old domain forever?

Effectively yes. Models will emit the old domain in answers long after cutover, and every stale mention is a real user clicking through. Renewal is cheap insurance; a lapsed domain turns your residual AI visibility into a squatter's traffic.

Do AI crawlers follow 301 redirects?

The major documented crawlers - GPTBot, ClaudeBot, PerplexityBot, Googlebot and Google-Extended - are standard HTTP clients and follow redirects when fetching. Keep chains to one hop and make sure the old domain's robots.txt does not block them from reaching the redirect in the first place.

Should I migrate content and redesign at the same time?

Avoid it if you can. Citations attach to specific extractable passages, and if you change domain, templates, and copy simultaneously, you cannot attribute a citation drop to any one cause. Migrate with content parity, hold for a measurement window, then revise deliberately.

Does llms.txt transfer through a redirect?

Serving a redirect from the old /llms.txt to the new one covers polite fetchers, but do not rely on it: publish a fresh llms.txt on the new domain with all internal URLs pointing at the new host, and validate it after cutover.

Run parity checks before and after cutover

The failure mode in AEO migrations is rarely the redirect map - teams get that right. It is the parity gaps on the new stack: a default robots.txt that blocks AI bots, a dropped Organization node, an llms.txt still listing old URLs. A Citevera audit run against staging before cutover and against production after gives you a before-and-after score on exactly those axes, and the free crawler access and llms.txt checkers linked above cover the two highest-risk files in under a minute. Migrate on two clocks, verify the one you control, and wait out the other with the old domain still resolving.