Website migration without erasing the evidence AI and search already know

A migration that loses URLs is a company burning its own citations. Every indexed URL is an evidence address: a location machines have already read, linked, and cited when they talk about you. Years of links, search history, and AI-answer evidence point at those addresses, and a rebuild that launches without a redirect map quietly turns them into 404s. The new site looks better. The machines that recommend you just lost their references.

The stakes grew with the readers. Search engines were always reading; now AI platforms crawl the same public surfaces to decide what to say about you, and Google is explicit that its AI search features work from the same crawled content as classic search. The old migration question was “will we keep our rankings.” The new one is “will the systems that already understand us still find the evidence.”

Inventory before anything moves

The map comes first, and Google's own site-move guidance says where to get it: sitemaps, server logs, and analytics. Between the three you find the URLs that matter, including the ones nobody remembers publishing: the old PDFs still earning links, the landing pages from three campaigns ago, the pages only bots visit. If you ran a truth audit first, you already hold most of this inventory, along with the claims each address carries.

Then decide per URL, deliberately: keep, merge, or retire. Keep means the address survives, ideally at the same path, because the cheapest migration risk is the one you never take. Merge means the page's job moves to a successor, and the address redirects there. Retire means the job is gone, and the address redirects to the nearest useful parent rather than a 404. What no URL gets is silence.

Redirect like you mean it

The mechanics are documented and blunt. Google's redirect guidance ranks server-side redirects as the kind with “the highest chance of being interpreted correctly,” and the site-move doc adds the numbers: permanent server-side redirects where technically possible, chains kept ideally to three hops or fewer, and the redirects held “generally at least 1 year.” In practice I keep them permanently. A redirect costs nothing to keep. Breaking one costs a reference.

Here is the difference on one made-up URL, in the form you can test. Broken: curl -I https://example.com/services/audit returns 404 Not Found after launch, and every link and AI citation pointing at it now dead-ends. Correct: the same request returns 301 Moved Permanently with Location: https://example.com/capabilities/audits, one hop, straight to the successor page. The first migration burned a reference. The second forwarded it.

Deterministic beats clever. A published mapping file, old path to new path, one line per URL, beats pattern-matching rules that mostly work. The mapping is also your acceptance test: after launch, request every old URL and confirm the status code and destination match the map. If you cannot test it line by line, you are hoping.

Preserve the evidence around the addresses

A URL that survives with its meaning stripped is half-preserved. The surfaces machines read travel with the page, and the new templates have to carry them:

• Titles and meta descriptions: ported or deliberately improved, never regenerated into generic boilerplate
• Structured data (the machine-readable identity markup in your pages): the markup that disambiguates your identity, with the same name, url, and sameAs properties on the new site
• The content itself: claims, numbers, and dates preserved through the rewrite, or updated on purpose with the change on the record
• PDFs and files: redirected like pages, because they earn links and citations like pages
• Machine-facing files, if you publish them: llms.txt and agent cards ported and updated, sitemap regenerated and submitted

That last step closes the loop with Google's guidance: submit the new sitemap, then watch index coverage in Search Console (its report of which URLs are indexed) on the old and new properties where both exist, old URLs draining as new ones fill.

The checklist

The full sequence, compressed. Each line is an acceptance test: it either passed or it did not.

1. Definitive URL inventory built from sitemaps, logs, and analytics
2. Keep, merge, or retire decided per URL, on the record
3. Mapping file written: every moved URL to exactly one destination
4. Server-side permanent redirects implemented from the mapping
5. Chains checked: three hops or fewer end to end
6. Titles, descriptions, and structured data ported to the new templates
7. PDFs and non-HTML assets mapped and redirected
8. Machine-facing files ported; new sitemap generated and submitted
9. Launch-day pass: every mapped URL requested, status and destination verified against the mapping
10. Post-launch watch: index coverage, crawl errors, and the answers AI systems give about you, on your locked query set

That last line is the new part. If you measure AI visibility with a locked query library, run it before the migration and after, and read the deltas the way you read index coverage: as an early-warning instrument, not a verdict.

What this cannot promise

Nobody controls the ranking systems or the AI platforms, and a migration window is noisy: rankings and answers move for reasons that have nothing to do with you. The checklist minimizes self-inflicted loss. It does not guarantee the absence of loss, and a vendor who guarantees rankings through a migration is telling you something about their claims discipline. What you can verify is everything on your side of the line: every address answered, every redirect correct, every evidence surface intact. That is the whole controllable risk, handled. One scoping note on the evidence: the redirect mechanics here rest on Google's own documentation, because Google documents them and its systems honor them. Other platforms publish less about how they treat moved URLs, which is a reason for the checklist's conservatism, never an argument against it.

How I run this

I have carried this discipline across builds and launches for more than 40 university platforms and the Texas General Land Office's public government properties, environments where a broken address is a public failure; the work record has the details. And I practice it at home: this site's own retired paths, like the old essay URL and a consolidated section, answer with permanent redirects to their successors right now. You can test that claim with a curl command, which is the standard I think migration claims should meet.

For clients, migration planning is part of a complete web presence transformation: the truth audit first, then the inventory, the mapping, the rebuild, and the verification pass, with the same-path option always evaluated first because the best redirect is the one you never need.

Questions worth asking next

Sources

1. Google Search Central, site moves with URL changes (mapping, permanent redirects, chain limits, one-year guidance, sitemap and monitoring). https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
2. Google Search Central, redirects and Google Search (redirect hierarchy and canonicalization). https://developers.google.com/search/docs/crawling-indexing/301-redirects
3. Google Search Central, "AI features and your website" guidance. https://developers.google.com/search/docs/fundamentals/ai-optimization-guide
4. Google Search Central, Organization structured data. https://developers.google.com/search/docs/appearance/structured-data/organization
5. Schema.org, Organization type. https://schema.org/Organization