Contents 11
Diagnose Merchant Center errors by their scope rather than changing an arbitrary attribute. One product, template, category, source and account need different checks. Compare data with the page and checkout; for suspension, separately review business information and sale terms.
Product issues and account issues are different tasks
A product-level disapproval affects an offer or a group of offers. An account-level warning or suspension has wider implications and requires checks of the website and business settings, not just one feed attribute.
Open the specific issue and affected-product examples. The same issue label can arise from different mismatches. Establish its scope first. The diagnostic table is a working method, not a list of guaranteed Google decisions.
| Level | Affected scope | Investigate | First check |
|---|---|---|---|
| SKU | Product or variant | Data, page, Product/Offer | Compare ID, price, stock, link and identifiers |
| Template | One page type | Theme, markup and checkout | Compare affected and approved pages |
| Category | Similar products | Import and mapping | Find the shared attribute or source |
| Source | Much of the catalog | XML/CSV/API, schedule and rules | Compare raw and processed records |
| Account | Whole store | Business, policies, domain and checkout | Test the buyer path and compare details |
Diagnose from one SKU to the whole account
1. Record the issue before changing anything
Keep the country and program, affected IDs, examples and date. Otherwise you cannot distinguish a resolved cause from a different set of examples.
2. Find the narrowest shared level
One SKU needs its own data checked. Repetition across a template points to theme or integration logic; a shared product source calls for checking export rules.
3. Compare four representations
Compare price, currency, promotion, selected variant, minimum quantity and the conditions for obtaining the advertised price. Every representation must describe the same offer. Google requires consistency with the landing page, structured data and checkout.
- The raw product record in the file or API.
- Processed offer data in Merchant Center.
- The visible product page and Product/Offer markup.
- Checkout after selecting the advertised variant.
Misrepresentation guide for account and policy issues →
4. Check whether the product can be bought
On a phone in a private session, select the variant, add it to the cart and check shipping and payment up to order confirmation. A failed test is useful evidence, not proof of what a Google reviewer did.
5. Fix the original source
Fix the CMS, ERP, rule or integration responsible. A manual Merchant Center edit may be replaced by the next import. Confirm that the corrected source record actually reached Merchant Center.
Symptoms, checks and root-cause fixes
Start with a reproducible mismatch. Price mismatch does not necessarily mean the XML alone is wrong: a variant, cache, markup or basket can carry another price. A system fix addresses that source instead of hiding one affected product.
Do not recreate offers or accounts to evade restrictions. Keep a change log and before/after checks. Approval of one example does not demonstrate that the whole cluster is fixed.
| Symptom | Check | Fix direction | Avoid |
|---|---|---|---|
| Price mismatch | Currency, sale, variant, quantity, cart | Synchronize the source and visible price | Changing only the feed |
| Availability mismatch | Data, page, markup and cart status | Update stock status and data delivery | Offering unavailable items as in stock |
| GTIN issue | Manufacturer, packaging, requirements | Submit reliable identifiers | Inventing a value or borrowing another GTIN |
| Page unavailable | HTTP, redirects, robots, mobile | Restore the specific product page | Sending every product to the homepage |
| Misrepresentation | Business, contacts, terms, offers | Make information accurate and consistent | Hiding the business or inventing affiliations |
Product data: fields to check first
ID, price, availability. ID should consistently identify the same product or variant. Price, currency and availability must agree with the page, markup and checkout. Titles, descriptions and images must describe the same offer; they need not be literal copies of every source field.
GTIN, MPN, brand, identifier_exists. Obtain GTIN from a reliable manufacturer source. A blank supplier spreadsheet does not prove that no identifier exists. Missing or wrong identifiers can limit visibility. Do not invent GTIN or use identifier_exists=no to bypass applicable requirements.
Link, mobile, title, image. Link to the specific product or variant. Check page/image access, redirects, robots, language and currency. For image-size changes and API migration, use dated requirements rather than an old recommendation copied from a guide.
Check older integrations for migration to Merchant API. Content API reached sunset on August 18, 2026; Google describes progressive failures without a Google-granted extension, not every request stopping at once. Check the current timetable and integration-provider responsibility.
Google: Content API lifecycle ↗
Google announced a 500×500 minimum for all product images from January 31, 2027 and recommends 1500×1500. Check the current image_link specification. Preserve source metadata for applicable AI imagery and accurately represent the actual product.
Account suspension and misrepresentation
Misrepresentation concerns inaccurate, unrealistic or misleading presentation of the business or its offers. “Google does not trust the site” is too vague to explain a specific cause. Google may consider the website, accounts, offers and third-party information.
Check the system as a whole. One absent item in the list does not establish the reason for suspension; these are surfaces to investigate, not an automatic diagnosis.
- Business name, actual address, phone and email.
- Verified domain and consistent business profile.
- Clear contact information in an accessible place on the site.
- Accessible, accurate shipping, payment, return and refund terms.
- Actual delivery times, limitations and costs.
- Promotions, prices and stock that match the ability to buy.
- No invented certifications, partnerships or brand affiliations.
Merchant readiness audit scope → · Demonstrative report using synthetic data →
When to request a review
Available issues can offer “I fixed the issue” or “I disagree with the issue”. Complete the steps shown in Needs attention, including identity verification if requested. Use the official channel; do not send documents in a public chat.
Before requesting review, confirm the website fix is live, updated data has been processed, affected clusters have been checked and store conditions agree. Explain specific changes rather than sending another request without checking.
Review availability and cooldown depend on the issue and review history. Support cannot shorten a cooldown. A review timeline is not a reinstatement guarantee; follow the notifications in the account.
- Fixes are live on the site and in the data source.
- Merchant Center has received and processed the update.
- Several affected items and the checkout path were checked.
- Account-level business information and policies agree.
- The cause and changes are recorded in a log.
If an empty data source makes review unavailable, the official instructions recommend manually adding at least one real product. Follow account prompts and requested verification; do not invent a product merely to enable the button.
UPLIFY’s working method
Start with an issue register and diagnostic level. Bulk-editing a feed before locating the cause mixes hypotheses. For each cluster, record IDs, shared template/source, the check performed and live confirmation of the correction.
This is an operating sequence, not an approval promise. It helps avoid a review request with a partially fixed system issue. The audit scope and public report sample show what the work delivers.
What you can fix yourself
Self-service work is reasonable when the cause is localized, your team controls the source and can verify price, stock, identifiers, links, images or mapping. Do not mix dozens of hypotheses into one release.
Bring in a specialist when the issue is account-wide, integrations conflict, checkout has complex logic or prior reviews failed. A specialist cannot guarantee Google’s decision either. After the data stabilizes, check its use in Shopping and PMax.
Questions before making changes
Should you change product ID after a disapproval?
Usually not. ID should consistently identify the same offer. Changing it does not fix price, stock, policy or page issues. Address the cause first; only change the identification scheme after checking history and integration implications.
The feed price is right, but Google sees another price. What should you check?
Compare default variant, sale_price, currency, markup, cache, mobile rendering and checkout. The URL and data must describe the specific offer. Check source-processing time and the entire affected cluster, not just one product page.
The supplier gave no GTIN. Can you set identifier_exists=no?
First establish whether the manufacturer actually assigned an identifier. A blank supplier spreadsheet does not prove otherwise. Never invent GTIN; submit reliable brand/MPN according to applicable requirements. Do not use identifier_exists=no to bypass rules.
Some products no longer show the issue. Is it time to request review?
Check the whole affected cluster, every source and variant. A few approved examples do not prove that the system cause is resolved. For account-level issues, separately check business information, policies and checkout.
Does Merchant Center always prohibit buyer registration?
No. The documentation permits free account creation without extra barriers and describes guest checkout or one-time-passcode verification. Do not require paid access, an app download or device switching. Check purchase access and the applicable country/program requirements.
Is Content API already fully switched off?
Sunset occurred on August 18, 2026, but that is not the same as every request failing simultaneously. Google describes progressive failures from September 1 without a Google-granted extension. Final decommissioning is planned for early 2027; the timetable may change. Check current status and the integration’s migration to Merchant API.
Sources and limits
Requirements were checked against Google. The diagnostic sequence is UPLIFY’s working method, not a reinstatement guarantee or an explanation of every reviewer decision.
- Google: Review workflow ↗
- Google: Misrepresentation ↗
- Google: Landing-page requirements ↗
- Google: Checkout requirements ↗
- Google: GTIN ↗
- Google: Image link ↗
- Google: Content API lifecycle ↗
- Google: Merchant API updates ↗
What to check next
- Misrepresentation guide
- Merchant readiness audit scope
- Demonstrative report using synthetic data
- Google Shopping and PMax after data stabilizes
Investigate your store’s issues
Send the store URL and issue name, not passwords or documents. We will agree checks, access and scope; Google’s decision is not guaranteed.