Blog · Diagnosis

Migrating a site without losing citations

Published 21 July 2026 · Updated 12 October 2026 · 8 min read

Migrating a site without losing citations
Photograph: Alicia Christin Gerald / unsplash

The short answer: Keep a one to one redirect from every old URL to the page that carries the same claim, hold those redirects for at least a year, and verify before launch that the new host still answers the documented AI crawlers and still allows snippets. A migration need not demote you in answers. What it changes is which document an engine fetches when it goes back to check a sentence it once attributed to you.

Rankings recover from a migration because search has machinery built for it, and Google documents that machinery. For answers we have found no equivalent published timetable, and recovery depends on the fetch at the other end of the citation still returning the thing that was cited.

Your old URL lives in three places, not one

The first place is the search index. That one has a documented repair path. Google tells site owners to keep redirects for as long as possible, generally at least 1 year, so that signals transfer, and to expect a few weeks before most pages of a small or medium site have moved across. There is a Change of Address tool for a domain or subdomain move. All of this is well worn and it works.

The second place is whatever retrieval store sits behind each assistant: an index of its own, a cache, a set of embeddings built from a crawl it ran on its own timetable. We read the public crawler and publisher documentation for the five engines in our prompt set in October 2026 and found neither a refresh interval for that store nor a form for submitting a move. We cannot see inside those stores, so the honest statement is that we found no documented way to notify them, not that no such path exists. Meanwhile you wait for the next crawl, and you make sure that when it comes, the old URL resolves to something that still contains the claim.

The third place is frozen. It is whatever a model absorbed at training time, the third-party pages that linked to your old URL, the directory entry somebody filled in during 2023. We cannot inspect a model's weights, so treat the first of those as inference from how models are built rather than something we have observed. None of it updates because you migrated. The only thing standing between a frozen reference and a dead end is your redirect.

That division matches what we have seen on the migrations we have reviewed, which is a small sample of client sites rather than a census: search traffic dips and returns first, while brand mentions in answers stay quiet for a good while after everything else looks healthy. We have not measured that gap against a defined sample, so we quote no interval for it. The same confusion sits under why AI never mentions your brand in cases that have nothing to do with content quality.

A citation is a URL plus a sentence, and bulk redirects break the pair

Most migration plans optimise for not returning a 404. That is the wrong target. An engine that revisits a cited URL is checking whether the page still supports the sentence it wrote. Land it on a category page, a hub, or the homepage, and the fetch succeeds, the status code is clean, and the document no longer contains the claim. The citation drops. Worse, the claim sometimes survives and gets reattributed to whichever competing page still says it plainly.

So the rule is not "redirect everything". It is one to one, to the page carrying the same claim, for every URL that was carrying weight. A blanket rule that sweeps 400 old article URLs into /resources/ satisfies every migration checklist ever written and removes you from the answer set.

The practical move is a census before you cut over. Pull 60 to 90 days of server logs and filter for the documented agents: OAI-SearchBot and ChatGPT-User from OpenAI, plus the equivalents the other engines publish. Those URLs, and the ones your prompt set shows being cited, are the protected list. In the audits where we have pulled those logs, the protected list has come out short enough to map by hand. We have not counted it across a defined sample, so treat that as a working expectation to test against your own logs rather than a measured ratio. Everything else can take the bulk rule.

For URLs that genuinely have no successor, return 410 rather than 404, and avoid a soft 404 that answers 200 with a "page not found" body. Google documents that a 200 is handed to its indexing pipeline and that a soft 404 has to be inferred from the content, because the response itself looks successful. A crawler that stores the body has no status code telling it the claim is gone.

The two regressions that pass every ranking check

Here is the failure mode that catches competent teams, and it is worth checking twice because both halves are invisible in the usual launch QA.

The first is robots. Migrations move you to a new host, a new CDN, or a new platform, and the new stack arrives with its own robots.txt and its own bot management defaults. On more than one migration we have reviewed, those defaults allowed Googlebot while blocking the documented AI crawlers, which some vendors classify as scraping. That is a handful of sites rather than a survey, so read it as a thing to check rather than a rate. Rankings are untouched. Citations stop renewing. OpenAI documents that it can take around 24 hours from a robots.txt update for its systems to adjust, so fix it, then test the next day, not the same afternoon. Can AI crawlers actually read your site covers the fetch side of this in more detail.

