How to Migrate a Website Without Losing AI Visibility

Every migration checklist I have read in the last decade optimises for the same thing: do not lose rankings. Map the URLs, ship the redirects, keep the titles, watch Search Console for three weeks, breathe out.

That checklist is still correct. It is also now incomplete, because rankings are no longer the only place your visibility lives. A growing share of your buyers ask an assistant instead of a search engine, and the mechanics that keep you visible there are not the mechanics a redirect map protects.

I went through this on my own site this month. The thing that surprised me was not that AI visibility moved during the migration. It was that I would have had no way to know, because almost nobody captures the measurement that would tell them.

Why AI visibility breaks differently

Organic rankings recover after a migration because Google has an explicit, well-documented mechanism for transferring signals between URLs. You tell it a page moved, it consolidates, and within a few weeks the new URL inherits most of what the old one had.

AI answer systems have no equivalent guarantee, for four reasons.

They see your site on their own schedule. AI crawlers are separate from Googlebot, obey their own directives, and re-crawl far less predictably. A page can be live and correct for weeks before the system that cites you has looked at it again. If your migration also changed robots rules or moved to a platform with different defaults, you may have quietly cut access entirely, which is a different failure, and the one I would check first.

A citation is attached to a URL, not to a domain. When an assistant cites you, it names a specific page. Redirect that page and the citation does not follow it the way authority follows a 301. It has to be re-earned by the new URL, on the new URL's own merits.

Third parties still point at the old address. Every roundup, forum reply, directory listing and newsletter archive that links to your old URLs is a source those systems read. Your redirect works for a crawler following the link. It does nothing about the fact that the text around that link describes a page that no longer exists in the form it described.

Your entity data is easy to fracture. Name, title, company, bio and the profiles that corroborate them are what let a system be confident it is talking about you. Migrations scatter these: a new about page, a changed job title, a bio rewritten in three places. Rankings barely notice. Entity confidence does.

Mapping the risk to the Visibility Stack

The four layers of the Visibility Stack fail in a migration in a specific order, and the order matters because the cheap failures are the ones people skip.

Access fails instantly and completely. New platform, new robots.txt, a staging block that shipped to production, a CDN rule, JavaScript rendering on a route that used to be static. This is a binary, it happens on day one, and it is the only layer where a single mistake wipes out everything above it. Check it before anything else.

Structure fails silently. Schema that lived in a plugin on the old platform and was never rebuilt. Heading hierarchies flattened by a new design system. Answer-first opening paragraphs edited into brand copy during the redesign. Nothing errors. The page just becomes harder to extract a clean answer from.

Entity fails gradually. Your title changed on the new about page but not on LinkedIn. Your organisation name is written three ways across the new site. Nothing is wrong; nothing quite agrees either.

Citation fails last and recovers slowest, because it depends on the other three being right first and on the rest of the web catching up second.

The redirect decision AI search changes

Here is the one place where the standard migration advice actively works against you.

Consolidation is good practice. Ninety thin old posts collapsing onto nine strong new pages is the right architecture, and I recommended exactly that for my own archive. For rankings it is close to free.

For citations it is not free, and the reason is that assistants cite at the level of the question, not the topic. If your old page answered "what should be on a website redesign checklist" and you redirect it into a broad pillar that mentions redesign in passing, a system looking for that answer now finds nothing specific enough to quote. The link equity arrived. The answer did not.

So apply one extra test to every consolidating redirect: does the target page actually contain a self-contained answer to the question the source page answered? If it does not, you have two honest options: add that answer as a section on the target, or keep a dedicated page. What you should not do is assume the redirect covered it.

The related discipline is boring and non-negotiable: one hop, never a chain, never a blanket redirect to the homepage, and every retirement that genuinely has no successor served as a clean 410 rather than a fake 301. A redirect to an irrelevant page is a worse signal than an honest gone.

What to do, in order

Before you migrate. This is the only step you cannot recover later.

Capture a baseline. Write a fixed set of prompts covering your category questions, your competitor set, your brand, and the specific questions your best pages answer. Twenty is enough; twenty-two is what I use. For each one record three things: whether you appear at all, which exact URL is cited if any, and how you are described in the answer.

Then lock the wording and never edit it. A baseline you keep tweaking is not a baseline. Run it across each surface you care about separately, because they disagree with each other and the disagreement is informative.

Do this before the new site goes live. Once it is live, the comparison you needed no longer exists, and no amount of analysis afterwards will reconstruct it.

During the build.

Verify crawler access on the new platform against the actual production robots rules, not the staging ones. Confirm that every indexable route renders its content in the initial HTML. If a page needs JavaScript to show its own body, assume some systems will not see it. Rebuild schema deliberately rather than assuming the new platform emits it. Keep the answer-first paragraph at the top of every page that had one, and resist the redesign instinct to replace it with a headline and a hero image.

Pull identity fields from one source. One file, one bio, one job title, propagated everywhere. Then make it match your LinkedIn, your YouTube channel and your X profile exactly.

After launch.

Re-run the frozen prompt set on a schedule (I use day 7, day 30, day 60 and day 90) and record the same three fields. Chart mention rate and citation rate separately from organic traffic, because they move on different timelines and averaging them hides both.

Expect the shape of the recovery to be uneven. Live-retrieval systems come back first. Anything reading from an older snapshot takes considerably longer, so the fastest and slowest surfaces can sit weeks apart. Track them separately rather than averaging, or the slow recovery hides inside the fast one and you call the migration done before it is.

The part most teams get wrong

They treat AI visibility as something to check after the migration, when the honest answer is that after the migration there is nothing to check against.

I have watched capable marketing teams run flawless technical migrations (clean redirect map, no chains, rankings back inside a month) and then be completely unable to answer their CEO's question about whether the company still shows up when someone asks ChatGPT for a recommendation in their category. Not because the answer was bad. Because they had no before.

The measurement costs an afternoon. The migration costs a quarter. Skipping the afternoon is the expensive decision.

If you are planning a redesign or replatform in the next two quarters, the baseline capture is the piece to schedule first, and it is the first thing I run in an AI search diagnostic for exactly that reason.

The takeaway

Redirects move authority. They do not move citations. Plan the migration for both: verify access on day one, preserve the specific answers your old pages gave rather than just their URLs, keep your entity data consistent across the site and the profiles that corroborate it, and, before anything else, freeze a measurement you can compare against ninety days later.

If you want the underlying model this sits on, it is the four layers in SEO in the AI era. If you suspect the access layer is already the problem, start with whether you are blocking AI crawlers instead.

This article is part of the SEO in the AI Era: The Complete Guide guide.