A Google Shopping specialist yesterday described a scenario that will be familiar to many agency professionals: a client's Google Merchant Center account disappeared without warning on March 6, 2026, wiped entirely by a third-party agency that had retained access for six years and decided to close its own account - taking the client's data with it.
The incident was documented by Emmanuel Flossie, founder of FeedArmy and a Google Ads Diamond Product Expert, in a video published today on the FeedArmy YouTube channel, which counts 4,450 subscribers. The account vanished on a Thursday morning. No prior notice. No explanation visible inside the platform. Just an empty space where a functioning Merchant Center had been.
"This week I had a mini heart attack when my client's Google Merchant Center account completely disappeared out of nowhere," according to Flossie in the video description published on March 7, 2026. "No warning. No explanation. Just gone."
What actually disappears when an account closes
The implications of a Merchant Center closure extend well beyond the loss of the account itself. When an account is closed - whether intentionally by the owner or inadvertently by a third-party user with sufficient permissions - the platform wipes everything associated with it.
According to Flossie, the deleted data includes primary product feeds, all feed rules, every supplemental feed, and all third-party account linkages. That last category is broad. Google Ads connections are severed. Google Analytics links disappear. Payment platform integrations - including PayPal - are removed. In short, the entire operational stack built up around a Merchant Center account is erased as if it had never existed.
"The feed is removed, all the feed rules are removed, all the supplemental feeds are removed," according to Flossie's account of the incident. "All the account linking - Google Ads, Google Analytics, platforms like PayPal - all of that is disconnected."
For merchants running active Google Shopping campaigns, the consequences are immediate. Without a functioning Merchant Center linked to Google Ads, Shopping ads stop serving. Remarketing campaigns that depend on product feed data lose their targeting foundation. As previously reported by PPC Land, consistent product data between Merchant Center, remarketing tags, and Google Ads is the bedrock of dynamic retail advertising - when that data disappears entirely, campaigns cannot function.
The reactivation process: 24 hours and a contact form
Flossie's response was immediate. He submitted a contact form to Google requesting account reactivation, a process that involves providing three pieces of information: the applicant's name, the company they represent, and the Merchant Center account ID.
The verification step matters. According to Flossie, Google uses the email address associated with the submission to confirm who holds admin status in the affected account. This design means the reactivation request must come from an address that Google can map to an existing administrative role - not just any email.
"Most likely because it needs to come from your email address so they can identify who is admin in the Google Merchant Center account," according to Flossie. Within 24 hours of submission, the account was reactivated. Flossie describes the timeline as going to sleep, and waking to find the account restored.
But reactivation is only the beginning. The account returns as a blank canvas. Feeds must be re-uploaded. Feed rules must be recreated from scratch. Supplemental feeds require resubmission. All account links - to Google Ads, Analytics, and any connected payment or commerce platforms - must be re-established individually. Flossie's client had created and managed the product feed independently, while Flossie handled feed optimisation and Google Ads management. That division of responsibility meant the client could quickly resubmit the feed once the account was live again. Teams without that existing feed infrastructure face a more demanding reconstruction.
The root cause: a six-year-old agency that never removed itself
The cause of the outage was not a technical failure, a policy violation, or an error by the account owner. It was an agency that had managed the account approximately six years earlier, had never removed its own access after the relationship ended, and - when it apparently closed its own agency account - inadvertently triggered the closure of its client's account in the process.
This is a critical distinction. In Google Merchant Center, agencies and freelancers are added as users - admins, standard users, or super admins - to client accounts. When an agency relationship ends, the correct procedure is for the agency to remove itself as a user from the client account. It is not to close the account. Closing an account that belongs to a client, which the agency does not own, deletes the entire account history.
"You don't close down an account that you don't own - you disconnect yourself," according to Flossie. "You unsubscribe or you remove yourself from the account."
Flossie draws a clear parallel to other Google platforms. The same logic applies to Google Analytics, Google Tag Manager, and Merchant Center alike. When a client relationship concludes, the correct action is self-removal, not account closure. The consequences of getting this wrong extend beyond data loss. According to Flossie, agencies that burn bridges in this way risk negative reviews and reputational damage with no corresponding benefit.
The broader professional argument is straightforward. According to Flossie's analysis, somewhere between 70 and 80 percent of clients who leave a specialist eventually return. Specialists who retain relationships professionally, even when those relationships end, preserve that possibility. Those who close accounts or take destructive actions on exit do not.
The super admin problem: MCC accounts and uninvited privilege escalation
The incident prompted Flossie to address a second, less obvious problem specific to agencies operating Multi-Client Center (MCC) accounts. Under certain conditions - which Flossie describes as connected to the age and configuration of his MCC account and a quirk in how Google's business manager assigns roles - adding a new client can result in the agency user becoming super admin, even when the client intended to add them only as a standard admin.
This creates a structural problem. The client, who is the legitimate account owner, may find themselves unable to remove the agency user, because the agency holds super admin status and the client does not. This situation is more common than it might appear. Flossie reports encountering it with a client added approximately two months before the video was recorded - the client later discovered they could not access the business manager account fully, and Flossie found he had inadvertently become super admin.
The issue was particularly prominent during the migration from Google Merchant Center classic to Merchant Center Next. According to Flossie, whoever performed the migration frequently became the super admin, creating a broad class of accounts where agencies held the highest privilege level without having sought it. "It was more prominent when you migrated from GMC classic to next, and then whoever did the migration became the super admin," according to Flossie. "So in that case it was always me."
The practical response Flossie recommends is transparency. When this situation arises, agencies should proactively promote the client to super admin status and explain that the role assignment was the result of a Google system behaviour, not a deliberate act. The client's ownership of their own account should be restored as quickly as possible.
One caveat applies. In the current environment of Merchant Center, super admin access may genuinely be necessary for certain agency tasks. According to Flossie, brand management and the AI agent features within Merchant Center currently appear to require super admin access. He notes that this remains under active testing and that the requirement may evolve as these features develop.
Why this matters for the marketing community in 2026
The FeedArmy incident is a practical illustration of a vulnerability that exists across Merchant Center accounts managed by multiple parties over time. As Google's platform has expanded - through the Merchant Center Next rollout, the launch of the Merchant API in August 2025, and the introduction of AI agent protocols in January 2026 - the operational complexity of a single Merchant Center account has grown substantially. Feeds now power Shopping ads, AI Mode listings, Business Agent interactions, and remarketing campaigns simultaneously. Losing an account is not merely an inconvenience. It is the loss of the data foundation for multiple active advertising programmes.
The Merchant Center glossary published in December 2024 defines Multi-Client Accounts as structures designed specifically for marketplaces and agencies managing multiple accounts. The documentation acknowledges the access control system, which allows merchants to grant different permission levels to users. What it does not address is what happens when users with high permissions depart without properly removing themselves - or when they actively close accounts they do not own.
Google's October 2024 automatic linking update, which began auto-connecting Google Ads accounts to Merchant Center accounts, has increased interdependency between the two platforms. When a Merchant Center account is wiped, it does not merely affect the Merchant Center itself - it severs connections that Google itself has worked to establish automatically. Rebuilding those links after reactivation is a manual process.
The situation is further complicated by the current state of Google's Merchant Center data infrastructure. As documented by PPC Land in January 2026, automatic imports have shown delays of nine to ten days in testing, meaning merchants who rely on automated feed pipelines may not immediately detect that their product data is outdated - or missing entirely. Manual auditing of feed status, account links, and user access lists is therefore a practical necessity rather than a precautionary measure.
Flossie's account also illustrates a gap in Google Merchant Center's current user management design. There is no apparent mechanism that prevents a third-party user - even one who has not interacted with an account in years - from closing that account entirely. The platform does not appear to send warnings to account owners when a deletion is initiated by a user other than the primary owner. Whether this gap will prompt a platform change is unclear.
Practical steps following account reactivation
Based on the FeedArmy documentation, the reconstruction sequence after a Merchant Center account is reactivated from closure involves several distinct stages.
Primary product feed: The feed must be re-uploaded or reconnected, whether it originated from a file, a Google Sheet, an e-commerce platform integration, or a supplemental data source. All feed rules applied to the primary feed must be recreated manually, as they are not stored outside the account itself.
Supplemental feeds: Any supplemental feeds used to override or supplement primary feed data - such as feeds carrying performance metrics from Performance Max campaigns or custom attribute overrides - must be resubmitted individually.
Account linking: Google Ads connections, Google Analytics links, and third-party integrations must be reconnected. Each link is a separate configuration step within the Merchant Center interface. Google Ads linking, in particular, is a prerequisite for Shopping ads to resume serving.
User access audit: According to Flossie, the incident prompted an immediate audit of all existing client accounts to identify users who no longer require access. Any user without a current business need for access should be removed. This is presented not as an optional hygiene measure but as a protective step that prevents future incidents of the same type.
Super admin verification: For agencies operating through MCC accounts, Flossie recommends verifying that clients hold super admin status in their own accounts, particularly for any accounts that were either migrated from classic Merchant Center or added to an MCC with an established account age.
Timeline
- Approximately 2019-2020: An agency begins managing a client's Google Merchant Center account, gaining user access.
- September 2024: Google completes the global Merchant Center Next rollout, with agencies performing migrations frequently becoming super admin.
- October 3, 2024: Google begins automatic linking of Google Ads and Merchant Center accounts, deepening platform interdependency.
- December 23, 2024: Google publishes an extensive Merchant Center Next glossary covering MCA structures and access controls.
- January 13, 2026: Emmanuel Flossie documents nine-to-ten-day delays in Merchant Center's automatic import feature, highlighting the fragility of feed data infrastructure.
- March 6, 2026: The client's Merchant Center account disappears. The cause is identified as a former agency - dormant for approximately six years - closing its own account and triggering closure of the client's account in the process.
- March 6, 2026: Flossie submits a reactivation request to Google via contact form, providing his name, company, and the Merchant Center account ID.
- March 6-7, 2026: Within 24 hours, Google reactivates the account. The client resubmits the product feed. Feed rules, supplemental feeds, and account links require manual reconstruction.
- March 7, 2026: Flossie publishes a video on the FeedArmy YouTube channel documenting the incident, the reactivation process, and the super admin issue connected to MCC accounts.
Summary
Who: Emmanuel Flossie, founder of FeedArmy and Google Ads Diamond Product Expert, documented the incident on behalf of an unnamed client whose Google Merchant Center account was closed without warning.
What: A Google Merchant Center account was closed on March 6, 2026, by a third-party agency that had retained user access for approximately six years and closed its own account without first removing itself from the client's account. The closure deleted all product feeds, feed rules, supplemental feeds, and account links including Google Ads, Google Analytics, and PayPal. The account was reactivated within 24 hours following a contact form submission to Google.
When: The account was closed on March 6, 2026. The reactivation request was submitted the same day, and the account was restored within 24 hours. Flossie's documentation of the incident was published on March 7, 2026.
Where: The incident occurred within Google Merchant Center, a platform used globally by retailers and agencies to manage product data for Google Shopping, Google Ads, and increasingly, AI-powered commerce surfaces.
Why: The incident matters because it exposes a structural vulnerability in how Google Merchant Center handles user access management. Accounts can be closed by any user with sufficient permissions - including former agencies that have not been removed after relationships end. With Merchant Center now serving as the data foundation for Shopping ads, AI Mode listings, dynamic remarketing, and Business Agent interactions, the consequences of an unexpected account closure extend across multiple active advertising programmes simultaneously.