Merchant Center disapproved products: check price and availability

When a Merchant Center product is disapproved for a price or availability mismatch, the fastest useful investigation starts with the exact item, not a broad catalogue rebuild. This guide compares the feed row, selected variant, shopper-facing product page and structured offer data. Two clearly illustrative cases and a practical decision table show how to choose the next check.

Identify the exact Merchant Center problem before changing data

A product can look perfectly ordinary when you open its online store page and still appear under “Needs attention” in Merchant Center. The reason is that Google receives a specific product offer, not merely the impression that the catalogue is functioning. A product data record contains an item ID, destination URL, price and availability. The destination page may contain multiple variants, a temporary promotional price, dynamically updated inventory and machine-readable Product/Offer information. These representations must describe the same offer.

Start with the individual item in Merchant Center and read its exact issue. A warning is different from a disapproved product, and a problem affecting one item is different from an account-level issue. A price or availability mismatch is also a different diagnostic task from a missing attribute, an inaccessible landing page or a broader policy finding. Use the item-level reason to decide which evidence is relevant rather than interpreting every warning as a general feed failure.

Write down the item identifier, its data source, its target country and the reported mismatch. Keep the comparison to one exact product variation. If your store sells the same product in multiple countries or languages, do not assume that the English page and a national feed share identical commercial data. Find the destination and currency associated with the affected Merchant Center offer.

The next question is practical: if a shopper follows that particular product link now, which version will they see, and what can they buy? The relevant facts are the selected variant, the clearly displayed total product price or sale price, the currency and the product's actual orderability. Compare those facts with the current submitted record. A full feed re-export without knowing which value differs can conceal the cause instead of locating it.

Merchant Center can show both price and availability problems on related offers. Treat each separately. A correctly priced product can still be reported as available while the actual selected variant cannot be purchased. Conversely, stock status can be accurate but the data source may contain yesterday's promotion. A precise diagnosis states which attribute is wrong, where it is wrong and which item it belongs to.

Follow the affected item ID, variation and target country

A product group is not the same as one offer. Clothing illustrates the difference: a blue shirt in size M, the same colour in XL and a black shirt in M can have distinct item IDs, prices and stock positions. Merchants often examine the parent product page and conclude that everything is available, yet the feed can target a size that is sold out. Begin with the exact variation represented by the record.

Copy the landing URL from the affected item in Merchant Center or its source record. Open it in a normal logged-out browser session rather than navigating through the homepage first. Check which colour, size, pack or specification is preselected. When the feed describes XL but the landing page opens M, the visible price and stock status may refer to another offer. Resolve the selection mismatch before treating the displayed number as proof that the feed value is incorrect.

Record the offer ID, group ID where present, variant details, currency, destination country and the selected state after page load. If a query parameter selects the variation, check that it is actually used on the public page. If the shop uses separate URLs, make sure the URL in the feed leads to the corresponding page. A title, image or parent category alone cannot establish variant identity.

Next test what a shopper can genuinely do. Does the buy button work for that selected configuration? Is a stock message tied to the same choice? Does selecting a different size refresh price and availability consistently? Is the initial HTML compatible with the final visible state? These observations distinguish a variant-specific mismatch from a display problem affecting the entire group.

For stores offering different national storefronts, repeat the check in the context of the country targeted by the record. A different currency, language or stock pool is not automatically a defect; the mismatch occurs when the submitted offer points users to a page that describes another offer. Keep your evidence focused on the relevant country-specific item rather than comparing arbitrary versions of a multilingual website.

Compare the feed, the visible page and the offer markup

Create a simple evidence line with five points: the store's authoritative price and inventory for the item, the currently supplied feed fields, the exact variant selected by the landing URL, the content visible to an ordinary visitor and the structured Offer values published by the page. A discrepancy becomes actionable when you can name the field and reproduce the difference in this chain.

For price, compare the feed's price and currency, plus any active sale_price, with the displayed amount. In structured Offer data, check price and priceCurrency for the matching variation. A store might have a regular price and an active promotion. The feed must represent the applicable offer rather than a price that ended yesterday. Be attentive to price ranges shown on parent pages, multi-pack pricing and variant-specific additions. The value attached to the selected item is the one that needs to be compared.

