Why Do Products Get Rejected by Google Merchant Center?

A Google Merchant Center rejection usually boils down to a conflict between your feed data and your live storefront, or a failure to meet Google’s site-wide trust standards. Before changing any product details, determine whether you are dealing with an item-level policy violation or an account-level suspension.

Fixing the issue starts with identifying the exact reason provided in your Merchant Center diagnostics. Once you correct the source data, often within PrestaShop, and ensure your storefront mirrors your feed, you can resubmit your products for review with confidence.

Why Was My Product Rejected in Google Merchant Center?

A Merchant Center rejection means Google found a disagreement between your product feed and your live storefront, or between your store and its trust expectations. It can usually be fixed: most rejected products are down to a price or stock mismatch, a missing GTIN, incomplete product data, or a feed module in PrestaShop exporting stale values. Work out whether the rejection is item-level (a policy violation in your feed) or account-level (a misrepresentation or website trust flag) before you change anything. Fixing it is mostly about reading the exact reason Google gives you, correcting that attribute at the source, and only then asking for a review.

How Google Merchant Center Actually Reviews Your Products

A rejected product in Merchant Center is not a random event; it is the output of two separate review systems.

The first is automated and literal: it reads every attribute in your feed and checks it against the signals on your live storefront. The second is broader and slower, looking at your whole account for signs a shopper could be misled. Google's own documentation describes the misrepresentation policy as a trust assessment, not a checklist.

Because of this, two stores can ship the same PrestaShop catalogue and get very different outcomes. One has a feed that matches its product pages attribute for attribute; the other has a feed built months ago and never refreshed.

• Feed Checks validate identifiers, prices, stock, images and required attributes against Google's specification.
• Storefront Checks compare what the crawler sees on your product pages with what the feed promises.
• Account-level Trust covers policy pages, business information and the overall reliability of your data over time.

Once you know which of these three is failing, the fix usually becomes obvious. Misrepresentation is assessed across the whole account, whereas policy violations are flagged per product or attribute.

Misrepresentation vs Policy Violation: What's the Real Difference?

Most Merchant Center help threads blur two very different problems, and that blur costs merchants days. A misrepresentation flag is a trust judgment on your business as a whole. A policy violation is a rule broken by one product, or one attribute on that product, inside your feed.

The distinction changes your fix order. A misrepresentation flag means no number of product-level edits will lift the account suspension. A policy violation means the rest of your catalogue can keep serving while you repair the affected items.

Google's own help community fills with sellers asking why a new store is suspended for misrepresentation before it has sold anything. That pattern is the giveaway: the trigger is usually trust, not a single bad product row.

Fix the account before the catalogue: product-level edits cannot rescue a misrepresentation suspension. Read the issue type on each notice, then work outward from the widest scope first.

In PrestaShop terms, misrepresentation almost always traces to what your storefront says about the business itself, while policy violations trace to what a single product row carries into the feed. Treat them as separate diagnostic tracks with separate checklists.

The Most Common Google Merchant Center Policy Violations

Policy violations are specific and fixable: Google flags a product attribute or listing detail that breaches its rules or contradicts your landing page. PrestaShop merchants can correct most of them in the back office or the feed, then resubmit. Always read the exact rejection reason in the Products tab before you change anything.

Two of these trip up PrestaShop stores more than any others. GTIN and brand fields are easy to leave blank during bulk import, and price mismatches appear the moment a catalog price rule kicks in after the feed was generated. Run feed generation after any pricing or stock change, not before.

• Fix the product data at the source in PrestaShop, then regenerate the feed, rather than editing values inside Merchant Center.
• Check the "Availability" mapping against your out-of-stock threshold, since a stock level of zero can still read as available if the attribute is misconfigured.
• For image rejections, verify the image URL is publicly reachable and free of text overlays before resubmitting.

Once the flagged attribute is corrected, request a review in Merchant Center rather than waiting for the next scheduled crawl. Reading the exact rejection reason first saves hours of guessing, because Google names the attribute it wants fixed. Many of these field-mapping errors trace back to the feed module used to export PrestaShop data, so review its attribute mapping whenever a batch of similar products fails together.

When 'Website Needs Improvement' Blocks Your Whole Account

