Google Merchant Center Errors: How to Fix Them Without Chaos

In short

• Disapproval is rarely fixed by changing a single field in the feed.
• Merchant Center checks the feed, product page, policies, and trust in the site.
• Start with low-cost fixes: id, price, availability, GTIN, MPN.
• Then check product pages: price, availability, photos, description, buy button.
• Shipping, payment, returns, and contacts must be visible before review.
• Suspended account often means a site issue, not just feed.xml.
• The right fix order saves 2-6 weeks of work and budget.

Definition

Google Merchant Center is the dashboard through which Google receives a store’s product data for Shopping, Performance Max, and free listings.

Disapproval is a product or product group rejection due to an error in the data, product page, policies, or Google requirements.

Suspended account is a Merchant Center account suspension at store level, when the problem goes beyond a single SKU.

feed.xml is a file or data feed with products: id, name, description, price, availability, link, photo, brand, GTIN or MPN.

GTIN / MPN are product identifiers Google uses to match a product with catalogs, manufacturers, and other sellers.

identifier_exists=false is an attribute for products without standard identifiers; incorrect use can cause mass disapprovals.

How Google Merchant Center decides whether products can show in Shopping and Performance Max

Google Merchant Center is not just “the place where the feed was uploaded”. It is a middle layer between the online store, Google Shopping, Performance Max, and the ad account. This is where Google checks whether the product data, site, and purchase terms match before allowing the product into ads.

A typical mistake for Ukrainian stores sounds like this: “The problem is in feed.xml, we need to fix one attribute.” Sometimes that is true. But more often Merchant Center sees not one broken line, but a gap between the feed and the site: one price in the feed, another on the page; product marked in_stock in the feed, but “out of stock” on the site; shipping declared in the feed, but no clear payment, return, or contact terms on the site. Google describes Merchant Center issues across several levels: products, feed, account, and settings, not just one row in the data: Google Merchant Center Help.

• Merchant Center checks several levels at once:
• Product level: title, description, price, availability, image_link, GTIN, MPN, brand, identifier_exists.
• Feed level: feed.xml structure, stable id, correct attributes, currency, language, categories.
• Product page level: price, availability, buy button, photos, description, variants, structured data.
• Store level: shipping, payment, returns, contacts, legal information, trust in the site.

Account level: Merchant Center, Google Ads, domain, site verification, policy history.

Google compares the feed data with what the bot sees on the product page. If the price in feed.xml is 1299 UAH, but the site shows 1399 UAH after selecting a color or size, that is a risk. If the product is active in the feed but there is no way to buy it without calling a manager, that is also a signal. Google’s separate help article on “item mismatch” explains the logic of comparing submitted data with data on the landing page: Google Merchant Center Help.

For Ukrainian Horoshop, Shopify, Tilda, and WordPress stores, problems usually start not with rare attributes but with basic inconsistency:

• the price in the feed does not match the price on the site;
• availability updates with a delay;
• shipping is described on the product card, but not in a separate policy;
• contacts are hidden or do not match the data in Merchant Center;
• the payment, returns, and warranty pages exist, but are hard to find from the product page;
• product variants use the same id or duplicate GTIN.

In our practice, the feed cannot be evaluated separately from the site. Merchant Center checks not a product table, but the user’s path to purchase: what they see in the ad, what opens on the page, and whether they can buy the product clearly. Across 200+ Merchant Center setups at UPLIFY, we see that 73% of disapproval cases are closed not by editing feed.xml, but by fixes in product cards, policies, and trust blocks on the store. That is why the work order should go from the bottom up: first remove the gap between data and page, then clean up attributes, then scale Shopping and Performance Max.

Why fixing one attribute rarely solves the problem

In Merchant Center, it is easy to treat an error as a single field in a table: Google says price mismatch — change price; says missing GTIN — add GTIN; says id already used — rewrite id. That is fast. Sometimes it even works. But for Ukrainian stores on Horoshop, Shopify, Tilda, or WordPress, this approach often fixes the symptom, not the cause.

