Site Migration for AI Search: Keep Cited Evidence Reachable

Moving a website is an evidence-delivery problem as well as an SEO project. A buyer can follow an old answer citation to a working redirect and still arrive at the wrong policy, a missing methodology, or a renamed product they cannot identify. A successful HTTP response is necessary evidence about the route; it is not proof that the buyer's question survived the move.

This guide covers planned domain changes, CMS replacements, and URL restructures affecting public information. Its AEO contribution is a release contract for cited evidence: preserve what a reader needs to verify, document intentional changes, and distinguish redirect checks from subsequent answer observations. It does not offer a technique for transferring AI citations or guaranteeing visibility.

Define the migration's evidence contract

Write the reader outcome before approving the redirect spreadsheet. For each important source page, name the question it answers, the claims that matter, and the evidence a visitor must still be able to inspect. A pricing explanation might need the eligibility conditions and billing basis. A technical guide might need a version constraint, code example, and link to the maintained reference. A study might need its sample definition and limitations.

Use three acceptance decisions: preserve, revise with explanation, or retire. Preserve means the question and supporting material remain available at the successor. Revise means an accountable owner has approved a substantive change and readers can distinguish current information from the previous edition. Retire means there is no honest equivalent destination. These are editorial decisions, not automatically inferred from matching URL fragments.

Separate a move from an improvement experiment. If the release changes the domain, redesigns navigation, rewrites claims, and removes half the documentation, later observations will describe a combined intervention. A small team can still ship such a release, but should not describe the outcome as evidence about redirects alone. Keep a dated list of changes and the reasons for combining them.

Build an old-URL inventory that includes cited evidence

Start with the URLs you own, not just the new CMS export. Compare the old CMS list with available sitemap, link, analytics, and server-log records. Add URLs from saved AI-answer observations. The observation list is a useful supplement: it is not a complete census of everything any assistant has ever seen or linked.

Give each row an owner and a destination decision. Include downloadable reports, images that carry important explanation, developer references, regional pages, and historical announcements. Mark whether the URL is still public, intentionally restricted, obsolete, or unknown. Resolve the unknowns before treating a broad redirect pattern as finished. A catch-all rule can hide inventory gaps behind a superficially successful response.

Keep discovery separate from priority. A URL with little recorded traffic can contain a contractual limitation or research qualification that matters greatly to a buyer. A popular landing page may carry no unique evidence. Prioritise the consequences of losing the answer, alongside observed visits and links, rather than using one traffic threshold to decide what survives.

Match successors by meaning, not by slug similarity

The strongest mapping review asks a person to read the old and new destinations together. Does the successor answer the same decision? Does it preserve the relevant scope? Can a reader recognise the product, version, market, or document edition? A new route named “solutions” is not necessarily a successor to a detailed integrations reference.

Google's site-move guidance calls for mapping old URLs to their new destinations. It warns against sending many old URLs to an irrelevant page such as the homepage, which can be treated as a soft 404. That is documented Google Search guidance, not a description of how every answer provider processes links.

Our editorial test adds a claim-level check to the mapping. When several old pages merge, confirm that the destination actually contains their still-valid information. When an old claim is no longer supported, do not restore it merely to make the map look complete. Provide an appropriate current explanation or record that no equivalent exists. Link consolidation and truth preservation are different jobs.

Treat the redirect response and the destination as separate tests

For a permanent move, Google's redirect documentation recommends a permanent server-side redirect where possible; 301 and 308 communicate a permanent relocation. Do not generalise that recommendation into a guarantee that an assistant will display the new URL, cite the same claim, or refresh an answer on your release schedule.

Ask engineering to test the original URL with an actual request and record the response, location, and final destination. Check a representative selection of routes and every high-consequence mapping, not only the homepage. Include the production hostname and common variants you actually use. Do not assume that a rule which works on staging also covers the public edge configuration.

Then read the destination. Confirm that the expected evidence is present without a login, locale mismatch, broken download, or consent-dependent empty view where public access is intended. A redirect check answers “where does this route go?” A content acceptance check answers “what can the reader verify there?” Requiring both prevents the team from declaring success on transport evidence alone.

Preserve fragments, references, and downloads deliberately

