Google Merchant Center Outage: A Retailer’s Response Plan

If Google Merchant Center stops accepting updates or showing reliable account data, your first instinct may be to repair the feed, reset an integration, or pause campaigns. During a platform incident, those reactions can create a second problem inside an account that was otherwise healthy.

Your immediate job is to establish what failed, preserve evidence, protect essential commerce operations, and avoid changes that will be difficult to untangle later. Here is a practical response plan for doing that while Google’s investigation remains incomplete.

Start with what Google has and has not confirmed

The known incident window began on August 6 at 13:06 UTC. Google published its first public update at 17:46 UTC, four hours and 40 minutes later, and said it was investigating reports of a Merchant Center problem. At that point, Google had not disclosed the root cause, the affected features, the size of the impact, or an estimated restoration time.

That distinction matters. Acknowledgment of a Merchant Center incident supports the conclusion that at least some failures may be platform-side. It does not prove that every account, feed, product, country, interface, or connected campaign is affected. It also does not prove that an account-level error appearing during the same period was caused by the incident.

The potential exposure is meaningful because merchants use Merchant Center to manage product information for Google Shopping, Performance Max, and free product listings. But potential exposure is not confirmed impact. Until the affected functions are identified, describe what you can observe rather than declaring that listings or campaigns are universally down.

Key takeaways

• Use August 6 at 13:06 UTC as the start of the known incident window when comparing errors, sync logs, and account changes.
• Treat Google’s acknowledgment as evidence of a platform incident, not proof that every Merchant Center anomaly has the same cause.
• Preserve failed requests, error messages, timestamps, and intended catalog changes before retrying anything.
• Avoid deleting feeds, replacing the full catalog, rebuilding integrations, or broadly pausing campaigns without evidence that the action is necessary.
• Validate the source catalog, storefront, Merchant Center state, and campaign outcomes separately; one healthy or unhealthy layer does not establish the state of the others.
• After service appears to return, test a small reversible operation before releasing a backlog of product updates.

Separate a platform outage from an account problem

A status notice gives you context, but your own operational evidence tells you what happened to your business. Build a short incident record before anyone starts changing settings.

1. Record the first observed failure in UTC. Include the Merchant Center account, the user or integration involved, the attempted action, the affected products or feed, and the exact error text.
2. Preserve evidence. Save screenshots, export available logs, and retain copies of any files or requests that failed. Do not rely on someone remembering the message after the interface changes.
3. Find the last known successful operation. Compare its timestamp with the 13:06 UTC incident start. A cluster of failures after that time supports a platform explanation, although it does not prove one.
4. Check for changes that began outside the incident window. Recent access changes, expired credentials, malformed source data, integration deployments, or catalog edits can still produce independent failures during a wider outage.
5. Compare more than one signal. If a scheduled feed job failed, determine whether the source file was created correctly, whether the request reached Google, and whether the storefront still contains the intended price and availability.
6. Use read-only checks first. If a write test becomes necessary, make one already-intended, reversible change to a low-risk item and document it. Do not use the entire catalog as a test payload.

This process prevents a common diagnostic mistake: seeing two events at the same time and assuming one caused the other. The incident may explain an error, but timing, logs, and repeatable behavior should carry more weight than coincidence alone.

Protect sales without making the account harder to recover

Merchant Center sits between several operational layers. Your source catalog can be correct while an update fails to reach Google. Merchant Center can accept product data while a campaign has a separate delivery problem. Your website can remain accurate while an external commerce surface displays older information. Check each layer on its own terms.

• Keep the storefront accurate. Continue correcting prices, availability, and product details in the system that normally owns those values. If delivery to Merchant Center fails, queue the intended changes with timestamps so they can be reconciled later.
• Preserve the normal source of truth. Do not create an improvised second catalog merely to work around an unconfirmed failure. Competing sources can leave your team unsure which values should survive after recovery.
• Do not rewrite Product structured data just because Merchant Center is having trouble. Change website markup only when an independent validation shows that the markup or visible page content is wrong. A platform outage is not evidence of a schema defect.
• Inspect actual campaign outcomes before changing budgets or pausing Performance Max. A Merchant Center error may affect campaign operations, but the scope was not confirmed. Broadly pausing healthy activity can suppress valid demand; leaving uncontrolled spend running can also create exposure. Follow your normal spend guardrails and escalate if campaign controls are unavailable or the potential exposure exceeds your authority.
• Record manual interventions. Note who changed what, when it changed, why it was necessary, and how to reverse it. That log becomes the recovery checklist when Google restores affected functions.

Be especially careful with full-feed uploads and repeated retries. An automated integration may already be configured to retry failed work. Adding manual submissions without checking that behavior can create duplicate effort, obscure the original failure, or send older catalog data after a newer update.

Your internal update should also preserve uncertainty. A useful note has four fields: what is confirmed, what users are observing, what remains unknown, and when the next review will happen. For example, say that Google acknowledged a Merchant Center incident and that your team observed failed product updates after a recorded time. Do not say that all listings disappeared unless you have verified that outcome.

Verify recovery in stages before clearing the backlog

An interface loading successfully is not enough to declare recovery. The failing operation may still be unavailable, delayed, or returning inconsistent results. Use a staged check that limits the consequences of a false recovery signal.

1. Review the latest public incident update and record the time. Keep Google’s status timeline separate from the time your own account begins behaving normally.
2. Repeat the same read-only checks used during diagnosis. Confirm that account data, product records, and recent processing information are available where expected.
3. Retry one failed, reversible operation. Use the original intended data rather than inventing a new test change.
4. Confirm the result at the destination. A successful submission message does not by itself prove that the intended product state is visible or usable.
5. Release queued work in controlled batches. Start with time-sensitive price and availability changes, then reconcile less urgent catalog edits.
6. Check for stale, missing, or duplicated work. Compare the final Merchant Center state with the source catalog instead of assuming every automated retry completed correctly.
7. Review campaign delivery and spend independently. Product processing may recover before every connected workflow returns to normal, or campaign performance may have a separate cause.
8. Close the incident only after documenting the affected period, verified impact, interventions, unresolved items, and any follow-up controls your team needs.

Do not force a root-cause conclusion before Google provides one. Your internal review can still identify useful weaknesses: missing integration logs, unclear feed ownership, no queue for failed updates, excessive permissions, or a recovery process that depends on one person. Those are improvements you can make without pretending to know what caused the platform incident.

For now, anchor your decisions to timestamps and observed behavior. Preserve the catalog state you trust, make the smallest reversible intervention available, and require a successful end-to-end test before normal processing resumes.

References

• Search Engine Land — Google investigates Merchant Center outage