A "Website needs improvement" flag is the account-level cousin of a single rejected product. It does not point at one SKU; it says Google's crawler or a human reviewer found the storefront itself unconvincing. When it escalates, every product in the feed can stop showing, which is why a rejected status suddenly appears across the whole catalogue at once.

The trigger is almost always a cluster of small credibility gaps rather than one dramatic flaw. Google's own misrepresentation policy guidance is deliberately broad, and merchants regularly report suspensions that arrive without a specific reason. Treat that vagueness as a prompt to audit the fundamentals below.

• Thin content: product pages with a title, a price and a photo, but no description, specifications or sizing details. PrestaShop's default Short description field is often left as a single line, which reads as a placeholder to a reviewer.
• Missing contact details: no physical address, no phone number, no clear way to reach a human. The Stores and Contact details blocks in PrestaShop's back office must actually be filled in and rendered on the front office, not just left in the theme.
• No returns or delivery pages: a shopper (and a reviewer) needs a reachable returns policy, shipping times and who pays return postage, linked from the footer on every page.
• Ambiguous checkout: totals that shift at the last step, unclear currency, or a payment method list that does not match what the checkout actually accepts.
• Feed and site disagreeing: a price, availability status or product name in the feed that no longer matches the product page after an update.

The diagnostic move is to shop your own store as a stranger would. Open an incognito window, land on a product page from a Google search, try to find your returns policy, and complete a test checkout. If you cannot answer "who is this seller and what happens if I need to return this?" within two clicks of the product page, a reviewer will flag it too.

How To Fix A Disapproved Product in Merchant Center Step by Step

Once you know which rejection reason applies, the repair itself is usually quick. The delays come from fixing the wrong layer, or from re-requesting review before the underlying problem is gone. Work through the sequence below in order.

Google does not resubmit instantly on its own timeline for a rejected item. Each manual review request carries a limit, so a rushed resubmission can cost you days before you are allowed to ask again.

1. Read the Exact Reason in Merchant Center, not the summary email. Open Products > Needs attention, click the rejected item and read the full diagnostic text. Note the policy name and any linked example URLs or fields flagging the issue.
2. Classify the Rejection Before Touching Anything. If the reason names a specific field or value, treat it as a data problem for the feed. If it names a policy (misrepresentation, website needs improvement), treat it as a site or trust problem that a feed edit will not fix.
3. Correct the Source, Not The Symptom. For feed errors, edit the product record in PrestaShop or in your feed module, not inside Merchant Center. Manual edits to a single SKU get overwritten the next time your feed syncs.
4. Sync or re-upload the feed and confirm the change landed. Trigger a manual fetch in your feed module or Merchant Center, then wait for the product to move from Processing to Active or back to Needs attention. Do not request review while the item is still processing.
5. Verify the landing page matches the feed. Open the product URL as an anonymous visitor and confirm price, availability, currency, and product name all match the feed values exactly. Mismatches here reappear after review.
6. Only then request a review. Use the Request review button on the rejected item, and give Google a short, specific note about what you changed. Vague notes like "fixed" produce slow or repeated rejections.
7. Log the rejection and the fix. Record the policy name, the SKU, the change made, and the date. When the same reason returns, you will know within seconds whether it is a repeat or a new issue.

Re-requesting review before the fix is verifiably live is the single biggest time-waster in Merchant Center troubleshooting, and it affects healthy SKUs too, because account-level trust signals can drop when repeated bad requests pile up.

If the rejection disappears from one SKU only to appear on its sibling variants, the problem is almost always in the shared product data template, not the individual products. Fix the template in PrestaShop once, and the whole family clears together.

Fixing Merchant Center Rejections in PrestaShop

Most PrestaShop rejections trace back to the feed itself, not the shop. The module that builds your product feed has to translate PrestaShop's catalogue structure into what Google expects, and small gaps in that translation produce disapprovals that look mysterious until you inspect the data Google actually received. Work through your feed module's configuration first, then your product data.

Start with category mapping. PrestaShop lets you organise products into your own categories, but Google needs each item mapped to its Google product taxonomy category. Unmapped or mismatched categories trigger "invalid or missing category" errors. In the feed module, check that every product's category maps to a specific leaf node in the taxonomy, not a top-level bucket.

GTIN handling is the next frequent culprit. If your products carry EAN-13, UPC or ISBN identifiers, the feed must pass them in the correct attribute with the right format. A common mistake is sending blank or placeholder values when the identifier genuinely exists, which reads as a data mismatch. Conversely, if a product has no GTIN, the feed should declare that explicitly rather than leaving the field empty.