A link may identify a specific section rather than a whole document. For priority pages, inventory meaningful heading anchors and test saved links in a browser after the move. If a cited link ends in a fragment that no longer identifies a section, the page can load while the reader loses the shortcut to the supporting passage. Preserve useful anchors where practical or make the replacement section easy to find.

Treat assets as first-class migration items. A report landing page can survive while its PDF disappears; an implementation guide can preserve prose while its diagram or example file breaks. Check links from inside the destination, not merely whether the file exists somewhere in storage. Avoid replacing an edition-specific file with materially different content without an explicit revision decision.

Maintain a small exception register for unavoidable changes. Record the old reference, the new route, what changed, and who approved it. The register is especially useful when support receives an old screenshot or a bookmarked study. For a deeper document review, use our PDF SEO and downloadable-evidence audit; a migration is not a substitute for checking the file itself.

Check the deployed publication state, not the staging preview

A preview proves that a person with preview access can see a build. It does not prove that the final public route is available under the intended access policy. Before the release, list the protections that are temporary and those that must remain. Have the responsible owners approve the production state rather than asking someone to remove all restrictions indiscriminately.

Google's HTTP-status documentation says a successful 2xx response does not guarantee indexing. It also describes how error-like content can yield a soft 404. This makes status and body checks complementary: a branded error template returning 200 is not a complete public evidence page.

Check the actual response body for priority content, then test the rendered view where the site depends on JavaScript. Verify that a downstream data failure has not replaced the evidence with a spinner, fallback message, or empty component. Capture the tested URL and time so engineering can reproduce a failure. Our JavaScript SEO technical audit covers that diagnostic work without treating one fetch as proof of universal crawler behavior.

Align public discovery with the successor URLs

Do not rely on redirects to repair every first-party path forever. Review navigation, related-reading links, author pages, downloads, emails you control, and maintained product profiles. Give a user a direct route to the current evidence. Include metadata and regional relationships in the release checklist so the visible page and its machine-readable descriptions do not tell different location stories.

Google's sitemap guidance specifies fully qualified URLs and recommends listing the URLs you want shown in Search. It also says lastmod should reflect a significant update, not a cosmetic date change. Review the generated output after deployment rather than trusting the CMS setting that is supposed to produce it.

Record the intended public URL set and check it against what the site actually emits. Look for stale hostnames, preview routes, and unintended archived entries. When the same evidence remains available in multiple places, the canonicalisation audit is a separate follow-up. This release check is about aligning the new publication surface, not inventing a universal AI-discovery feed.

Freeze a pre-move answer sample with exact destinations

Before launch, save a manageable set of buyer questions and the conditions under which you run them. Record the answer date, provider, observed mode, question, visible brand mentions, and displayed source links. Include some questions whose answer should depend on the material being moved. A brand-only question can miss a broken technical or policy destination.

For recurring observations, CiteCue's AI visibility monitoring can support the monitoring step alongside the migration register. AnswerBench and CiteCue have common ownership. Keep its findings tied to the specific saved question and visible source URL; use engineering checks and editorial review to determine whether a migration defect exists.

Do not turn the baseline into an eligibility claim. A page observed once is not assured of appearing again, and an unobserved page may still be important. Preserve the original records rather than overwriting them with current redirects or normalised domains. The distinction between the displayed citation and the URL it now reaches is central to investigating this release.

Classify post-move links without rewriting the history

Use four separate fields: displayed link, current resolved destination, destination quality, and answer accuracy. That structure supports useful distinctions which a single “citation retained” checkbox hides. An old URL can remain displayed while its redirect reaches a correct successor. A new URL can be displayed while its page is missing a crucial qualification. Either finding deserves a precise description.

For an old link that works, record “old URL displayed; successor reachable and relevant.” For an old link that fails, record the actual request failure or irrelevant destination. For a changed answer with no visible support, record the claim discrepancy and what is unknown about its origin. Do not label all three cases as loss of authority or assume a hidden cache explanation.

Keep the before-and-after samples comparable, but accept uncertainty. Different outputs can be observations worth investigating without being proof that the migration caused them. The useful next action is often narrow: repair a broken mapping, restore a supported qualification, or review a regional destination. The citation-source ledger provides a fuller record format for ongoing source review.

Use Google's inspection evidence for the question it answers

Google's URL Inspection documentation distinguishes information about the indexed version from a live test of potential indexability. The live test cannot predict Google's chosen canonical. Inspect the final destination explicitly, and note which view and timestamp your evidence came from.