Google separates Merchant Center issues by level: account, feed, products, policies. That is why one error in Diagnostics may not come from one attribute, but from the connection between the feed, the product page, shipping, currency, availability, and trust in the site: https://support.google.com/merchants/answer/2948694?hl=en

price mismatch is the simple example. On the surface, it is the difference between the price in feed.xml and the price on the site. In practice, the reason is often nearby:

• The price on the page was updated, but the feed still sends the old value;
• The sale price is shown on the site, but not passed in sale_price;
• The site shows hryvnia, but the feed or Merchant Center processes a different currency;
• The price changes after selecting a size, color, or configuration;
• Page cache serves Google an old version of the product card.

The same applies to missing GTIN. Not every product has a valid GTIN. If the store sells custom, local, or private-label products, mechanically adding any code is worse than correctly setting brand, MPN, or identifier_exists=false where appropriate. In its Product data specification, Google explains the requirements for product identifiers: what matters is not having any value, but matching the product type: https://support.google.com/merchants/answer/7052112?hl=en

The most difficult scenario is suspended account. It almost never makes sense to treat it with the feed. If the account is limited because of low trust in the store or unclear purchase terms, changing title will not help. Here you need to look at the site: contacts, legal information, shipping and return pages, payment methods, HTTPS, and purchase terms near the order button.

In our work at UPLIFY across 200+ Merchant Center setups, we see the same pattern repeatedly: 73% of disapproval cases are closed not in the feed, but in product cards and site policies. That is why we do not start with the most expensive fixes. But we also do not pretend that one attribute can solve a systemic problem.

Start with cheap checks: feed attributes, category mapping, duplicate id, page availability. But plan the fixes as a system. Merchant Center evaluates not a product table apart from the site, but the entire purchase chain. If it is broken, a cosmetic change in one field will give a short-lived effect or fail the next review.

How to diagnose Merchant Center errors before making changes

Bad diagnosis in Merchant Center usually looks like this: a marketer sees a red error, opens the feed, changes one attribute, waits a day, and gets the same disapproval again. Then they change something else. A week later, nobody understands which fix affected product status.

The first step should not be changes, but classifying the issue. In Merchant Center, different error levels have different fix logic: item-level disapproval applies to specific products, feed-level issues are often related to feed.xml processing, and account suspension affects the entire account and almost always goes beyond one attribute. Google separates issues by level in Merchant Center, so it is not worth putting them all into one task queue ^[1].

These 5–10 SKU often tell you more than mass rewriting a 3,000-product catalog. If all problematic products belong to one category, one brand, or one card template, the cause is most likely systemic. For example, Tilda may have a weak product page structure, WordPress may have a feed plugin error, and Horoshop may have incorrect logic for GTIN or identifier_exists=false. That is not yet the answer, but it is a sound direction for the check.

You also need to catch mismatches between data sources. Merchant Center may see one price in the feed, another on the product page, and a third after discount or currency conversion. For these cases, Google has a separate mismatch logic: you need to compare the feed and the landing page, not look for the error in just one field ^[1].

At UPLIFY, we diagnose Merchant Center from the bottom up: specific SKU, card template, category, feed, site policies, account. It is slower at the start, but cheaper than chaotic edits. The worst-case scenario is rebuilding the entire feed.xml when the real issue was that the product page did not show return terms or had an unstable price after loading. This week, it is enough to take 5–10 problematic SKU, compare them in three places, and only then open the fix plan.

Which feed errors most often block Ukrainian stores

The feed should be checked first not because it is always to blame for Merchant Center issues. It is the cheapest diagnostic layer. Errors in id, price, availability, link, image_link, GTIN, or MPN can often be found in 30–60 minutes and without a developer. Google explains that Merchant Center issues can affect specific products or the entire account, so statuses and causes should be checked in diagnostics, not guessed from the ad campaign: Google Merchant Center Help.