Image and price consistency catch many stores. Google compares the feed image URL and price against your product page at crawl time. If a PrestaShop module generates a different image (a resized cache variant, say) or a price that includes or excludes tax differently to the visible page, the item can be disapproved for image or price mismatch.

• Confirm feed category maps to a Google taxonomy leaf, not a generic parent.
• Send valid GTINs in the correct format, and declare missing identifiers rather than blanking them.
• Make feed images match the product page exactly, including the variant shown.
• Keep feed price, currency and tax display identical to what shoppers see.
• Check that availability reflects real PrestaShop stock, not a stale value.

Before applying changes, export a backup of your current feed and note which products are disapproved. Fix one attribute at a time, resubmit, and confirm the affected listings clear before moving to the next. A bulk rewrite of every field can pull previously approved products back into review, so change in small batches and verify each round.

What to Do If Products Stay Disapproved After You Fix Them

A fix that does not move the needle usually means the correction never reached Google, or the rejection is account-level rather than product-level. Merchant Center sometimes holds a cached verdict until it re-crawls the page and the feed, and a misrepresentation flag on the account can keep individual items disapproved even when each one looks compliant.

Work through the loop in this order:

1. Confirm the Fix is Live. Check the product page as an anonymous visitor, not a logged-in admin, so you see what Googlebot sees. Clear the PrestaShop cache under Advanced Parameters > Performance before you re-check.
2. Request A Re-crawl. Use the URL inspection or fetch tool in Google Search Console, then update the item in Merchant Center so the feed timestamp changes.
3. Ask For A Manual Review. Open the product in Merchant Center, click the disapproved status, and use the request review option. If the whole account is affected, use the account-level review request and add a short, factual note describing what you changed.
4. Document the Corrections. Keep a dated log of each fix (page edited, feed re-uploaded, images replaced). Reviewers move faster when the note points to specific changes.
5. Escalate Only After A Review. If nothing shifts, use the contact options in Merchant Center help and reference your review case. For account suspensions, the appeals process is the correct channel, not the product-level review button.

One clean, well-documented review request beats five rushed ones. Repeatedly resubmitting before the crawl completes tends to reset the clock rather than speed it up.

• Watch for products that flip to approved then back to disapproved, which points to a page that changes after review, such as stock status or price.
• Check the account for warnings outside the product list, including business information and website verification status.
• If a single product refuses to clear, duplicate it in PrestaShop as a test listing with the same data to see whether the rejection follows the item or the URL.

Symptoms of A Merchant Center Rejection

Before you change anything, confirm the rejection is really product-level and not something broader. These are the signals merchants usually see:

• Products show as "Disapproved" or "Limited" in the Products tab of Merchant Center, with a reason like "Incorrect price" or "Missing GTIN".
• The overall account shows a warning or suspension banner even though individual products look fine.
• Free listings appear on Google while paid Shopping ads do not, or the reverse.
• Items were approved recently and are suddenly disapproved after an update.
• The diagnostics show "Website needs improvement" against many products at once.
• Only a subset of products are affected, usually those with variants, sale prices, or no GTIN.
• Google Ads shows "Product disapproved" for a Shopping campaign that used to run.
• The feed shows a successful fetch, but individual items carry an error in the item-level detail view.

If everything is rejected at once, treat it as an account or website trust problem. If a handful of items are rejected, treat it as a feed problem first.

What Causes A Merchant Center Rejection?

The table below maps each common cause to what it looks like and how hard it usually is to fix. Work down from the top; the easier fixes catch most cases.

Quick Fixes to Try First

These steps clear the simplest and most common cases. Do them in order, then request a review only once the changes have gone live.

1. Open the Products tab and filter by "Not approved" so you see the exact rejection reason for each item.
2. Pick five rejected products and compare the feed price, currency, and availability against the live product page in a private browser window.
3. Fix any price or stock-status mismatch at the source, in PrestaShop, then re-export the feed.
4. Add or correct GTINs for products that have a manufacturer barcode.
5. Check that every rejected product has a valid image URL, brand, and clear description.
6. Re-fetch the feed manually in Merchant Center rather than waiting for the scheduled crawl.
7. Open the diagnostics page and read the account-level warnings, not just the item-level ones.
8. Only after the fixes are live, request a review of the rejected products or the account.

