You are moving your store to a new platform, and somewhere in the back of your mind is a quiet worry: what happens to all the places you already show up? Not just Google rankings. The moments when ChatGPT, Perplexity, or Google AI Mode names your product to someone ready to buy. Those citations live on specific URLs, and a replatform touches every one of them.
Here is the good news. An ecommerce replatform AI engines can follow cleanly is mostly a planning problem, not a luck problem. The stores that lose visibility almost always skip the same steps. The stores that preserve AI citations migration usually breaks do a few unglamorous things in the right order.
This guide gives you that order, so your ecommerce replatform AI visibility comes through intact. It is built for the person who owns content and search, not the engineer running the deploy, and it centers on the two places migrations go wrong at scale: mapping thousands of product URLs and handling faceted pages during cutover. Take it one step at a time.
Why a replatform puts AI citations at risk
First, know what you are protecting. A standard replatform does three risky things at once. It changes your URL structure, it swaps the structured-data layer, and it re-emits your metadata. Each one can break a signal AI engines rely on to cite a product page.
AI engines add a second layer of risk that a normal redirect audit misses. They cache URLs aggressively and re-fetch on slower cycles than Googlebot. When an engine cited your Nike Pegasus page last week, it stored that exact URL. If the redirect is missing or lands on the wrong page after cutover, that engine will not cite the new URL cleanly until it re-fetches and validates the chain. Even on a clean migration, expect a two to four week gap between when the old URLs stop being cited and when the new ones start.
A clean cutover with a complete redirect map and schema parity usually sees a 5 to 15 percent organic dip that recovers within about 90 days. A sloppy one, with mass homepage redirects and lost schema, can drop 15 to 20 percent or worse and take a year or more to recover, if it recovers at all. The whole point of the plan ahead is to preserve AI citations migration would otherwise erase, and stay firmly in the first camp.
One story makes the stakes concrete. A brand moving 847 product pages from one platform to another redirected 311 of them to the homepage during cutover and lost most of its organic revenue within three weeks. Two extra days of URL mapping would have prevented it. Treat that as a cautionary tale, not a statistic, but let it motivate the mapping work ahead.
Step 1: Baseline your AI citations before anything moves
You cannot protect what you have not measured. So the first move, four to eight weeks before cutover, is to document where you show up in AI answers today.
Pick 15 to 25 buyer prompts that matter in your category. Real ones, the kind a shopper types: "best trail running shoes for wide feet under $150." Run each prompt in ChatGPT, Perplexity, Gemini, Claude, and Google AI Mode. For every prompt, record three things: whether your brand is mentioned, which of your URLs is cited, and which competitor URL is cited. Run it twice over a couple of weeks so the baseline is stable, not a one-day snapshot.
You know this step is done when you have a per-prompt, per-engine table showing your mentions, your cited URLs, and the competitors winning the same prompts. That table becomes your recovery benchmark. After cutover, you re-run the exact same prompts and watch the numbers come back.
Here is where people go wrong: they record their own citations but skip the competitors. Citation recovery is relative. Without a competing baseline, you cannot tell whether you actually recovered or just slipped while a rival held steady.
Running this by hand across five engines is real work, and it is easy to skip when you are busy. This is one of the spots where a dedicated AI visibility platform earns its place. DeepSmith tracks mention rate and citation rate across ChatGPT, Perplexity, Gemini, Claude, and Google AI Mode, keeps per-prompt history so you can see the dip and the recovery, and shows the competitor leaderboard for each prompt. Its Discover Prompts feature can even generate your starter battery from your products and buyers, so you are not staring at a blank page.
Step 2: Export and audit every URL and its schema
Now inventory what you have. Crawl the live old site and export every indexable URL with its title, H1, meta description, canonical tag, the schema types it emits, and its status code. For a catalog of 10,000 products, this can balloon to hundreds of thousands of URLs once faceted combinations are counted. That is the real surface AI engines see.
While you are at it, audit schema by template, not by page. Which templates emit Product, Offer, AggregateRating, Review, and BreadcrumbList markup? Which fields are actually populated? A tool like Screaming Frog handles the crawl and chain export; the free tier covers small sites, and a license covers unlimited URLs. Larger catalogs may need something built for scale.
You are done when you have a complete list with status codes, the redirect chain each URL already sits in, and a clear picture of which templates have working schema and which do not.
The common mistake here is crawling only the pretty product and category URLs and ignoring search, sort, and pagination URLs. AI engines see all of them, so your export should too. The same goes for schema: audit category, search, and informational templates too, since engines cite those pages as well.
Step 3: Lock your new URL naming convention
Decisions you make now cost almost nothing to change. The same decisions inherited by 10,000 auto-generated URLs cost a fortune. So define your new URL structure before a single line of storefront code ships.
A dependable convention looks like /category/subcategory/product-handle/: lowercase, hyphenated, no database IDs in the path, no session or sort parameters, and a single consistent choice on trailing slashes. Some platforms fix parts of this for you. Shopify, for example, always serves products under /products/ and collections under /collections/. Any gap between your old paths and those fixed paths becomes a redirect you will have to write, so map that gap now, not on launch night.
You know this step is done when you have a written URL spec with a real example for each template, checked against how your new platform actually emits URLs in staging.
The mistake to avoid is inheriting the platform's raw defaults, like /products/12345-blue-widget, without normalizing them. Pro tip: test the default on five real products in staging before you commit. Headless platforms differ, and a demo URL is not always what you get in production. Pick a convention, freeze it, and move on.
Step 4: Build the product URL redirect map
This is the heart of site migration AI visibility work, and the step the failed migrations always shortcut. Your product URL redirect map is a single table where every old URL has a defined home on the new site.
Build it in order of confidence. Match first by SKU or product ID, which is your cleanest one-to-one. Then match by slug, normalizing case and hyphens and fuzzy-matching what is left. Then match by parent category plus the closest descendant. Whatever remains goes to manual review, where each orphan URL gets one of four decisions: a 301 to the closest equivalent product, a 301 to the parent category, a 410 Gone if the product is truly retired, or, only as a genuine last resort, the homepage.
Give every row these columns: source URL, destination URL, status code, match type, a note on why it changed, whether it was tested in staging, and its go-live date. That discipline is what separates a map you can trust from one that hides holes.
You are done when every source URL either points to a live 200 page that matches the original intent, or returns a 410 because nothing on the new site should replace it. No orphans, no guesses.
Two mistakes wreck redirect maps. The first is the homepage dump. Search engines and AI engines treat a product-to-homepage redirect as a soft 404 and quietly drop it, which is exactly how that 847-page brand lost its revenue. The second is over-broad regex. A rule that promises to remap a whole tree in one line can collapse distinct categories and erase the meaning in your URLs. Audit every pattern.
For catalogs above 10,000 products, generate the map programmatically from your old and new exports rather than by hand. And remember your Step 2 inventory: knowing each old URL's topic and intent is what lets you choose the right destination instead of the nearest one. This is where DeepSmith's Sitemap module helps, since it classifies your existing pages by topic, type, and buyer stage, giving you a cross-check when you decide where a retired URL should point.
Step 5: Decide the faceted URL policy on purpose
Every filter combination on a category page, color, size, brand, price, sort, is technically its own URL. During a replatform, these ecommerce migration redirects are the easiest thing to get wrong, because there are so many of them and no one owns the decision. So make the decision on purpose, before cutover.
Start by sorting your faceted URLs into two piles. Keep and redirect the ones that earn their place: any facet with external backlinks, with real clicks or impressions, with an AI citation, or that matches genuine buyer intent like "women's running shoes size 10." Those get 301s to their new equivalents. Everything else, the thin or duplicate combinations, can be consolidated or kept out of the index entirely.
For the URLs you do not want indexed, you have clean options. Blocking the parameter patterns in robots.txt is the simplest and Google's usual preference. Canonical tags pointing to the base category preserve the URLs while consolidating signals. Noindex works too, but leaks the most crawl budget. Pick one policy per template and code it before launch.
You are done when you have a written, per-template faceted policy and the matching robots, canonical, or noindex rules are already in the new site.
The AI-specific mistakes here are subtle. A product page whose canonical points to its category will never be cited as a unique product. A canonical that points at a URL which is itself a redirect never lands its signal. And canonicalizing your variant pages into the parent can erase the exact "size 10, blue" combination a shopper asked an AI engine to find. Check that your canonicals point to live, self-referencing pages.
Step 6: Keep AI crawlers welcome in robots.txt
A replatform is the most common moment to accidentally lock AI crawlers out, because the new site often inherits a robots.txt from a staging template or a security plugin. Those defaults quietly lock AI crawlers out, blocking the exact bots you need.
Decide your access policy deliberately. The major AI crawlers now use identifiable user-agent tokens: GPTBot, OAI-SearchBot, and ChatGPT-User for OpenAI; ClaudeBot and Claude-SearchBot for Anthropic; PerplexityBot and Perplexity-User for Perplexity; Google-Extended for Gemini grounding. For AI visibility, you want these allowed on your live product, category, and informational paths. Disallow only true waste: internal search, cart, checkout, account, admin, and the sort or filter parameters you decided to block in Step 5.
One nuance trips people up. Blocking Google-Extended does not remove you from Google Search; normal Googlebot indexing is untouched. It only stops your content from appearing in Gemini-grounded answers. If AI citations are the goal, allow it.
You are done when your robots.txt names each crawler you want, allows it on the paths that matter, and blocks only waste. Validate it by fetching real pages as each user agent and confirming they return 200.
The mistake, again, is the inherited default. Before you flip DNS, open the new robots.txt and read it line by line. A single stray Disallow on GPTBot or PerplexityBot can quietly cost you every citation on those engines.
Step 7: Cut over with redirects live first
Order is everything on launch day. Your redirect rules must be live before any traffic, including search engines and AI crawlers, reaches the new URLs. If you have to do it in one window, deploy the redirects first, validate a sample, then flip DNS. For very large rule sets, a reverse proxy or edge-worker layer is the cleanest way to manage them.
Keep the rules simple and permanent. Use 301 for every product, category, and content URL that changed, since your ecommerce migration redirects only pass signal cleanly when they are permanent. Skip 302 entirely unless the move is genuinely temporary, because a 302 does not pass signal predictably. And keep the redirects in place for at least 12 months. The cost of leaving a redirect up is near zero; the cost of removing it early is a fresh round of lost citations.
You know cutover went well when a random sample of 100 redirected URLs each returns the right destination at status 200, with a canonical pointing to itself and no extra hops in the chain. This sample check is your fastest read on site migration AI visibility health in the first hours after launch.
Watch for the small compounding mistakes: redirecting retired products to the homepage, mixing www and non-www or http and https without their own rules, trailing-slash and uppercase mismatches, and tracking parameters carried onto the destination. None is dramatic alone, but together they turn a clean plan into a messy one. Take a breath and check them one at a time.
Step 8: Rebuild schema to match or beat the old site
Your redirects can be perfect and your citations can still slide if the schema quietly regresses. New platforms, especially headless ones, emit different structured data by default, and the gaps are easy to miss.
Do a field-by-field diff between what your old templates emitted and what the new one produces. The usual regressions: Offer.price missing on variants, AggregateRating dropped from product pages that have reviews, BreadcrumbList missing its item URLs, and schema prices that no longer match the on-page price. That last one matters, because engines treat a price mismatch as a trust problem. Stick with JSON-LD, since it is the format AI crawlers parse most reliably. Validate every template against Google's Rich Results Test and the Schema Markup Validator before launch.
You are done when your per-template schema counts and per-field fill rates match or exceed the old baseline, with no required field missing on any page you test.
The mistake is treating schema as a "later" task. These regressions are small and silent, and they compound over weeks into a real citation loss. Pro tip: guard your reviews above all. Ratings and review content directly answer the "is this any good?" sub-question AI engines fan out to, so losing review markup during migration causes a measurable drop. Any content rebuilt after launch should ship with the same structured-data baseline instead of drifting from it. Publishing pipelines that bake AEO formatting and schema in during creation, like the one inside DeepSmith, keep that baseline consistent so post-migration content does not quietly fall behind.
Step 9: Validate and monitor recovery for 90 days
Launch is not the finish line. AI engines re-cache on slow cycles, so a problem you cannot see on day one can surface at day 60.
Run these checks weekly for the first eight weeks, then monthly through six months. Confirm redirect coverage on a rolling sample of 100 URLs. Watch Search Console coverage; a drop of more than 10 percent needs investigation. Compare your indexed URL count before and after. Re-validate schema on a sample of product, category, and blog pages against your baseline. And, most important for this guide, re-run your Step 1 prompt battery every 30 days and track mention and citation rate per engine.
You are done, and can relax the cadence, when the numbers sit in the healthy band: a 5 to 15 percent traffic dip that recovers within 90 days, and an AI citation dip under 20 percent in the first month that fills back in over 30 to 90 days.
The classic mistake is stopping the watch at week four because early numbers looked fine. That is exactly when a quiet schema or canonical break starts to bite. Keeping a citation monitor running past launch, whether that is your manual prompt battery or a tool like DeepSmith's AI Visibility tracking, is how you catch a slow regression while it is still cheap to fix.
What to do next
You do not need to do all nine steps today. You need the first one. Baseline where you show up in AI answers now, before anything moves, because that single table is what makes every later step measurable. Then work down the list in order, and lean hardest on the redirect map and the faceted policy, since that is where migrations quietly lose their citations.
If tracking citations across five engines by hand is the part that keeps slipping, that is worth fixing before your cutover, not after. DeepSmith gives you the AI visibility baseline, the per-prompt recovery tracking, and the publish-ready content pipeline in one place, so your migration has a safety net instead of a blind spot. You can start a free DeepSmith trial and have real data before your move.
You have got this. One step at a time.
