How to Preserve AI Visibility During a Website Migration
A practical website migration plan for URL redirects, canonicals, multilingual pages, indexing, and AI source citations before and after launch.
Key Takeaways
4- Keep valuable URLs unchanged when you can. If URLs must change, map each old page to the most relevant new page before launch.
- Record cited URLs and a stable set of AI questions before migration. Search traffic alone cannot tell you whether source citations survived.
- Test redirects, canonicals, language alternatives, internal links, sitemaps, and indexability on the final public site, not only in staging.
- Compare the same pages and questions after launch, allowing time for recrawling. A working redirect improves continuity but does not guarantee a citation.
A website migration can leave the site looking better while its most useful pages become harder to find. Sometimes an old article redirects to the homepage. Sometimes the new page works in a browser but carries a staging noindex tag. Search visits may recover while an AI answer continues to cite an old URL, or stops citing the page altogether.
The safest approach is to treat the move as a transfer of pages, answers, and evidence, not just a transfer of URLs. Preserve the pages people already use, make every necessary move explicit, and measure search and AI citations separately afterward.
First, decide whether the URLs need to change
A redesign does not require new URLs. If a page’s purpose is the same, keeping its address usually removes one source of migration risk. You still need to test the new HTML, navigation, canonical tags, and indexability, but you do not need a redirect for a URL that never moved.
If the domain, language path, category structure, or individual slugs must change, prepare a page-by-page map. Do this before anyone switches the site live. A list of old URLs without destinations is not a migration plan.
For each important page, record its current URL, destination, page purpose, primary question, owner, and intended action. A simple sheet is enough. Give special attention to product and service pages, documentation, research, and pages already cited in AI answers.
| What happens to the page? | Appropriate action | Check after launch |
|---|---|---|
| It keeps the same purpose and URL | Keep the URL; review the new page output | Content, canonical, indexability, and internal links |
| It moves to a new equivalent URL | Redirect the old URL permanently to that page | Final status, destination, and page relevance |
| Two pages become one genuinely useful page | Redirect each old URL to the consolidated resource | Whether the new page still answers both original needs |
| It has no replacement | Return a real 404 or 410 when removal is intentional | Remove it from navigation and the new sitemap |
Sending every old page to the new homepage may look like a quick fix, but it rarely helps the visitor who wanted a specific answer. Google’s site-move guidance warns against redirects to irrelevant destinations. The same principle matters when an answer engine follows a source link: the destination should still support the claim for which the old page was useful.
Capture a baseline before you move
You cannot tell what was lost unless you know what was visible beforehand. Save the old sitemap and a crawl of the important templates. Export the landing pages and queries that matter in Search Console. If you use Bing Webmaster Tools’ AI Performance report, note the URLs it shows as cited pages; that report covers supported Microsoft AI experiences, not every answer engine.
Then choose a small, stable set of questions tied to the pages being moved. For each question, record the market, language, answer engine, date, answer, and cited URL. Brantial’s prompt and source views can help you repeat that check after launch, but do not treat one answer as a permanent ranking. Answers and citations can change between runs even when your site has not changed.
Prioritize by consequence. A pricing page quoted for buying questions deserves closer attention than an archive page nobody reaches. This is not a reason to ignore the rest of the site; it is a way to direct the first round of checks.
Make the new page a credible replacement
A redirect alone cannot preserve information that disappeared from the destination. If the old page explained a product limit, a comparison method, or a return condition, check that the new version still makes that fact easy to find and verify. A visual redesign that replaces useful text with an image can make the page less helpful to readers and automated retrieval systems.
Review the title, main heading, direct answer, supporting details, and visible update context. Keep claims accurate rather than copying old text blindly. Where product data changes frequently, check that the page, structured data, and any feed agree on price, availability, and specifications.
If the new site relies on JavaScript, inspect the response a crawler receives. The main answer, links, and canonical should not depend entirely on a click or a late-loading API. Our AI site audit checklist covers the wider access and rendering checks; this migration guide focuses on continuity between old and new pages.
Test the technical signals together
Before launch, test a sample from every page type. After launch, repeat the same tests against the public URLs, including the ones that used to be cited.
- Redirects: An old URL should reach its relevant final destination through a server-side permanent redirect, usually
301or308. Avoid unnecessary chains and loops. - Canonical URLs: The final page should identify its own preferred URL. Do not leave canonicals pointing at staging or the retired domain.
- Language versions: If English and Turkish pages both exist, update
hreflangpairs to the actual new URLs. Do not advertise a translation that redirects to another language. - Internal links: Update menus, article links, product cards, and footer links to their final URLs instead of relying on redirects forever.
- Sitemaps and access: List the new canonical, indexable pages. Remove staging
noindexrules and verify that robots, CDN, and security settings allow the intended crawlers to reach public content. - Response and content: A missing page should not return a misleading
200. A page that returns200should contain the expected answer, not an empty shell or a security challenge.
These checks reinforce each other. A correct 301 will not solve a destination with noindex; a clean sitemap will not rescue a page whose canonical points somewhere else. Google’s migration documentation recommends updating redirects, canonicals, internal links, language annotations, and sitemaps as one coordinated move.
What to watch after launch
Start with the mapped, high-value URLs. Confirm the redirect destination, the final page’s response, and what a logged-out visitor can actually read. Inspect representative pages in Search Console and Bing Webmaster Tools. For a domain change, use Search Console’s Change of Address process where applicable; a path change on the same domain is not the same procedure. Submit the new sitemap, and use IndexNow for supported search engines if it is part of your publishing workflow.
Next, compare outcomes without mixing them into one score:
- Search continuity: Are the new URLs being discovered, indexed, and visited? Which old URLs still appear in search reports?
- AI citation continuity: For the same question set, do answers cite the old URL, the new URL, another page on your site, or no owned source?
- Answer accuracy: Does the answer still describe the current product or policy correctly, even when it cites a different page?
- Business outcome: Are relevant visits and actions continuing on the new pages?
Give the systems time to recrawl. A citation on an old URL a few days after launch is a signal to investigate, not proof that the migration failed. Likewise, one answer citing the new page is encouraging but not proof that every market or engine has caught up. Compare like-for-like periods and keep a record of other changes, such as major content edits or product launches.
A practical first-week review
On launch day, test the homepage, a sample from every template, and every high-value old URL. Check the final status and destination, then inspect the new page’s canonical, language tags, indexability, and primary text. Fix broken journeys before polishing secondary metadata.
During the first week, review crawl and indexing errors daily for the pages that matter most. Repeat your saved AI questions on the same engines and in the same markets, recording cited URLs and answer accuracy. If citations move to a different source, inspect what that source answers before rewriting your page. The problem may be a broken path, a missing fact, or a source that now provides clearer evidence.
After the initial move settles, keep the redirect map and monitoring in place. Google advises keeping permanent redirects for at least a year and, where practical, longer. A website migration is complete when visitors and systems consistently reach the right information, not merely when the new design is online.
Frequently asked questions
Will a 301 redirect preserve my AI citations?
It helps people and crawlers reach the replacement page and is the right choice for a permanent move. It cannot guarantee that any AI system will cite the new URL. The destination still needs to be accessible, relevant, and useful for the question.
Do I need new URLs for a redesign?
No. If the page’s role has not changed, keeping the existing URL is often simpler. Test the redesigned page’s content and technical signals anyway; a redesign can introduce problems without changing a single path.
Can Search Console show every AI citation I lost?
No. Google includes its AI search features in overall Search performance reporting rather than providing a complete, cross-platform citation list. Compare Search Console with the citation data available in the specific answer engines and tools you use. The measures answer different questions.