For availability, use the real state of the selected item. The familiar values in_stock and out_of_stock describe different purchase possibilities. Preorder and backorder serve specific situations and should correspond to what the visitor sees about ordering and expected availability. A generic “available” indicator for a product family cannot replace the status of the variation actually advertised.

Look beyond the visible page. Structured data can carry an Offer with a price, currency and availability value. A price in a theme may be changed while old JSON-LD persists in the rendered output or a cache. Google's Rich Results Test can help inspect the markup, but the test should sit alongside direct examination of the live visitor experience and the data record. The existence of valid Product markup by itself does not prove that every Merchant Center attribute matches.

Timing belongs in the same evidence set. Record when the store price or stock was changed, when the feed was generated and when the source was processed. When those dates differ, you can tell whether a record is simply behind the current store or whether two systems continually calculate different values. The goal is to repair the source relationship, not merely make one screenshot appear correct.

Decision table: symptom, evidence and next action

Observed issue	Compare	First useful action	Verification
Price mismatch	Feed price, currency, selected variant and visible price	Correct the source value for that offer	Same item, currency and price in the current feed and public page
Promotion mismatch	Regular price, sale_price, promotion timing	Align active offer and submitted promotion fields	Visible promotion corresponds to the relevant feed fields
Availability mismatch	Variant stock, availability value and add-to-cart behaviour	Update the specific item's availability	The preselected variant can be ordered as indicated
Wrong variant opens	Item ID, colour/size selector and target URL	Make the landing link open the intended variation	The correct option and its information load together
Page looks correct	Structured data, cached HTML and timestamps	Find the stale or inconsistent representation	Markup and visible content reflect current offer data
Another issue reason	Exact item issue and affected destination	Investigate the reported attribute or page condition	The specific Merchant Center issue has a verified next status

The table works best when applied to one item at a time. If the same group produces multiple disapprovals, identify the matching offer for each line. Fixing a parent product description does not necessarily correct the availability of its variations, and updating a feed does not necessarily fix a wrong landing link. Every action needs a corresponding verification.

Prioritise facts that determine the customer's purchase: which exact item opened, what it costs and whether it can be ordered. Next inspect delayed exports, page rendering and structured data. That order avoids the common situation in which a merchant regenerates XML repeatedly although the buyer is landing on the wrong variation.

Worked example: a promotion that has not reached the feed

Illustrative example, not store data. An online lighting shop sells a desk lamp in white and black. The regular price for the black option is €79 and a temporary campaign lowers it to €69. The product page displays €69 with black selected, but a feed generated before the promotion still submits €79 without the current sale value. The white version remains €79. These example prices exist solely to show how the diagnostic process works.

The affected item in Merchant Center is the black lamp. Start by copying its ID and submitted link. Open the link in a logged-out session and confirm that black is selected. Read the current visible price and currency. Then compare the submitted price and any sale_price with the campaign that is actually live. A specific discrepancy emerges: the feed describes the old offer and the page displays the current one.

Do not stop once the numerical price has been corrected. If the feed link actually opens white, the item still points to another offer even if the numbers happen to match. Check the variant URL and the selected state as carefully as the amount. The most useful remediation is to synchronize the offer data and its destination from one authoritative store record wherever possible.

After the change, save the current item ID, time of update, published feed values, public destination and visible offer state. Inspect Product/Offer markup for the black variation as well. Then return to the affected Merchant Center item to check which issue is still being shown and which next step the interface offers. Updating your data and seeing Merchant Center process it are distinct observations.

This example also highlights a maintenance decision. A theme-level promotional label and a separately edited feed attribute create two places that can drift apart. A predictable workflow records the active promotion once and propagates it consistently to the page and source. That operational improvement has value even when the current disapproval has already been identified.

Worked example: one sold-out size inside an available product group

Illustrative example, not a real client's inventory. A footwear store offers a running shoe in sizes 40, 41 and 42. Sizes 40 and 41 can be ordered, but 42 has sold out. The parent product card still says “available” because some sizes remain. Meanwhile, the specific feed record for size 42 says in_stock, and the landing link preselects size 41. The store is operational, but the advertised offer and destination do not describe the same variation.

