Site Migration in 2026: How to Move a Domain Without Losing Rankings OR AI Citations

Most "2026 site migration" checklists you will find on page one are 2018 advice wearing a fresh jumper. They map URLs, they 301 them, they file a Change of Address, they tell you to watch Search Console for three months. All correct. All incomplete.

Because a site migration in 2026 is no longer just a Google problem. It is a Google and ChatGPT and Perplexity and Gemini and AI Mode problem, and those surfaces cache, recall and re-cite your URLs on completely different clocks. We have migrated client sites across all of them without tanking rankings, mostly by being almost paranoid about redirects. This is the migration playbook we actually run, including the AI layer the rest of the internet keeps skipping.

The short version (read this even if you read nothing else)

• Google needs roughly 180 days of clean redirects minimum, and ideally a full year. The AI layer needs far longer than that, because AI training and retrieval pipelines have a long memory.
• Server-side 301s, a one-to-one URL map and a Change of Address request handle Google. Not one of those signals reaches an LLM directly. There is no Change of Address tool for ChatGPT.
• The AI layer needs its own checklist: lower DNS TTL early, refresh your entity and schema signals, keep the old domain crawlable and 301ing for two years, and push fresh snapshots to the Wayback Machine before and after launch.
• If you change one habit in 2026, change this one: do not retire the old domain. Park it, keep it answering, and 301 at the edge so AI bots that already cached the old URL get pulled to the new content.

Why we are writing this (and who it is for)

We run an SEO agency, and over the last twelve months our team has helped clients through six domain moves and replatforms. Three were straight domain changes, two were CMS swaps on the same domain, one was a subdomain-to-subfolder consolidation.

Five went smoothly. One went sideways. The one that wobbled was, of course, the one where we let the standard checklist do the talking. Google rankings recovered in a fortnight. The AI citations took nine weeks. The client's branded query volume slid during that window because their name had quietly fallen out of AI answers, and nobody noticed until a prospect mentioned it on a sales call. That stung. It also taught us the lesson behind every paragraph below.

This is for SEO leads, founders and in-house marketers planning a move in 2026. If you want the broader engineering view, our technical SEO strategies guide covers the fundamentals this post assumes you already have in place.

What is actually different about migrations in 2026?

For a decade, a migration was a clean checklist: map URLs, 301 them, update the sitemap, file the Change of Address, watch Search Console. That still matters, and Google's own site move with URL changes documentation still calls for server-side permanent redirects, a fresh sitemap, and keeping redirects "for as long as possible, generally at least 1 year".

The new variable is AI search, and it is not a rounding error any more. Pew Research Center's July 2025 study of real US browsing data found that 18% of all Google searches in March 2025 already triggered an AI summary, and that users clicked a normal result on just 8% of those searches versus 15% when no summary appeared. Clicks inside the summary happened in a measly 1% of visits. So getting cited in the answer matters more than ever, and a sloppy migration can knock you out of that answer for weeks.

Here is how that changes your migration risk, in three specific ways.

AI engines do not crawl on Google's schedule. ChatGPT's retrieval index refreshes more slowly than Googlebot. Perplexity blends live search with cached snippets. Gemini and AI Mode sit on Google's index but apply their own logic on top. Move a URL and every surface processes that change at a different speed.

AI training and retrieval data casts a long shadow. Common Crawl, which feeds a lot of downstream LLM pipelines, publishes its web archives on a monthly basis. If your old URLs landed in a recent snapshot, that old content can keep getting cited well after the URL itself 404s. Time your move badly and you can lose two or three months of AI visibility on top of the normal Google dip.

AI engines lean on stable entity signals. About pages, author bios, schema, brand mentions, external citations. Break those even briefly and you can drop out of AI answers while your Google rankings sit perfectly still. We dug into the mechanics of that in our piece on knowledge graphs and entity optimisation for AI search, and it is the bit migrations damage most often.

The honest pre-migration audit (start six weeks out)

Most guides say start two weeks before launch. That is too late. Six weeks gives you room to fix what the audit digs up, and to lower DNS TTL slowly so nobody notices.

Here is the spreadsheet we build in week one. Five tabs, then de-duplicate into one master redirect map.

