Fixing Google Merchant Feed Errors: Disapproved Products and How to Fix Them

You set up Google Merchant Center, uploaded your PrestaShop feed, and now half the catalogue is flagged. Red triangles in the Products tab, an "Account suspended" warning that wasn't there last week, and items that should be live in Shopping showing as Disapproved instead. The frustrating part is that disapprovals rarely tell you the whole story in plain language — Google names a symptom ("Mismatched value: price") and leaves you to work out which PrestaShop setting actually caused it.

Last updated: June 2026.

This guide is specifically about diagnosing and clearing disapprovals: reading the error, tracing it back to the exact PrestaShop setting or feed attribute that triggered it, and fixing it so the product re-approves. It is the troubleshooting companion to the wider feed work — if your products are already approved and you want them to perform better (titles, taxonomy, custom labels), that is a different job covered in our Merchant Center feed optimization guide. Here we keep strictly to: it's red, why, and how to make it green.

First, read the disapproval correctly

Before touching a single setting, separate two things Merchant Center deliberately blurs together. An item-level issue disapproves one product or a handful — you fix the data and it re-approves on the next feed pull. An account-level issue (misrepresentation, policy, a suspended account) can take every product offline at once and needs a different response. The fastest way to tell them apart is the Diagnostics view, not the per-product red icon.

In the current Merchant Center, open Products → Diagnostics (or Needs attention in Merchant Center Next). It groups disapprovals by issue and tells you, per issue, whether it's Account, Item, or Feed level, how many products are affected, example items, and — where Google provides one — the deadline before the issue starts costing you. Work that list top-down by affected-product count: one feed-level fix usually clears dozens of items at once, where chasing individual products is whack-a-mole. So what does that buy you? You spend your fix-time on the one setting that re-approves forty products instead of editing forty products by hand.

Price mismatch — the single most common PrestaShop disapproval

Error: "Mismatched value (page crawl): price [price]" or "Item disapproved due to policy violation: price mismatch."

Google crawls the live product page and compares the visible price to the price in your feed. If they differ by more than a tiny tolerance, the item is disapproved on the grounds that the shopper would see a different number than the ad promised. On PrestaShop this almost always traces to one of four causes, and they need different fixes — so identify which before you change anything.

A quick way to confirm tax is the culprit: open the disapproved product in an incognito window, note the displayed price, then open your feed file and find that product's <g:price>. If the ratio between them is your VAT rate (1.19, 1.21, 1.23…), you have a tax-mode mismatch, not a stale-data problem — and changing the feed's tax mode fixes the whole batch.

For reference, here is what a discounted item should look like in an XML feed: send the regular price as g:price (tax-included, to match the B2C page Google crawls) and the discounted price as g:sale_price, both in the currency the page renders — never only the full price while the page shows the sale price.

<item>
  <g:id>1234</g:id>
  <g:price>49.99 EUR</g:price>
  <g:sale_price>39.99 EUR</g:sale_price>
  <g:availability>in_stock</g:availability>
  <g:brand>Acme</g:brand>
  <g:gtin>4006381333931</g:gtin>
</item>

And for a product that legitimately has no barcode — handmade, custom, your own private label — tell Google to stop expecting a GTIN rather than inventing one, which would trip "Incorrect identifier":

<item>
  <g:id>5678</g:id>
  <g:brand>Your Label</g:brand>
  <g:identifier_exists>false</g:identifier_exists>
</item>

Stale feed data — the cause behind half the "random" disapprovals

Error: intermittent price or availability mismatches that "fix themselves" then come back.

If your feed is a file you generated once and uploaded, it is a photograph of your catalogue at that moment. Every price edit, stock change, or sale you make afterwards drifts the feed out of sync with the live pages Google crawls — and the disapprovals that follow look random because they track your editing activity, not a single broken setting. The fix is to make the feed regenerate on a schedule.

