Products → Needs Attention: The Merchant Center Next Diagnostic Entry Point

If you are following a troubleshooting guide that says “click Diagnostics,” you are in the wrong place. In Merchant Center Next — the rebuilt product all retailers were migrated to by September 2024 — the classic Diagnostics tab no longer exists. The current entry point for product-level issues is Products → Needs attention, which shows three high-impact issue cards at the top, ranked by click potential: High / Medium / Low, followed by the full product list and a “View history” link for trend data. Account-level issues (warnings and full suspensions) appear separately from the item-level cards. Source: Google Merchant Center — Issues in Merchant Center.

The second change that trips up merchants reading older guides is the status vocabulary. The labels Active, Pending, Disapproved, and Expiring are legacy Merchant Center Classic terms — they do not exist in Merchant Center Next. The current product status set is five labels: Approved, Limited, Not Approved, Under Review, and Processing. The most critical distinction is Limited: a Limited product is still serving on some surfaces or in some countries — it earns impressions and clicks — but a policy restriction or quality signal has excluded it from the full configured surface set. Diagnosing a Limited product and diagnosing a Not Approved product are different tasks with different fix paths; treating them the same leads to unnecessary changes that can create new issues. For a full explanation of product feed attributes and required fields, see what is a product feed in Google Merchant Center.

Reading Each Status: The Action for Every State

The five product statuses encode what is happening to a product right now and what action is required. Getting the read wrong costs merchants unnecessary effort and can create new issues by changing something that was working.

Approved is the only fully clean state. A product with Approved status is eligible for all configured Shopping ad surfaces and free listing placements in all enabled countries. The only action is maintenance: keep the feed data accurate, ensure the landing page price and availability stay in sync, and confirm that automatic item updates is on (Products → Automations) so minor data source drift does not trigger a Preemptive Item Disapproval. For best practices on feed data quality, see best practices for optimizing product feeds.

Limited is the status most often misread as a disapproval. A Limited product is actively serving on some surfaces or in some countries — it earns impressions and clicks — but a policy restriction or quality signal has excluded it from the full configured surface set. Common causes include a country-level policy restriction, a quality signal that reduces eligibility for a top-of-page Shopping placement, or a missing supplemental attribute that unlocks additional surfaces. The correct action is to click through to the product detail to see which surfaces are excluded and address only that specific issue. Treating a Limited product as fully disapproved and making broad feed changes can remove it from the surfaces where it was serving correctly.

Not Approved is a full disapproval: the product is ineligible for all surfaces until the issue is resolved. The disapproval reason is visible in the product detail. Note that price or availability mismatch disapprovals (PID) result in a Not Approved status but require a manual review request to reinstate — a feed fix alone does not restore serving. Google’s product data quality help page lists all fixable item-level issue types.

Under Review and Processing are transient states. Processing means the product was recently submitted or updated and eligibility has not yet been determined; it typically resolves within hours. Under Review means Google is actively reviewing the item — this occurs after a fix is submitted, after a manual review request is filed for a PID, or for certain product types that require human review before serving. Neither state requires action beyond waiting. Diagnosing a Processing product as an issue before the processing cycle finishes generates false positives that lead to unnecessary feed changes. The managing and automating product feeds guide covers how feed update frequency affects how quickly status changes propagate after a fix.

Common Google Merchant Center Disapproval Reasons and How to Fix Them

The Needs attention surface groups product issues by type and ranks them by click potential. Understanding which disapproval categories are immediate (the product stops serving the moment the issue is detected) versus which give a warning window changes the fix sequence entirely. Price and availability mismatch (PID) is the only disapproval type that is both item-level and immediate — all other item-level disapprovals typically carry a warning period of 7 or 28 calendar days before the product is pulled.

The preemptive disapproval model for price and availability mismatch is a design choice by Google, not a quirk: landing page accuracy is a core trust signal for Shopping. Many merchants optimize their feed but leave the schema.org Offer markup on the page incorrect — and Google reads the page, not just the feed. The overview of Google Merchant Center explains the relationship between the Merchant Center account, the data source, and the landing pages that Google crawls continuously.

Price and Availability Mismatch: Why PID Is Different from Every Other Disapproval

