Site migrations used to be a two-part problem: preserve rankings, preserve traffic. Now they're a three-part problem, and the third part is harder to see. AI citations are structurally decoupled from Google rankings (only 38% of AI Overview citations come from top-10 organic results as of March 2026, down from 76% in July 2025, per Ahrefs' data linked below), which means a botched migration can nuke an AI citation independently of what happens to your rank. And AI crawlers behave differently from Googlebot in ways that don't show up in traditional migration checklists.
The good news: the fixes are almost all mechanical, and once you know what to look for, the AEO layer of a migration adds about a day of work to a project that was already going to take weeks. What follows is the checklist we run against our own migrations, updated for what actually broke sites in 2025-2026.
Key Takeaways
- AI crawlers tolerate only 3-5 redirect hops in third-party testing (GPTBot / ClaudeBot / PerplexityBot ~5, OAI-SearchBot / Claude-SearchBot ~3), versus Googlebot's documented 10 (CaptainDNS, May 2026). Chain redirects that Googlebot survives can silently drop you from the AI index.
- Only 38% of AI Overview citations come from organic top-10 pages as of March 2026, per Ahrefs' 863K-SERP analysis. Ranking loss and citation loss can happen independently.
- Google's June 17, 2026 site-move guidance update now explicitly requires Change of Address requests for every subdomain variant including www and non-www.
- Server-side 301s only. Most AI training crawlers don't execute JavaScript;
window.location, meta refresh, and JS redirects are invisible to them. - Subdirectory beats subdomain for AI citations, 2-5x on small-sample audits. Migration is the natural moment to consolidate.
Why the AEO Layer Matters Now
Ahrefs' most recent AI Overview data is the clearest single argument for treating AI citations as a distinct migration KPI. In July 2025, 76% of AIO citations came from top-10 organic results. By March 2026, that had dropped to 38%. The two systems are drifting apart, and BrightEdge's 2025 migration guidance made explicit what that means: target retention of at least 95% of AI citations and 90% of organic traffic within 60 days of migration. Two separate targets, both worth tracking.
The stakes are documented. DigitalApplied's analysis of 892 migrations found average recovery time of 523 days and 17% of migrations never recovering after 1,000 days. It takes about a year and a half to recover, and one in six sites never do.
Even Google isn't immune. Glenn Gabe caught them botching their own Nest community migration this May:
It's not often you get to see a Google site migration. Google moved the Nest community to its own support system. How? Every page now uses a meta refresh redirect to the homepage of the new support area. Oof. 313K urls indexed. 🤦♂️ https://t.co/eBdifTrHjS
Glenn Gabe@glenngabeMay 13, 2026313,000 URLs, meta-refresh redirects to a hub page instead of 1:1 server-side 301s. That's the mistake that erases AI citations, ranking equity, and traffic all at once, and it happens because someone shipped a "good enough" redirect strategy. Don't ship a good-enough strategy.
Step 1: Pre-Migration Baseline
Before you touch anything, snapshot the metrics you'll compare against post-launch:
- Organic traffic (90-day window, split by top 20 landing pages)
- Keyword rankings (top 100 tracked keywords)
- Indexed page count (Search Console +
site:operator) - AI citation count (top 30 buyer prompts sampled across ChatGPT, Perplexity, Google AI Mode)
- Valid-schema page count (Rich Results Test / Screaming Frog schema report)
- Referring-domain count (Ahrefs / Semrush)
- Existing redirect-chain count (any URL requiring more than one hop today)
The citation baseline is the one most teams skip. Sample 30 prompts minimum; 100+ if you have the tooling.
Step 2: URL Mapping
Every URL on the old site needs an explicit mapping. Three destination types:
- 1:1 mapping for content with a direct equivalent (server-side 301 or 308).
- Consolidation to a category page for merged content, sparingly.
- 410 Gone for retired content. Don't 301 dead content to your homepage; that's what ate 313K URLs at Nest.
Chains matter more than most guides admit. Aim for zero URLs requiring more than one redirect hop after the migration. If your old site already has 301 chains (previous migrations layered on top of each other), flatten them at the source: update the original rule to point to the final destination in one hop.
Glenn Gabe also flagged the newly-explicit domain-variant requirement from Google's June 17, 2026 documentation update:
A very interesting change in the documentation. Especially since many site owners don't even have those properties set up in GSC. I always recommend having them set up for several reasons. Now Google is underscoring another reason, for domain name changes. I've seen some strange
Glenn Gabe@glenngabeJun 18, 2026The practical impact: if you have example.com, www.example.com, and any subdomains that live in your Search Console footprint, every one of them needs its own verified property and its own Change of Address filing. Skip one and Google's signals-forwarding pipeline treats that variant as a separate migration that never officially happened.
Step 3: Redirect Implementation for AI Crawlers
Here's the piece traditional migration checklists don't cover. AI crawlers behave differently from Googlebot in three ways that matter.
Hop tolerance. CaptainDNS's May 2026 testing found GPTBot, ClaudeBot, and PerplexityBot silently abandon URLs after roughly 5 hops. OAI-SearchBot and Claude-SearchBot (the real-time search variants) tolerate about 3. Googlebot's documented tolerance is 10. If you migrate a site with 2-3 pre-existing chained redirects and add one more for the migration, you cross the AI threshold without ever crossing the Google threshold.
JavaScript blindness. GPTBot and ClaudeBot don't execute JS. Any JavaScript redirect (window.location, meta refresh with delay, framework-level client-side redirect) is invisible to them. Server-side 301 in your web server or CDN layer is the only option.
Redirect type. Google's docs distinguish 301/308 (permanent) from 302/307 (temporary). AI crawlers seem to follow the same convention based on third-party testing, but with less tolerance for ambiguity. Use 301 or 308 for migration redirects, never 302.
Official crawler documentation to know:
- OpenAI bots (GPTBot / OAI-SearchBot / ChatGPT-User) with separate user-agents and IP JSONs.
- Anthropic bots (ClaudeBot / Claude-User / Claude-SearchBot) documented February 2026.
- Perplexity crawlers (PerplexityBot for search, Perplexity-User for user-initiated fetches).
Update both domains' robots.txt at least 24 hours before cutover; that's the propagation window.

