Your Shopping campaign is only as good as your product data

A Shopping ad is assembled from your feed, not from ad copy someone wrote. The title, image, price and availability shown in the auction come straight from the attributes you send, and matching is driven by what that text says rather than by keywords you picked. That has two consequences. First, a product with a thin or generic title competes for the wrong queries and loses the ones it should win. Second, a product that fails validation does not compete at all — it is simply absent, while the campaign keeps spending its budget on whatever remains eligible. Raising a bid on a disapproved catalogue changes nothing. Opening the diagnostics view and counting how many items are genuinely active is the first honest measurement any Shopping account deserves.

Google's Merchant Center product data specification defines the contract. Every item needs a stable id, a title, a description, a link to the landing page, an image_link, availability and price, plus — for most retail categories — brand and either GTIN or MPN. Condition matters for refurbished and used goods. Shipping and tax are configured either in the feed or in account settings, and US accounts need tax handled correctly before ads serve. Two rules cause most of the pain: IDs must never be recycled between products, because review status and performance history attach to them, and every value you send must be true on the landing page at the moment Google checks. The same data also powers free listings in the Shopping tab, so a clean feed earns unpaid placement whether or not you are bidding.

• id, title, description, link and image_link as the non-negotiable core
• availability and price that match the landing page exactly
• brand plus GTIN or MPN across most retail categories
• condition, shipping and tax settled before anything serves

Rejection reasons cluster into a short list, and each has a different fix. A price or availability mismatch means the crawler read a different number on the page than the feed sent — usually a sale price the feed does not know about, a tax or currency display difference, or a page that renders price only after JavaScript runs. Missing GTIN blocks items in categories where Google expects a barcode; the fix is to collect real ones from the supplier, never to fabricate them. Promotional overlay text burned into the image file, a SALE badge or watermark, is rejected on sight, so the feed should point at a clean product photo rather than the merchandised version used on site. Policy issues in restricted categories need the account fixed, not the feed. And an unverified or unclaimed domain silently stops everything, which is worth checking before anyone debugs a single product.

• Price or availability mismatch: align the page, not just the file
• Missing GTIN: source real barcodes from suppliers
• Image with overlay text: submit a clean product photo
• Unverified or unclaimed domain: fix the account first

The title is the strongest relevance signal in the feed, and it is what most WooCommerce catalogues get wrong, because the product name in WordPress was written for someone already browsing your category. A shopper in Google rarely types your internal name. They type a brand, a product type, and the attribute that decides the purchase — size, colour, capacity, compatibility. A structure that survives truncation puts brand first, then the product name, then that deciding attribute, because the visible portion of the title is short. Resist stuffing: repeated keywords do not improve matching and read badly in the ad. This is a mapping exercise rather than a rewrite of your site, since the feed title is allowed to differ from the heading on the page, and for many catalogues it should.

Variable products create the most common structural mistake. Submitting the parent as a single item hides the fact that only two of nine sizes are in stock, and it sends a price that may not match the variation the shopper lands on. In most catalogues each purchasable variation should be its own item, sharing an item_group_id so Google understands they belong together, with size, colour and other variant attributes populated. Where a variation has its own photo, send it. Supplemental feeds are the pragmatic tool for everything the plugin cannot express: a second file that overrides titles for your worst performers, adds GTINs gathered from suppliers, or excludes products you do not want advertised — all without editing the underlying WooCommerce data or fighting the primary feed generator.

A feed is a snapshot, and the gap between snapshots is where mismatches are born. There are three mechanisms and they are not equivalent. A scheduled fetch pulls your generated file once or a few times a day, which is fine for a stable catalogue and dangerous during a flash sale. Google's crawler independently reads the landing page and compares it against what you sent, so a disagreeing page creates a disapproval even when the file itself is valid. The Content API pushes changes as they happen and is the right answer for stores with frequent price moves or thin stock. Whichever you pick, decide deliberately what happens to out-of-stock items — quietly leaving them marked as available is the fastest route to an account-level warning. A second opinion on that setup is a reasonable thing to bring to a call.

• Scheduled fetch: simple, but stale between runs
• Crawler comparison: the page is the source Google trusts
• Content API: near real-time, worth it for volatile pricing
• Out-of-stock rule agreed before the sale, not during it

This is the line between the shop and the shopfront. WooCommerce stays the system of record: products, variations, stock levels, prices, tax rules, coupons and orders never leave it, and the feed generator keeps reading from that same data. What changes is the page the crawler lands on. If price and availability appear only after client-side JavaScript, or if the page is slow enough that the crawler gives up, the comparison fails and items are suspended for reasons that look like a feed bug but are not. A server-rendered product page puts price, currency and availability in the HTML, backed by Product structured data stating the same numbers the feed claims. That consistency is not decoration; it is the mechanism that keeps items approved. It is also the same work that improves product page performance and organic visibility.

There is a version of this where you should not hire anyone. If Merchant Center already shows most of your catalogue active and your titles carry brand and attribute, the problem is probably in the account — negatives, product segmentation, margin per order — and no amount of feed work will move it. If you run a few hundred products, a well-configured free feed plugin plus an afternoon of manual GTIN entry gets you most of the way, and that is cheaper than any engagement. And if the campaign is unprofitable because your margin cannot support the click price in your category, better data only makes you lose money more efficiently. Work here starts at $1,999 and earns its keep when the storefront itself is causing the mismatch; pricing sets out what that covers. Otherwise, spend the afternoon in Merchant Center first.