Every other disapproval category in Merchant Center gives you time to fix the issue before the product is pulled from serving. Price and availability mismatch does not. When Google’s continuous automated crawl detects a discrepancy between a product’s feed data and either the visible landing-page price or availability or the schema.org Offer structured data in the server-rendered HTML, it fires a Preemptive Item Disapproval (PID): the product stops serving immediately, with no warning and no grace period. Per Google’s PID help page, the six documented PID triggers are: (1) unsynced product data with the website; (2) misalignment with schema.org or structured data markup; (3) IP-based or geo-dynamic pricing not reflected in the feed; (4) multiple prices on the landing page without proper attribution; (5) minimum order quantities not reflected in the feed price; (6) product variant preselection showing a different variant’s price.

The schema.org distinction is the one most merchants miss. Google’s crawler reads the schema.org Offer structured data from the initial HTML response of the landing page — not from JavaScript-rendered markup. A product page built in a client-side framework with @type: "Offer" rendered by the browser rather than the server can have a perfectly accurate feed and a correct visible price, yet still fire a PID because the crawl sees the stale server-rendered HTML without executing the JavaScript. If your store runs client-side rendering, fix the schema.org Offer in the server-rendered HTML source first — then fix the feed attribute — then verify automatic item updates is enabled. The automatic item updates safety net reads the same structured data source, so a broken schema in the raw HTML means neither the feed fix nor the automation catches the discrepancy.

Once a PID fires, correcting the feed data alone does not self-clear it. You need to submit a manual review request. After fixing the landing page, schema markup, and feed attribute, click “I fixed the issue” or “Request review” in Merchant Center under the product detail in Products → Needs attention. Google’s PID help page states the review takes up to 7 business days. A failed review — one submitted before the underlying cause is actually fixed — triggers a 7-business-day cooldown before another review can be submitted. Submitting a PID review before the schema.org fix is live is the most common reason reviews fail and cooldowns stack up.

MB Adv Agency treats PID as the highest-priority error class in any Shopping feed audit. A live campaign with active PIDs generates zero impressions on the affected products — in a large catalog, this can silently eliminate a significant share of impression volume before the merchant notices the issue. Our Google Shopping feed management team monitors the Needs attention surface on an ongoing basis specifically because PID can fire on an already-correct feed when a site update changes the server-rendered schema without a corresponding feed refresh. The fastest resolution path: fix schema.org first, fix the feed second, verify automations third, then submit the review.

Automatic Item Updates: What They Fix, What They Cannot

Automatic item updates is one of the most misunderstood safety nets in Merchant Center Next. It is on by default for all accounts, lives under Products → Automations, and reads schema.org Offer structured data in the server-rendered HTML of each landing page to keep feed data in sync with the page. What it cannot do is self-clear a PID once issued, and it cannot read schema.org markup that is rendered by JavaScript rather than the server.

The operational rule: automatic item updates keeps the feed current between scheduled feed fetches, but it only reads what Google sees in the server-rendered page source. Feed freshness — scheduling daily data source fetches so the feed stays current with inventory and pricing — is the proactive layer that makes automatic item updates unnecessary for most data-drift scenarios. For feed scheduling and supplemental data source management, see managing and automating product feeds.

The Availability Attribute: Four Accepted Values and the Preorder vs Backorder Trap

The availability attribute accepts exactly four values: in_stock, out_of_stock, preorder, backorder. Google does not accept freeform strings. The most consequential error in this attribute is using preorder for a product that is temporarily out of stock — the correct value for a manufactured-but-OOS product is backorder, and the mix-up triggers unnecessary disapprovals every peak season.

MB Adv Agency’s feed management team tracks the preorder/backorder split closely during peak season. The Q4 pattern repeats every year: a merchant marks sold-out products as preorder because “the customer is ordering before it comes back,” which is the semantic for backorder, not preorder. preorder in the spec means the product has not yet been manufactured or released. Using it for an OOS product triggers a policy flag. A correct backorder + availability_date keeps the product serving on free listings while the restock is pending. For the relationship between availability attribute values and feed data structure, see what is a product feed in Google Merchant Center.

Sale-Price Price-History Rules: How They Differ by Surface

The sale-price history rules exist to prevent merchants from inflating a “regular” price to create an artificial discount. They require that the price (the regular price the sale is discounted from) has been the actual price for a qualifying period before the sale_price takes effect. The qualifying period is not the same across all surfaces — it is stricter for free listings and Local Inventory Ads than for US Shopping ads. Qualifying for the “Sale” annotation on US Shopping ads does not mean the same product qualifies on non-US free listings.