Your competitors are getting cited by AI. You're not.
Every day without citation tracking is a day your competitors pull ahead in ChatGPT, Perplexity, and Claude.
Step 4: Schema and Entity Migration
The entity graph is where AI citations live, and migration is when it's easiest to break.
Update Organization schema on every page of the new domain. The url, logo, and sameAs array all need the new domain baked in. If your sameAs array points to your old LinkedIn, Crunchbase, X, YouTube, or GitHub URLs, update every one of them (and update those external profiles to link back to the new domain).
Update author landing pages. Every /author/[slug] URL needs the same domain-swap treatment. ProfilePage schema, sameAs, and any external profile links.
Rebuild indexables. This is the killer failure mode. Yoast's cached indexables ship canonicals pointing at whatever domain was live when they were built. If you built indexables on staging, they'll ship pointing at staging.example.com after cutover. Fix: rebuild indexables (Yoast has a specific tool for this) after cutover, then audit every canonical tag on the new site before flipping DNS.
Server-side JSON-LD. Client-side-injected schema may not be seen on first crawl pass. Most AI training crawlers don't render JS at all. Verify JSON-LD ships in the initial HTML response with curl -sL https://newdomain.com/ | grep application/ld+json.
Step 5: Consolidation Opportunities
Migration is the natural moment to fix architecture debts you've been living with.
Subdomain to subfolder. SEO Engico's small-sample audit of 13 clients found subfolder content pulled 2-5x more AI citations than subdomain content over 90 days. The mechanism is entity binding: content on the main domain inherits the brand's entity signals, while subdomain content re-fragments them. If your docs, blog, or help center lives on a subdomain, migration is when to move it.
URL slug preservation. Search Engine Journal's guidance is direct: don't restructure your entire URL architecture for marginal AI retrieval gains. Preserve slug structure whenever possible, especially for high-citation URLs. Do the URL redesign only when you're already redesigning the CMS.
www vs non-www consolidation. Pick one, redirect the other, register both as GSC properties, file Change of Address on both. Google's June 2026 update made this non-optional.
Step 6: Post-Migration Monitoring
The first 60 days is where you catch the citation problems. Weekly checks minimum:
- Citation share on the 30 baseline prompts. Any prompt that used to cite you and no longer does after week two = a redirect chain problem or a 404 you missed. Investigate immediately.
- GSC coverage report. New URLs indexing? Any spike in "Crawled - currently not indexed"?
- Redirect chain audit. Screaming Frog or Sitebulb, checking that no path exceeds 2 hops.
- Rich Results Test on top 20 pages. Confirm schema still validates with the new URLs baked in.
- Perplexity re-index. Perplexity re-indexes fastest of the AI engines; if you're still cited there but not in ChatGPT after week 3, ChatGPT's retrieval hasn't caught up.
An r/TechSEO post from February 2026 captured what happens when this monitoring layer isn't in place:
Domain migration disaster — 98% traffic drop. Recovery strategy check?
Hey everyone, looking for honest feedback on our situation and recovery plan. We're a B2B company with an international presence. In October 2025 we migrated from our legacy domain (15+ years old, ~700k monthly impressions) to a brand new d...
That's the failure mode: legacy domain migrated without a redirect strategy, old server going dark, impressions collapsing from 700K to 14K. The recovery in the thread required backfilling ~1,100 fuzzy-match redirects and burning Google Ads spend to plug the gap. Four months in, still not back.
200+ SaaS teams already track their AI citations.
They know exactly when ChatGPT mentions their brand, and when it stops. Do you?