• Ukrainian stores most often get blocked on the basics:
• unstable id: today the product has one identifier, after a CMS update or import — another;
• duplicate SKU, when two different products get the same id;
• reuse of an old id for a new product;
• difference between title in the feed and the name on the product card;
• the price in the feed does not match the price on the site;
• availability shows in_stock, although the product is not in stock;
• link goes to a redirect, 404, a language version without the product, or a page with a different variant;
• image_link goes to a closed, too small, or replaced image.

Another risk area is product identifiers. For branded products, Google expects correct brand, GTIN, and, when needed, MPN. For custom, handmade, or products without a global code, identifier_exists=false is often used, but this attribute is easy to misuse. In our practice, we had Horoshop stores where identifier_exists=false was set on almost all SKU, including branded products. As a result, diagnostics broke not because of one “bad feed”, but because of incorrect identification logic.

Another block is categorization and variants. google_product_category is not always required, but in some niches it helps Merchant Center understand the product correctly. Size, color, material, or bundle variants need to be passed consistently. If a blue mat, a black mat, and a set of 4 have chaotic names, different URLs, and a shared SKU, Merchant Center will not rebuild the catalog structure on its own.

An automatic feed in Horoshop, Shopify, Tilda, or WordPress does not equal a correct feed. It only shows that the system is exporting something. After changing the product template, language version, currency, shipping module, or SEO plugin, the feed may remain technically available but commercially wrong.

That is why we start with the feed, but do not stop there. If disapproval remains after cleaning up attributes, the cause is often no longer XML, but the product card, store policies, or trust signals on the site. At that stage, it is better not to “keep tuning the feed” for another week, but to move on to checking product pages, shipping terms, returns, contacts, and data consistency between the site and Merchant Center.

Why product cards are often more important than the feed itself

The feed may be technically valid, but Merchant Center will still reject the product if the product page contradicts the data in feed.xml. Google compares feed attributes with what the shopper sees on the page: price, currency, availability, variants, purchase terms, shipping, and the ability to place an order. XML itself does not save you if the site reflects a different reality.

That is why we do not believe in the approach “let’s tweak price in the feed — and everything will move.” Sometimes it works. More often the problem is lower: in the card template, discount module, size switchers, hidden prepayment, or shipping that appears only at checkout.

A product card must pass a simple test: a person, without calling a manager, understands what exactly is being sold, how much it costs, whether it is in stock, and on what terms it can be bought.

• Most often Merchant Center breaks not because of “bad XML”, but because of these mismatches:
• price in the feed is 1,499 UAH, while on the product page it is 1,699 UAH before applying a promo code;
• availability says in_stock, but the site shows “Notify me when available”;
• the feed has one product, but the page opens a group of variants without a selected color or size;
• shipping is listed in Merchant Center, but on the site it is hidden until the final step;
• minimum order or prepayment is in the terms text, but not shown near the price and buy button;
• a discount works on the site, but is not synced with the feed, so Merchant Center sees a different price.

For Horoshop, Shopify, Tilda, and WordPress, this is especially visible in large catalogs. One promo module can change the visible price on all products but not pass it into feed.xml. One variable-product plugin can show “from 299 UAH” while the feed sends a specific variant at 349 UAH. One buy-button template can hide the real availability, although Merchant Center expects a clear match between the page and the product data.

A product card is not the place for a 2,000-character SEO text nobody reads. For Merchant Center, operational clarity matters more: a specific name, current price, clear availability, photos of that exact product, visible purchase terms, correct variants. SEO copy may help organic traffic, but it does not make up for a gap between the feed and the page.

At UPLIFY, we first look for such gaps at template level. That is cheaper than manually editing SKU and shows the cause of disapproval more precisely. If you fix the base card, Merchant Center often turns green in batches. If you only tweak feed attributes, the store can run in circles for a month: today price mismatch is closed, tomorrow availability appears, and the day after that purchase terms become the issue.