1. Every URL that earned a Google click or impression in the last 12 months. Search Console, Performance, Pages, maximum date range, export. This is your redirect priority list.
2. Every URL with backlinks. Ahrefs, Semrush, or Search Console Links. These hold the ranking equity, so losing them quietly is expensive.
3. An LLM citation audit. Manually query ChatGPT, Perplexity, AI Mode and Gemini for your 30 top branded and category queries. Note every URL of yours that gets cited. This is the single most overlooked step in 2026 migrations, and the gap most page-one guides ignore entirely.
4. Your Wayback Machine snapshots. Check archive.org/web for the old URLs that get cited. Strong archive history means you preserve those exact paths or 301 them precisely.
5. A JavaScript-rendering crawl. Screaming Frog or Sitebulb in JS mode. AI bots have patchy JavaScript support, so anything depending on client-side rendering is a flight risk.

One extra pass we always run: audit your structured data for hardcoded old URLs hiding in sameAs, url and logo fields. They are easy to miss and a nightmare to debug after launch.

What this looked like on a real job

On one client migration, the Google priority list had 142 URLs. The AI citation audit added another 23 that Google barely ranked but ChatGPT cited regularly: a couple of old service brochures in PDF, a glossary page, and three blog posts from 2022 we had nearly pruned for being "thin". Kill those and we would have lost AI mentions on the exact queries the client was trying to win. We kept them, redirected them carefully, and the citations carried over. That is the whole game.

Build the URL map (and the redirect strategy LLMs respect)

URL mapping is still the single most important deliverable. One old URL to one new URL. No chains, no loops. Google's docs are blunt about this: Googlebot can follow up to ten hops, but you should redirect "to the final destination directly", and if you must chain, keep it to "no more than 3 and fewer than 5".

What we do differently in 2026:

• 301 nearly everything, even pages you would normally 410. AI crawlers are messier than Googlebot. A 410 on a URL that ChatGPT cached six months ago can vaporise that citation. A 301 carries it forward to the closest equivalent. Save your 410s for genuine junk.
• Map AI-cited URLs to their closest topical match, not their structural match. If ChatGPT cites your old /glossary/canonical-tag and the new site has no glossary, send it to your best canonical content, not the homepage. Homepage redirects are citation killers. Every time.
• Keep the old domain alive if you are changing domain. Park it, point an A record at a small worker, and 301 at the edge. Google recommends keeping redirects for at least a year, and Bing goes further: its own website migration guidance says the redirects "need to remain live for at least 1 to 2 years, preferably longer". For the AI layer we stretch that to 24 months as a floor.
• Document your canonical decisions inside the redirect map. When two old pages collapse into one new page, decide which gets the canonical credit and write it down. Skip this and you create exactly the ambiguity LLMs hate.

A blunt reminder on robots: do not block the old domain after migration. We see this on roughly one migration a year. Someone thinks they are tidying up, and they are actually wiping AI memory. Keep the old robots.txt allowing crawl for the entire redirect window. Our robots.txt optimisation guide covers the safer patterns if you want them in front of you on the day.

If your move involves shifting between a subdomain and a subfolder, the calculus changes again, and we broke that down specifically in subdomain versus subdirectory in 2026 for AI citations. Worth a read before you commit to a structure.

The AI layer (the part the other checklists skip)

If you only take one section from this post, take this one.

Pre-migration AI prep (T-minus 14 days)

1. Publish a clean llms.txt on the old domain. A simple file at /llms.txt listing your canonical URLs with one-line descriptions. It is not a magic bullet, and we said so plainly in our llms.txt and AI citations data piece, but it gives compliant AI crawlers a hint sheet at the worst possible moment for confusion.
2. Push your top 50 cited pages into the Wayback Machine. Use the Save Page Now feature at archive.org/web, which the Internet Archive describes as "put a URL into the form, press the button, and we save the page. You will instantly have a permanent URL for your page." Those snapshots stay searchable after you migrate.
3. Prime your About, Author and Organization schema. Get the sameAs arrays pointing at the new social profiles and the new canonical domain, and test it in Google's Rich Results Test before launch, not after.
4. Refresh your highest-authority external citations of the old URL. Not all of them. The top five to ten with real topical weight. These are entity anchors and they carry far more AI influence than their raw link value suggests.

Migration day AI tasks

1. Switch llms.txt to the new domain on launch.
2. Keep the old domain's llms.txt 301ing to the new one.
3. Re-submit the new top 50 pages to Wayback within the first six hours. This is your archival proof that the new URL exists with the right content.
4. Manually query five to ten of your most important prompts on ChatGPT, Perplexity and AI Mode, and record the URLs cited. That is your pre-recrawl baseline.

Post-migration AI recovery (weeks 1 to 12)

Here is the bit nobody plans for. Google usually recovers in two to four weeks. AI recovery takes longer because LLMs have no Change of Address tool. You have to rebuild signal volume the slow way.