The additional cross-surface constraints apply to every surface: the discount must be greater than 5% and less than 90% of the regular price, and both the original price and the active sale price must be clearly displayed on the landing page (the sale price more prominent; the original price visually de-emphasized). A sale_price cannot run continuously for more than 30 days per promotion period; use the sale_price_effective_date attribute to specify the valid date range. And meeting the history threshold does not guarantee the “Sale” badge appears — Google applies editorial judgment on which annotations surface.

Account Suspension: Immediate vs Warning-Period Causes

Misrepresentation is the number one cause of Merchant Center account suspension — and it is always immediate. No warning email, no 7-day window, no chance to fix before the account is pulled. Most merchants who receive a suspension assume they are in the standard “warning then suspension” bucket. Misrepresentation and counterfeit goods are not. Understanding which bucket your suspension falls into determines whether you need days or weeks to fix it before submitting a review.

The key operational insight our ecommerce PPC audit team applies when a merchant arrives with a suspension: the first question is whether the suspension is Misrepresentation-class (needs a deep policy audit, site restructure, and possible checkout rebuild before submitting a review) or a warning-class violation that can be resolved in days. Confusing the two categories leads merchants to submit a review before fully fixing the underlying problem, which starts the growing cool-down timer and makes reinstatement harder, not faster. For the full taxonomy of prohibited and restricted product categories, see overview of Merchant Center policies.

Reinstatement After Suspension: The Exact Flow and the Cool-Down Trap

The reinstatement process is precise: fix every identified policy violation, then submit a Request review in Merchant Center, then wait 3–7 business days. The step that determines whether reinstatement succeeds or fails is the first one — “fix every violation” requires fixing all flagged issues, not just the most obvious one, before submitting. A rejected review starts a growing cool-down period: each failed resubmission extends the wait before the next Request review can be submitted, and the cool-down end date is visible in Merchant Center under Needs attention → View setup and Policy issues.

For account-level issues, the “Request review” button lives under the account-level issue section of Products → Needs attention, separate from item-level product disapprovals. After clicking, Google’s help page states the review typically completes within 3–7 business days. If the review is approved, the account reinstates and products return to serving. If denied, the growing cool-down begins. Identity documents (passport, utility bill, company registration) are frequently required for Misrepresentation and counterfeit suspensions; having these ready before submission prevents additional delays.

The triage rule MB Adv Agency applies to every feed audit: fix all 0-day issues (PID, missing required attributes, account-level suspensions) before touching anything else, because those products are already not serving. Warning-period issues (GTIN, image, title, landing page) have a window — begin fixing within 24 hours of the warning email, but the immediate items take priority. For the performance metrics that help you see which disapprovals are costing the most impression share, see our ecommerce PPC audit process, which maps feed errors to revenue impact before prioritizing the fix sequence.

How to Fix a Disapproved Product in Google Merchant Center

The fix-a-disapproved-product flow in Merchant Center Next differs depending on whether the disapproval is a PID (requires manual review) or a standard data quality issue (fixes automatically after a feed update and recrawl). The six steps below cover both paths.

1. Go to Products → Needs attention and identify the disapproval. Click the product to see the specific issue code — price mismatch, missing attribute, image violation, policy issue. The issue detail shows the exact attribute or policy that triggered the Not Approved status. Note whether it is flagged as High, Medium, or Low click potential.
2. Determine whether it is a PID (price or availability mismatch). If the issue code indicates a price or availability discrepancy, the fix must cover two things beyond the feed: the visible landing page AND the schema.org Offer structured data in the server-rendered HTML. A feed-only fix does not resolve a PID.
3. Fix the source. For PID: update the schema.org Offer markup in the server-rendered page HTML first, update the landing page price or availability, then correct the feed attribute. For image, title, description, GTIN, or landing page issues: fix at the data source level (the spreadsheet, feed file, or CMS field that generates the feed attribute). For policy violations: fix the underlying site or business practice before touching the feed.
4. Update the data source and trigger a re-fetch. After fixing the source, trigger a feed refresh (via scheduled fetch, file re-upload, SFTP update, or Merchant API). Allow up to 24–72 hours for Google to recrawl the products and update their status in Merchant Center.
5. For PID or manual-review cases, click “Request review” or “I fixed the issue.” Google’s automated recrawl alone does not clear a PID — a manual review request is required. The PID review takes up to 7 business days. A failed review triggers a 7-business-day cooldown before another review can be submitted.
6. Verify the product status returns to Approved (or Limited with the specific limitation addressed). Check Products → Needs attention for the updated status. A product that returns to Limited rather than Approved still has a surface-specific restriction — click through to see which surface is excluded and what attribute triggers the remaining limitation.