A useful incident note might say: “The successor now loads correctly in our public test; the indexed report still reflects an earlier crawl.” That is more defensible than claiming the repair failed because an older report has not changed. Conversely, an old indexed record does not excuse a current broken route. Keep both observations visible until the team has enough evidence to close the specific defect.

Do not use a Google-native report as a proxy for every assistant's citation behavior. Maintain separate columns for public route checks, Google indexing evidence, answer observations, and identifiable referral visits. Their disagreements are diagnostic inputs, not numbers to average into a migration score. If analytics configuration also changed, annotate it before comparing visit totals.

Set release blockers before looking at the dashboard

Agree which failures require a correction or rollback and who can authorise it. For a small team, good blockers include a priority policy landing on an irrelevant page, a public reference unexpectedly requiring credentials, or a central claim becoming misleading. A missing mention in one answer run is not the same kind of release defect.

Assign a technical owner to transport failures and a content owner to equivalence failures. They may collaborate on the same row, but neither should close the other's acceptance check without evidence. Keep a communications contact for cases where an externally linked document changes meaning. This makes the migration review a set of accountable decisions rather than a contest over which dashboard looks healthier.

A rollback is also a URL event. Before using it, review whether the old site can serve current, approved information and whether redirect rules would create conflicting paths. Do not switch hostnames back automatically because an answer sample fluctuates. Escalate based on the agreed user-impact threshold and verify the chosen response through the same route and evidence checks.

Keep the old-domain obligations on the calendar

A domain move is not finished when the new homepage launches. Keep ownership, certificates, redirect hosting, and renewal responsibilities assigned. Otherwise, a future infrastructure cleanup can silently undo the route that the release team carefully verified. Budget for maintaining that path instead of treating it as an unowned legacy cost.

Google's move guidance recommends keeping redirects as long as possible, generally at least one year, and considering them indefinitely for users. That is a Google migration recommendation, not a one-year guarantee for AI citation replacement. Choose your operational retention policy with reader needs, external links, and maintenance risk in view.

Review the remaining old-URL requests and known external references periodically. Ask maintainers of important first-party profiles and useful third-party links to update destinations where appropriate; do not demand that they change independent editorial conclusions. A review date should trigger a decision, not automatic deletion. Preserve the mapping history so the next team knows why a redirect exists.

Report evidence continuity, not an invented visibility transfer

The release report should say how many priority mappings were reviewed, which destinations failed, which approved evidence changed, and what remains unresolved. Add dated answer observations as a separate appendix. That format gives founders a concrete view of what the team can control without pretending that search and answer systems update in synchrony.

For example, report “all twelve priority references resolve to reviewed successors; two historical studies retain their editions; one regional policy needs correction.” If a later sample displays fewer old URLs, describe the sample and conditions. Do not rename that observation a transferred ranking, protected citation share, or revenue win. Those labels assert more than the route and output checks establish.

The practical goal is durable evidence access. Keep the question, its supported answer, and a traceable destination connected through the move. A clear migration register helps engineering ship the route, editors preserve meaning, and marketers interpret subsequent observations responsibly. It remains useful even when no monitored assistant mentions the site.

Methodology and primary sources

Verified 7 October 2026. This is primary-source desk research on Google migration, redirect, HTTP response, sitemap, and URL Inspection documentation. The evidence contract, claim-equivalence review, fragment inventory, release blockers, and citation classifications are AnswerBench editorial methods, not provider-mandated AEO rules. Examples are hypothetical; no migration experiment was performed.

Topic selection followed a review of AnswerBench's published and seed catalogue. Current search results showed discussion of migration and AI citations, supporting the usefulness of the question, not a measured keyword-volume claim. This guide addresses planned evidence continuity rather than the separate problems of duplicate consolidation, PDF extraction, or generic monitoring design.

• Site moves with URL changes — Google Search Central.
• Redirects and Google Search — Google Search Central.
• HTTP status codes and Google's crawlers — Google Crawling Infrastructure.
• Build and submit a sitemap — Google Search Central.
• URL Inspection tool — Google Search Console Help.

For the recurring observation layer after a move, use CiteCue for AI visibility monitoring. Keep the resulting observations beside the migration evidence register and verify the destination before deciding what to fix. Monitoring does not promise rankings, mentions, citations, visits, conversions, or revenue.