Google's Content API for Shopping is off. Here's how to tell if your feed is quietly broken

Google switched off the Content API for Shopping on 18 August 2026, and since 1 September the calls that survived have been failing outright. If nobody on your team has raised it, that is not reassuring. This is a failure that arrives as products quietly going stale rather than as an error anyone sees, and the 30-day clock that decides when it becomes visible runs out at roughly this point in September.

What changed, and on which dates

Three dates matter, and only the third one is visible to anyone who is not reading API logs.

The replacement is the Merchant API, now generally available. It is not a version bump. It lives on a different host, uses a different resource model, and rewrites the object shapes: resources are identified by name rather than id, child resources are addressed through a parent, and prices moved to an amountMicros plus currencyCode pair. Anyone who built against the old API has to change code, not configuration. That is exactly why so many integrations were left until after the deadline.

Are you actually affected?

Most merchants are not, and the ones who are usually do not know which group they are in. The dividing line is simple: the shutdown only affects programmatic integrations. If your product data reaches Merchant Center through a scheduled fetch of a feed URL, a manual file upload, a Google Sheet or Google's own crawl of your site, this change does not touch that pipe at all.

The awkward cases are the ones in the middle. A store can run the Shopify channel and a separate feed tool for a subset of markets, or have inherited a script an agency wrote three years ago that still quietly pushes price updates every night. Ownership, not platform, is what determines exposure, and ownership is what almost nobody has written down.

The twelve-minute check anyone can run

You do not need a developer to find out whether your feed is still alive. Six steps, in this order, and stop as soon as one of them fails.

1. Merchant Center → Products. Look at the "last updated" timestamps across your catalogue. If the most recent update predates 18 August 2026, nothing has written to the account since the shutdown, and you have your answer in one step.
2. Check each product's data source. Merchant Center records where an item came from. An item whose source is the API and whose timestamp is stale is a confirmed casualty.
3. Look at expiring items, not disapprovals. The count that moves first is expired or soon-to-expire products. Disapprovals are a different failure and will distract you.
4. Compare five SKUs by hand. Pick five products whose price or stock changed in the last two weeks. Compare what Merchant Center shows against your live product page. Drift means the feed is stale even when the account looks healthy.
5. Chart Shopping and Performance Max impressions by day since 18 August. The signature of this failure is a step down followed by a slow decline as more SKUs expire, not a smooth slope.
6. Search the account owner's inbox. Google sent migration notices to affected accounts through 2026 and showed them in Merchant Center. Those notices went to whoever owns the account, which is frequently not whoever runs the ads.

Why some unmigrated stores are still fine

Here is the part that makes this failure genuinely hard to spot: some accounts with a dead API integration are still serving most of their catalogue, and the reason is their own website.

Google refreshes Merchant Center products by crawling the product landing page. Where a page carries valid schema.org Product structured data that can be validated against the page itself — price, availability, identifiers — Google can refresh the item automatically without any upload. An account whose API writes stopped on 18 August can therefore be kept partly alive by its own product pages, for the subset of attributes that mechanism covers.

Two things follow from that, and both are worth more than the migration itself.

1. Your structured data is a redundancy layer, not just a rich-results feature. Most teams treat Product schema as an SEO nicety. In this failure mode it is the thing standing between a broken pipe and an empty Shopping account. If your product pages carry accurate, validated Product markup, you have a second path into Merchant Center that costs nothing per month.
2. Partial survival is why this goes unnoticed. If the failure were total, someone would have caught it in the first week. Instead the well-marked-up half of the catalogue keeps serving while the rest expires, impressions fall by a third rather than to zero, and the whole thing gets attributed to seasonality.

The caveat matters: automatic refreshes from a crawl are a safety net, not a replacement. They cover a limited set of attributes, they depend on your markup validating against the visible page, and they do nothing for the products you add, retire or re-price in bulk. Treat them as the reason you still have time, not as the fix.

What a stale feed costs, in numbers you can calculate

Two separate losses run at once, and conflating them is why this gets under-prioritised.

Expiry loss is the SKUs that fall out of the account entirely. It compounds daily as more items hit their 30-day mark:

Mismatch loss is quieter and often larger: products still serving on stale data. You pay for clicks on items that are out of stock, and price mismatches between the feed and the landing page trigger disapprovals of their own. Neither shows up as a missing product.

A worked illustration, with the assumptions stated so you can substitute your own numbers. Take a store doing $4,000 a day in Shopping and Performance Max revenue across 2,000 live SKUs, whose API writes stopped on 18 August, with expiry starting 17 September and rolling through the catalogue over the following fortnight:

These figures are an illustration of the shape of the loss, not a benchmark — the inputs are yours to replace. The shape is the point. The loss is negligible in week one, which is precisely when it is cheap to fix, and it is close to total by the time it is large enough for anyone to notice in a monthly report. Push that curve four weeks later and it runs straight through the only quarter that pays for the year.

If you have not migrated, do this in this order

1. Establish whether anything is still writing. Step one of the check above. Ninety seconds.
2. Stop the bleeding before you fix the plumbing. If the API path is dead, add a scheduled fetch of a feed URL, or a supplemental feed, as a stopgap. It is not elegant and it does not need to be — it refreshes products and resets the 30-day clock while the real migration happens.
3. Find out whether an extension applies to you. Google ran an extension request process for accounts that needed more time. If yours was approved, your calls may still be working and your deadline is later than you think. If nobody applied, assume not.
4. Audit your product structured data. Valid, page-matching Product markup on your PDPs buys you resilience for this failure and for the next one. It is worth doing whether or not you migrate today.
5. Migrate the integration to the Merchant API. Budget developer time rather than configuration time: new host, new resource names, new price shape, and feed labels that do not carry across automatically.
6. Write down who owns each pipe. One page listing every route product data takes into Merchant Center, the system that owns it and the person who gets the email when it breaks.

What this changes about how you buy feed work

The technical migration is a week of someone's time. The reason it turned into a live revenue risk for a slice of merchants is organisational: the Content API was usually installed once, by someone who has since left or been replaced, and it has no owner. Google's notices went to a Merchant Center account owner who may not be the person running the ad account, and the failure surfaced as a metric decline rather than an alert.

That is a fixable gap and it is not specific to this API. The same pattern is why checkout tracking breaks silently after a platform deadline, and why a plugin update takes down a form nobody tests. If you are commissioning paid media work or a store build, ask for the integration inventory as a deliverable: every pipe, its owner, its renewal or deprecation date, and the alert that fires when it stops. It is an hour of documentation that turns this class of failure from a Q4 emergency into a calendar entry.

Frequently asked questions

Has the Content API for Shopping actually stopped working?

Yes. Google shut it down on 18 August 2026, and since 1 September 2026 requests from accounts without an approved extension have been failing intermittently with HTTP 410. The replacement is the Merchant API, which is generally available. Applications built against the old API need code changes, not configuration changes, because the host, the resource model and the price format all differ.

Am I affected if I use Shopify's Google & YouTube channel or a feed tool?

Not directly. The shutdown only affects programmatic integrations, and with Shopify's channel, a WooCommerce plugin or a feed management platform, the integration belongs to that vendor rather than to you. Your job is verification, not migration: check that your products still show recent last-updated timestamps, make sure the app or plugin is on a current version, and ask the vendor in writing to confirm they migrated.

How do I check whether my product feed is still updating?

Open Merchant Center, go to Products and look at the last-updated timestamps across your catalogue. If the most recent update predates 18 August 2026, nothing has written to the account since the shutdown. Then compare five products whose price or stock changed recently against your live product pages. Drift between the two means the feed is stale even if the account otherwise looks healthy.

What happens to my Shopping campaigns if the feed stops updating?

Products expire from Merchant Center 30 days after their last refresh, so an account whose writes stopped on 18 August 2026 begins losing products from around 17 September. Expired products stop serving in Shopping and Performance Max. Before that, products still serving on stale data cause a second problem: wasted clicks on out-of-stock items and disapprovals where the feed price no longer matches the landing page.

Why are some products still updating even though our integration is dead?

Google refreshes Merchant Center products by crawling the product landing page. Where a page carries valid schema.org Product structured data that validates against the visible page, Google can refresh those items automatically without any upload. This is why an account with a broken API integration can still be serving part of its catalogue, and it is the main reason the failure goes unnoticed. It covers a limited set of attributes and is a safety net, not a replacement for a working feed.

Can I still get an extension for the Content API?

Google ran an extension request process for accounts that needed more time, and accounts with an approved extension may still be receiving responses. If nobody on your side applied, assume you do not have one. The practical fallback if your integration is dead is to add a scheduled fetch of a feed URL or a supplemental feed as a stopgap, which refreshes products and resets the 30-day expiry clock while the real migration is built.

The takeaway

Nothing about this shutdown announces itself. There is no error page, no email to the person running your ads, and no single day on which Shopping stops working. There is a dead integration, a 30-day expiry clock that started on 18 August, and a decline curve that is cheap to fix in week one and close to total by week four. Open Merchant Center, look at when your products were last updated, and you will know within ninety seconds which of those two situations you are in.