> ## Content Index > Fetch the complete content index at: https://www.livain.com/llms.txt > Use this file to discover other available public pages before exploring further. # A shop platform upgrade took out the ad layer, not the shop: 60 disapproved Google Ads that don't come back when the pages do - URL: https://www.livain.com/blog/shop-platform-upgrade-disapproved-google-ads-dont-come-back-by-themselves/ - Published: 2026-10-14T07:00:00.000Z - Updated: 2026-10-14T06:59:59.000Z - Description: A major Shopware version jump left every page returning 200 by the next morning — and sixty ads still disapproved. Ad rejections are stored state, not a symptom, and somebody has to ask for the re-review. - Author: Remco Livain - Tags: Google Ads, Ecommerce, Merchant Center, Deployment, Marketing Tech The morning after a major shop-platform upgrade, I crawled every URL in the sitemap with Google's own ad crawler user-agent. All 200\. One category path answered with a redirect; the homepage and the cart were fine. The shop was healthy. Sixty ads and five assets were still disapproved, across sixteen campaigns. The feed for the main market had lost over 40% of its active items inside a six-hour window. Nobody had reported any of it. The dashboard in the shop admin was green, because the shop admin doesn't know what Google thinks. That gap — the pages are fine and the advertising is still dead — is the whole post. It is the part of a deployment that nobody owns. ### What actually happened A home & living brand I look after ran a major version jump on its shop platform ([Shopware 6.6 to 6.7](https://developer.shopware.com/release-notes/6.7/6.7.0.0.html?ref=livain.com), a release with a long list of breaking changes). The window was approved for a morning mid-week. I'd signed off with an explicit reservation on record: marketplace deals were live that week, and the agency that owns the platform isn't reachable at the weekend. Two independent systems flagged it within hours of each other. Google Ads reported mass disapproval with the reason "destination not working" on most of them. Merchant Center reported active items collapsing, simultaneously in Shopping, free listings and dynamic remarketing for that country. The cause was transient and completely mundane. During the upgrade's error window, Google's AdsBot crawled, got HTTP errors, and did what Google's [destination requirements](https://support.google.com/adspolicy/answer/6368661?ref=livain.com) say it will do: refused the destinations. The feed crawl hit the same window and dropped the items it couldn't verify. By the next morning the pages were back. The disapprovals were not. ### Rejections are state, not a symptom This is the bit I want operators to internalise, because it inverts the normal debugging instinct. Fix the cause, symptom clears — that's the usual deal. Not here. Google is unambiguous: [a disapproved ad won't run until the violation is fixed *and the ad is reviewed again*](https://support.google.com/google-ads/answer/9338593?ref=livain.com). Saving an edit resubmits it. Or you go into the Policy manager, open the policy issues tab, and appeal under "made changes to comply with policy." Either way, somebody has to make an explicit request. There is no process that notices your site recovered and quietly puts your inventory back. So the shop being healthy again is necessary and not remotely sufficient. The disapproval is a stored decision about your account, and it sits there until a human asks for a re-review. Over a weekend, with nobody on the agency side watching, that's two full days of dead inventory going into the pre-Black-Friday run-up. The appeal, in this case, was the only remaining step — the destinations were already fine, which is the easiest appeal there is and still requires someone to file it. > The outage lasted three hours. The consequence lasts until someone clicks appeal. The feed is a slightly different animal — it should recover on the next crawl. "Should" is doing real work in that sentence, and I've learned to verify rather than assume, because major upgrades have a habit of resetting field mappings: GTIN, availability, price. The same brand lost a [promotion on four country shops for a month](https://www.livain.com/blog/price-governance-ecommerce-promotion-died-silently-four-shops/) to an undocumented date lock that survived a restore. A feed that silently serves the wrong price is worse than a feed that empties out, because nothing alerts on plausible. ### The expensive part isn't the ads, it's the timing Among the sixteen affected campaigns were the ones carrying a video launch that was due to scale into four figures a day, and on which the platform's own rep was waiting for a go-live confirmation. From Google's side, that launch was not live. Any status update claiming otherwise would have been wrong, and I had a draft sitting there that needed rewriting before it went out. It also landed in a week where the board was already questioning the campaign restructure on the back of a weak month. That's the part a technical post-mortem usually leaves out and shouldn't. Two measurable technical causes of lost reach and lost signal belong in that analysis *before* the strategy gets written off — otherwise a deployment accident gets recorded as a marketing misjudgement, permanently, in a board pack. Making that distinction is most of what a fractional marketing exec is actually for. ### The governance question, which is the real one This was the third incident from the same platform partner in two weeks: a main call-to-action pointing at a 404 and still unfixed a week later, now redirecting in a circle; a marketplace pulling a base price nobody could explain; and this upgrade, shipped into a live promotional test window with no post-deploy check of the ad layer. The useful question is not "when will this be fixed." It's: which approval and verification rule is missing? A major platform upgrade without a subsequent check of ads, feed and prices is not a deployment. It's a risk with no owner. DORA's research treats [change failure rate](https://incident.io/blog/dora-metrics-change-failure-rate?ref=livain.com) as a first-class delivery metric, and the usual mistake is to scope "failure" to the application. Here the application was fine within hours. The commercial layer bolted onto it was not, and nothing in the release process was looking at it. So the post-deploy checklist I now ask for is short and boring. Crawl the sitemap with the ad crawler's user-agent. Pull the ad account's policy issues. Diff active feed items against the pre-deploy count. Spot-check three prices against checkout. Four checks, ten minutes, and a named owner — because the [last time a deploy quietly removed a tracking snippet](https://www.livain.com/blog/gtm-snippet-removed-from-page-nineteen-days-no-measurement/) it cost nineteen days of measurement, and the time before that we were [fixing checkout in production](https://www.livain.com/blog/we-fixed-checkout-in-production/). Deployments get tested. The marketing layer hanging off them mostly doesn't — and it's the layer that stops earning money the moment a crawler sees a 500. ### Sources & further reading **External** [Fix a disapproved ad or appeal a policy decision](https://support.google.com/google-ads/answer/9338593?ref=livain.com) — Google Ads Help [Destination requirements](https://support.google.com/adspolicy/answer/6368661?ref=livain.com) — Google Advertising Policies Help [Release notes, Shopware 6.7.0.0](https://developer.shopware.com/release-notes/6.7/6.7.0.0.html?ref=livain.com) — Shopware developer documentation [Understanding DORA's change failure rate metric](https://incident.io/blog/dora-metrics-change-failure-rate?ref=livain.com) — incident.io **Related posts** [Price governance in ecommerce: a promotion that died silently on four shops](https://www.livain.com/blog/price-governance-ecommerce-promotion-died-silently-four-shops/) [The GTM snippet was gone from the page](https://www.livain.com/blog/gtm-snippet-removed-from-page-nineteen-days-no-measurement/) [We fixed checkout in production](https://www.livain.com/blog/we-fixed-checkout-in-production/) [Everything returned 200](https://www.livain.com/blog/everything-returned-200/)