You delete a product, refresh Merchant Center, and there it is again. For an indie shop owner, deleted product feeds keep coming back at exactly the wrong moment: after a sellout, after a discontinued item, or after you’ve already moved on to the next fire. That kind of mismatch costs more than a little cleanup. It can waste ad spend, send shoppers to dead pages, and make your catalog look less trustworthy than it is.
The frustrating part is how often the obvious fix looks correct. The product is gone in your store. The feed file looks clean. The app says it’s synced. Meanwhile, another connection, another schedule, or another layer of processing can keep publishing the old version of your catalog long after you thought the job was done. Once that happens, deletion stops being a simple edit and turns into a control problem.
1) Content API: Hidden data sources that resurrect products
You pulled the product three days ago. It’s gone from your storefront, gone from your inventory system, and yet there it sits in Google Merchant Center, still live, still potentially routing shoppers to a page that no longer exists. Before you assume the problem is your feed file or a sync delay on Shopify’s end, check something less obvious: whether a second ingestion path is feeding Merchant Center entirely independently of the feed you just edited.
Google’s Merchant API allows accounts to create and manage data sources programmatically, through a method called dataSources.create, which supports both primary and supplemental product data sources. A developer who wired up your store, a marketing app you installed six months ago, or a price-comparison integration you half-remember approving can each maintain their own live data source. When a product is removed via your storefront or your main feed, those API-connected sources keep running their own logic. The deletion signal never reaches them because it was never sent to them.
Removing a product through the API requires a separate call, accounts.productInputs.delete, and that request must explicitly name the data source it targets. If a product was inserted into a supplemental source by a third-party app, your manual feed deletion touches a completely different object. The product input in the API source remains intact, and Merchant Center will keep surfacing it.
The complication worth sitting with: for file-based data sources, you cannot directly query data source status as a single operation. Checking what is actually live requires pulling dataSources.list and then cross-referencing with fileUploads.get, which means the audit step is less clean than the fix itself. You may have to map your active sources manually before you can be certain which one is keeping a deleted product alive.
Crawl timing layers on top of this. Even after a product input is correctly deleted from every source, Google’s crawler can take up to 30 days to re-check and reflect that removal. Fixing the ingestion source is the necessary first step, but it rarely produces an immediate result in what you see displayed.
2) Scheduled fetch: Cached URLs can re-add deleted items
Crawl timing is only one half of the delay problem. The other half lives inside your own account configuration, and it runs on a clock you probably set once and forgot.
Google Merchant Center supports scheduled fetches, where it retrieves your feed file automatically at a fixed interval rather than waiting for you to upload one manually. For product feeds, Google Dynamic Content can be configured to pull updated XML or CSV files up to 6 times per day. The idea is straightforward: keep the feed current without manual intervention. In practice, it creates a mechanism that can override your intentional deletions on a predictable schedule.
When you remove a product, your feed file reflects that removal the moment you save it. But if a scheduled fetch is set to pull from a cached or slowly updating URL, the crawler may retrieve a version of the file that still contains the deleted product. Caching plugins and server-side caching layers can hold a stale copy of your feed file at that URL. If your hosting environment serves the cached version rather than the live one, the scheduled fetch fires correctly but reads the wrong data. Disabling the scheduled fetch is not the solution, because that leaves your entire feed unrefreshed; the fix is ensuring the feed URL itself bypasses caching so the file Google retrieves always reflects your current catalog.
There is a second layer underneath this. Google Merchant Center’s Product Protection feature includes an item deletion threshold: if too many products disappear from a feed at once, the system treats the disappearance as a potential error and holds the removed items rather than processing their deletion. A scheduled fetch that pulls an accurate, updated file can still fail to remove a product if that threshold is triggered.
A deleted product can still come back after you have confirmed the feed file is correct. The scheduled fetch retrieves a fresh file, Product Protection second-guesses the removals, and the crawler’s own re-check window stretches up to 30 days on top of both. Three separate mechanisms are working against the same deletion, and fixing the feed file alone addresses only the first one.
3) Feed reprocessing: Stale syncs keep deleted items live
Even when the feed file is clean and the fetch schedule is accurate, the processing layer between your catalog and Merchant Center can hold deleted items in circulation long after you stopped sending them.
The most straightforward version of this failure is also the easiest to miss: a product you deleted in Shopify is still being submitted to Merchant Center because the feed itself has not refreshed. Deletion on the storefront side does not automatically propagate downstream. Until the feed regenerates and Merchant Center ingests the updated file, the removed item travels through the pipeline exactly as it did before you pulled it. Confirming the feed is set to update daily and that no stale cached version is being served covers most of these cases, though some reports trace the persistence to a backend sync failure inside Shopify’s own feed generation service, where deleted variants remain stuck in the pipeline regardless of what the storefront shows.
The harder version involves parallel sources. If more than one data feed is submitting your catalog to Merchant Center (a second feed you set up for a specific campaign, an old staging connection that never got disconnected, a supplemental feed added by an app), deleting a product from your primary source accomplishes nothing while the secondary source keeps filing the same item. Google surfaces guidance to audit exactly this: confirm there is only one active feed, and that it is the one reflecting your current catalog. When multiple sources are involved, the fix is not just correcting one feed but identifying and removing every upstream connection that might still be publishing the product.
Product Protection compounds both scenarios. A processing layer that intentionally stops large-scale removals from taking effect will hold deleted products whether the deletion came from a clean single feed or a partially corrected parallel setup. The deleted product feeds keep coming back, in these cases, because the system was designed to resist exactly that kind of bulk disappearance.
Audit your active data sources before you troubleshoot the feed file itself. One connected source you forgot about will undo every fix you make to the one you remember.
4) Third-party app integrations: Syncs can override deletions
Third-party sync apps introduce a control problem that’s distinct from everything upstream: the app may keep publishing your catalog even when you believe you’ve severed the connection.
The clearest illustration of this is what happens after you reinstall Shopify’s Google & YouTube app. The expectation is that a clean reinstall resets the relationship. In practice, the Merchant Center feed source can persist independently inside Merchant Center itself, still pulling data from a connection the app created before you removed it. Removing the app from Shopify does not remove the feed source in Google, so both endpoints must be closed separately. And here’s the sharper problem: if Shopify is still actively pushing product data through any live integration, manual removals you make inside Merchant Center may only hold temporarily before the next sync overwrites them. Switching to a third-party feed manager or a manual upload approach may be the only way to stop the overwrite cycle when the app’s automatic sync is the source of the conflict.
For WooCommerce stores, the culprit is more likely caching. A plugin or host-level cache can serve a stale version of the feed file to Merchant Center, one that still includes products you’ve already removed from the catalog. The feed Merchant Center sees lags behind the feed that exists now; it’s the feed that existed when the cache was last written. Purging or disabling that cache is the fix, but the storefront can still look correct even as the feed being transmitted is weeks out of date.
When neither of those applies, the delay itself can read as a malfunction when it isn’t one. Deletions can take anywhere from a few hours to roughly 72 hours to clear from Merchant Center depending on catalog size and system load, and it may take as long as 30 days for Google to recheck a product URL after deletion. That window makes a resolved problem look like a persistent one.
The question worth sitting with is whether your current setup gives you actual control over what gets published, or only the appearance of it. An app that syncs on its own schedule, through its own connection, answers to its own logic first.
Final thoughts
A product that won’t stay deleted is a sign that your catalog has more than one boss. When Merchant Center, a sync app, a scheduled fetch, and your store can each keep publishing their own version of the truth, the real cost isn’t the stray listing. The real cost is losing confidence in which system actually has authority over your inventory.
Control is the asset at stake here. If deleted product feeds keep coming back, your setup is telling you that removal doesn’t travel cleanly from decision to publication. Treat that as an operating issue, and the fix gets clearer: reduce duplicate sources, make update paths visible, and keep one place where a deletion truly sticks.