In PrestaShop the clean way is a cron job hitting your feed controller (or your feed module's "generate" URL) on a schedule. PrestaShop's official Cron tasks module (the cronjobs module, free on PrestaShop Addons, managed under Modules) can call the URL daily; if your host gives you real system cron, point it at the same URL. Match the cadence to how often you change prices — daily is the floor, hourly if you run frequent flash sales. So what? Prices and stock in the feed always reflect the page Google is about to crawl, which closes the most common re-disapproval loop entirely. (For the broader feed-generation architecture — which export method, performance on large catalogues — that's covered in the feed optimization guide.)

Availability mismatch

Error: "Mismatched value (page crawl): availability" or "Product unavailable."

Google read in stock in your feed but the live page said sold out, or vice versa. On PrestaShop this is almost always the interaction between a product's stock quantity and its "When out of stock" behaviour (set per product on the Stock tab, with the global default under Shop Parameters → Product Settings). If a product is at zero quantity but set to "Allow orders," the page still sells it — so your feed should report in stock, not out of stock. Make sure the feed reads both the quantity and the out-of-stock policy, not quantity alone, or back-orderable products will be wrongly marked unavailable.

Image violations

Error: "Image too small," "Promotional overlay on image," or "Image not crawlable."

• Image too small. The minimum is 100×100 px (250×250 for apparel), and 800×800+ is a practical quality recommendation worth meeting. PrestaShop generates many resized copies of every image (the named image types under Design → Image Settings — home_default, large_default, cart_default and friends). Your feed must reference the large type's URL, not a thumbnail — a feed that points at home_default will trip "too small" on every product.
• Promotional overlay. Any text, badge, watermark or logo burned into the image — "SALE," "-30%," "FREE SHIPPING" — is a disapproval. If you've baked promo flashes into product photos, that's the cause; the product image must show the product on a clean background only.
• Not crawlable. Googlebot can't fetch the URL. Check three things in order: robots.txt isn't blocking /img/, any hotlink-protection or WAF rule isn't blocking Google's image crawler user-agent, and the image URL doesn't 404. Paste the exact <g:image_link> URL into an incognito window — if you can't load it logged-out, neither can Google.

Missing identifiers (GTIN / MPN / brand)

Error: "Missing value: GTIN," "Incorrect identifier," or "Limited performance due to missing identifiers."

Google matches your products against its catalogue using identifiers. For most branded, manufactured products it wants brand + GTIN (the EAN/UPC barcode). PrestaShop's barcode field — labelled GTIN (EAN, JAN, ITF or UPC/UCC code) in the References block on the product's Details tab (combinations carry their own barcode, which matters if you sell variants) — maps directly to Google's gtin attribute. The Brand attribute maps from the PrestaShop Manufacturer assigned to the product.

• Branded products with barcodes: populate the GTIN/EAN-13 barcode field in PrestaShop and assign a Manufacturer. This is also the single highest-impact change for visibility — products with valid GTINs get matched into more searches.
• Products that legitimately have no barcode (handmade, custom, your own private label): set identifier_exists = false in the feed so Google stops expecting a GTIN. Do not invent a barcode — a wrong GTIN is worse than none and triggers "Incorrect identifier."
• "Incorrect identifier": usually a malformed or check-digit-invalid barcode someone typed into the field. Validate the EAN-13/GTIN rather than guessing.

Shipping not configured for the target country

Error: "Missing shipping information" or "No shipping cost for [country]."

Google needs a shipping cost it can show before checkout. You can supply it per-product via the feed's shipping attribute, but the cleaner route for a PrestaShop store is account-level: set it once in Merchant Center under Shipping and returns, matching your PrestaShop carrier rates (Shipping → Carriers). Two PrestaShop-specific gotchas:

• Free shipping is not "no shipping." If you offer free delivery, configure a 0-cost shipping service explicitly. An empty shipping field reads to Google as "shipping unavailable," which disapproves the item.
• Every targeted country needs a rate. If you target Germany and France but your Merchant Center shipping only covers France, the German products disapprove. This mirrors your PrestaShop carrier zones — if a carrier doesn't serve a zone you're advertising into, Google sees the gap.

Policy and misrepresentation — the account-level threats

Error: "Policy violation," "Misrepresentation," or the dreaded "Account suspended."

These are the serious ones because they can take the whole account down, not one product. They're rarely a feed-attribute problem — they're about your store's trust signals, which Google checks on the live site. The PrestaShop-specific checklist:

• Visible, complete return/refund policy. Create it as a CMS page (Design → Pages) and link it from the footer. A buried or missing policy is a frequent suspension trigger.
• Reachable contact details. Your store must show a real way to contact you. PrestaShop's Contact controller and a populated Shop Parameters → Contact address/phone cover this — don't leave the demo data in.
• HTTPS everywhere, no mixed content. Enable Shop Parameters → General → Enable SSL so HTTPS is enforced site-wide. A checkout that's HTTPS but loads an http:// image counts as mixed content and can read as insecure.
• Titles that match what you actually sell. "Samsung Galaxy S24 case" is honest; "Samsung Galaxy S24" for a third-party case is misrepresentation. If your PrestaShop titles lead with a brand you don't manufacture, fix the product name, not the feed.

If your account is suspended for misrepresentation, fix every item above before requesting review — Google typically grants a limited number of re-review requests, so a half-fix that fails review burns one of your chances.

A fix-and-verify loop that actually clears the queue

Disapprovals don't clear the instant you save a setting. Work the loop deliberately:

• Fix at the source, not in Merchant Center. Change the PrestaShop setting or feed logic so the next regeneration is correct — patching one product by hand in Merchant Center gets overwritten on the next feed pull.
• Regenerate the feed so the corrected data is actually in the file Google reads. (This is exactly why the daily cron above matters — without it your fix sits in PrestaShop but never reaches Google.)
• Re-fetch and wait for the crawl. Item re-approval follows the next feed processing and page crawl, not your save button. Most clear within a day or two; don't panic-edit in the meantime.
• Re-check Diagnostics, top issue first. Confirm the affected-product count dropped before moving to the next issue.

Keep them green: monitoring

Once the queue is clear, the job becomes prevention. Check Diagnostics weekly, address new disapprovals within a day or two (prolonged disapprovals can drag account standing toward a warning), and keep that feed regenerating on schedule so price and stock never drift. Most "sudden" disapproval waves are a stale feed catching up with a batch of price edits — a reliable cron quietly removes that entire category of problem.

The pattern across every error above is the same: a disapproval is Google telling you the feed and the live page disagree about something — price, stock, an image, an identifier, a policy. Fix the disagreement at its PrestaShop source, regenerate, and the red clears. Once products are reliably approved, the next lever is making them compete — sharper titles, the right taxonomy, custom labels for bidding — which is the territory of the feed optimization guide. And if you're stepping back to the strategy of running Shopping campaigns profitably, start with Google Merchant for PrestaShop PPC success and don't pour budget into it before reading how to choose the right Google Ads budget — a clean feed only pays off if the spend behind it is sized right.

Merchant feed disapproval FAQ

How do I tell an item-level problem from an account-level one? Use Products → Diagnostics (or "Needs attention" in Merchant Center Next), not the per-product red icon. It groups disapprovals by issue and tags each as Account, Item or Feed level with the affected-product count. An item issue disapproves a few products and clears on the next feed pull; an account issue (misrepresentation, policy, suspension) can take everything offline at once and needs a different response.

Why is "price mismatch" the most common PrestaShop disapproval? Google crawls the live page and compares its visible price to the feed price. The usual cause is a tax-mode mismatch — the feed exports tax-excluded prices while the B2C storefront shows tax-included. Quick check: open the product incognito, find its g:price in the feed; if the ratio is your VAT rate (1.19, 1.21, 1.23…), switch the feed to tax-included and the whole batch clears.

My disapprovals come and go "randomly" — why? Almost always a stale feed. A file generated once is a photograph of your catalogue at that moment; every later price or stock edit drifts it out of sync with the pages Google crawls, so the disapprovals track your editing, not one broken setting. Regenerate on a schedule — daily at minimum, hourly if you run flash sales — via PrestaShop's Cron tasks module or real system cron.

My product images are disapproved — what's wrong? Three common causes: the feed points at a thumbnail (home_default) instead of the large image type, so it trips "too small"; a promo badge ("SALE", "-30%") is burned into the photo, which isn't allowed; or the URL isn't crawlable (robots.txt blocking /img/, a WAF blocking Google's crawler, or a 404). Paste the exact g:image_link into an incognito window — if you can't load it logged-out, neither can Google.

How long does re-approval take after I fix something? Not instantly. Fix at the source in PrestaShop (patching one product by hand in Merchant Center gets overwritten on the next pull), regenerate the feed so the corrected data is in the file Google reads, then wait for the next processing and crawl — most clear within a day or two. Re-check Diagnostics top-issue-first and confirm the affected count dropped before moving on.

Related reading

• Smart Google Merchant feed manager — generates a feed that reads live prices and stock, closing the stale-feed disapproval loop.
• Merchant Center feed optimization guide — once products are approved, making them compete on titles, taxonomy and labels.
• Choosing the right Google Ads budget — a clean feed only pays off if the spend is sized right.