WooCommerce Google Shopping: The Feed Errors That Recur

What do you need before connecting WooCommerce to Google Shopping

Getting a WooCommerce Google Shopping feed approved starts with four things a store needs in place before any submission: a Google Merchant Center account, ownership verification of the store’s domain, a product catalogue where every sellable item has a title, an image, a price and a category assigned in WooCommerce itself, and a decision about how the feed gets generated in the first place. WooCommerce and Google Shopping do not talk to each other natively; WooCommerce has no built-in export that matches Google’s product feed specification, so this is the first and most consequential setup decision.

Most stores in the $3M-$30M range choose between three approaches: a dedicated feed plugin that reads the WooCommerce product database and outputs an XML or text feed on a schedule, a custom feed built against the WooCommerce REST API for stores with catalogue logic too specific for an off-the-shelf plugin, or a broader feed management platform that handles Google Shopping alongside other advertising and marketplace destinations at once. The right choice depends on catalogue size and how often prices and stock actually change; a catalogue under a few thousand SKUs with occasional pricing changes runs fine on most plugins, while a catalogue with frequent promotional pricing or fast-turning stock benefits from a feed refresh cycle closer to real time, which usually means paying for a plan tier with more frequent syncs or connecting through the Content API directly rather than a scheduled file upload.

Before making any of these changes, audit the underlying WooCommerce data itself. A feed plugin can only export what WooCommerce actually has: if half your catalogue has no brand field filled in, no GTIN recorded, or a category structure that was never mapped to anything Google recognises, the feed will inherit every one of those gaps. Fixing product data after a feed submission is slower than fixing it before, because every gap becomes a disapproval you then have to trace back to its source.

Generate a WooCommerce product feed built for Google Merchant Center

Install a feed-generation plugin from the WooCommerce or WordPress plugin ecosystem, or, for stores with catalogue logic too specific for a general plugin, build a custom export against the WooCommerce REST API. Either way, the output needs to follow Google’s product feed specification exactly, not a generic product export: field names, required versus optional attributes, and formatting rules (currency codes, date formats, boolean values written as the literal strings Google expects) all matter, and a plugin built for a different destination will produce a feed that looks complete but fails validation.

Configure the feed to run on a schedule that matches how often your catalogue actually changes. A daily refresh is the common default and works for stores with stable pricing; stores running frequent promotions, flash sales, or fast-moving stock levels need either a shorter interval or a plugin that supports webhook-triggered updates on stock and price changes specifically, separate from the full catalogue refresh. Confirm your hosting environment can handle the export job: a large catalogue with complex variation structures can take real processing time to generate, and a feed job that times out partway through produces a truncated feed, which shows up in Merchant Center as missing products rather than an obvious error.

Map your WooCommerce categories to Google’s product taxonomy at this stage rather than leaving it as a later cleanup task. WooCommerce category names are usually store-specific language (“Everyday Totes”, “New Arrivals”) and Google expects the google_product_category attribute to reference its own standard taxonomy. Most feed plugins offer a mapping interface for this; skipping it and leaving the field blank or auto-filled with a guessed value is one of the more common sources of avoidable disapprovals later.

Verify your site and claim your URL in Google Merchant Center

Create or sign into your Google Merchant Center account and add your store’s domain as a new business. Google requires you to verify ownership of that domain, most commonly through an HTML tag added to your site’s header or a DNS TXT record added at your domain registrar, before it will accept a product feed pointing at that URL. WooCommerce stores usually add the HTML verification tag through a theme header snippet, an SEO plugin’s custom code field, or directly in the site’s template, whichever your team already uses for similar verification tags like Google Search Console.

Verification alone is not the same as claiming the URL. Merchant Center distinguishes between confirming you own a domain and formally claiming it for use in Shopping ads and free listings; skip the claim step and your feed can process without errors while your listings still fail to serve, which is a confusing state because nothing in the diagnostics page points directly at “URL not claimed” as the cause. Complete both steps before moving on, and confirm the claimed URL matches the domain your WooCommerce feed’s link attribute actually points to, including whether it’s the www or non-www version and whether it uses https.

If your store runs on a staging or a recently migrated domain, or has moved from a different platform, re-verify and re-claim after the migration completes. Google’s verification is tied to the specific URL, and a domain change that isn’t followed by re-verification is a common, quiet cause of a feed that was working suddenly showing zero approved products with no new disapproval reason given.

Set the feed attributes Google Merchant Center checks first

