If your Google Shopping data feed starts drowning in low impressions, your product titles are probably just… bad. Not cute-bad. Just nonfunctional. I once spent two hours wondering why a trending LED home sign got zero clicks—it turned out the brand had prepended “ArtGlowCo™” in every product title before the core keyword. Removed it, and instantly saw impressions double.
The feed doesn’t care about your brand aesthetic; it wants categorical matchability. Google’s algorithm is still surprisingly literal in Shopping feeds. It’s matching user searches—”wireless noise cancelling headphones”—to string arrangements. If your title starts with a serial number or internal SKU, congrats, you’re invisible. If you stuff the title with adjectives people don’t search for (“premium artisan saddle-stitched full-grain leather…”), same issue.
Start with the exact product type (“Men’s trail running shoes”, not “XtremeGrip Pro Series”)
Then size, color, brand, features – in that order, if they matter
Use real phrases humans type, not “shop-friendly” copy
No emojis, no symbols, no slogans
Cut the brand if it’s not already established in search volume
Not sure what to lead with? Type what the product is into Google and check the autocomplete suggestions. That’s your title seed.
Why GTINs Randomly Break Entire Product Groups
This is one of those absurd backend situations where you follow the rules too precisely and it backfires. I had a client in housewares who properly filled in GTINs for 200+ SKUs—came from the manufacturer, scanned and verified. A few days later, boom: huge quality drop alerts in GMC for “Incorrect Product Identifiers.” Panic. Turns out, Google cross-references GTINs with their structured product index database, and if their internal record has missing fields or contradicts your entry… errors show on your side, not theirs.
Even dumber: when the same GTIN is used by a brand across slightly different variants and the feed doesn’t make that variant distinction clear, Google just refuses it silently. No flag, no soft rejection. Just… nothing. Silent nulling.
If a product is suddenly missing from results but clearly active in the feed, double-check whether other sellers are using that GTIN for something very similar but not quite.
A slightly janky fix I’ve used: omit the GTIN for an affected listing and overtly specify brand + MPN + variant. Usually Google’s fallback logic accepts the item again, this time under ‘identifier exists’ = false.
Why “identifier_exists” Can’t Be Trusted
There’s a special kind of confusion when the feed item preview in Google Merchant Center says “identifier exists = false”, but Google refuses to take it because of missing GTIN. It’s pretending you set the flag wrong even though you’re literally following the spec. Overshare time: I’ve experienced this firsthand on a feed where most of the products were custom bundles—think “3-pack gift set of soy candles”—with no singular GTIN.
Problem is, if even one of the bundled items has a known GTIN in the database, Google sometimes flags the bundle entry as incomplete, even if you set identifier_exists to false. And yes, I’ve emailed support who told me to “re-review the schema requirements.” Thanks, Jaya.
If you’re importing a feed using Shopify or WooCommerce, double-check what’s defaulting in the JSON. Some plugins reset identifier_exists = true during auto-export, even if your local product has a blank GTIN field. You think you’re excluding it—but nope. Plugin lies.
Diagnosing Why Shipping Info Fails Even When It’s Set
My personal breaking point: spent three hours figuring out why an apparel feed wasn’t triggering Shopping visibility, even though shipping rates were defined at both Google Merchant Center AND via the feed import. Turns out, if the shipping table in Google doesn’t specify the exact weight range for the product—in pounds or kg, matching the units in the feed—it silently ignores the product for Shopping listings. Not paused. Not errors. Just… drops exposure.
Watch the Unit Mismatches
If your feed says weight = “200 g” and your table is set for items over “0.2 lb,” Google doesn’t do the math for you. It just doesn’t apply shipping. I verified this by changing one item to “1 lb” and saw it reappear in Shopping within 12 hours.
“kg” and “g” in feeds must be matched in the rate rules. You can’t mix and match imperial/metric without alerting the Merchant Center UI somehow.
This is why half the time issues around shipping eligibility end up being about units, not rates themselves. And of course, it’s not documented at https://support.google.com/adsense or anywhere else clearly.
Feed Scheduling Logic That Caches Wrong Data
This one’s straight-up a behavioral bug. Google Merchant Center sometimes caches old feed data when using scheduled fetches—even after manual feed validation shows the new data. This means the UI says “last uploaded: today” but your Shopping ads are running off stuff from last week.
I’ve seen this consistently when the remote .xml file is served from a CDN (Cloudflare, in my case) and is technically 200-OK but hasn’t yet refreshed the edge version. Google doesn’t revalidate schema changes deeply—it just pulls the file and checks if the timestamp changed. If the CDN serves an older version, the timestamp is new but the data is stale. Super fun loop.
Fix: Bypass Your Own CDN
The hack that worked for me was pushing a query string param (“?nocache=1”) to the feed URL and resubmitting it manually. That forces the CDN (Cloudflare or Fastly) to deliver a fresh copy and triggers Google’s backend to scan it again fully. After that, it actually seemed to reset their feed logic—products with new attributes started populating in Shopping ads within an hour.
Why “Out of Stock” Can Wreck Non-Suppressed Items
I learned this the hard way with a multi-variant product (hoodies, 5 sizes, 3 colors). Stock ran out on just one color-size combo, set as “out of stock” properly. But the main item—the parent—still had 12 variants live. Yet views dropped across the whole category. Why?
Here’s the dumb part: if your feed isn’t clearly structured as variant/subvariant correctly, Google might treat the out-of-stock indicator as overarching. Especially in cases where your product cluster uses the same image URL for all variants. The shared image being associated with an out-of-stock item triggers “limited stock” handling across the full item group.
I fixed it by generating distinct image URLs per variant (even if they were pixel-identical) by appending a meaningless query param to the URL (?id=blue-xs). Overnight change. Went from near-zero clicks to steady daily flow again.
Discrepancy Hell Between Merchant Center and Ads UI
This is for everyone who thinks Shopping is plug-and-play. Ever seen a product that clearly says “Approved” in Merchant Center… but won’t show impressions in Shopping Ads preview for 5+ days? Welcome to sync limbo.
Here’s what you need to know: Merchant Center approvals aren’t instantly acknowledged by Google Ads. Especially when campaigns use product groups filtered by custom labels, product types, or specific attributes. If those attributes change in the feed and trigger product re-approval, your campaign often retains the previous filters—silently excluding the product.
We saw this on an account that used Custom Label 0 = “Holiday2023”. The feed removed that label for off-season logic. Campaign kept filtering by it. Products became uneligible silently, even though “approved” stayed green.
Two-Minute Fix: Temporary Campaign Baby-Sitting
I duplicated one high-performing campaign with no filters or labels, broad product target, and let it run on max CPC for 48 hours. Watch what populates. You’ll catch products excluded by logic, not eligibility.
Honestly, that two-day diagnostic campaign told me more about feed issues than Search Console ever has on organic.
Tripping Over Sale Price Annotations (When the Logic Isn’t Obvious)
You want those slick strikeout prices with red “On Sale” text, right? Here’s the gotcha: if you set sale_price in your feed without price being obviously higher on both your landing page AND the crawlable schema, Google treats it as non-sale. Meaning, even if you input sale_price accurately, Google won’t show the annotation unless:
1. Original price appears visibly (and in schema!) on your product page
2. Price >= sale_price consistently
Also, if the discount is like two dollars off on a $300 item? Google may suppress it under the hood via what looks like discount threshold logic. I asked support—got told “We don’t guarantee the annotation will show even with correct pricing.” That’s the most supporty sentence ever.
Your landing page matters more than most think. I fixed this (and got strikeouts) by updating schema.org markup using Product and Offer properties via GTM, then adding visibly styled MSRP on the page. 12 hours later? Strikethrough glory.
Fabricated Price Discrepancies from Compression Plugins
Real story: a client on WordPress had dynamic cart logic—free shipping over $50—calculated via JS. Their theme also used a poorly configured minification plugin that merged multiple JS files. This broke price rendering in certain cases. Googlebot fetched the product page, rendered the final price including regional tax, but used the base price from the feed. Discrepancy alert. Product disapproved.
Unless your JavaScript is deterministic and quick, Google’s mobile crawler might misinterpret price. And if your page obfuscates initial price behind tab logic or sliders—it might never render.
I eventually used a server-side rendered cache of the product page (via WP Rocket) and isolated tax display logic using a country-picker cookie. Google finally saw the price they expected.
