How to Protect AI Retrieval During a Site Migration: Redirects, Canonicals, and Prompt QA

A site migration can keep rankings alive and still wreck your AI retrieval.

That is the part many teams miss.

A page can hold onto some organic visibility after a migration and still disappear from answer-engine responses. The URL changed. The canonical changed. The proof block got trimmed by a designer. The FAQ markup vanished with the old template. The internal links now point at a cleaner but thinner page.

To a search team, the migration looks acceptable. To ChatGPT, Claude, Gemini, or Google AI Mode, the page may no longer look like the same source.

We ran a DataForSEO validation before writing this. The demand is there. site migration seo shows 720 US monthly searches, website migration seo checklist shows 480, site migration checklist shows 260, and seo migration checklist shows 210. That is classic SEO demand, but the GEO layer is now part of the same job. If your migration breaks retrieval on pricing, services, comparison, and case-study pages, you can lose much more than rankings.

This guide is not a general migration checklist. It is the operator workflow for preserving answer-engine visibility during a replatform, template overhaul, URL restructure, or information-architecture change.

Why migrations break AI retrieval faster than teams expect

Search rankings can recover from some mess. AI retrieval is less forgiving when page identity gets blurry.

Here is what usually changes during a migration:

• •URLs get consolidated
• •templates get simplified
• •answer blocks get rewritten into shorter copy
• •proof, screenshots, quotes, or FAQs get dropped
• •canonicals get standardized without checking page purpose
• •internal links move to a new nav model

Those decisions look harmless in isolation. Together they change what the page is for.

That matters because answer engines do not just need a crawlable page. They need a page that still matches the same buyer job with the same proof and the same contextual cues.

If you need the broader technical foundation first, read our GEO crawlability audit and AEO schema audit. This article picks up where those leave off. It covers the migration moment, when good pages often lose continuity because teams focus on launch mechanics instead of retrieval continuity.

Step 1: baseline the URLs that already win important prompts

Do not start with the full URL inventory.

Start with the URLs that already do real commercial work.

For most brands, that means some mix of:

• •service pages
• •pricing pages
• •comparison pages
• •category or solution pages
• •case studies
• •expert or author pages
• •a small set of educational pages that support high-intent prompts

Before anything moves, capture four things for each winning page:

This is where URL-level citation tracking becomes essential. Domain-level reporting will not tell you which page actually did the work before the migration.

A quick example:

• •/services/geo-agency wins commercial prompts about hiring a GEO partner
• •/pricing appears for qualification questions about cost and scope
• •/blog/case-studies-ai-citations supports trust and proof-heavy prompts

If you only baseline the domain, you miss that each of those URLs serves a different retrieval role.

Step 2: map redirects by page job, not by folder structure

This is where migrations go sideways.

Teams often map old URLs to the nearest new folder match. That is efficient for engineering. It is terrible for retrieval continuity.

An old comparison page should not redirect to a generic product hub just because both sit under /solutions. A case-study page should not redirect to a broader resource center page. A proof-rich pricing page should not redirect to a lightweight contact page with a pricing teaser.

The redirect target needs to do the same job.

Use a redirect sheet like this:

The question is simple:

If an answer engine retrieved the old page for a buyer prompt, would the new target still deserve that retrieval?

If the answer is no, you do not have a redirect map. You have a relevance leak.

Step 3: preserve canonical and schema parity at cutover

A lot of migrations lose AI visibility because the new page technically exists, but it no longer sends the same machine-readable signals.

Check these on every high-value migrated page:

• •canonical points to the intended new winner, not to a parent page or filtered variant
• •breadcrumb structure still reflects the page type
• •FAQ, service, article, or review-related schema still matches the visible content
• •updated dates, author context, and proof elements are still present where they matter
• •page metadata still names the same core topic and use case

This does not mean you should clone every old tag and field blindly. It means you should preserve the parts that clarified page role.

A common failure looks like this:

• •old page had a direct service answer block, fit criteria, case-study links, FAQ markup, and a clean canonical
• •new page has nicer design, fewer words, no visible FAQ, weaker qualification copy, and a shared canonical mistake from the new template

That page may be prettier. It is also less interpretable.

If the migrated page is a commercial asset, apply the same discipline we recommend in service-page answer blocks. If it is a proof asset, preserve the source detail and narrative density that makes case studies citable.

Step 4: protect the proof layer, not just the page shell

Many migration checklists track URLs and status codes. They do not track evidence.

That is a problem because AI retrieval often leans on the proof layer:

• •specific numbers
• •time references
• •customer segments
• •named comparisons
• •implementation steps
• •qualification criteria
• •concise FAQs with visible answers

During a redesign, those details often get cut because they feel repetitive or visually dense.

That is exactly the content that helps a model decide the page is useful.

Build a proof-preservation checklist for each important page type.

