Disapproved products in Merchant Center usually trace back to one of three causes: product identifiers (GTIN, brand, MPN) that are wrong or misused, a price or availability value in the feed that differs from what the store shows, or a title or image that breaks the specification. The fix follows a set order. Open the "Needs attention" tab to learn the type and spread of the problem, correct the source (the feed, the product page or the structured data), and only then request a review. Skip that order and the same error returns after the next feed upload.
This guide is for the SEO specialist, marketer or developer who maintains an online store's product feed. Merchant Center Help pages change over time, so check the current page on your publication date for dates and timings. Interface labels are quoted in English because your account may show them in another language. None of the fixes below guarantees that products return by a given date or with a given level of visibility.
Where Merchant Center Shows What Is Wrong
Before editing any single product, work out where the problem sits and how widespread it is. Diagnostics are built for bulk decisions.
Product-level and account-level issues
According to the Help page on issues (Opens in a new tab), all product-level issues appear on the "Needs attention" tab of the Products page. Setup and policy issues show in a banner at the top of the account and under "View setup and policy issues" on the same tab. They behave differently:
| Level | What it affects | Documented outcome |
|---|---|---|
| --- | --- | --- |
| Product warning | Individual products | Products still show, performance may be limited, unresolved warnings can become disapprovals |
| Product disapproval | Individual products | Products stop showing across Google |
| Preemptive item disapproval | Products with price or availability mismatches | A review is required to resolve it |
| Account warning | The whole account | You may get an email with examples and a warning period; products keep showing meanwhile |
| Account suspension | The whole account | If issues remain after the warning period the account is suspended, and some serious issues cause immediate suspension |
An account-level policy problem can affect the entire catalog, so it takes priority over a GTIN error on a handful of products.
Treat warnings as early notice
Because the Help page says unresolved warnings can lead to disapprovals, a clean disapproval count does not mean a healthy feed. Warnings on a product tell you which items are about to be disapproved. Clearing them during a regular check costs less than waiting for disapproval and then waiting on a review.
Find the common thread
The Help page suggests using the filters on the Needs attention list or downloading the list as a .csv file to review affected items. The issue details page shows the impact and the resolution steps. Look for what the affected products share: one supplier, one brand, one category or one product template. A common thread usually reveals the root cause. Fifty products from one supplier rarely mean fifty separate mistakes; they point to one data problem.
Check the three basics first
The page recommends fixing the product data and re-uploading it, and lists mismatched information, broken links and a robots.txt file that blocks Googlebot among the common causes. These three double as a quick triage: does the product link open, can Googlebot reach the page, and does the feed value equal the value on the page?
Product Identifiers: GTIN, Brand and MPN
Identifier fields are explicitly named in the specification as reasons for disapproval. Whether they are required depends on the product, and filling them in wrongly can be worse than leaving them out.
GTIN: only if you are sure
The product data specification (Opens in a new tab) gives a clear rule: provide a GTIN only if you are sure it is correct. A product submitted with an incorrect GTIN is disapproved. A product that has a GTIN but is submitted without one may have limited visibility. The GTIN must have no dashes or spaces, and its checksum must be valid.
The decision rule follows from that. If the manufacturer's GTIN is available and verifiable, send it. If it is not, do not guess or copy one from a similar item. Common sources of bad GTINs are:
- A spreadsheet turning a long number into scientific notation or dropping leading zeros.
- The parent product's GTIN copied onto every size and color variant.
- A supplier's internal product code mistaken for a GTIN.
- The GTIN of a single unit used for a multipack.
Example scenario: a damaged supplier file
A store imports a new supplier's spreadsheet into its feed. The GTIN column was stored as a number, so long codes were altered and leading zeros vanished. After the next upload, many products show GTIN problems. The cause is not many separate errors but one column format. The right fix is to re-import the column as text and request verified codes from the supplier; correcting codes by hand or guessing them creates new errors. The scenario is fictional and has no figures; it shows why searching for the shared cause pays off.
Brand: a real brand or nothing
Per the specification, brand is required for new products, except movies, books and musical recordings, and it should be the brand generally recognized by consumers. Use your own brand only if you manufacture the product or it falls into a generic brand category. For products with no brand, leave the field empty. Do not enter placeholders such as "N/A," "Generic," "No brand" or "Does not exist."
A frequent cause is a feed tool that writes a default such as "Other" instead of an empty value. Sort the exported brand column by how often each value occurs; placeholders will stand out immediately.
MPN and identifier_exists
The MPN is required only when the product has no manufacturer-assigned GTIN, and only manufacturer-assigned MPNs should be submitted. An incorrect MPN can also get a product disapproved. Do not send your internal SKU as an MPN.
The identifier_exists attribute defaults to yes. Use "no" only when a product truly lacks identifiers; the specification's examples include a media item without an available GTIN and an apparel item without a brand. If a product does have unique identifiers, submitting "no" can get it disapproved. The attribute reports a situation honestly; it is not a way to silence a warning.
What the free listings page adds
The free listings requirements (Opens in a new tab) page says a GTIN is required when the manufacturer assigned one, brand when a product has a clearly associated brand or manufacturer, and MPN when there is no GTIN. It also notes that strong identifiers, meaning a GTIN or an MPN with a brand, help products appear in the Shopping Knowledge Panel. That is a documented benefit of correct identifiers, not a promise of visibility.
Identifier summary
| Field | When it is needed | What to avoid |
|---|---|---|
| --- | --- | --- |
| GTIN | When the manufacturer assigned one | Guessing, dashes, spaces, invalid checksums |
| Brand | New products, except movies, books and music | Placeholders such as "N/A" or "Generic" |
| MPN | When there is no GTIN | Sending an internal SKU as the MPN |
| identifier_exists | Set to "no" only if no identifiers exist | Using "no" on a product that has identifiers |
When the Feed and the Store Disagree
These issues are often the most urgent because the Help page says a price or availability mismatch between product data and product pages can trigger a preemptive item disapproval that needs a review to resolve. The introduction to the specification also warns that conflicting data between your data source and your website can keep ads and free listings from showing.
One price in three places
The specification defines the rule: the price must match the price on the landing page, in the structured data and at checkout, and the product must be purchasable online at that price. On tax, read the country rule: for the US and Canada, do not include sales tax, while for other countries include VAT or GST. Check the section for your own market before relying on this summary.
The most common sources of a price mismatch are:
- The feed refreshes once a day while the store changes prices during the day.
- A promotion is applied only in the storefront, so the feed still carries the old list price.
- Member pricing, which the specification also requires to match across the data source, the landing page and checkout.
Example scenario: a store applies a weekend discount through its theme while its feed comes from a weekly export. All weekend the product page shows the discounted price and the feed shows the list price. The fix is to feed the discount to both from a single source of truth.
Availability values and matching
The accepted availability values are in_stock, out_of_stock, preorder and backorder, and the value must match the landing page, checkout pages and structured data. If an item is out of stock, its price must still be clearly visible on the landing page. For preorder and backorder, an availability_date is expected; it is required for preorder.
The classic stock mismatch happens when a discontinued product disappears from the store but stays "in_stock" in the feed. How the page itself should behave when a product is sold out or removed is covered in the guide to out-of-stock and discontinued product pages. The feed has to reflect the same state at the same time.
Structured data must agree too
The specification treats structured data as one of the sources the feed has to match. If the visible price and the JSON-LD price differ, two of your three sources contradict each other. The free listings page tells you to check Search Console for markup errors if you use structured data. The correct properties are explained in the product schema markup guide. For this guide, the only rule is that all three sources agree.
Variants
The free listings page requires item_group_id for product variants. Each variant's price and availability should match what a shopper sees after choosing that variant. If colors and sizes are selected on one page, test that the feed link opens the intended selection. URL and canonical choices are covered in the product variants guide; for Merchant Center, what matters is that the feed link lands on the same variant the feed describes.
Titles and Images That Fail Review
After identifiers and prices are right, titles and images tend to be what remains.
Title rules
The specification says the title should accurately describe the product and match the title on the landing page, with a maximum of 150 characters. For variants, include distinguishing features such as color or size. Promotional text such as "free shipping" does not belong in the title. A simple check sorts feed titles by length and searches for words like "free," "sale" and "best."
A subtler error is writing the feed title differently from the page title for marketing reasons. Because the specification asks for a match, align them. If you shorten a long title, shorten the page title with the same logic.
Image rules
The image must accurately display the product, with no promotional text, watermarks or borders, and no placeholder or generic image. For size, the specification says at least 500 x 500 pixels for all product images and states that enforcement starts January 31, 2027. The free listings page likewise says images must be large enough and free of promotional content.
Three quick image checks: does the supplier image carry a logo or watermark, were small images enlarged to pass, and did a "no image" placeholder slip into the feed? Also confirm that image links are not blocked by robots.txt, since the Help page names that as a common cause of product-level issues.
Automating the checks
A short script can list feed rows with titles above 150 characters, titles containing promotional words, and titles that differ from the page title. For images, test pixel dimensions instead of file size and list the small ones separately. Because the size requirement carries an enforcement date, finding small images now lowers the risk of a mass disapproval later.
Page access and broken links
Broken links, redirect chains and product pages closed to Googlebot are quiet causes. Test the product URL with something that checks bot access, not only a browser. If the page opens for people and not for the bot, the fault is in the server or blocking rules, not the feed.
Requesting a Review Without Wasting Cool-Down
Once the data is fixed, a review is the next step. The Help pages describe it in two places.
Steps for product-level issues
On the page about requesting a review (Opens in a new tab), product-level issues work like this: on the Needs attention tab find the product and select "Fix" under Status, then under "What needs attention" choose "Request website check" or "I disagree with the issue," and then select "Request website check" or "Request review" if available. For setup and policy issues, open "View setup and policy issues," choose "I fixed the issue" or "I disagree with the issue" for each, and select "Request review."
Why the button may be inactive
The button may stay inactive until you complete merchant verification and have at least one product in your data source. If the data source is empty, the page suggests adding a product manually under "All products." During a cool down period the button is also greyed out. The period begins after you use the disagree option and attempt to fix the issue, and the Needs attention tab shows when it ends.
Cool down and timing
The documentation states that Google support cannot bypass or shorten the cool down, that it may grow longer with each unsuccessful review, and that a one-week cool down may begin if the issue is not resolved by the second attempt. Timing statements differ by context: wait 7 business days for setup and policy reviews, up to 2 weeks for general notifications, up to 7 business days for disagree appeals, and approved products become eligible to show across Google within 24 hours. The issues page says setup and policy reviews can take up to 7 days. Plan around the longest figure.
Readiness list before asking
- The root cause was found and corrected at the source.
- The corrected data reached the feed and was uploaded.
- Price and availability agree on the product page, structured data and checkout.
- Pages are open to Googlebot and links work.
- Merchant verification is complete and the button is active.
- Any disagreement is backed by evidence; if the flag is correct, do not dispute it.
Asking before this list is complete spends cool-down time for nothing, which matters because a failed second attempt can lengthen the wait.
Beyond the Fix: Prerequisites and a Weekly Routine
Correct product fields are not enough on their own. The free listings page asks that products comply with Google's policies for showing products for free, that a return policy be on your website (and recommends adding it in Merchant Center), and that shipping be set up through settings or the shipping attribute. Shipping information may be mandatory depending on the country; check the Merchant Center documentation for your account's target country. The page also says free listing status controls permission to show products but does not guarantee impressions.
A required-fields audit
The page's required list works as a lookup table. Every product needs id, title, link, image_link, price, description and availability. Condition is required for used or refurbished items, brand when a brand or manufacturer is clearly associated, multipack for multipacks, is_bundle for bundles and item_group_id for variants. Apparel and accessories also need color, size, age_group and gender. Recommended fields include additional images (up to 10), canonical_link and, for apparel, material and pattern. Compare this list against your feed export columns. If a store sells apparel but has no age_group column, the problem lies in the template, not in individual products.
Weekly routine
- Compare warning and disapproval counts on the Needs attention tab with last week.
- Sample products from any new supplier file and verify GTIN, brand and image by hand.
- Open page price, feed price and checkout price side by side for the products whose prices change most often.
- Check that products removed from the store left the feed.
- Check Search Console for product markup errors.
Keep notes: which supplier, which field, which fix. When one supplier repeats the same error, a transformation rule in the feed is more durable than a manual fix.
Evidence before disputing
Before disagreeing with a flag, collect a screenshot of the product page, the price at checkout, the structured data output and the feed row. Gathering this often reveals the mismatch yourself, so you fix it instead of disputing. That also avoids the extra waiting a failed second attempt can bring.
Think in templates
Many disapprovals are template errors. If the title template appends "free shipping," the whole catalog fails on titles; if the image process adds a logo to every picture, every image has a problem. Ask how many products share the cause. A template fix can repair hundreds of items at once, and can also break hundreds if done wrongly, so test on a small group, verify the feed, then roll out widely.
Symptom to Action Table
| Symptom | Likely root cause | First check | Where to fix |
|---|---|---|---|
| --- | --- | --- | --- |
| Many GTIN disapprovals | Bad supplier codes or format corruption | GTIN length, dashes and spaces on sample items | Feed source |
| Brand warning | Placeholder such as "N/A" or "Generic" | Frequency of brand column values | Feed transformation rule |
| Price mismatch | Feed lag or storefront-only promotion | Feed price vs page vs checkout | Price source and refresh rate |
| Availability mismatch | Removed product still in the feed | Feed status vs page status | Stock sync |
| Title disapproval | Promotional text or title differing from page | Search for "free," "sale" | Title template |
| Image disapproval | Watermark, placeholder or small image | Sample images and dimensions | Image source |
| Product link fails | Broken link or robots.txt block | Open the link with bot access | Server or blocking rule |
The causes in this table combine the common causes the documentation names with frequent feed mistakes; for your own account's exact cause, open the issue details page.
Preventing the Problem at Its Source
Fixing a disapproval is a one-off; preventing it is data discipline. Four habits help:
- Feed products from one product data source, not separate price tables for store and feed.
- Match feed refresh frequency to how often prices and stock change.
- Check feed fields for placeholders and blanks.
- Spot-check GTIN, brand and image whenever a new supplier file arrives.
Merchant Center problems are solved by accurate product data, not by link building. Off-site visibility for category pages is a separate workstream, described in the category page backlinks guide.
Common Mistakes
- Typing a guessed GTIN: An incorrect GTIN gets the product disapproved; if unsure, do not send one.
- Using placeholder brands: "N/A" or "Generic" violates the specification.
- Setting identifier_exists to "no" to quiet the issue: Doing so on a product with identifiers can cause disapproval.
- Feed and checkout price differ: The price must also match at checkout, not only on the product page.
- Removed products left in the feed: Availability no longer matches the site.
- Requesting review before finding the cause: The cool down gets longer.
- Fixing products one by one: Without a shared cause the problem comes back.
Frequently Asked Questions
Is sending a wrong GTIN worse than sending none?
According to the specification, a product submitted with an incorrect GTIN is disapproved, while a product that has a GTIN but is submitted without one may have limited visibility. Send a GTIN only when you are sure it is correct and verifiable, and do not guess.
What should I put in the brand field for an unbranded product?
Leave it empty. The specification says to leave the field empty for products with no brand and not to enter placeholders such as "N/A," "Generic," "No brand" or "Does not exist."
Can I set identifier_exists to "no" to get past a GTIN error?
No. Use "no" only when the product truly has no GTIN or no MPN and brand combination. Submitting "no" for a product that does have unique identifiers can get it disapproved.
Which pages is the feed price compared with?
The specification requires the price to match the landing page, the structured data and checkout. The issues page says a price or availability mismatch can trigger a preemptive item disapproval that needs a review to resolve.
Why is the request review button inactive?
The documentation says the button may stay inactive until merchant verification is complete and your data source has at least one product. It is also greyed out during the cool down period, which Google support cannot bypass or shorten.
How long does a review take?
The documentation gives different timings: up to 7 business days for disagree appeals, up to 2 weeks for general notifications, 7 business days to wait for setup and policy reviews, and approved products become eligible to show within 24 hours. Plan around the longest figure and treat none as a guarantee.
Conclusion
A Merchant Center disapproval signals a mismatch between your product data and your site. Honest identifiers, one price and one stock status across feed, page, structured data and checkout, titles and images that follow the specification, and a controlled review request are the four parts of the fix. Find the level and the shared cause first, correct the source, and request review last. Use the documented timings for planning, not as promises.
If you also want to build outside visibility for your product and category pages, you can review the guest post service at Akua Adforce; scope and terms are stated on the product page.
Post a comment
Please log in to leave a comment. Login