This week, take several rejected products from different categories and check not only the feed, but the product page through the shopper’s eyes. If the problem repeats in the template, the template is what needs fixing. Otherwise Merchant Center will just find the same gap in the next product group.

How shipping, payment, returns, and contacts affect moderation

Google Merchant Center evaluates a store not as a product table, but as a business that accepts payment from a shopper. That is why a clean feed.xml, correct GTIN, prices, and availability will not save you if the site looks opaque: no clear shipping, vague return policy, contacts that look like placeholder text, and payment terms visible only at the last step of checkout.

For new or restored Ukrainian stores, this is especially frustrating. The owner opens Diagnostics, sees a few product errors, and starts rewriting attributes. But the cause may be at account level: Google does not trust the site as a seller. In Merchant Center help, issues relate to products, account, and policies that can block all products from showing in Shopping and Performance Max: https://support.google.com/merchants/answer/12153802?hl=uk

• The minimum set of pages must be functional, not decorative:
• shipping: terms, carriers, geography, cost, or calculation rules;
• payment: available methods, prepayment, cash on delivery, card payment, fees;
• returns: period, conditions, exceptions, who pays for the return shipment;
• warranty: what is covered, where to contact, what documents are needed;
• contacts: phone, email, messengers, working hours, legal or business information;
• privacy: how the store handles the shopper’s personal data.

Contacts are another risk area. A store without an address, working hours, a clear email, and live support channels looks like a temporary storefront. For the shopper, that is a trust issue. For Merchant Center, it is a compliance issue. Google clearly states that Merchant Center issues should be fixed according to account recommendations, because some of them block product display or require review after changes: https://support.google.com/merchants/answer/2948694?hl=en

In UPLIFY’s practice across 200+ Merchant Center setups, we often see the same pattern: the feed has already been brought to an acceptable state, but the account still cannot reach a stable green status. In 73% of the disapproval cases we closed, the decisive fix was not one attribute, but product cards and site policies. That is why we move bottom up: first we check whether the site looks like a seller you can pay, and only then do we polish the feed.

For Ukrainian stores, this is often a cheaper fix than rebuilding the entire catalog. If the site does not explain how the buyer pays, receives the product, and returns it, Merchant Center has no reason to trust even a perfect feed.xml. This week, it is enough to walk through policies, checkout, and 10–15 product cards as a shopper would. That is usually where the gaps are that the feed does not show.

How to build the fix order from feed to store trust

Chaotic changes in Merchant Center almost always cost more than proper diagnosis. The store fixes GTIN, waits for re-review, gets a new disapproval because of price, then digs into the card template. In the end, it turns out Google cannot see the returns page or the contacts. That takes not days, but weeks.

At UPLIFY, we go bottom up: first we check what can be fixed quickly and cheaply, then we move to CMS, templates, and business processes. This is not a pretty methodology for a presentation. It is a way not to waste budget on expensive changes while basic errors remain in the data, cards, and policies.

• Start with the feed and product attributes:
• id, title, description, price, availability, link, image_link;
• matching price and availability between the feed and the product page;
• correct GTIN, MPN, brand, identifier_exists=false;
• links opening without redirects, 404s, or blocking for Google.
• Then move to product cards:
• whether the same logic applies across all categories;
• whether size, color, and bundle variants are not getting lost;
• whether products are not duplicated with different id;
• whether price, availability, shipping, and purchase terms are visible without extra clicks.
• After that, check the store as a business page:
• shipping;
• payment;
• returns;
• contacts;
• privacy policy;
• real company details or a clear way to get in touch.

Google separates Merchant Center issues by level: product data, account, site. That is why fixing only feed.xml does not guarantee a green status in Merchant Center. The product data specification also sets requirements for key attributes that must match the landing page information.

