Route the Merchant Center issue at the level it actually affects

Classify the notice before estimating its impact

Google distinguishes individual product issues from setup and policy issues affecting the account. Its guidance also distinguishes warnings from disapprovals and suspensions. Use the current notice to determine the actual restriction; do not infer scope from a red icon or from a decline in impressions alone.

Create one incident record containing the issue wording, detection time, affected destination and country, representative item IDs, and any stated review deadline. Preserve the notice before changing data. An internal category such as urgent is useful for routing work, but it is not a substitute for the platform's status. Keep confirmed restrictions separate from estimated lost demand. A campaign forecast cannot prove which items Google currently considers eligible.

Trace the defect to the system that owns it

Inspect several affected records, including a high-volume item and an apparently ordinary one. Compare their submitted values, processed product details and customer-visible pages. Look for shared supplier, template, export job or country settings. A cluster can reveal a faulty transformation even when the displayed examples look unrelated.

Assign the fix to the team that owns the underlying fact or rule. Catalog operations can correct an export mapping; a policy or business-identity concern may need a different accountable owner. Record which systems will reproduce the bad value if only the Merchant Center interface is edited. Do not make a convenient local correction that the next scheduled import silently reverses.

Repair the affected class, then assemble review evidence

Define a testable repair statement: which field or website condition was wrong, what changed, and how the team checked related items. Test the transformation on a copy or limited sample before a broad release. Keep item identifiers stable unless the actual identity model requires a separately reviewed migration.

Have someone other than the implementer inspect the corrected examples and a small unaffected control set. This catches repairs that remove one error while changing valid records. Where the account offers a review or appeal route, follow the current instructions and submit only supportable explanations. Do not repeatedly request review while the evidence still shows the original problem. Keep any notice-specific deadline visible to the owner.

Close on observed status, not on a successful upload

A completed upload proves transport, not recovery. Check the processed product data and the current issue state after the relevant processing or review interval. Record submission time, platform response and unresolved exceptions separately. If an item remains restricted, compare the new evidence with the same issue rather than declaring a second unrelated outage.

Report operational recovery and commercial recovery separately. The catalog may become eligible while impressions remain low for auction, budget or demand reasons. Conversely, a few impressions do not establish that every affected item recovered. Close the incident when its stated verification gate is met, and leave any remaining campaign investigation with its own owner and evidence.

Make the reasoning concrete.

A fictional cookware merchant sees 40 items with incorrect identifiers and a separate account warning about inconsistent business information. The media team asks for a single bulk re-upload.

The team maintains two verification gates. Corrected item data is checked independently of the account review; neither is reported as complete merely because the upload succeeds.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Scope

   Which items, destinations and countries does the notice actually name?

2. Evidence

   What did the notice and processed data show before repair?

3. Owner

   Which system and person can remove the underlying cause?

4. Gate

   What observable status will establish recovery?

5. Deadline

   Does the notice specify a deadline or review restriction?

Watch for the wrong conclusion.

• Treating every warning as an account suspension.
• Changing bids to solve a data-quality restriction.
• Closing the incident at upload completion.

Sources & scope

Workflows, worksheets and fictional examples are original editorial analysis, not Google instructions or measured business results. Sources support only the specifically attributed platform facts. Platform controls and eligibility can change; verify current account guidance before implementation.

• Google Merchant Center: Issues in Merchant Center →Primary platform documentation · Supports: Supports the distinction between product-level issues, account setup and policy issues, warnings, disapprovals and suspensions. The incident workflow is original editorial analysis.