Most single-item rejections clear after a clean re-fetch and a short re-crawl. Account-level warnings take longer and need real changes first.

Price and Availability Mismatches

This is the most common rejection in PrestaShop stores, and the easiest to misdiagnose. Google compares the feed value to the product page and rejects the item when they disagree. The price on the site is the source of truth, so the feed must match it exactly, including tax settings and currency.

Start in PrestaShop's Catalog menu, then Products and open the product in question. Check the base price, the specific price (sale price), and the tax rules group. Then check the same values in your feed export. If they differ, the feed is reading the wrong field or ignoring your tax settings.

• Sale prices must show the same reduced price on both the feed and the page, with the same end date.
• Availability must match: if PrestaShop shows "out of stock" after a variant sells, the feed must too.
• Currency and tax display must be consistent between the feed and the storefront.

If the mismatch keeps coming back, check whether your feed module reads the pre-tax or post-tax price, and whether it uses the regular or specific price field. Google does not care which price you chose; it cares that both sides agree at the moment it checks.

Missing or Invalid GTINs

Products that have a manufacturer barcode must carry a GTIN in the feed, along with a matching MPN and brand. Items with no GTIN must be flagged as such. Getting this wrong produces a specific "Missing GTIN" or "Invalid GTIN" rejection.

In PrestaShop, the reference and barcode fields live on the product's Options tab. The product's EAN-13UPC or ISBN value must be filled in exactly as it appears on the packaging, with no spaces or dashes. Then map that field to the feed's gtin attribute in your feed module.

There are three distinct failure patterns, and they need different fixes:

• Blank in the feed, present in PrestaShop: the module is not mapping the barcode field. Fix the attribute mapping, then regenerate.
• Invalid format: the value has letters, wrong length or a checksum failure. Re-enter the barcode from the packaging.
• No barcode at all: the product genuinely has no GTIN. Declare that in the feed (using the identifier-exists attribute) rather than leaving the field empty.

Bulk import is the usual culprit. A CSV import that puts a manufacturer reference into the barcode field will create hundreds of "Invalid GTIN" rejections in one go. Spot-check a sample of the imported products before requesting review.

Incomplete or Thin Product Data

Google wants enough information to make a confident listing, and a sparse product row reads as low-quality data. The rejection often names the missing attribute directly, so the fix is a matter of filling in the field at the source in PrestaShop.

The attributes that cause the most friction for PrestaShop stores:

Thin data also feeds into account-level trust judgments. A store where half the catalogue has a single-line description is the kind of pattern that contributes to a website quality flag. Filling in the description and brand fields properly is a trust signal as well as a data fix.

Feed Module Configuration in PrestaShop

When a whole batch of products fails together, the problem is almost never the individual products. It is the rule the feed module applies to all of them. That is why a single bad category mapping can produce hundreds of rejections overnight, while a one-off bad product affects only itself.

Check these configuration points before you touch individual products:

1. Category mapping: does every PrestaShop category map to the correct Google product taxonomy leaf? Look for any category mapped to a generic parent or left unmapped.
2. Attribute Mapping: is each Google-required attribute reading the correct PrestaShop field? A swapped GTIN and reference mapping is a common import error.
3. Field Selection: Is the module using the product's specific price (the sale price) or the base price? Which tax display does it apply?
4. Refresh Frequency: Is the feed rebuilt on a schedule, or only when you manually trigger it? A stale feed is a mismatch waiting to happen.
5. Variant Handling: Are combinations exported as separate items with their own GTIN, price and stock, or collapsed into the parent product?

Keep a note of the module version and the last change you made. If rejections started after an update or a mapping change, you have your prime suspect.

Website Trust Signals and Misrepresentation

When the rejection is account-level, no feed edit will fix it. Google is judging the storefront, and the fix is to make the store look like a legitimate, contactable business rather than an anonymous catalogue.

The audit checklist, from the shopper's point of view:

• A visible physical address, phone number and email, consistently shown across the site and your business profiles.
• A returns policy, a delivery policy and terms of service, each linked from the footer on every page.
• Product pages with real descriptions, specifications and clear pricing, not placeholder text.
• A checkout that shows the final total clearly, with accepted payment methods that match what you advertise.
• Business details registered in Merchant Center matching the storefront exactly.

