Last updated: October 29, 2026
AI answers already point to a surprising number of dead pages. In a paper first posted on April 3, 2026, university researchers checked 168,021 URLs that three commercial AI models cited when answering expert questions across 32 academic fields. Overall, 8.22% didn't resolve. The rate ranged by field from 5.4% for business questions to 11.4% for theology, and by model from 4.20% to 9.38%.
Some of those failures were invented links. Others were what the authors call stale URLs: addresses the Internet Archive had recorded, so the page once existed, that no longer resolved. The paper doesn't single out site migrations as a cause. But every SaaS team that relaunches a website without a complete redirect map adds its own pages to that stale pile.
My position: a migration is one of the riskiest SEO events a SaaS company goes through, and the risk now covers AI answers as well as rankings. The fix is a complete URL inventory, a one-to-one redirect map, a disciplined launch day and 90 days of watching, none of it clever. Skip any of the four and you'll spend the next year recovering.
A note on the scope of the study, which comes from researchers at the University of Pennsylvania. The three models included versions released through November 2025, the questions came from an existing expert-question dataset rather than buyer prompts, and the authors don't state the exact date of their URL checks, though the newest model's November 2025 release puts them between then and April 2026. Use the figures as evidence that cited links break often. They don't predict what will happen to your site.
This guide covers redesigns, replatforms and domain changes. For the wider picture of how answer engines select sources, start with the guide to AEO.
Step 1: Build the pre-migration inventory
You can't redirect what you haven't listed. Google's guide to a site move with URL changes says to collect old URLs from several places, and it's right to insist on more than one.
Pull URLs from:
A full crawl of the current site.
Your CMS export, including drafts that went live by accident.
The XML sitemaps, old and current.
Search Console's Performance report, for every URL with impressions in the last 16 months.
Your analytics, for every landing page with sessions.
Server logs, which Google's guide recommends for finding URLs visited at least once recently.
Backlink data, for URLs other sites link to, including ones that already 404.
Google's guide also says to include images, videos, JavaScript and CSS files, because embedded URLs move too. On a SaaS site, don't forget PDFs such as security whitepapers, the help center if it shares the domain, localized paths and any campaign landing pages that ads still point to.
Then mark each URL with three fields: its traffic, its backlinks and whether it states a fact buyers ask about, such as a price, a limit or a certification. That third field matters for AI search, and Step 4 explains why.
Step 2: Write a one-to-one redirect map
Every old URL gets a single destination: the closest equivalent page on the new site. That rules out the home page and any category page that only vaguely covers the topic.
Google's site move guide is specific about this. It says to use server-side permanent redirects (301 or 308) and warns against redirecting many old URLs "to one irrelevant single URL destination, such as the home page", which "might be treated as a soft 404 error." Where you've genuinely merged several pages into one, redirecting the old ones to the merged page is fine.
Three rules keep the map clean:
Redirect to the final destination. Google's guide says Googlebot can follow up to 10 hops but advises "ideally no more than 3 and fewer than 5." If last year's migration left redirects in place, update them to point straight at the new URLs.
Keep URLs that don't need to change. A redesign is not a reason to rename every slug. Each changed URL is a risk you've chosen to take.
Decide deliberately about dead content. If a page has no traffic, no links and no current equivalent, let it return 404 or 410 rather than forcing a weak redirect.
Put the map in a spreadsheet with columns for old URL, new URL, status code, owner and a test result. You'll use it on launch day and for months afterwards.
Crawl staging before you flip the switch
Run a full crawl of the staging site a week before launch, with staging's crawl block lifted only for your crawler. Compare it with the crawl of the live site from Step 1. You're looking for four kinds of gap: pages in the old crawl with no row in the redirect map, new pages that return errors, templates that lost their title tags or headings, and pages whose word count fell sharply. That last check catches the redesign that quietly cut half the copy from your feature pages.
Also check the rendered HTML, not just the source. A new front-end framework can move body copy into JavaScript that some crawlers never execute. If the raw HTML of a key page is mostly empty, fix it before launch rather than after.
Step 3: Run the launch-day checks
Many migration problems come from a handful of settings carried over from staging. Check each of these within the first hour.
Robots rules
Staging sites are usually blocked from crawling. Confirm the production robots.txt doesn't still disallow everything. Then confirm that no template carries a staging-era noindex robots meta tag.
Canonicals
Every page's rel="canonical" should point to its own new URL, not to the old domain, not to staging and not to the home page. Google's guide says to check canonicals and robots meta rules once the redirects are active.
Redirects in practice
Test a sample of the redirect map with a script, and test every URL in the top tier by traffic and backlinks. Google's guide suggests the URL Inspection tool for individual URLs and command-line tools or scripts for large sets.
Sitemaps
Submit the new sitemap in Search Console. Google's guide says that at this point you can remove the old sitemap, since Google will use the new one going forward.
Search Console and Change of Address
If the domain or subdomain changes, verify the new property and submit a Change of Address from the old one. Google's guide says you only need it for moves between domains or subdomains, not for HTTP to HTTPS moves, www to non-www switches or path changes on the same domain. It also says to submit Change of Address for every verified variant of the old domain, including subdomains and www and non-www versions, even ones you don't actively use.
Bing
Verify both old and new sites in Bing Webmaster Tools and submit the new sitemap there too. Bing's December 2025 guidance on duplicate content describes IndexNow as a way to notify participating search engines when URLs are added, updated or deleted, which suits a migration. The old Bing Site Move tool help page no longer loads, so check what your Webmaster Tools account currently offers rather than relying on older guides.
Internal links
Update internal links to point at new URLs directly. Redirects should catch outside traffic, not carry your own navigation.
Step 4: Protect the facts AI answers quote
Rankings can come through a migration intact while the passages AI answers quote don't.
Answer engines quote short, specific passages: a starting price, an integration list, a data residency statement, an uptime commitment. During a redesign, those passages are often rewritten for tone, split across tabs, moved into images or dropped. The page survives the move and the quotable fact is gone.
Use the third field from your inventory. For every URL marked as stating a buyer-relevant fact:
Keep the fact as plain HTML text on the new page, not inside an image, an accordion that loads on click or a JavaScript widget.
Keep the wording close to the old version unless the fact itself changed.
Keep a visible "last updated" date where the old page had one.
If structured data existed on the old page, carry it over and validate it. The post on schema markup for AI search covers what to keep.
Before launch, run your standard buyer prompts through the assistants you track and save the answers and their citations. After launch, run them again weekly. If a citation that used to point at your pricing page now points at a review site or a competitor, find out which fact went missing.
Step 5: Monitor for 90 days, with rollback triggers
Some movement is normal. Google's guide says to expect temporary ranking fluctuation, and that for medium-sized websites "it can take a few weeks or more" for Google to start showing new URLs instead of old ones, longer for larger sites. It also advises keeping redirects for "generally at least 1 year", and from users' perspective it suggests keeping them indefinitely.
What isn't normal is a sustained drop on pages that should have moved cleanly. Watch these weekly:
Clicks and impressions on the new property versus the old, combined, against the pre-launch baseline.
Coverage and indexing reports for spikes in "not found", soft 404 or "excluded by noindex".
Crawl stats for a fall in pages crawled per day.
Your redirect map's test column, rerun weekly against live URLs.
Your saved AI prompt panel, rerun with identical wording each week. The method is set out in the article on tracking AI search visibility.
Agree rollback triggers before launch, in writing. For example: "If non-branded clicks on [page group] stay [percentage] below baseline for [number] consecutive weeks with no fluctuation pattern, we restore the old templates for that group." You set the numbers, and you set them before launch-day nerves are involved.
What to do first, by situation
You're redesigning on the same domain with the same URLs. Your risk sits in templates, not redirects. Focus on Steps 3 and 4: robots rules, canonicals and keeping quotable facts as text.
You're changing URL structure on the same domain. The redirect map carries most of the risk. Don't use Change of Address, because it's only for moves between domains or subdomains.
You're moving to a new domain. Do all five steps, verify every domain variant, and expect the longest monitoring window.
You're replatforming the help center or docs at the same time. Don't. Split the projects if you can, so you know which change caused which effect.
The crawl, redirect testing and monitoring described above are covered on the SEO site migration agency page.
What to watch out for
Launching on a Friday. Problems surface over the weekend when nobody is watching. Google's guide suggests moving during a traffic dip, and a weekday morning gives you a full team to react.
Redirecting everything to the home page. It's quick and it throws away the relevance of every old URL. Google may treat it as a soft 404.
Removing redirects after a few months. Old links on other sites, bookmarks and AI answers keep pointing at old URLs for a long time. Google advises at least a year.
Forgetting the Search Console verification file. Google's guide reminds you that verification tokens may differ after the move. Lose verification and you lose your monitoring view at the worst moment.
Rewriting copy and moving URLs in the same release. If rankings drop, you won't know whether the content or the move caused it.
Bulk-generating new pages to fill the redesign. Google's spam policies treat many low-value pages produced at scale as scaled content abuse, however they're made.
Final thoughts
A website migration feels like a design project, but search engines and answer engines experience it as thousands of URLs changing at once. The teams that come through cleanly list every URL, map each one to a single destination, check the boring settings on launch day and keep watching for three months.
Add one more habit for the AI era: protect the sentences buyers ask about. A page can survive a migration and still lose its citation if the fact it was cited for disappears.