Google’s product feed specification has required and recommended attributes, and the required set is where most WooCommerce disapprovals originate. At minimum, every item needs an id (unique and stable across feed refreshes, since changing it makes Google treat the product as new), a title, a description, a link to the live product page, an image_link, availability, price, and a condition. For most categories you also need a GTIN, or a brand and MPN pairing, or an explicit identifier_exists flag set to indicate the product genuinely has none of those identifiers, which applies to handmade or custom items far more often than to a typical multi-brand WooCommerce catalogue.

The google_product_category attribute deserves particular attention because it’s easy to fill with something plausible-looking that Google’s taxonomy doesn’t actually recognise. Use Google’s published taxonomy list, not a free-text guess, and map it at the WooCommerce category level so new products inherit the correct mapping automatically rather than needing manual assignment each time a product is added. A mismatched or missing category doesn’t always cause an outright disapproval, but it does affect which searches your product can match, which is a slower, quieter failure than a rejection notice.

Price and availability attributes need to match what a shopper actually sees on the linked product page at the moment Google crawls it, not what the feed said when it was generated. This is the single most common source of the “mismatched value” disapproval category: a price change, a promotional discount, or a stock level update on the WooCommerce site that the next feed refresh hasn’t caught up to yet. Shortening the refresh interval for price and availability specifically, even if the full catalogue feed runs less often, closes most of this gap.

Map WooCommerce product variations to Google Shopping’s item group model

WooCommerce’s data model and Google’s feed specification genuinely diverge here, and this is the step most teams get wrong. WooCommerce stores a variable product as one parent product with a set of variations underneath it, each variation carrying its own price, stock level and attribute combination (a size, a colour). Google Shopping has no concept of a parent-with-children structure in the same sense; instead, every sellable variation is submitted as its own separate item in the feed, and Google links related variations together using a shared item_group_id, along with attributes like colour and size on each individual item so it can display them as selectable options on one listing.

The recurring mistake is treating the WooCommerce parent product as the thing that gets submitted to Google, with variations either flattened into one generic listing or left out of the feed entirely because the plugin’s default configuration wasn’t set up to iterate through variations. Either outcome loses information Google needs: a flattened listing loses per-variant pricing and stock accuracy, and a missing variation is simply absent from search, with no disapproval notice pointing at the gap because nothing was submitted to be checked. The correct configuration submits every variation as its own item, with its own unique id distinct from the parent product’s id, its own price and availability reflecting that specific variation’s stock, and the same item_group_id value shared across every variation of that one parent, so Google groups them.

Confirm your feed plugin actually iterates variations by default rather than needing an explicit setting turned on. Several popular plugins ship with variation export enabled, but the item_group_id field is filled inconsistently unless the plugin’s mapping is checked against the parent product’s own stable identifier (such as its WooCommerce product ID or SKU prefix, not a value that changes on export). Test this by pulling a handful of variable products from your live feed and confirming that variations of the same parent share one item_group_id value and nothing else in the feed accidentally reuses it.

Submit the feed and read the diagnostics page before anything else

Submit the feed URL, or upload the file directly, in Merchant Center’s Products section, and give it time to complete an initial processing pass. Do not assume the feed is working because the upload succeeded; a successful upload only means Google received a file it could parse, not that the products inside it were approved. The diagnostics page, found under Products in Merchant Center, is where the actual outcome lives, broken down by issue type, severity, and the number of affected items.

Work through diagnostics in order of what blocks the most products first, not in the order they appear on the page. A single misconfigured attribute, a wrong google_product_category mapping applied at the category level, or a missing GTIN default, can account for the bulk of disapprovals in one fix, while chasing individual product-level warnings one at a time before addressing the systemic cause wastes review cycles. Google’s review process re-checks affected items after a feed update, but it isn’t instant, so batching fixes by root cause rather than reacting to each disapproval individually gets a clean feed faster.

Re-check the diagnostics page after every feed refresh for at least the first few cycles, not just once after initial setup. New disapprovals can appear as products are added, as WooCommerce data changes (a new variation added without a category assigned, for instance), or as Google updates its own policy enforcement for a category. Treating the diagnostics page as a one-time setup checklist rather than an ongoing operational check is how a feed that passed review in its first week quietly accumulates disapproved products six months later with nobody noticing until traffic drops.

Why do WooCommerce Google Shopping feeds get disapproved

Disapprovals cluster around a small number of recurring causes rather than being evenly spread across the whole attribute list. Missing or mismatched identifiers (GTIN, brand, MPN) sit at the top, because Google treats a listing it cannot confirm as a real, distinct product as a policy risk rather than a minor data gap. Price and availability mismatches between the feed and the live product page are close behind, almost always caused by a refresh interval that’s slower than how often the store’s pricing or stock actually changes.