Misrepresentation suspensions often arrive without a specific reason, which is frustrating but not a dead end. Treat the checklist above as the audit you were asked to do: fix each gap, then appeal at the account level with a factual summary of what changed. A store that gives a shopper everything they need to trust you is the only store that clears a misrepresentation flag.

Step-by-Step Diagnosis Process

Work through this sequence before applying any fix, so you treat the real cause rather than a symptom of it. Each step narrows the scope.

1. Establish the scope. Is it one product, a group of similar products, or every product in the account? One product means a feed attribute; every product means an account or website flag.
2. Capture the exact diagnostic. Screenshot or note the full rejection reason, the named policy, and any flagged fields or example URLs.
3. Compare feed to page. For one rejected product, check price, currency, availability, name, image and brand against the live product page as an anonymous visitor.
4. Check the feed timestamp. Has the feed refreshed since the last product change? A stale feed is the simplest explanation for a fresh rejection.
5. Inspect the account-level warnings. Look beyond the product list at business information, website verification and any trust banners.
6. Check for recent changes. A module update, a pricing rule, a theme change or a stock import are all plausible triggers. Note the timing.
7. Apply the narrowest fix, then verify. Change one attribute or setting, regenerate the feed, confirm the change is live and only then request review.

Advanced Troubleshooting

If the basics do not clear the rejection, move to the deeper checks. These need a little more comfort with tooling but often surface the real cause.

Enable debug mode to see the real error. In PrestaShop, turn on debug mode under Advanced Parameters > Performance while you test, then turn it off again. It surfaces PHP errors that a friendly error page hides, and it can reveal why a product page is failing to render properly to a crawler.

Read the server error log. Your host's error log tells you whether Googlebot is hitting a 500 error, a redirect loop, or a page that times out. A page that loads for you but errors for the crawler will produce mismatches that never seem to fix.

Use the browser console and network tab. Open a product page, watch for failed image requests, blocked resources or JavaScript errors. A broken image URL in the console is often the same image that the feed promises and Google cannot reach.

Run a conflict test on a staging copy. If product pages look correct in the admin but render oddly on the front office, disable non-essential modules and switch to a default theme in a staging environment. This isolates a theme or module conflict from a data problem.

Inspect the raw feed. Download the feed file and read the actual row for a rejected product. It is common to find an empty GTIN, a leftover placeholder, or an old price in the raw export even when the PrestaShop record looks correct.

Check robots and redirects. A product URL that redirects, or that is blocked in robots.txt, can prevent Google from verifying the landing page. Confirm the exact URL in the feed resolves cleanly, with no redirect chain.

How to Prevent This Problem

Most Merchant Center rejections come back because the same underlying cause was never removed. Build these habits into your workflow and the cycle of reject, fix and re-reject breaks.

• Regenerate the feed after any price change, stock update, catalog rule or product edit, so the feed never drifts from the storefront.
• Keep GTIN, brand and category fields filled in as part of product creation, not as an afterthought during a rejection.
• Fix product data in PrestaShop at the source, never inside Merchant Center, because manual edits are overwritten on the next sync.
• Spot-check a sample of any new CSV import for mis-mapped barcode, brand or category fields before publishing.
• Keep your returns, delivery and contact pages live and linked from the footer on every page.
• Write real descriptions and specifications for products, and treat thin pages as a trust risk, not just a data gap.
• Log every rejection and its fix, so a returning issue is recognisable in seconds.
• Review account-level warnings weekly, not only when products go disapproved.

Recommended Tools & Resources

A short list of tools that genuinely help you diagnose and prevent these rejections, in the order most merchants reach for them.

• Google Merchant Center Help: the policy documentation and the diagnostics that name the exact attribute at issue.
• Google Search Console: the URL inspection tool confirms what Googlebot actually sees and whether a page is crawlable.
• Merchant Center diagnostics and URL inspection: read the account-level and item-level diagnostics side by side to separate the two tracks.
• Browser incognito mode and the browser console: the fastest way to see your store as a stranger and catch broken images or blocked resources.
• Google product taxonomy: the reference for mapping PrestaShop categories to valid Google categories.

Your own feed module is the single most important tool in the chain, since it decides what data reaches Google. Review its mapping and refresh settings before every review request.