01 · Diagnosis before assumptions
Merchant Center disapprovals: identify the actual cause first
A message becomes a task only when you have evidence
When Merchant Center disapproves products, indiscriminately rewriting the feed rarely helps. First establish exactly what is affected: individual offers, a particular country, a destination or the account. Then test the suspected cause against the same variant and document a correction whose result you can verify again.
This guide is for small and medium-sized online shops in Germany with an existing Merchant Center account. It starts with a specific issue and works through product data, the website, policies and account status towards the appropriate recheck. Initial setup and the optimisation of otherwise sound product titles remain separate tasks. Here, the objective is to restore eligibility after investigating a demonstrable error.
The working tool is a Merchant Center diagnostic decision tree with an issue register. It connects the symptom, affected offers, evidence, ownership, correction and final verification. Other people can then understand why a change was made and which questions remain unresolved.
Have a current product export, access to processed attributes and access to the affected shop pages ready. Technical problems may require help from the person responsible for the exporter or web server. Account documents remain with the authorised business; they do not belong in publicly shared example files.
Current as of 22 September 2026. The examples and internal sign-off rules are an editorial working method, not a promise from Google. Restored eligibility, actual ad delivery and commercial success are separate outcomes.
02 · Status and scope
Distinguish warnings, disapprovals and account suspensions
Similar colours do not mean the same action is required
Start by opening the full message. Google's overview of Merchant Center issues distinguishes product-level problems from account-level problems. A warning does not confirm approval, but it does not automatically mean a complete suspension either. Serious violations can lead to suspension without a prior warning. The specific status and stated scope determine the next step.
| Observation | Level | Possible effect | Initial evidence | Work required | Do not infer |
|---|---|---|---|---|---|
| Warning on an offer | Product | Restrictions or later disapproval | Message and affected destination | Investigate the cause | Entire account suspended |
| Offer disapproved | Product | Ineligible in the affected context | ID, country and issue | Correct product data or website | Every variant is affected |
| Setup notice | Account | A prerequisite is missing | Account banner and details | Resolve the prerequisite | The product title caused it |
| Account suspended | Account | Broad exclusion | Policy and account finding | Address the complete finding | A new feed fixes everything |
| Review in progress | Product or account | Decision pending | Status and request date | Monitor the review step | A new error has been established |
Record the country and destination explicitly. The same offer can be assessed differently across markets or programmes. Looking only at an aggregate product count may conceal these differences. Ask not just how many items are affected, but which offers are affected and under which conditions.
Count causes and products separately as well. Several messages may refer to the same item, so their totals do not automatically equal the number of distinct disapproved products. Conversely, a single error in a shared template can affect many items. This distinction avoids both understating the problem and exaggerating its scale.
One person should keep the findings together, even when others implement the changes. Feed corrections, website changes and review requests can then be placed on a timeline instead of leaving everyone to guess their effects afterwards.
03 · Preserve the evidence
Save the finding before changing the data
The starting state, time and selection must be reconstructable
The Needs attention area provides affected products, filters, issue information and status history. An issue's detail view brings together further information and possible actions. Check any active priority filters: a view limited to high-impact issues does not necessarily show every existing problem. Estimated click potential helps with prioritisation; it is not a measured revenue forecast.
Save the exact message, observation time, country, destination and several specific offer IDs. Export the affected list where available. Add the time of the latest data run and the last known correct state. You can then investigate whether a new import, theme change or promotion coincided with the issue.
A timing connection is initially a hypothesis. If disapprovals appeared after an app update, the update is not yet a proven cause. Look for a reproducible discrepancy: what was correct before, what is now submitted, and where does the difference arise? Record findings that contradict your first suspicion as well.
For your sample, choose an affected item and a reasonably similar unaffected item. Compare their shared template, data source and target market. Different statuses do not constitute a perfect experiment, but the comparison can narrow the investigation. Keep the complete affected list alongside the sample so that the sample is not later confused with the full scope.
A useful initial record contains the message, context, offer ID, timestamp and observed value. Personal customer data is generally unnecessary for this. Remove such data from screenshots and exports before sharing them with external participants.
04 · The diagnostic tree
Work through six decision gates
Every outcome needs evidence and a next step
The following tree is an editorial working method. It organises the investigation without replacing Google's specific message. Run it for each distinct type of issue. When several causes emerge, create separate tasks under the same case instead of hiding them inside a vague instruction to “repair the feed”.
- 1 · Is the finding clear?
No: add the message, country, destination and IDs; do not request a review yet. Yes: record the affected scope and proceed to the next gate.
- 2 · Is there an account-level issue?
Yes: address account prerequisites and policies; individual product corrections alone do not close the case. No: continue with the affected offers.
- 3 · Did the correct record arrive?
No: correct submission, matching and processing. Yes: compare the processed values with the specific landing page.
- 4 · Do the offer and website agree?
No: investigate price, availability, variant, image or access as appropriate. Yes: examine the named policy and whether it applies.
- 5 · Is the cause established and corrected?
No: obtain targeted expert clarification or contact support with evidence. Yes: check the next regular data run and the affected pages.
- 6 · Is a review required?
Yes: meet the prerequisites and use the review route shown. No: monitor automatic reassessment. In either case, keep the issue open until its status has been checked and documented.
This sequence avoids unnecessary work. A record that has not been processed cannot be repaired by improving an image crop. Equally, a correct feed price does not explain an account-wide policy issue. The tree keeps technical repair separate from the eligibility decision without skipping either task.
Stop making changes while the correct value remains unclear. Unknown manufacturer data, uncertain delivery commitments and contradictory business details require a factual decision first; technical access cannot make that decision for you.
05 · Check processing
Compare source data with the offer that was actually processed
A successful upload is not a content approval
First check whether the affected item has arrived in the expected record at all. Do the offer ID, language, data source and market match? Has the latest file been processed? Is the value you are looking at current, or does it still come from an older run? Answer these questions before assessing the title or interpreting a policy.
The Google product data specification sets out formatting and content requirements. Required attributes depend on factors including the product and target market. Check the particular requirement behind the message. Inventing an unknown GTIN or indiscriminately declaring existing identifiers absent does not produce a defensible correction.
Trace the disputed field through three points: the factually confirmed source value, the submitted version and the processed result. An export may look correct while a rule or manual edit produces a different value. Conversely, the shop interface may be correct while the exporter still reads an outdated field.
If the basic structure itself is missing, use the guide to setting up Google Merchant Center. For the current incident, then document the data path actually affected. Explaining a particular mapping is usually more useful than starting a complete rebuild without a demonstrated reason.
After correction, check the same item again and retain its stable identity. An error disappearing after you delete an offer does not prove that it was repaired. Record whether the product still exists, remains included in the intended market and has actually received the changed values.
06 · Price discrepancies
Compare the same price for the same variant
Amount, currency and timing belong together
For a price issue, the processed value, landing page and checkout are all relevant. The requirements for the price attribute require matching information for the product offered. Do not compare a variant price with a general “from” price, or a sale price with a value from outside its validity period. Consider shipping costs separately.
| Checkpoint | Offer | Timing | Observation | Possible explanation | Next evidence |
|---|---|---|---|---|---|
| Processed data | Variant A | Current run | EUR 49.00 | Old regular price | Source value and rule |
| Product page | Variant A | Same review period | EUR 44.00 | Active promotion | Promotion period |
| Structured data | Variant A | Same retrieval | EUR 49.00 | Outdated template | Output offer data |
| Basket | Variant A | After direct entry | EUR 44.00 | Shop promotion applies | Checkout for the same variant |
| After correction | Variant A | New data run | Values match the promotion | Cause may have been resolved | Status and subsequent run |
The table is a hypothetical investigation, not an observed client case. Initially, it establishes only a discrepancy. Before changing the source, the responsible person must confirm which price should apply at which time. Otherwise, you could change the correct shop price to match an incorrect export and create a new commercial error.
For promotions, also check the start, end and time zone, along with the mapping to the specific variant. Open the submitted URL in a new session. If the price matches only after applying a saved coupon or membership, investigate the relevant pricing rules separately; do not treat this as a generally available standard price.
Close the case only after comparing the affected points again. A changed screenshot is insufficient if machine-readable information or the next import still supplies the old value. Describe the established cause in the register, rather than merely the final result now visible.
07 · Availability
Check whether the specific variant can be ordered and fulfilled
Stock quantity alone does not explain the submitted status
An available product family does not make every size or colour available. Start with the disputed variant and follow its purchase journey. Can it actually be ordered, and does the delivery statement match? An active purchase button for another size does not answer that question. Even positive stock can be insufficient without a corresponding shipping option.
The availability specification distinguishes values including in_stock, out_of_stock, preorder and backorder. Preorders and backorders have different conditions; both require an appropriate availability_date. Do not use out_of_stock merely because you temporarily do not want to advertise a product that customers can still order. Ad controls and actual availability are different tasks.
Investigate the update chain. When does the inventory system change stock, when does the shop adopt the status, and when does the new information reach Merchant Center? Document these times for one item. This helps distinguish a permanently incorrect mapping from recurring delays that create contradictory states.
Also inspect the visible delivery statement and machine-readable information on the same page. Wording such as “available soon” may be too imprecise to substantiate the submitted status. Ask the person responsible for stock and delivery to confirm the correct statement. Do not replace that clarification with whichever setting produces the least red text.
After repair, check a regular stock change. The correct variant must still be submitted accurately afterwards; a manual correction might otherwise last only until the next sale.
08 · Landing page and variant
Test the submitted URL from a fresh entry point
The correct page must lead to the offer without prior knowledge
Copy the URL from the processed record rather than navigating to the product inside your logged-in shop. Check redirects, language, currency and variant. A functioning home or category page does not establish that the specific product link is correct. Saved settings can hide errors that new visitors and automated retrievals actually encounter.
The product landing page requirements call for a specific, matching offer with the essential information. Information should remain consistent during loading; preselecting the appropriate variant is an important recommendation. Product descriptions and titles need not match the feed word for word, but must describe the same product. This is not a blanket ban on JavaScript.
Document the initial state and the state after loading. If the page first selects a default size before a script chooses the advertised variant, that transition may be relevant. An employee finding the desired offer after several clicks does not confirm that the original entry state was correct.
Check mobile entry as well as desktop. Look for obscured prices, dialogs that cannot be dismissed and variant fields that work only at one screen size. Do not “repair” a consent dialog by disabling the necessary consent logic; resolve the specific usability or display problem.
Save the result with the URL, variant, language, currency and review time. If the behaviour occurs only under certain conditions, describe them. A precise account such as “direct mobile entry without a saved selection” enables a targeted technical correction and a repeatable acceptance check.
09 · Retrieval
Distinguish access, rendering and indexing
Your own successful visit does not establish a successful Google crawl
For a retrieval issue, check the product page and image file separately. Google's explanation of quality and policy checks that cannot be completed includes blocked crawlers. A robots rule may block the relevant path; technical protection mechanisms or server problems can also complicate the investigation. What matters is the actual fault at the reported destination.
Have the complete redirect chain, response status and returned content checked. A page may technically respond while delivering only an error message, a login dialog or a general search view. A status code is therefore one check, not a content approval. The same applies to a product image visible in the browser when its underlying file is protected differently.
For intermittent errors, timestamps and server logs can help. Compare recorded failures with the affected URLs and recent changes. Saying “the shop works for me” is of little use if the problem occurs only for new sessions, particular requests or regular periods of high load.
Change protection and crawl rules precisely. Do not pre-emptively expose private areas or remove every security measure. The technical task is to make public product information reliably accessible. A simulated user-agent string alone does not establish that an authentic Google request succeeded.
After correction, technical retrieval and product status remain separate checkpoints. Accessibility means neither indexing nor immediate Shopping eligibility. Allow the reassessment required for this issue to take place and add its result to the existing case instead of closing it based on your own successful test.
10 · Image issues
Examine the submitted image file, not just the shop gallery
Subject, variant and technical access must all match
Open the image_link that was actually processed. Check that it returns a usable image file of the correct variant, rather than a placeholder or an HTML error page. The first image in an extensive shop gallery may be correct while the export uses a different or outdated image. Record the specific image address in the finding.
The image_link requirements cover product presentation, image quality and prohibited promotional overlays, among other things. An added discount panel differs from a brand that is genuinely part of the depicted product. Required provenance metadata must be preserved for AI-generated images. Check the relevant requirement instead of treating every visible word as an error.
Assign the defect to the appropriate owner: incorrect catalogue image selection, faulty export mapping, an unsuitable file or an inaccessible media path. These causes require different changes. A new photograph does not resolve an access restriction; an accessible file does not correct the wrong product colour.
When replacing a file, document the previous and current mapping. Check what is actually served from the saved address and whether caching still delivers the old version. Agree the technical update with the system owner rather than making tracking harder through constant address changes.
Then check affected and neighbouring variants. A repaired image rule could accidentally assign the same picture to every colour. Document the corrected variant and a comparison offer that remains correct.
11 · Policies and trust
Treat misrepresentation as a separate diagnostic branch
An account finding cannot be reduced to one footer text
If the message names a policy, read its precise scope. The misrepresentation policy covers matters including false identity or business relationships, misleading offers and missing essential purchase conditions. Serious violations can result in immediate suspension. A general list of design recommendations cannot reliably diagnose such a finding.
Instead, compare the relevant information: who sells, how can the seller be contacted, what is promised and which conditions apply? Compare the website, account information and actual purchase process. Different spellings do not automatically constitute deception; materially conflicting seller identities, however, require substantiated clarification.
Check claims about brand partnerships, authorisation or special product characteristics against available evidence. Do not add invented certificates, reviews or business details to simulate trust. If a statement cannot be substantiated, it needs to be accurately qualified or removed. The actual facts remain the foundation of the presentation.
Return, shipping and contact information must be findable, understandable and accurate in practice. Have the described procedures confirmed by the appropriate owner. Copied conditions that the business does not fulfil merely move the problem elsewhere.
Record the specific contradictions found as well as the points checked without an adverse finding. A complete factual explanation is more useful than saying “everything improved”. Where legal obligations or interpretation are involved, obtain competent advice on those specific points; a technical Merchant Center check does not settle them conclusively.
12 · Shipping and purchase terms
Check the effective conditions all the way to checkout
Product data can override a correct account setting
Start with the affected delivery country and an address that the business genuinely serves. Which shipping option, cost and delivery statement appear in the purchase journey? Compare them with the settings effective for this specific offer. A general statement that you “ship to Germany” does not explain a different rule for a particular item or region.
The documentation for the shipping attribute also describes product-level overrides. If its price sub-attribute is submitted, the matching account shipping service settings are ignored for that product, including the associated delivery times and minimum order values. Check the effective configuration, not just the account table most recently edited.
Follow a specific example up to the point before a binding order. Record the basket, delivery country, offered service and additional costs. A technical test need not create an unintended paid order. If a complete test order is necessary, use an agreed procedure with clear responsibility for payment and reversal.
For a broader shop review, use the checklist for preparing Shopify for Google Shopping. For this incident, transfer only the relevant checks into your register. The finding must explain which statement was incorrect and whether the correction was made in the shop, the data source or the account settings.
Repeat the test for a justified boundary case, such as another supported region or a different basket value. This reveals rules that happened to work for the first test only. Do not promise a shipping condition the business cannot fulfil simply to make a diagnostic field look reassuring.
13 · Automatic changes
Establish who changed the final value
Automatic assistance does not replace resolving the cause
Google describes automatic product updates that can mitigate detected discrepancies in certain offer values. They do not replace regular, accurate data submission. If a price looks correct following an automatic change, why your source submitted an incorrect price remains unresolved. Check where the final value came from before closing the case.
Distinguish these updates from accepted attribute suggestions, persistent automatic fix rules and manual product changes. These interventions can affect subsequent data submissions differently. Document the function actually used and where it can be seen. A general note saying “Google corrected it” is insufficient for the next import.
For ongoing maintenance of identifiers, titles and classifications, use the Feed Quality Register for product feed optimisation. This diagnostic issue register adds the message, scope and restored eligibility. Connect both tasks through the same offer IDs instead of creating contradictory lists without any link between them.
Test whether the agreed correction survives a new regular data run. Then check whether a temporary override is still needed or can be removed in a controlled way. Remove it only once the actual source reliably produces the correct result. Otherwise, you may restore the discrepancy it previously caught.
Record helpful automatic interventions too. They may explain why identical source values produced different results. This documentation saves a search for apparently random behaviour when the next incident occurs.
14 · Issue register
Connect the symptom, evidence and closure in one record
The table should support decisions, not merely collect tasks
Use the following structure as a register you can copy. All entries are hypothetical. For each case, add a unique case number, offer IDs, country, destination, timestamps and linked evidence in your working file. Each row describes a distinct cause; multiple affected items are linked to it without duplicating the explanation.
| Symptom and scope | Evidence | Confirmed cause | Correction and owner | Recheck | Closure criterion |
|---|---|---|---|---|---|
| Price discrepancy · Variant family | Export, page and checkout | Promotion rule missing from export | Change mapping · Feed owner | New run and same variants | Values and status match |
| Image inaccessible · Media path | URL and technical response | Public file blocked | Correct access · Web team | File retrieval and reassessment | Image accessible, finding resolved |
| Incorrect availability · One size | Selection and stock log | Variant mapped incorrectly | Correct mapping · Shop team | Follow a stock change | Correct status persists |
| Account finding · Seller details | Message and page comparison | Not yet established | Clarify facts · Business | Only after documented clarification | No premature closure |
| Error returns after import | Two data runs | Source overwrites repair | Correct authoritative field · Data team | Subsequent run and comparison item | No recurrence |
Separate the work status from Google's decision. “Technically corrected” can be true while “review in progress” still applies. Only a successful status check in the correct context closes the eligibility task. If ads do not subsequently appear, start a new delivery investigation; do not overwrite the closed finding with a different question.
Every open row needs a next action: “waiting” needs an expected review step and a follow-up date; “support” needs a precise question and evidence. This distinguishes missing information, ongoing reviews and outstanding changes.
15 · Requesting another review
Request a review only after a verified correction
Resolving an issue and making a reasoned appeal are different routes
The instructions for requesting a review distinguish fixing an issue from disagreeing with the finding. Use the appropriate function offered in the account. Some cases first require additional steps, such as requested identity verification. If the button is unavailable, check ongoing proceedings, data source prerequisites and any applicable waiting period as well.
Before requesting a review, your case should contain a short, verifiable explanation: which message was affected, what you established, where you corrected the cause and what the recheck found. If you disagree, explain instead which substantiated facts make the decision incorrect in your view. Rejecting the finding without evidence does not make the explanation stronger.
Google documents a review period of up to seven business days; this is not a promise of reinstatement for your case. A review is also distinct from initial data processing or a single crawl. Record the status visible in the account and the request date instead of combining different time references into a fixed deadline.
You may have only one opportunity to disagree. Unsuccessful attempts can lead to waiting periods that may become longer; Google support cannot shorten them. Use such a period to check the facts again. Repeated clicking, a new account or an empty data source are not dependable alternatives to the prescribed process.
Keep changes traceable during the review. Urgent inaccuracies still need correcting, but a simultaneous complete redesign makes assessment more difficult. When requesting assistance, provide the case number, context and relevant evidence through the designated secure channel and ask a clearly bounded question.
16 · Verify restored eligibility
Close the case using the same offers
Fewer error messages may simply mean that products disappeared
After processing or review, compare the same offer IDs in the same country and destination. Check that the products are still included in the intended assortment. A falling error count is insufficient: deletion, a different selection or a changed filter could explain it. Document factual correctness and the visible system state separately.
| Checkpoint | Comparison basis | Passes when | Reopen when | Evidence |
|---|---|---|---|---|
| Data value | Originally affected IDs | Correct value processed | Old value returns | Export and time |
| Website | Same variant and URL | Purchase offer matches | Selection or condition contradicts it | Test record |
| Product status | Same country and destination | Relevant finding resolved | Disapproval remains or changes | Status and message |
| Account status | Same account finding | Relevant restriction lifted | Account issue persists | Decision in the account |
| Subsequent run | Next regular import | Correction remains stable | Error returns | Version and owner |
If the disapproval has disappeared but ads are not running, investigate the new question separately: are the products used in the intended campaign, and what restrictions exist there? Merchant Center eligibility alone guarantees neither impressions nor clicks. Do not change the verified product data again simply because the commercial effect has not yet appeared.
After closing the case, agree a suitable routine for recurring causes. A repaired mapping needs checking when connectors change; a price issue needs attention during promotions; a website issue needs checking after relevant releases. Frequency depends on actual business changes, not a universal mandatory daily schedule.
17 · Frequently asked questions
Answers to common uncertainties during an incident
Does a warning mean all products are suspended?
No. Read the level, destination and affected offers. A warning deserves attention, but does not automatically equal an account suspension. The specific message determines which correction is needed.
Why is the shop price correct while the item remains disapproved?
A different variant, an older dataset or a conflicting machine-readable value may be involved. Check the same item from the processed record through to checkout, and record the relevant times.
Can I solve GTIN issues with invented numbers?
No. Establish the correct identifier and the applicable attribute requirement. An unknown value is different from an identifier that is demonstrably unassigned. Document outstanding supplier questions.
Is deleting and recreating disapproved products enough?
This does not demonstrate a resolved cause. It also interrupts tracking of the same offer. Correct the actual error and verify the existing mapping unless a structural change is substantively necessary.
Why is the review button greyed out?
Check the notices about prerequisites, an ongoing review or a waiting period. Further evidence may be requested depending on the case. The actual account view governs the next step; another request is not always immediately available.
Does an automatic correction prove that the feed is healthy?
No. It can catch a discrepancy while the source continues to submit incorrect data. Check the origin of the final value and the next regular data run before marking the cause as resolved.
Can an agency guarantee reinstatement?
A sound investigation can organise findings, correct substantiated errors and prepare a review. Google makes the decision. Without access to the message and evidence, even the specific cause cannot be determined reliably.
When is the case complete?
When the cause has been demonstrably corrected, the affected offers have the required status in the correct context, and the subsequent run preserves the correction. Actual advertising delivery is then checked separately.
18 · Next step
Start with one documented issue
A traceable diagnosis provides the basis for a lasting correction
Choose a current message and preserve its exact context. Work through the diagnostic tree, compare an affected variant across the complete data path, and enter the confirmed cause in the register. If the cause remains unresolved, turn the missing information into a specific next task.
Then correct the responsible source or system and check the result again. Request a review only through the appropriate available route and after meeting its prerequisites. Close the case using the original offers, not a reassuring aggregate number. The work will remain understandable at the next import and when responsibility changes hands.
Keep the connection between message, cause and outcome documented: what was wrong, what changed, and which evidence confirms the correction? This creates a reusable review procedure.
If you would like to examine product data, your shop and account findings together and prepare the next steps systematically, Salestudia can help with Google Merchant Center setup and optimisation.