The Traps
Nine failure modes, in decreasing order of frequency.
Chain redirects (301 → 301 → 301). Flatten at source. Update the original rule to point directly to the final destination. Aim for ≤2 hops on every URL post-migration.
Redirect loops. Immediate abandonment across all AI crawlers. If a URL appears twice in a redirect chain, they drop it and don't retry. Same for Googlebot, but AI crawlers won't come back as aggressively.
Canonical tags pointing to staging. The Yoast indexable bug specifically. Also applies to any CMS with cached canonicals. Rebuild after cutover, audit every canonical, fix before flipping DNS.
Noindex tags forgotten on staging. Someone marked staging pages noindex, the tag shipped to production, whole site becomes uncitable. Grep the built HTML for noindex before you cut over.
Meta refresh or JavaScript redirects. Invisible to AI crawlers. Server-side 301 only.
www vs non-www forgotten. File Change of Address on every subdomain variant, per Google's June 2026 update.
Sitemap and Change of Address not filed. New sitemap on the new property day one; Change of Address on all variants to start Google's 180-day forwarding window.
An r/bigseo poster documented what happens even when the mechanical checklist is clean:
6 months post 301 migration to new domain problem
Hey guys, I moved a domain from .net to .org with perfect 301s, robots.txt, sitemap submitted, and confirmed Google can crawl the new URLs. My .net shows 100% 301 status on Google Search Console crawl stats so everything appears normal. How...
Six months post-migration, 40,000+ URLs "crawled but not indexed", 100% 301 status on GSC crawl stats, and Google still not trusting the new domain. Their memory of pre-2020 migrations was 2-4 week consolidation; today, the trust flip isn't happening on any predictable timeline. Which is exactly why post-migration monitoring has to be active rather than passive.
The Week-Zero Checklist
If you're migrating this quarter, run this the week before cutover:
- Baseline all metrics (traffic, rankings, indexed pages, citation share on 30 prompts, valid-schema pages, referring domains, existing redirect chains).
- Build the URL map: 1:1 where possible, 410 for retired content.
- Flatten existing 301 chains on the source before adding migration redirects.
- Update Organization schema, author landing pages, and every
sameAsreference on staging. - Rebuild indexables and audit every canonical tag on staging.
- Verify JSON-LD ships in initial HTML with curl.
- Set up GSC properties for every domain variant. File Change of Address on all of them.
- Update robots.txt on both domains 24 hours before cutover.
- Cutover: server-side 301s only, monitor 24 hours for anomalies.
- Weekly monitoring starts day one.
Our content engine handles the schema-and-canonical rebuild when you register a domain change, and our AI visibility tracking samples 30 buyer prompts across ChatGPT, Perplexity, and Google AI Mode every week so citation drops surface within days. For the entity-graph pieces that break most in migrations, our Organization schema playbook covers the brand side.
Migrations are the moment sites lose citations they earned over years. Do the mechanical checklist and the AI-crawler-specific pieces, and the migration becomes the boring event it was supposed to be.
How often does ChatGPT mention your brand?
Most founders have no idea. The answer might surprise you.





