Google’s Content API for Shopping reached its official sunset date on August 18, 2026, and on September 1 the consequences started arriving. Requests from Google Cloud projects without an approved extension now fail intermittently with an HTTP 410 Gone response, with full decommissioning scheduled for early 2027 according to Google’s published sunset timetable.
For Michigan retailers selling through Shopping ads and free listings, this is the least dramatic and most expensive kind of deadline: nothing crashed, no alert fired, and the damage compounds quietly for weeks before anyone notices revenue is off.
What exactly changed on September 1, 2026?
Google began deliberately breaking a percentage of Content API v2.1 requests rather than shutting the API off. Google calls this “progressive service degradation.” Calls that get rejected return a 410 error whose payload includes the reason content_api_sunset, your Google Cloud project ID and number, and a link to the Merchant API compatibility guide.
Three details from Google’s documentation matter more than the headline. First, the artificial errors do not count against your project’s API quota, so quota dashboards stay green. Second, Google states plainly that a retried request may succeed, because only a portion of traffic is rejected. Third, the failure rate is designed to increase over time until every request fails at decommissioning.
The replacement is Merchant API v1, which splits the old monolithic API into sub-APIs for products, inventory, accounts, and reporting. It is not a version bump you absorb by changing a URL string — resource names, authentication scopes, and the batching model all changed.
Why is an intermittent failure worse than a full shutdown?
Because a total outage gets escalated within an hour, and a 10% failure rate gets swallowed by a retry loop and a monitoring threshold that was tuned for normal network flakiness. The mechanism is worth understanding, because it predicts exactly which parts of your catalog break first.
Most feed integrations do not push every SKU on every run. They push deltas: the items whose price, availability, or shipping data changed since the last sync. When a slice of those calls returns 410 and your job does not surface the failure, Google keeps serving the last successfully received values for those items. Your site says $189.99 and out of stock; Merchant Center still believes $164.99 and in stock.
That mismatch does not produce an API alert. It produces item-level disapprovals for price mismatch and availability mismatch, and those items stop serving in Shopping and stop feeding Performance Max. Account-level impression share barely moves, because the other 90% of your catalog is fine. The SKUs that vanish are, by construction, the ones you changed most recently — which for most retailers means the items being repriced for a promotion or restocked for a seasonal push. You lose exactly the inventory you were trying to sell hardest.
Apply that logic anywhere. A store that syncs once nightly and reprices monthly might go six weeks before a single item drifts. A store running hourly inventory updates against a warehouse system will start bleeding availability accuracy within days.
Does “my platform handles the migration” actually cover me?
Sometimes, and it is the assumption most likely to cost a Michigan retailer money this quarter. Google’s guidance splits the world in two: custom integrations must be rewritten by whoever built them, and merchants who connect through an ecommerce platform have the migration managed by that platform partner, with no action required.
Here is my disagreement with how that line is being repeated across the industry. “Your platform partner manages it” describes the mainline connector, not the accretion of custom work that sits around it. In practice, most catalogs of any size have accumulated a second integration path: a supplemental feed script a developer wrote in 2022 to push fitment attributes the platform app did not support, a nightly job that updates local inventory for one storefront, a promotions uploader, a script that flips availability when a supplier file lands. Those all authenticate through a separate Google Cloud project, and that project is not covered by anyone’s platform migration.
This is the specific shape of the risk for Michigan’s aftermarket and industrial sellers. A parts distributor in Warren or a marine dealer near Traverse City competes on fitment precision and stock accuracy, and those are exactly the fields that get maintained by bolt-on scripts rather than by the storefront app. The platform keeps syncing titles and images beautifully while the custom job that carries year/make/model attributes quietly returns 410s, and the listings that survive are the ones least able to win a fitment-critical search.
How do I check whether my store is affected this week?
Search your logs for the string content_api_sunset and check Merchant Center for a rising count of price and availability mismatch disapprovals. If either turns up something, you have an active integration that has not migrated.
Two supporting checks close the gap. In Google Cloud console, open APIs & Services for every project your business owns and look at whether Content API for Shopping still shows recent traffic — traffic there is the definitive answer, because it means something is still calling the old endpoints regardless of what your vendor told you. Then compare the “last updated” timestamp on a handful of products in Merchant Center against the last time you actually changed those products in your own system. A gap of more than one sync cycle is drift.
What is the seven-step migration checklist for a small team?
- Inventory every caller. List each Google Cloud project and service account that touches Merchant Center. Include the ones owned by a former contractor. This is a one-hour task and it is the step people skip.
- Grep your codebase for the old endpoints. Search for
shoppingcontent.googleapis.comandcontent/v2.1. Anything that matches is on the clock. - File the extension request immediately for anything you cannot rewrite in 30 days. Google exempts approved projects from the artificial errors, but extensions do not survive past decommissioning in early 2027. Treat it as breathing room, not a reprieve.
- Map old services to Merchant API sub-APIs. Products, inventory, accounts, and reporting now live in separate surfaces. Google’s compatibility guide gives the equivalents; do this on paper before writing code.
- Install the current Merchant API client library for your language and rebuild authentication against the new scopes rather than adapting the old credentials.
- Test against a non-production Merchant Center account and diff the resulting product data field by field against what your live account holds. Fitment and custom attributes are where silent field loss shows up.
- Add a failing-loudly alert. Any non-2xx response from a feed job should page someone. If your sync jobs currently swallow errors, fix that before you fix anything else — it is the actual root cause of every scenario in this article.
All seven fit inside a week for a team of three, and steps 1, 2, and 7 take a marketer with log access one afternoon. The expensive part of this deadline is not the engineering — it is discovering in November that nobody owned it.
Which dates should be on the calendar right now?
- August 18, 2026 — Content API for Shopping officially sunset.
- September 1, 2026 — Intermittent
HTTP 410 Goneresponses began for projects without an approved extension. - Late September 2026 — Practical deadline to finish migration before Q4 volume. Feed instability during a promotional calendar is far harder to diagnose than feed instability in a quiet month.
- October 2026 — Michigan’s winter-goods demand curve begins. Batteries, plow parts, winter tires, and generators start moving, and these are inventory-volatile categories where availability drift costs the most.
- Black Friday week, November 27, 2026 — The worst week to reprice through a degraded API.
- Early 2027 — Full decommissioning. All Content API endpoints turn down and every request fails. Google notes this timing may shift with ecosystem migration progress, so treat it as a floor.
If you are also rebuilding how product data reaches Google, it is a reasonable moment to audit what those listings actually say. Our team at Rosh Media tends to find that a feed migration surfaces attribute gaps that predate the API change by years.
Frequently asked questions
Will retrying failed requests get me through to 2027?
Retries will work for a while, and Google says so explicitly, but it is a trap. The failure rate is scheduled to increase until every request fails at decommissioning, so a retry-based patch degrades continuously without ever throwing a clear error. You will be tuning retry counts upward for months instead of spending one week migrating.
Does the extension request cost anything or require a Google rep?
No. Google publishes a self-serve extension request form in the Merchant API support documentation, and an approved extension exempts your Cloud project from the artificial 410 responses for the approved window. It does not extend past final decommissioning in early 2027, and it does not migrate anything for you.
My Merchant Center account looks healthy. Am I fine?
Not necessarily. The account-level view stays healthy while individual items drift, because the products Google is still serving are the ones whose data successfully uploaded before the failures started. Check item-level disapproval trends and product update timestamps rather than the account summary, and check your application logs for the 410 reason string.
Does this affect free listings as well as paid Shopping ads?
Yes. Merchant Center product data powers free listings, Shopping ads, and the product inventory that Performance Max draws on. A price mismatch disapproval removes an item from all of them at once, which is why an API problem that looks purely technical shows up as an organic visibility problem too.
The short version
Find every Google Cloud project that still calls Content API for Shopping, file an extension for anything you cannot rewrite this month, and make your feed jobs alert on failure. The deadline that will actually hurt is not early 2027 — it is the six weeks between now and Q4, when a slowly degrading feed and a seasonal repricing cycle overlap. If you want a second set of eyes on a feed setup before the holiday ramp, start here.
Comments are closed