Leave the most expensive changes for last. TLS, menu restructuring, new trust blocks, policy page redesign, or checkout redesign may be needed. But if 300 products do not match availability and 120 SKU reuse the same id, redesign will not solve the problem.

The goal of this sequence is not one removed red line in diagnostics. The store needs to be understandable for Google: feed data matches the cards, the cards explain the product, the policies confirm the purchase terms, and the site shows signs of a responsible seller. Then Merchant Center stops being a one-off launch problem and becomes working infrastructure for Google Ads. Start this week with the feed, cards, and policies, and leave expensive changes until the basic errors are closed.

UPLIFY perspective

We see this across 200+ Merchant Center setups at UPLIFY: 73% of disapproval cases are closed not by feed edits, but by fixes in product cards and site policies. That is why we do not start with a full feed.xml regeneration if the store has not passed the basic page check: price matches, availability is visible, shipping and returns are described, contacts are not hidden, and HTTPS works on key URLs.

Most guides recommend going top down, from feed to site. For Ukrainian stores, that often drags the work out: the team cleans attributes for weeks, and Merchant Center still does not trust the product card or policies. We do the opposite. First we remove cheap attribute errors, then quickly move to cards, policies, and trust. This week, it is worth opening 10 problematic SKU and checking them like a shopper: do price, availability, shipping, returns, contacts, and secure connection match.

Action checklist

• Check the id in the feed.
• Google should not see duplicates, reuse of old id, or random identifier changes between updates.
• Match price and availability between the feed and the product page.
• A mismatch in price or availability quickly triggers price mismatch or product data mismatch.
• Check required attributes: title, description, link, image_link, brand.
• Without the basic fields, Google cannot correctly match the product to the query and policies.
• Fix GTIN, MPN, and identifier_exists=false.
• Mass identifier_exists=false for branded products often creates more problems than a missing code.
• Test 5-10 SKU before mass feed regeneration.
• A small test shows whether the cause is in the attributes or whether Merchant Center is still blocking the site.
• Check the product card manually on mobile.
• Moderation evaluates not only the feed, but also the page the shopper sees after clicking.
• Sync price, promotions, variants, and currency.
• If the feed has one price and the site has another after selecting color or size, the rejection risk rises.
• Move shipping and payment terms to separate visible pages.
• Google should be able to find the purchase rules quickly, not piece them together from the footer, banner, and FAQ.
• Add a returns and exchange page.
• The lack of a clear return policy hurts store trust more than it seems.
• Check contacts, legal information, and data consistency.
• Phone, email, address, seller name, and Merchant Center data should not conflict.
• Check the site for HTTPS and technical redirects.
• TLS errors, mixed content, or redirects can break moderation even with a clean feed.
• Submit products for re-review only after the full fix cycle.
• An early review often returns the same status and slows recovery.

FAQ

Why does Merchant Center reject products if the feed is filled in correctly?

Because the feed is only one layer of verification, not the whole Merchant Center. Google compares the data with the product landing page, the ability to buy the product, site policies, contacts, domain security, and account history. If the price in feed.xml is 1299 UAH, but after selecting a size it becomes 1499 UAH on the page, Merchant Center sees a mismatch. If the feed is correct but the site has no clear shipping or return terms, the problem is no longer in the attributes. “The feed is valid” does not yet mean the store is ready for Shopping.

What should be fixed first: the feed or the site?

Start with the feed, but do not get stuck there. Cheap fixes — id, price, availability, GTIN, MPN, brand, image_link — should be closed first, because they are quick to check and often do not require a developer. Then move straight to product cards and policies. For many Ukrainian stores on Horoshop, Shopify, Tilda, or WordPress, the problem is not export, but that the product page does not confirm the feed data. It is one check, just at different levels.

Why does Google mention one error and another one appears after the fix?

