Migrating Your Store Without Breaking Product Feeds

Short answer: When you move a store to a new platform or theme, protect four things: product IDs (so platforms keep item history and pixel matching), product URLs (so feed links resolve to the right pages), the feed data source (so platforms keep fetching a valid file), and account settings such as the verified domain and shipping. Build the new feed before launch, compare it item by item with the old one, switch data sources on launch day, and check diagnostics daily for the following two weeks.

Why migrations break feeds

Platform migrations are among the most common causes of sudden drops in Shopping and catalog ad performance. The new store may look better and work faster, but underneath, many small things change at once: product IDs, SKUs, URL structures, variant handling, image URLs, price and tax settings, structured data and the feed tool itself. Each change can be harmless on its own. Together, they can make platforms see a completely new catalog.

When item IDs change, Merchant Center treats every product as new: previous performance data no longer attaches to the items, and campaigns built on product-level decisions lose their footing. When pixel content IDs change differently from feed IDs, Meta retargeting stops matching. When URLs change without the feed following, every link is broken until the next fetch.

None of this is inevitable. With a plan, a migration can pass almost unnoticed by the platforms.

Theme changes on the same platform deserve the same care on a smaller scale. A new theme can change how variant URLs work, how prices are displayed with tax, what structured data is output and whether verification tags remain in the page header. Treat a theme switch as a mini-migration and run the same checks.

Protect product IDs

The single most important decision is to keep item IDs the same. In most stores, feed IDs are SKUs, which can usually be carried over to the new platform as long as they are imported correctly. Check:

• Every product and variant keeps its SKU in the new platform.
• The new feed tool uses the SKU as id, not a platform-specific internal ID or a new format with prefixes.
• Variants keep the same level of granularity: if the old feed listed variants, the new feed must too.
• The pixel and Conversions API on the new site send the same content IDs as the feed.

If IDs must change, for example because the old ones were internal database IDs, accept that history resets and plan for a learning period in campaigns. Do not change IDs twice.

A quick way to confirm ID continuity is to take the old feed file and the new one, extract the id column from each, and compare the lists. The number of IDs present in only one of the two lists tells you immediately how much history is at risk. For a smooth migration, that number should be close to zero, apart from products you deliberately added or removed.

Map URLs and keep links valid

URL structures often change between platforms. Product pages that lived at one path move to another. For search engines, you add redirects from old to new URLs. For feeds, the new feed should use the new URLs directly, because links that redirect can cause issues and slow down crawling.

1. Export all old product URLs and map each to its new URL.
2. Set up redirects on the new site for search and for any old links still in platforms.
3. Make sure the new feed contains the new URLs, including variant parameters.
4. Check that the domain stays the same, or plan for claiming a new domain in Merchant Center before launch.

A domain change is a bigger step: Merchant Center must verify and claim the new domain, and products linking to the unclaimed domain will be disapproved until that is done.

Image URLs usually change too. That is fine for feeds, as long as the new URLs point to full-size images on a reachable host. Expect platforms to re-crawl all images after the switch, which can briefly show items as pending while images are processed.

Rebuild and test the feed before launch

Build the new feed on the new platform before the store goes live, and compare it with the old feed. A comparison by ID reveals most problems:

If the new store runs on a staging domain before launch, remember that its feed will contain staging URLs. Do not submit it to the live account; use it only for comparison, and make sure the production feed uses the final domain.

Involve whoever manages campaigns in this comparison. They know which products carry the most spend and which labels campaigns depend on, and can spot missing custom labels or product types that a purely technical check would not flag as important.

Switch data sources deliberately

On launch day, the order of steps matters:

1. Launch the new store on the final domain and confirm product pages work.
2. Generate the production feed and check a sample of links, prices and stock.
3. Point the existing data source to the new feed URL, or add the new feed as a source and remove the old one after a successful fetch.
4. Trigger a manual fetch rather than waiting for the schedule.
5. Update the Meta catalog data source in the same way.

Keeping the same data source and only changing its URL is usually simplest, because targeting, feed labels and settings stay intact. Avoid running old and new feeds side by side in the live account with the same IDs, which can cause conflicts.

Timing matters too. Avoid launching a migration right before a major sale or peak season. If something goes wrong, you want time to fix it before the most valuable traffic of the year arrives. Many teams schedule launches early in the week, so issues surface on working days.

Check account settings

Migrations also affect things outside the feed. Verify after launch:

• Website verification still works; verification tags or files may not have been carried over to the new theme.
• Shipping costs and delivery times at checkout still match Merchant Center settings.
• Return policy, contact page and other trust pages exist at working URLs.
• Product structured data on the new pages is correct and consistent with the feed.
• Conversion tracking and pixels fire correctly with the expected IDs.

If conversion tracking changes during the migration, for example because the new platform uses a different tracking integration, compare reported conversions with actual orders for a few days. Automated bidding relies on these signals, and a silent drop in tracked conversions can look like a performance collapse even when sales are fine.

Monitor the first two weeks

For about two weeks after launch, check diagnostics daily. Watch for landing page errors, price and availability mismatches, image issues and sudden changes in approved item counts. In ad platforms, compare impressions and clicks with the weeks before, allowing for some fluctuation. Fix issues at the source on the new platform quickly, while the team still has the migration in mind.

Keep the old feed file available for reference during this period. When something looks different, comparing an item in the old and new files is often the fastest way to see what changed.

Finally, write down what you learned. Migrations are infrequent, so the lessons are easily lost by the next one. A short note on what broke and how it was fixed is valuable for the next theme change or platform move.

How Feeds helps

Because Feeds builds feeds from outside the store, you can create a feed from the new WooCommerce or Shopify store (or a CSV export) and compare it with the old one before switching, without installing anything on either. The output is a Google product XML file that Merchant Center and Meta can fetch, with rules to skip out-of-stock items, rewrite titles and adjust prices. See the pricing page for plans.

Related reading

• Product Feed URL: Hosting, Access and Keeping It Reliable
• Product Landing Pages: What Feed Links Must Lead To
• Feed Plugin, Channel App or Feed Service: How to Choose

The bottom line

A store migration is safe for product feeds when item IDs stay the same, feed links use the new URLs, the new feed is compared with the old one before launch, data sources are switched deliberately, and account settings are rechecked. Monitor diagnostics daily for two weeks and fix issues at the source on the new platform.

FAQ

Will changing my e-commerce platform reset Merchant Center history?

Only if item IDs change. If the new feed uses the same IDs, products keep their history in Merchant Center.

Should feed links use redirects from old URLs?

No. Redirects help search engines, but the feed should link directly to the new product URLs.

What if my domain changes during the migration?

Verify and claim the new domain in Merchant Center before switching feeds, otherwise products linking to it will be disapproved.

Can I test the new feed before the store goes live?

Yes. Generate it from the new store and compare it with the old feed by ID. Do not submit a feed with staging URLs to the live account.

How long should I monitor after a migration?

About two weeks of daily checks, then return to the normal weekly routine if everything is stable.