If the new template cannot hold the same evidence density, fix the template before launch. Do not tell yourself you will add it back later. Later becomes the recovery sprint.

Step 5: rewire internal links around the new winners on day one

Migrations often keep the new pages live but starve them of internal reinforcement.

That shows up in a few ways:

• •blog posts still point to redirected legacy URLs
• •nav links move buyers toward category pages instead of the real commercial winner
• •case studies lose links into services and pricing pages
• •comparison pages become isolated because the new IA treats them as secondary resources

Your launch checklist should include a short list of link-source pages for every important migrated URL.

For example:

• •core service page should receive links from the homepage, framework page, relevant blog posts, and supporting proof pages
• •pricing page should receive links from service pages, sales enablement content, and decision-stage guides
• •case studies should link back into the service or solution page they validate

This is one reason migration QA should include page clusters, not just page-by-page checks. Retrieval continuity depends on the supporting network too.

Step 6: run prompt QA before launch and again after launch

Do not wait for rankings reports.

If a page was winning prompts before the migration, test those prompts again as soon as the new version is live.

Your QA set should include:

• •the original commercial prompt cluster
• •adjacent comparison prompts
• •qualification prompts
• •implementation prompts if the page used to support them
• •at least two alternative surfaces, such as ChatGPT and Gemini, or ChatGPT and Google AI Mode

A simple launch-day QA log works well:

That table does two things.

First, it tells you whether the migration preserved retrieval. Second, it creates the recovery queue immediately when it did not.

A practical example: service page survives, pricing page disappears

Imagine a B2B SaaS company migrates from a custom site to a new CMS.

The service page keeps most of its answer blocks and still appears for agency-selection prompts.

The pricing page does not.

Why?

Because the old pricing page had:

• •scope qualifiers
• •clear package logic
• •implementation notes
• •a visible update date
• •links from service and case-study pages

The new pricing page has:

• •a single hero line
• •a "contact us for pricing" form
• •no scope guidance
• •no FAQ section
• •no direct internal links from supporting pages yet

The redirect worked. The retrieval job did not.

This is why migration QA needs to ask two different questions:

1. •Did the old URL resolve correctly?
2. •Does the new page still deserve the same retrieval outcome?

Too many teams stop at the first one.

Build a seven-day recovery loop before launch, not after the damage

Even a good migration will create some misses.

Plan for them.

Your first post-launch week should have a fixed recovery cadence:

This is where a migration-specific process beats a generic checklist. You are not just checking whether the site launched. You are checking whether the commercial retrieval system survived.

The migration mistakes that cause the ugliest GEO losses

A few patterns show up again and again.

Redirecting high-intent pages to broader category hubs

This weakens intent match fast. Broad hubs rarely replace a page that used to answer a narrow commercial prompt.

Removing visible proof because the redesign feels too crowded

If the new design cannot carry the proof the old page relied on, the design is the problem.

Treating canonicals as a template exercise

Shared canonical logic can quietly point important pages at the wrong winner.

Delaying prompt QA until the next reporting cycle

By then the team has lost the cleanest view of what changed at launch.

Measuring the migration at the domain level

That hides the exact page that lost the retrieval job.

Where this fits in a serious GEO operating model

A migration-safe GEO workflow connects four layers:

• •baseline the pages and prompts that matter
• •preserve page job, proof, and machine-readable context through the move
• •test retrieval immediately after cutover
• •turn misses into owner-specific recovery work inside the first week

If you already have monitoring but no execution system, pair this with our guide to a GEO content refresh queue. If you are still working at too broad a level, start with URL-level citation tracking. Those two systems make migration recovery much faster because they tell you which page slipped and what kind of fix it needs.

Final takeaway

A site migration is not just a technical event.

For answer engines, it is a test of continuity.

Can the new page still be found? Does it still answer the same buyer job? Does it still carry the proof that made it useful? Do your internal links, canonicals, and schema still point at the right winner?

That is the real migration question now.

If your team is replatforming, consolidating URLs, or rebuilding templates, we can help you protect the pages that drive AI visibility before launch and recover the ones that slip after cutover.

FAQ

How is a GEO-safe migration different from a normal SEO migration?

A normal SEO migration usually focuses on redirects, status codes, indexing, and ranking preservation. A GEO-safe migration adds another layer: preserving page purpose, proof, answer blocks, schema context, and prompt-level retrieval for the specific URLs that matter in AI search.

Which pages should get prompt QA first after a migration?

Start with service, pricing, comparison, and case-study pages. Those pages usually influence commercial prompts and buying decisions most directly. Educational pages can follow after the money pages are stable.

Can a correct redirect still hurt AI visibility?

Yes. A redirect can be technically correct and still weaken retrieval if the new target page is thinner, more generic, missing proof, or pointing to the wrong canonical. Redirect accuracy and retrieval continuity are related, but they are not the same thing.