By Marius Pahomi · Published 2026-06-03 · Last updated 2026-07-13
A Google Merchant Center disapproval means a product no longer matches Google’s product data specification or the data on your website, so it stops showing in Shopping ads and free listings. Disapprovals come in two layers, and telling them apart is the first diagnostic step. Item-level disapprovals affect single products and are fixed by correcting that product’s data and re-uploading. Account-level enforcement is more serious: data quality violations trigger a 28-day warning window, and if unresolved the whole account can be suspended — except for price and availability mismatches, which trigger preemptive item disapproval (PID) immediately rather than waiting.
The fix loop is the same regardless of cause: open the Diagnostics or “Needs attention” page to read the exact issue name, correct the underlying product data (or the landing page it disagrees with), validate the change before you push it, re-upload the feed, and either wait for the automatic 3–5 business day re-review or use the “Request review” button (which takes up to 7 days).
In practice the overwhelming majority of disapprovals fall into roughly six buckets: product identifier errors, price mismatch, availability mismatch, image problems, title and description quality, and missing required or category attributes. This guide walks each bucket from symptom to fix, then shows how to prevent the recurring ones at feed-build time instead of discovering them after Google rejects the upload.
Run the free feed validator — free, in your browser, no account needed.
Google reviews individual products submitted in your feed on a rolling basis. When a single product’s data doesn’t match your website or breaks the product data specification, that item is disapproved and stops serving, while the rest of the account keeps running. This is the common, low-stakes case: fix the one product, re-upload, done. If you are staring at a Diagnostics row right now, paste the exact issue name into the free disapproval diagnostic to get the cause and fix steps for that specific issue. Account-level enforcement is different. When a data quality violation is systemic — for example most of your catalogue is missing a required identifier — Google issues an account warning by email and on the Diagnostics page, with a window to fix it. If you ignore the window, the account is suspended and every item for that feed stops serving at once — at that point you are dealing with a full Merchant Center account suspension, which has its own reinstatement workflow and cool-down trap. The practical rule: treat any email with the word “warning” as a deadline, not a notification.
Three states are easy to confuse. A warning means the product still serves but with limited performance and may be suspended later — it is a yellow light. A disapproval means the product is not serving now. Preemptive item disapproval (PID) is a special account-level state reserved for price and availability mismatches between your feed and your landing pages: Google errs on the side of caution and disapproves the suspect items immediately, while letting your compliant items keep serving. PID still requires an account review to clear fully — fixing the data alone is not enough, you also have to request the review. Only price and availability mismatch trigger PID; every other violation runs through the ordinary 28-day warning path.
After you correct product data it takes Google 3–5 business days to re-review automatically. For account-level issues, a review happens automatically at the end of the 28-day warning period, but you are entitled to one courtesy review earlier via the “Request review” button. Review requests take up to 7 days. If a review fails, a cool-down period starts during which the review button is disabled and the account stays suspended; each failed review can lengthen the cool-down. The engineering lesson is to never request a review until you have actually verified the fix — a premature request that fails costs you days of locked cool-down, not just the review time.
The single largest bucket. Google checks any identifier you submit, and surfaces errors like “Missing IDs (GTIN or MPN and brand)”, “Invalid value (GTIN)”, “Incorrect identifier (GTIN)”, and “GTIN not correct length”. Products with an incorrect or missing GTIN are not synced and are disapproved outright — this is not a soft warning. The fix is to assign valid unique product identifiers to every product that has one. The most common own-goal is copying an internal SKU into the GTIN field: SKUs have no GS1 prefix and no check digit, and Google validates the check digit on every submission, so an SKU-as-GTIN always fails. Validate the GTIN check digit before export — the free GTIN validator checks the check digit, the format, and the stripped-leading-zero case instantly — not after the disapproval email.
“GTIN not correct length” usually means a real barcode mangled in transit rather than a missing one. Spreadsheet software silently strips the leading zero from a GTIN-13 that starts with 0, turning it into 12 digits and breaking validation. Store identifiers as text, never as numbers. A valid GTIN is GTIN-8, GTIN-12 (UPC-A), GTIN-13 (EAN-13), or GTIN-14, and the final digit is a modulo-10 check digit computed from the others. If the check digit doesn’t verify, the code is malformed regardless of length. See the GTIN reference for the exact formats and the check-digit algorithm, and MPN for the manufacturer-part-number fallback when no GTIN exists.
“Conflicting values (GTIN, brand)” means the GTIN you submitted is not registered to the brand you submitted — Google cross-checks GTIN ownership against the GS1 database, so a checksum-valid but unassigned code still fails. Submit a GTIN actually issued to that brand. For products that genuinely have no GTIN — private label, custom-made, vintage, refurbished, art, handmade goods — do not fabricate one. Set identifier_exists=no so Google knows the omission is intentional; the product can then be approved without an identifier. Fabricating a fake-but-valid GTIN to bypass the field is treated as misrepresentation, which is an account-level policy risk far worse than a single item warning.
Price mismatch is one of only two violations that trigger preemptive item disapproval, because a shopper who clicks an ad showing one price and lands on another is a direct trust failure. Google compares the price in your feed against the price on the landing page and throughout checkout. If they disagree, the item is disapproved preemptively and the account enters the PID state. The mismatch does not have to be large — a stale sale price is enough. Because PID is account-level, you must both fix the data and request a review to clear it; correcting the feed silently is not sufficient.
Most price mismatches are timing or formatting problems, not deliberate. A sale started or ended on the site but the feed still carries the old price. Currency in the feed doesn’t match the storefront’s currency for that country. Tax-inclusive versus tax-exclusive pricing differs between feed and page. Structured data (the product JSON-LD on the page) carries a different number from the visible price, and Google reads the structured data. Rounding differences from a currency conversion also count. Each of these is invisible until Google’s crawler compares the two surfaces.
Align all three surfaces — feed, visible landing-page price, and on-page structured data — to the same number and currency, then re-upload and request the review. To prevent recurrence, drive price from a single source of truth and regenerate the feed whenever price changes rather than on a fixed daily schedule, so a flash sale never outruns the feed. If you use sale_price, make sure the sale window in the feed matches the actual on-site sale window. A feed validation step that flags feed-vs-source price drift before upload turns this from a recurring disapproval into a caught error.
The second PID trigger. The availability value in your feed must match the landing page, the checkout page, and the on-page structured data. If the feed says “in stock” but the page shows sold out (or vice versa), the item is preemptively disapproved. As with price, this is account-level and needs a review request to clear. The check is strict because availability, like price, is a promise the shopper acts on immediately.
The classic case is a product that sold out on the site faster than the feed refreshed, so the feed still advertises stock. The reverse — restocked on site but still “out of stock” in the feed — costs you impressions without a disapproval but is just as worth fixing. Structured-data availability that disagrees with the visible button state is another silent cause. Regional feeds add a twist: a product in stock in one country’s warehouse but not another can mismatch per-country if availability isn’t set per feed.
Synchronise availability from your inventory system to the feed, the visible page, and the structured data together. The durable fix is event-driven: when stock changes, update all surfaces and regenerate the feed, instead of relying on a once-a-day batch that can be hours stale during a sell-out. Google also offers automated availability checks that update items based on landing-page signals — useful as a safety net, but not a substitute for an accurate feed. After correcting, re-upload and request the account review to exit PID.
Every product must have a main image_link that clearly shows the actual product. Logos, “No image available” graphics, and generic placeholders are disapproved and stay disapproved until the image is replaced — there is no review shortcut, only a real image. This commonly bites drop-shippers and stores that publish a product before photography is ready. The fix is simply a genuine product photo; for most categories a placeholder is never acceptable.
Images may not contain promotional text (retailer logos, “Free shipping”, “Sale”, calls to action) or obstructing elements like watermarks. Shopping wants a clean, unobstructed view of the product, so any overlay triggers “Promotional overlay on image”. Re-export the image without the badge. Google’s automatic image improvements can strip some overlays for you if enabled, but the reliable path is to keep marketing text out of the source image entirely and let the ad format carry promotions.
Images must meet minimum sizes: at least 100×100 px for non-apparel and 250×250 px for apparel, no larger than 64 megapixels, and no file over 16 MB. Don’t upscale thumbnails to hit the minimum — Google can tell, and a stretched image reads as low quality. Aim for the product filling 75–90% of the frame. These are deterministic rules, so they are ideal to check programmatically at feed-build time rather than discovering them in the Diagnostics report.
Titles with gimmicky or excessive capitalization (“BEST CHEAP SHOES SALE!!!”) are flagged because the pattern correlates with spam, and shoppers trust them less. Use normal sentence or title case. If your platform sends the SEO title rather than the product title to Merchant Center, fix it in whichever field Google actually reads — check which field your integration maps to the feed title before editing the wrong one.
Like images, titles must describe the product, not advertise it. Pricing, shipping promises, and calls to action (“Buy now”, “Free delivery”) don’t belong in the title attribute. Lead with the attributes shoppers actually search — brand, product type, and key variant (size, colour) — because the title is both a ranking and a relevance signal. Putting the size or colour at the front also gives context to the image.
A good feed title front-loads the most distinctive attributes and stays specific: “Bosch 18V Cordless Drill — 2 Batteries, Blue” beats “Great Drill for DIY”. This both avoids editorial flags and improves matching, so it is one of the few compliance fixes that also raises performance. You can test any title against the editorial rules — length, capitalization, promotional wording, keyword stuffing — with the free product title checker. Define title construction once as a feed rule — for example “{brand} {product_type} {color} {size}” — so every product is generated consistently instead of hand-edited.
Lower data quality from missing required attributes reduces performance and can escalate to disapproval. Brand is required for all new products except movies, books, and musical recordings — and values like “N/A”, “Generic”, “No brand”, or “Does not exist” are rejected. If you manufacture the product or it is genuinely generic, you may use your store name; otherwise use the manufacturer or supplier name. Supply the full set of required attributes (id, title, description, link, image_link, availability, price) rather than only the one currently flagged, since the next review will catch the others. If you build the feed by hand, the walkthrough to create a Google Shopping XML feed manually shows the complete RSS 2.0 markup with every required attribute in place.
“Invalid value (Google product category)” means your google_product_category doesn’t match the official taxonomy. Submit either the numeric category ID (for example 1580) or the full category path (“Apparel & Accessories > Clothing > Suits > Tuxedos”). Submitting only the last segment (“Tuxedos”) is rejected. The free Google product category finder searches the official taxonomy by keyword and gives you the exact ID or full path to copy. Mapping your internal categories to the Google taxonomy once, as a rule, prevents this across the whole catalogue.
Apparel & Accessories products require gender (male/female/unisex), age_group (newborn/infant/toddler/kids/adult), color, and size. Colour must be spelled the American-English “color” and shouldn’t be jammed together (use “Red/Pink/Blue”, not “RedPinkBlue”) or set to non-colours like “multicolor” or “N/A”. Size should use one consistent format. These can be omitted only when already captured in product variants. Because the rules are categorical and well-defined, they validate cleanly before upload.
“Unable to check product pages” means Google’s crawler can’t fetch your landing pages — almost always a robots.txt or server problem, not a feed problem. Allow both the Googlebot and Googlebot-image user-agents to crawl your full site; blocking either prevents Google from verifying price, availability, and images, which cascades into other disapprovals. Aggressive bot-protection or rate-limiting that challenges Google’s crawler produces the same symptom. Verify by fetching the page as Googlebot and checking your robots.txt before assuming the feed is at fault.
A landing page that 404s, times out, or redirects to a generic page disapproves the item — the link must resolve to the live product. Beyond reachability, the page content must match the feed: the product shown, its price, and its availability all have to agree with what you submitted. A page that loads but shows a different product or an out-of-stock state still fails. Keep the canonical product URL in the feed and make sure it doesn’t redirect through a stale path.
Every fix begins with the exact error string, not a paraphrase. Account-level problems surface as a banner and on the “Needs attention” page; item-level problems appear in the Diagnostics / Products view, where each affected product lists its precise issue — for example “Invalid value [gtin]”, “Identifier exists [identifier_exists]”, or “Mismatched value (price) [price]”. Google groups these under the umbrella merchants search as “Google Shopping feed errors”, but the bracketed attribute name is what tells you which field to fix. Read the string verbatim, note the attribute in brackets, then jump to the matching section below. If you only have the error text and want the cause and fix steps without hunting, paste it into the free disapproval diagnostic.
The identifier_exists attribute tells Google whether a product has a manufacturer identifier (GTIN/MPN/brand), and the error appears in two opposite shapes. If you submit identifier_exists=no but Google detects the product does have a known GTIN, it flags the contradiction — remove the flag and submit the real GTIN. The reverse, more common case: a branded product is missing its identifier and you have not set the flag, so Google expects an identifier that is not there. The fix is to add the correct GTIN (validate the check digit with the free GTIN validator first) — or, only for genuinely identifier-less products such as private-label, custom, vintage, or handmade goods, set identifier_exists=no deliberately. Never set the flag just to silence the error on a product that really does have a barcode, because Google cross-checks ownership against GS1 and treats that as misrepresentation.
Most Google Shopping feed errors map to one bucket in this guide by the attribute in brackets. “Mismatched value (price)” or “(availability)” → price / availability mismatch (both trigger preemptive item disapproval). “Invalid value [gtin]”, “Incorrect identifier”, or “Identifier exists” → product identifier errors. “Image too small”, “Generic image”, or “Promotional overlay” → image problems. “Invalid value [google_product_category]” or “Missing value [brand]” → required and category attributes. “Unable to check product pages” → crawlability. Once you classify the error by its attribute the fix is deterministic; the only judgement call is whether it lives in the feed, the landing page, or the image.
Every fix starts with the exact issue name. In Merchant Center, account-level issues appear in a banner and in the summary cards on the “Needs attention” page; item-level issues appear in the Diagnostics / Products view. Don’t guess from the email subject — open the page, read the precise issue string (for example “Invalid value (GTIN)” vs “Conflicting values (GTIN, brand)”), and map it to the relevant section above. The issue name tells you whether you’re fixing feed data, a landing page, or an image.
Fix the underlying data at its source, not by patching the export. Then validate the change before pushing — confirm the GTIN check digit verifies, the price matches the page, the image meets size rules — so you don’t spend a 3–5 day review cycle on a fix that was itself wrong. Re-upload the corrected feed. For ordinary item-level disapprovals the re-review is automatic; you only use “Request review” for account-level enforcement, PID, or to claim your one courtesy review during a warning window.
Use “Request review” only after you’ve verified the fix end to end. A failed review during a suspension starts a cool-down that disables the button and can lengthen with each failure, so a premature request is expensive. If you genuinely disagree with an issue you can also request a review to contest it. Otherwise, the discipline is simple: fix, verify, re-upload, confirm the data is clean, then request the review once.
Most of the buckets above are deterministic — they can be checked by a machine before Google ever sees the feed. GTIN check-digit and length, leading-zero preservation, missing required attributes, invalid Google product category, image size, and excessive-capitalization titles are all rule-checkable. FeedArc validates these at import time — whether the catalog arrives through a platform integration or file import — so a malformed GTIN or a 12-digit code that lost its leading zero is caught and surfaced before export — it never reaches Merchant Center to become a disapproval. This moves the work from reactive (read the disapproval, fix, wait 5 days) to preventive. You can spot-check these deterministic rules on your own feed right now with the free Google Shopping feed validator — it runs in your browser and flags the same issues before you upload.
Beyond pass/fail validation, a feed validation grade scores the whole feed so you can see systemic risk — the kind that escalates to an account-level warning — before it does. Title construction, category mapping, and identifier fallbacks (including identifier_exists=no for genuinely GTIN-less products) are defined once as feed rules and applied consistently across the catalogue, instead of hand-edited per product. Consistent rules are what keep a one-off fix from re-breaking on the next import. Try this on the Google Shopping channel.
Once the feed is clean, disapprovals stop being the bottleneck — the next gains come from product feed optimization: title structure, attribute completeness, and segmentation that improve how often your approved products actually show.
FeedArc validates GTIN check digits, required attributes, image sizes, and Google product categories the moment you import — so the deterministic disapprovals in this guide are caught and fixed before the feed ever reaches Merchant Center, instead of after Google rejects your products and ad spend stops.
Feed validation is the process of checking a product feed against a channel's schema and rules — required fields, data types, value formats, and business logic — before upload, so errors are caught locally rather than after disapproval.
A Global Trade Item Number (GTIN) is the international barcode identifier — UPC, EAN, JAN, or ISBN — that uniquely identifies a manufactured product worldwide, issued by GS1.
Google Merchant Center (GMC) is the Google platform where you upload, validate, and manage product feeds that power Google Shopping ads, free listings, Performance Max, and Demand Gen campaigns.
Feed rules are transformations applied to a product catalog before export — mapping internal field names to channel-specific schemas, filtering out ineligible products, enriching data, or applying conditional logic per channel.
An MPN (Manufacturer Part Number) is the unique code a manufacturer assigns to one of its products, used together with the brand field to identify products that do not have a GTIN.
Build a Google Shopping XML feed that clears Merchant Center review. FeedArc maps required attributes and fixes GTIN and category errors before export.
Generate a Meta Catalog feed for Facebook Shops, Instagram Shopping, and Dynamic Ads. FeedArc catches row-level validation errors, applink included.
Apply this playbook to your own product feed in minutes. Free to start, no credit card needed.