• Re-query every seven days for the first month, then every fourteen days for the next two months. Track which citations have moved to the new URL and which are stubbornly stuck on the old one.
• For anything stuck, run a curl test to confirm the 301 is firing cleanly. One misconfigured redirect can leave AI bots wedged on the wrong path indefinitely.
• Publish two or three fresh pieces on the new domain that reference your old high-citation pages by name. New internal pathways plus a fresh "this domain owns this topic" signal. The pattern is the same one we use to get cited in ChatGPT and AI Overviews in the first place.

What Google still wants (the traditional checklist, verified)

The AI layer sits on top of the Google layer, it does not replace it. And the Google playbook in 2026 has barely shifted. Straight from the site move documentation:

• Use server-side permanent redirects (301 or 308) wherever technically possible. Google notes that permanent redirects "don't cause a loss in PageRank".
• Avoid redirect chains. Point the old URL directly at the final new URL.
• Submit the new sitemap in Search Console.
• Keep redirects "for as long as possible, generally at least 1 year".

Google's separate Change of Address documentation adds two things worth tattooing on the project plan. First, you should "maintain the redirects for at least 180 days, longer if you still see any traffic to them from Google Search", and after that window Google "treats the old site as an unrelated site". Second, the tool tells Google "to prefer the new site over the old when determining canonical pages". That is the canonical handover doing its job.

A few practical traps that catch people out:

• The Change of Address tool only works at the domain property level, not URL-prefix. If you only verified a URL-prefix property, switch to domain property at least two weeks before the move so the tool is even available.
• Verify the new property in Search Console before launch. Do not leave it to the day itself.
• Internal links should already point at the new URLs on launch day. Do not lean on redirects to clean up your own navigation.
• Watch for bloat. Migrations love to drag in extra theme files and third-party scripts, and a heavier site can quietly slip outside your crawl budget right when Googlebot is recrawling everything.

The DNS and CDN piece (where teams improvise badly)

Developers often handle DNS at the last minute. Fine for an internal app. Not fine for SEO. Three rules we never break.

Rule 1: lower TTL early. Cloudflare's DNS TTL documentation notes that proxied records sit on an "Auto" TTL of 300 seconds, while DNS-only records can drop to 60 seconds on non-Enterprise plans. Two weeks out, drop the records you will touch to 300 or 600 seconds, then wait out the duration of your old TTL before changing anything. If your previous TTL was 24 hours, you genuinely wait 24 hours. No shortcuts.

Rule 2: migrate during a low-traffic window. We pick an early-morning Tuesday or Wednesday in the client's quietest region. We avoid weekends, because in our server logs AI crawlers seem to spike crawl on weekends, and you want them hitting a clean state, not a half-cut-over one.

Rule 3: pre-warm the new CDN. Most CDNs cache by URL, so the first request to each URL after launch is uncached and slow. Slow first responses dent Core Web Vitals at the exact moment Googlebot is recrawling. Run a sitemap-based pre-warm script the night before.

Migration day: the four-hour window

We run every migration inside a defined four-hour window with a checklist printed on paper. Yes, paper. The internet goes down sometimes, usually at the worst moment.

Hour 0: pre-launch

• Confirm the staging site is noindex, nofollow.
• Confirm the new site has an indexable robots.txt and correct canonical tags.
• Confirm SSL on the new domain is valid and trusted across three browsers.
• Confirm the 301 rules in staging with curl, not by clicking.

Hour 1: cutover

• Update DNS records.
• Push redirect rules to production.
• Disable any caching that could serve old content.
• Submit the new XML sitemap in Search Console and Bing Webmaster Tools.

Hour 2: validation

• Curl 20 random old URLs. Each should 301 to the correct new URL.
• Curl 10 new URLs. Each should return 200.
• Check the new homepage in incognito on mobile and desktop.
• Inspect rendering with the URL Inspection tool. Confirm the rendered HTML contains your main content and canonical tags.

Hour 3: AI and external

• Submit the new top 50 pages to Wayback via Save Page Now.
• Manually query 5 to 10 priority prompts in ChatGPT, Perplexity, AI Mode and Gemini.
• File the Change of Address request in Search Console and the Site Move request in Bing Webmaster Tools.
• Update social profile URLs (your schema sameAs property reads these), Google Business Profile, and any directories you control.

The migration is not finished at hour three. It is finished at week twelve.

Post-migration monitoring (weeks 1 to 12)

What we check every day for the first fortnight:

