When you migrate a store, your product reviews need to be exported from the source and reimported as structured data, because they are both your social proof and the basis for the star ratings you show in search, so losing them costs conversions and rich snippets at once. Reviews are visible on your product pages, so a capture sees the text, but to reimport them properly you need each review as data: its rating, author, date, and the product it belongs to, which comes from an export of the store’s review records. On the new platform you load that data into the review system, whether the platform’s own or a review app, so the reviews reattach to the right products with their ratings intact. Keep the product URLs the same so the reviews, and the star snippets they feed, stay with the same pages. WPBuildAI exports your product reviews with their ratings and dates and reimports them onto the matching products, so your social proof and your search stars survive the move.
Reviews do two jobs, so losing them hurts twice
The reason reviews deserve real care is that they carry two kinds of value at once. On the page, they are social proof: the ratings and comments that reassure a shopper and tip them toward buying, so a product page stripped of its reviews converts worse. In search, they are the data behind your star ratings, the review snippets that make your result stand out. Lose the reviews and you lose both at the same moment, weaker pages and no stars, which is a double hit to conversions. That combined role is exactly why reviews cannot be treated as disposable page text in a migration; they are among the most valuable data a store carries, and they need to arrive on the new platform intact.
Capture sees the text, but you need the data
There is a subtlety that trips people up. Reviews are public, shown right on the product page, so a front-end capture does see the review text, which might suggest capture is enough. It is not, if you want to reimport them properly, because a captured page gives you the reviews as displayed prose, not as structured records you can load into a new review system with their ratings, authors, and dates attached to the right products. This is the same output-versus-data distinction that governs custom field content: to reuse reviews as functioning reviews, you export them as data from the store’s records, not scrape them from the page. So the reliable route is an export of the review records, taken while you still have access to the source store.
Reimport onto the matching products
With the reviews exported as data, the new platform loads them into its review system, and the crucial part is that each review reattaches to the correct product with its rating, author, and date preserved. Whether the new store uses the platform’s native reviews or a dedicated review app, the import maps every review to its product, so a product that had forty reviews and a strong average shows forty reviews and that average on the new site, not a blank widget starting from zero. Preserving the dates matters too, since the history and recency of reviews are part of their credibility. This mapping is the heart of the job: reviews that arrive unattached, or as anonymous text, are not really migrated, because the value was in the structured connection between a review, its rating, and its product.
Keep product URLs stable so stars reattach
The SEO half depends on URL stability. Star snippets attach to a specific product URL, so keeping your product pages at the same URLs, and 301-ing any that must change as in any careful site move, is what lets Google reassociate the reviews and their stars with the same page after recrawl. Combined with re-emitting the product and review structured data on those pages, the reimported reviews then support the star rich results again, once Google revalidates them. This is the same mechanism covered in keeping review star snippets through a migration: real reviews plus valid markup on stable URLs. The reviews are the data; the URL and schema are what keep the search stars pointing at the right page.
Never fabricate to fill the gap
A warning worth stating plainly: do not paper over lost reviews with fabricated ones. Google requires that review snippets reflect genuine reviews, and inventing ratings to keep the stars, or padding thin review counts, violates its policies and risks the snippet entirely, quite apart from misleading shoppers. The platform itself is not a ranking factor, as the Backlinko analysis shows, and neither are fake reviews a shortcut; they are a liability. So the honest and effective path is to migrate the real reviews you earned. If some genuinely cannot be moved, it is better to continue collecting real reviews on the new store than to fabricate, because authenticity is both the compliant choice and what actually persuades customers.
Steps to migrate product reviews
- Export the reviews as data from the source: rating, author, date, and product.
- Choose the destination: the new platform’s reviews or a review app.
- Import and map each review to its correct product, preserving ratings and dates.
- Keep product URLs stable, 301-ing any that must change.
- Re-emit review and product structured data on the product pages.
- Verify counts and averages match the old store, and never fabricate to fill gaps.
Worked example: social proof and stars both survived
Consider a store whose bestselling products carried hundreds of genuine reviews and showed star ratings in search. Migrating platforms, the team exported the reviews as structured data rather than trusting a page capture, so each review kept its rating, author, and date. On the new store they imported the reviews through a review app, mapping every one to its product, so the bestsellers again displayed their full review counts and averages. Product URLs stayed the same, and the review and product schema were re-emitted. After Google recrawled, the star snippets returned to the same product pages. Both jobs the reviews did, persuading shoppers and earning search stars, came through the migration intact, because the reviews moved as real data on stable URLs.
Limitation: some review sources may not export cleanly
It is honest to bound this. Reviews stored in the store’s own records usually export well, but reviews held in a third-party review service, or in a format the new platform’s importer does not accept, may need the service’s own export, a mapping step, or in stubborn cases may not transfer completely. Verified-purchase flags, review images, and merchant replies are extras that do not always survive an import. So inventory where your reviews actually live and in what form before assuming they will move, and where a source resists, work with that review provider’s export tools. The core ratings and text are usually recoverable; the trimmings deserve a check, and continuing to collect genuine reviews on the new store backfills anything that could not come across.
Key points
When you migrate a store, product reviews must be exported from the source and reimported as data, because they are both social proof on the page and the basis for your search star ratings, so losing them costs conversions and rich snippets together. Though reviews are visible, a capture only gives you the text; reimporting them properly needs each review as a record with its rating, author, date, and product, loaded into the new platform’s review system and mapped to the matching products. Keep product URLs stable and re-emit review and product structured data so the star snippets reattach after recrawl, and never fabricate reviews to fill gaps, since that breaks Google’s policy and misleads customers. Some reviews held in third-party services may need their own export and can lose extras like images or replies. WPBuildAI exports your product reviews with their ratings and dates and reimports them onto the matching products, so your social proof and your search stars survive the move. Send your web address for a free analysis.
Not affiliated with WordPress, Lovable, Webflow, Shopify, Wix, or Squarespace.