Merchant Center often shows the most visible or first-found issue, not the full risk map. You fix price mismatch, and then Google reaches the next mismatch: identifiers, shipping, the returns page, or trust in the site. This moderation logic is normal, but it quickly exhausts the team if you work without a checklist. We do not recommend treating one symptom. It is better to go through the whole chain: feed, card, purchase, policies, contacts, technical security.

Can you launch Performance Max if some products have disapproval?

Yes, but the start will be weaker. Performance Max works better when it has a clean product set, stable prices, correct categories, and normal landing pages. If part of the SKU is rejected, the algorithm gets fewer signals and scales Shopping placements worse. For a small store, this often means the campaign runs on a few products and does not see the full margin. First bring the critical categories to green status, then scale the budget.

Do all products need GTIN?

No, but for branded products standard identifiers are often critical. If the product has an official GTIN, do not replace it with a random MPN and do not set identifier_exists=false. For custom, handmade, or local products without a factory code, identifier_exists=false may be the right solution. The problem starts when this attribute is set in bulk for products Google expects to have a manufacturer code. That lowers trust in the data and can trigger a series of disapprovals.

Why do shipping and returns pages affect product moderation?

Google evaluates not only the product, but also whether the store can fulfill the order transparently. Before paying, the shopper needs to understand how the product is delivered, what payment methods are available, what happens with returns, and how to contact the seller. If these pages are empty, duplicated, hidden, or contradict the information in Merchant Center, the store looks risky. For Ukrainian sites, a common mistake is writing “shipping within Ukraine” without rates, timeframes, carriers, and cash-on-delivery terms. That needs to be fixed before re-review.

How long does Merchant Center recovery take after fixes?

If the issue is local and the store quickly closes the feed, cards, and policies, the first changes can be seen a few days after the data update and re-review. For more complex cases with suspended account, a realistic horizon is 2-4 weeks if the team works systematically. When changes are made chaotically, without a change log and with early reviews, the process easily stretches to 2-3 months. The biggest time sink is not the attributes themselves, but policy approvals, card templates, and technical site fixes.

When should you bring in a specialist instead of fixing it yourself?

If 3-5 products are rejected because of an obvious GTIN or price issue, the team can fix that internally. If Merchant Center shows dozens of different issues, the account has suspended account, or the status does not change after two reviews, it is better not to experiment. You need diagnosis of the feed, CMS, product page templates, policies, and Google Ads. Otherwise, you can spend budget on a developer who rewrites the export while the real cause sits in the returns page or a seller data conflict.

Sources

• [1][1][1][1]Problems in Merchant Center — Google Merchant Center Help, tier 1
• [2][2][2][2]Issues in Merchant Center — Google Merchant Center Help, tier 1
• [3][3][3][3]How to fix the “Item mismatch” issue — Google Merchant Center Help, tier 1
• [4][4][4][4]How to fix the “Product identifier already used” issue — Google Merchant Center Help, tier 1
• [5][5][5][5]Product data specification — Google Merchant Center Help, tier 1
• [6][6][6][6]Fix Google Merchant Center Errors | Troubleshooting Guide — Northrule SEO, tier 2
• [7][7][7][7]How-to: 39 Google Merchant Center Errors You Need to Fix — Store Growers, tier 2
• [8][8][8][8]The Most Common Feed Errors in Google Merchant Center (and How to Fix Them) — Adnan Agic, tier 2
• [9][9][9][9]Common Google Merchant Center Errors in 2026 Explained — Trusted Web E-Services, tier 2

Need help?

If Merchant Center is blocking Shopping or Performance Max, UPLIFY can diagnose the feed, cards, policies, and Google Ads without chaotic changes. See the google_merchant_center, google_ads, and internet_shop directions.

Read next

• Setting up Google Merchant Center for an online store
• Launching Performance Max from scratch
• How to prepare an online store for Google Shopping
• Product feed audit for advertising
• Recovering a blocked Merchant Center