• Search Console coverage (new URLs indexing, old URLs processing).
• Crawl Stats (crawl rate should rise then settle).
• Server logs filtered by Googlebot, Bingbot, GPTBot, PerplexityBot, ClaudeBot and Google-Extended.
• 4xx and 5xx error rate. Any spike means a redirect rule has failed somewhere.
• Branded query impressions and clicks, because branded queries shift fastest and give the earliest warning.

Weekly: top 100 keyword rankings (any drop greater than five positions gets investigated), the same 30 AI citation queries from your pre-migration audit, Core Web Vitals, your backlink profile, and Wayback indexing of the new pages.

Monthly: year-over-year traffic and conversions on key pages, visibility share against competitors, schema validation across templates, and a fresh AI citation audit compared to baseline.

Mistakes we have made (so you do not have to)

• Killed the old domain too early. Cancelled hosting at week eight to save budget, and the 301s went with it. We lost a chunk of remaining AI citations in a single week. Now the old domain stays alive for 24 months, full stop.
• Trusted a redirect plugin. A WordPress plugin looked fine but was firing 302s on a slice of URLs thanks to a conflicting rewrite rule. We caught it on day four. Always test with curl, never by clicking through.
• Forgot the trailing slash. The new site enforced trailing slashes, the old one did not. Redirects worked for one variant and 404'd for the other. Three days of confusing coverage errors before the penny dropped.
• Left schema stale. Organisation schema still pointed at the old sameAs array, so Google had no clean entity confirmation for the new domain. AI Overviews stopped citing the brand for two weeks.
• Filed Change of Address before redirects were fully live. The pre-move checks passed because most URLs redirected, but one subdirectory did not. The request got accepted, then started throwing errors. Waiting an extra day beats fighting Search Console's queue.

How long until you recover?

Google's documentation says a small to medium site "can take a few weeks for most pages to move", and larger sites longer. In our experience, for a clean migration:

• Days 1 to 7: crawl spike, some volatility, expect a 10 to 30% impression dip.
• Weeks 2 to 4: most pages re-indexed, top-priority rankings usually back within five positions of baseline.
• Weeks 4 to 8: full Google recovery on clean migrations, AI citations starting to shift to the new URLs.
• Weeks 8 to 12: AI citation recovery completes on most major surfaces, long-tail still settling.
• Months 4 to 6: anything still off is probably a content or technical issue, not a migration one.

If you are still down 20% or more on Google at week eight, something specific is broken. Nine times out of ten it is a redirect chain, a robots.txt that accidentally blocks the new domain, or a canonical still pointing at the old URL.

Our contrarian take: do not migrate unless you have to

A migration is a tax on your SEO. You will lose something. You can minimise the loss, you cannot eliminate it. So the only question that matters is whether the upside clears the bill.

When a move is genuinely worth it: a rebrand with a real legal or commercial driver, consolidating a pile of weak domains into one strong one, escaping a platform that is actually broken rather than merely irritating, or internationalisation that needs a different domain structure.

When people migrate but probably should not: they fancy a prettier domain, they want to escape a vague "reputation" thing nobody outside marketing can define, a new designer wants a clean slate, or a competitor did it and it gave someone fear of missing out. If your reason lives in that second list, run an honest ROI calculation that includes three to six months of degraded performance, the cost of parallel infrastructure, and the engineering time. The maths usually says stay put.

What to do this week

Got a move coming in the next 90 days? Start here:

1. Export your top 200 URLs from Search Console, by impressions and by clicks.
2. Run a manual AI citation audit on your 20 top branded and category queries across ChatGPT, Perplexity, AI Mode and Gemini, and save the results.
3. Verify both old and new domains in Search Console as domain properties, not URL prefix.
4. Verify both in Bing Webmaster Tools.
5. Lower DNS TTL to 300 seconds for every record you plan to touch.
6. Audit your schema for hardcoded old URLs in sameAs, url and logo fields.
7. Submit your top 50 currently-cited URLs to the Wayback Machine.

If the move is also a redesign, get the build right at the same time so you are not paying the migration tax twice. That is exactly the kind of project our web design team plans around redirect and entity preservation from day one, rather than treating SEO as a post-launch surprise. For the search side itself, our SEO services exist to keep both the Google and AI layers intact through the transition.

And if you simply want a second pair of eyes on the plan before you ship it, that is what we are here for. Talk to our team and we will pressure-test your redirect map and AI checklist before launch, not after the citations have already gone quiet.

One last thing. Do not skip the AI layer because it feels new and the docs are thin. The other side of a 2026 migration is not just Google traffic. It is being the brand that gets named when someone asks an AI which company to trust. Lose that signal and you will spend the next three months earning it back, one snapshot at a time.