MB Adv Agency’s feed management process runs this checklist on every Needs attention flag before submitting any review request. The highest-risk step is step 5: merchants who submit a PID review before completing step 3 (fixing the schema.org markup) almost always receive a failed review and a 7-business-day cooldown. For proactive feed error prevention — catching title, image, and GTIN issues before Google flags them — see best practices for optimizing product feeds. For a full ecommerce feed and campaign audit, see our Google Shopping feed management service or the ecommerce PPC audit.

Three Misconceptions That Send Merchants in the Wrong Direction

The three most costly misconceptions in Merchant Center troubleshooting all share the same structure: a merchant follows an older guide that describes the wrong interface, the wrong status labels, or the wrong fix path for a PID, and loses days or weeks before finding the correct answer.

Misconception 1: “Diagnostics” is where I find disapprovals. The Diagnostics tab no longer exists in Merchant Center Next. Every troubleshooting guide published before September 2024 describes this tab. In Merchant Center Next, product-level issues appear under Products → Needs attention, ranked by click potential (High / Medium / Low), not by error count. Account-level issues appear separately. If a guide says “click Diagnostics,” the rest of the instructions describe a flow that no longer exists in the current UI.

Misconception 2: “A price mismatch gives me time to fix it.” Most error categories in Merchant Center give you a warning period of 7 or 28 calendar days before the product is pulled. Price and availability mismatch does not. A Preemptive Item Disapproval fires the moment the crawl detects the gap — the product stops serving before the merchant receives any notification. The fix path for PID is also different from a standard feed fix: correcting the feed attribute does not clear the disapproval. The schema.org Offer markup in the server-rendered HTML must also be correct, and a manual review request must be submitted. See the PID section above for the full resolution path.

Misconception 3: “A Limited product is disapproved.” Limited is the status most often misread as a full disapproval. A Limited product is actively serving — it earns impressions and clicks — but a specific surface or country is excluded by a policy restriction or quality signal. Not Approved is the full-disapproval status. Treating a Limited product as Not Approved and making broad feed changes risks removing it from the surfaces where it was serving correctly. The correct action is to click through to the product detail, see which specific surface is excluded, and address only that restriction. The overview of Merchant Center programs explains how free listings, Shopping ads, and other surfaces each have distinct eligibility requirements.

Google Merchant Center Disapprovals FAQ

Methodology

This pillar consolidates six absorbed Google Merchant Center pages: the primary debugging pillar (debugging-feed-disapprovals-and-errors-in-merchant-center), common-feed-errors-and-how-to-fix-them (261 GSC impressions at position 25.53 for “common feed errors” — the only absorbed-zombie signal in the batch), fixing-pricing-and-availability-discrepancies-in-merchant-center, managing-stock-status-with-the-availability-attribute, price-and-sale-price-guidelines-for-merchant-center, and resolving-account-suspension-issues-in-merchant-center. Every platform-mechanic figure (the five product statuses; the four availability values; the sale-price history thresholds by surface; the PID review timeline of up to 7 business days; the account suspension reinstatement timeline of 3–7 business days; the October 2025 Dishonest Pricing Practices policy update) is sourced to a named Google help page verified on 2026-06-30: answer/12153802 (Needs attention); answer/9773429 (PID); answer/12157888 (automatic item updates); answer/9017019 (sale price annotations); answer/13889434 (availability attribute); answer/13693195 (suspensions and reinstatement); answer/6150127 (Misrepresentation); answer/6149993 (Counterfeit products); answer/13693497 (product data quality violations). The warning-period 7-vs-28-day per-violation split is documented in Google’s own language as “7 or 28 calendar days” without specifying which violation types receive each track — this is a [Verify] item; use “7 or 28 calendar days” as the exact Google phrasing rather than asserting a rule. No mbadv client metrics appear in this article — all agency point of view is qualitative. Search demand context from ecommerce PPC agency data and Ahrefs, June 2026. GSC data: project 8261895 (mbadv.agency), 90-day window 2026-04-01 through 2026-06-30. Reviewed by MB Adv Agency, June 2026.