Open the item record for size 42 and its actual link. Note the currently selected size. Select 42 manually and inspect the buy button and inventory message. The resulting facts show that this variant cannot be ordered, even though another size can. The inventory attribute for 42 should represent that status; the URL should present the matching option rather than substituting 41.

Now inspect the structured Offer information. If the markup states InStock for 42 while the visible interface disables the purchase button, the page itself provides conflicting descriptions of availability. Changing the product title does not solve that difference. The store needs the stock record, variant selection, public interface and markup to use the same current state.

Keep preorder and backorder distinct from a sold-out option. If an item is available to reserve before release, that is a different commercial state and requires corresponding information on the landing page and in the product data. Likewise, if an item can be ordered for later fulfilment, the offer should explain what the shopper is actually purchasing. Simply marking every unavailable item as in_stock obscures the important distinction.

Test size 41 after correcting 42. A broad rule that marks the entire group as out_of_stock would introduce a new error, because size 41 is still purchasable. Good verification therefore covers both the affected variation and a neighbouring available variant. It demonstrates that the fix is precise rather than a change to unrelated stock.

The useful outcome is an item-level inventory process. The quantity for each offer drives the store selector, the feed status and any corresponding Offer markup. That prevents a generic category or parent-product indicator from becoming the final authority for every variation.

Timing, country context and the verification after a fix

Some mismatches are synchronization problems rather than incorrect manual edits. A storefront may update after an order, while the feed is exported once each night. A scheduled promotion may end on the website while the external source still contains the old sale fields. Compare the modification time of the product, the generation time of the feed and the point at which Merchant Center last processed that input.

Cached or script-generated content deserves another test. The price a customer sees after selecting a size may be rendered after page load, while the initially delivered HTML contains another amount. A static JSON-LD block may carry the previous availability value. Inspect the public source and the final selected state together. When they disagree, identify the component responsible for each value instead of changing visible text at random.

Target-country differences require the same discipline. Compare the feed entry intended for a country with the matching public offer and currency. Don't use a different national version as the reference. Where pricing or availability is genuinely regional, review the supported targeting and the buyer-facing information for that region. Unpredictable changes based on IP or session can make a published offer hard to reproduce.

After correcting the underlying store or feed source, check the newest accessible item state under Merchant Center's “Needs attention” view. A source submission, a reprocessing event and an assessment of the reported issue are separate steps. Look at the current message and follow the relevant official workflow. Keep the item reference, before-and-after values and timing as a concise diagnostic record.

Official product guidance covers price inconsistencies, availability inconsistencies and Merchant Center item issues. Google's ProductGroup documentation explains the representation of variations where relevant.

For a technical review, Kiljano offers a Merchant Center Feed Check. A Supplier XML/CSV Feed Analysis can help when the source file is the problem, and a Product Variant Data Check focuses on variation records.

Frequently asked questions about price and availability discrepancies

Why is one item disapproved if the product page looks normal?

Merchant Center evaluates a specific offer. Its record can contain a different price, variant URL or availability value from the selected variation on the public page. Locate the item ID and its destination first, rather than judging the whole product family.

Is a price mismatch always caused by the XML feed?

No single source should be assumed. Compare submitted price and currency, current public price, selected variation and Product/Offer markup. A stale page, a promotion that has not propagated or a wrong target URL can each create a discrepancy.

How should I compare sale_price and the ordinary price?

Check which promotion is currently active for that exact item, which normal and sale values are in the data source, and which amount the landing page displays. Include the date of a scheduled price change in the comparison.

What does in_stock mean when one size is sold out?

The relevant question is whether the advertised variation is actually orderable. Another size being available does not make the sold-out size available. Match the feed record to the variant selector and working purchase button.

Can an incorrect variant link trigger an availability problem?

Yes. A link that selects a different colour or size can display the inventory state of another offer. Check the selected option on page load against the item ID and its variant-specific feed attributes.

Why inspect structured data if the visible price is correct?

The page may publish machine-readable Offer information with an older price or availability state. Inspect the current markup alongside the visitor-facing page and the data source to find which representation is out of date.

What should I do immediately after a correction?

Reopen the exact public product URL, compare it with a freshly produced data record, confirm the selected offer and check the corresponding Merchant Center issue. Record the observed status rather than treating a new feed upload as the final verification.