Migrating a Site That AI Assistants Already Cite

The client I migrated last week found me through Grok. He asked it a question in my field, it named two providers, I was one of them, and he emailed me. That’s recorded in my own notes as the attribution, because he told me on the call.

Which means I spent a fortnight rebuilding the site of somebody who hired me because of an AI citation, on a domain that has hundreds of pages old enough and specific enough to be cited the same way.

That reframed what the risky part of the migration was.

Rankings are the exposure people plan for

Everyone migrating a site knows to protect the rankings. You inventory the URLs, you map the redirects, you keep the titles, you watch Search Console for coverage errors, and if something drops you can see it drop.

The feedback loop works. Search Console will tell you a page 404s. It’ll tell you impressions fell. There’s a dashboard, a date, and a graph with a cliff in it.

AI surfaces give you none of that.

What breaks, and how quietly

An assistant that cites your site cites a specific URL. It either resolves or it doesn’t, and there’s no report anywhere that tells you it stopped.

Four things go wrong in a migration, in rough order of how often I see them:

The URL changed. Someone tidied /carpal-tunnel-syndrome/ into /conditions/carpal-tunnel-syndrome/ because it’s a better structure. It is a better structure. It also breaks every citation pointing at the old one unless the redirect is there, and unlike a search engine, nothing comes back to re-crawl and forgive you on a schedule you can predict.

Two pages got merged. This is the one that has no redirect fix. Content consolidation is usually good SEO hygiene, and it’s the most destructive thing you can do to a cited corpus, because the passage that was being quoted no longer exists anywhere. A 301 sends the reader to a page that doesn’t contain the answer they were cited to.

The headings moved. Extraction works on structure. A page that answered a question under an h2 phrased the way people ask it, rewritten into prose with a decorative heading, can stay live and stay ranked and stop being quotable.

The machine-readable files 404. If your site publishes llms.txt, or a feed, or structured data that the page depends on, a build that omits them still produces pages that render correctly end to end. On the launch I did last week, exactly that happened: the generated files were skipped by a build command that ran the framework instead of the project’s build, and llms.txt returned 404 for about an hour on a site whose own pages link to it. I wrote that failure up in Four Ways a Site Launch Lies to You.

What I did instead

The old site had 533 URLs. I crawled and inventoried all of them before a single page of the new site was written: status, final URL, title, description, H1, word count, canonical, indexable, in the sitemap. The new site was fitted to that inventory rather than the inventory being fitted to the new site.

Three rules came out of it.

Consolidation is allowed, but only in one direction. I want to be precise here, because my first draft of this post said nothing gets consolidated during a migration and that was a rule I had not actually followed. This migration retired 58 legacy URLs into the blog index and merged six more into surviving posts.

What separates those from the failure above is what was in them. The retired set is almost entirely off-topic local filler that a previous content programme had produced: the best barbecue spots near Dallas, the best boxing gyms in Dallas, the farmers markets. None of it answers a question about hands or wrists, so none of it can be cited for anything the practice wants to be cited for. The six merges go the other way, folding three near-identical posts about food and joint pain into the one that covers it properly.

The rule I would write down is narrower than “never consolidate.” Do not merge or retire a page that answers a question in the subject you want to be known for. Everything else is fair, and a migration is a reasonable moment to do it, because you are rebuilding the redirect map anyway. What you cannot do is discover afterwards that the page you folded away was the one being quoted.

Every legacy URL resolves, and the redirects preserve the query string. After cutover I sampled 40 rules against the live domain and checked both the status and the target. Query-string preservation matters for a different reason, which is that it carries the advertising click identifiers, and I’ve written that up separately in A 200 Is Not Proof.

Old media URLs resolve too. Images embedded in other people’s pages and in years of syndicated content are citations of a sort. The forced media redirects on this site land on the preserved originals, so they still resolve.

How to check whether you have this exposure

You can’t query most of these surfaces directly, so the check is indirect, and it’s a short one.

Ask three or four assistants the questions your best pages answer, and write down every URL of yours they cite. That list is your real exposure, and it’s usually a different set of pages than your top-ranking ones, skewed toward older content that answers a specific question and away from the commercial pages you’d protect first.

Then look at your referrer data for assistant hostnames, and look for traffic to pages you’d forgotten about. On the migration I just did, the pages carrying the most of this exposure were condition articles written years before anyone was optimizing for a language model.

Whatever that list contains, those URLs don’t change, don’t merge, and don’t get their headings rewritten in the same release as everything else.

The part I’d argue with myself about

There’s a fair objection here, which is that assistants re-crawl, indexes refresh, and a correct 301 will eventually be followed by everything that matters.

Probably true, and I would still plan around the gap rather than the steady state. Nobody I’ve asked can tell me how long the refresh takes for any given surface, the pages most likely to be cited are the ones least likely to be missed in your own analytics, and the whole failure is silent. For the cost of an inventory and a redirect map you’d build anyway, the downside of being careful is nothing.

The full write-up of that migration, including the eight ad landing pages and the 51% of conversions I deliberately didn’t move, is in the case study.