Image issues form a third cluster: images below Google’s minimum resolution requirements, images with promotional text or watermarks overlaid, or an image_link pointing at a broken or redirected URL after a site migration. WooCommerce product images pulled directly from a theme’s generated thumbnail sizes sometimes fail resolution requirements even when the original uploaded image was large enough, because the feed plugin defaulted to a smaller cached version rather than the full-size original.

Category and taxonomy mismatches cause a quieter kind of failure: a product isn’t outright disapproved, but it’s approved into the wrong category, which limits which searches it can match without ever showing up as an error to investigate. And restricted or regulated product categories, certain supplements, certain claims-heavy skincare language in titles and descriptions, trigger policy reviews that a purely data-focused feed audit won’t catch, because the issue is the product’s marketing language rather than a missing field.

What’s the step most teams get wrong in a WooCommerce Google Shopping setup

Item_group_id on variable products. Every other setup mistake in this article tends to produce a visible signal, a disapproval, a warning, a diagnostics entry pointing at a specific attribute. Getting item_group_id wrong or leaving it unset often does not. A feed can pass initial validation, individual variations can each get approved, and the store can be running Shopping ads or free listings that appear to work, while Google is treating each variation as an unrelated, standalone product rather than showing them grouped with selectable options the way a shopper expects on a competitor’s listing.

The practical cost shows up as a worse shopping experience rather than an error message: a shopper searching for a product sees one colour or size, clicks through, and either doesn’t realise other options exist or has to navigate the site to find them, both of which cost conversions that a properly grouped listing would have kept. Because nothing in Merchant Center flags this as wrong, it tends to persist for months after initial setup, discovered only when someone manually compares how a competitor’s variable product displays in search results against how the store’s own listing displays.

A fix means going back to the feed plugin’s variation mapping settings and confirming item_group_id is populated from a value tied to the WooCommerce parent product, not left blank, not auto-generated per variation, and not accidentally reused across genuinely different parent products that happen to share a naming pattern. Pull a sample of variable products directly from the submitted feed file or the plugin’s preview tool and check this by hand at least once after setup, because it’s the one attribute where “the feed submitted successfully” gives no assurance it was done correctly.

How do you verify a WooCommerce Google Shopping feed is actually working

Verification has three layers, and checking only the first one is how a partially broken feed goes unnoticed. The first layer is Merchant Center’s diagnostics page: are products approved, and if not, what’s the stated reason. This is necessary but not sufficient. Some failures, like item_group_id gaps, don’t produce a diagnostics entry at all.

Pulling a recent copy of the submitted feed and spot-checking a sample of products is the second layer: does the price match what WooCommerce shows, does the availability match, is the image the one you’d expect, and for variable products, do variations share the item_group_id they should. This catches mapping errors that technically validate but produce wrong values.

A real search is the third layer, and the only one that reflects what a customer actually experiences: search for your own product by name or a close variant, using a query a real shopper would type, and confirm the listing appears, shows the correct price, and, for a variable product, groups the way you configured it to. Do this periodically rather than only immediately after setup, since Google’s own ranking and eligibility behaviour for a given listing can shift over time independent of anything changing on the WooCommerce side.

Who should not run Google Shopping from WooCommerce without help

A catalogue with fewer than a few hundred SKUs and simple, stable pricing can often manage a WooCommerce Google Shopping feed with a well-configured plugin and periodic manual checks, no dedicated feed management layer required. That changes at the higher end of the $3M-$30M range this article is written for: a catalogue with thousands of SKUs, frequent variation changes, multiple brands with inconsistent GTIN availability, or promotional pricing that changes daily is running past what a default plugin configuration and occasional manual review can reliably catch.

A WooCommerce Google Shopping setup is also not a good fit for a team without anyone assigned to own the feed’s health on an ongoing basis. The mistakes described in this article, especially the item_group_id gap, are not one-time setup errors; they recur every time a new variable product is added incorrectly, every time a category is created without a taxonomy mapping, every time a migration or a re-platforming event breaks a verified URL. A feed with no owner drifts the same way an unmonitored inventory sync drifts, quietly, until a drop in Shopping traffic forces someone to go looking for the cause.

Catalogue and feed accuracy is the actual mechanism behind every disapproval, every mis-grouped variant listing, and every product that silently stops showing in Google Shopping search results, which makes this a feed automation problem rather than a one-time integration task. That is the specific gap Pointerflow’s catalogue and feed automation service is built to close.