The second is snippets. Google is explicit that a page is eligible for AI Overviews and AI Mode only if it is indexed and eligible to be shown in Search with a snippet, and that nosnippet, data-nosnippet, max-snippet and noindex apply to AI features in the same way they apply to a result. A new template that ships max-snippet:0, or a data-nosnippet attribute wrapped around the main content block by a developer protecting a paywall preview, will rank fine and will be ineligible for the surface you care about. Grep the built HTML for nosnippet, max-snippet and noindex on the staging build before launch. It takes a minute, and we have found a live snippet directive this way on more than one staging build during audits.

Publishers hit both of these harder than anyone, because the archive is the asset. The economics of that are in AEO for publishers losing clicks.

Tell the engines you can tell

You cannot notify an assistant directly. You can notify the indexes some of them sit on top of. IndexNow accepts up to 10,000 URLs per request, covers URLs that were added, updated or deleted, and participating engines share submissions with each other, so a move is worth pushing through it on the day of cutover rather than waiting for a crawl.

Keep both sitemaps live for a while. Submit the new one, leave the old one in place, and watch the indexed count on the old set fall while the new set climbs. Set lastmod honestly on the new URLs. A migration that stamps today's date on every archived page tells a crawler nothing it can use to prioritise.

What to run the week before and the week after

Five things, in order, and none of them need a tool.

Request a sample of your protected URLs with each documented AI user agent string and record the status chain and the final body. Fetch /robots.txt on the new host, on every subdomain in the redirect graph, and read it rather than skim it. Grep the staging build for snippet directives. Run your prompt set once before the cutover and store the cited URLs verbatim. Re-run the same prompt set weekly after, and compare the cited URL list, not the sentiment.

The thing you are watching for in that comparison is not a drop in mentions. It is a change in which URL gets cited. A citation that moved from your article to your homepage means the redirect is wrong. A citation that moved to a competitor means the claim is now easier to find elsewhere. A self-audit checklist for AI visibility has the broader version of this list, and the self-check is ten of these you can run this afternoon without touching the migration plan.

Honest limits

This post does not establish a recovery timeline. We have no way to force an assistant to re-crawl a moved URL, and nothing here comes from a controlled before and after study, so every pattern we describe from our own work is a small sample of client migrations rather than a measured rate. We cannot see inside the retrieval store behind an assistant, so where we call a behaviour undocumented we mean we did not find it in the public documentation of the five engines in our prompt set in October 2026, not that it does not exist. The idea that a retired domain lingers in a model's training data is inference from how models are built, not something we can inspect, so the share of the loss that is not recoverable is a reason to keep redirects long rather than a figure we can give you. Plan the redirect lifetime around that, not around the day your analytics look normal again.

FAQ

How long should the redirects stay up? At least a year is the published guidance for search, and for answer engines we would keep them longer, because the frozen references that point at your old URLs do not expire on a schedule you control. Treat the redirect map as infrastructure, not as launch cleanup.

Is a domain change worse than a URL structure change? Usually yes, because it breaks entity identity as well as addressing. The name, the URL in your schema, the profiles you control and the third-party listings all have to agree again, and that reconciliation is slower than any crawl.

Will a 302 do during a phased migration? It will keep users moving, and Google documents a temporary redirect as a signal to keep the old URL in its index, which is the opposite of what a finished move wants. Use a permanent redirect once the page has genuinely moved.

How soon should we expect citations back? Access fixes can land within a crawl cycle, since they only need the next fetch to succeed. Citation recovery after a clean migration has been slower than search recovery on the migrations we have followed, and uneven across engines, but that is a handful of sites and we quote no interval from it. We found no published recovery schedule in the documentation of the engines in our prompt set to quote instead.

Sources

All six were opened and checked against the sentences that cite them on 12 October 2026.

Related reading

Why AI never mentions your brandA self-audit checklist for AI visibilityAEO for publishers losing clicksCan AI crawlers actually read your siteThe small-site authority problemHow to check what engines say about you, properly