Google Merchant Center: how to set up a feed so products are not disapproved

Google Merchant Center is a free Google account where a store submits data about its products: title, price, availability, images, page URL. From this data Google builds product listings for the Shopping tab and for ads with an image and a price. The account itself sells and shows nothing: it takes in the catalog, checks it and tells you which items can be shown and which cannot.

That is why setting up Merchant Center is mostly work with data. The account takes an evening to create. A feed where the price matches the page, every product has a valid identifier and every link leads to exactly its own product takes longer to build, and that feed is the reason products get disapproved.

Below is the order of steps, from an empty account to connected ads. Section names in your account may differ: Google updates the interface regularly. The logic has stayed the same for years: the data in the feed must match what the shopper sees on the site.

What Merchant Center gives a store

You need the account in three situations.

Shopping campaigns in Google Ads. Ads with an image, title, price and store name, next to or above the regular search results. There are no keywords here: Google matches the query to the title, category and attributes of the product from the feed. Without Merchant Center these campaigns cannot run at all.

Performance Max. A campaign that shows products across several Google channels at once. Its product part takes data from the same feed.

Free listings. Depending on the country and category, Google may show products from the account without any cost per click. What is available for your market is shown in the account’s programs or channels section; check it right after signing up, and do not build any forecasts on it in advance.

You do not need the account if you sell services or do not plan to advertise products: a feed nobody reads will just sit there.

Before you sign up: what the site must have

Google checks not only the products but the store itself. Without these, problems appear at the level of the whole account:

• Contact details on the site: phone, email, address or at least some way to get in touch.
• Published shipping and return policies. On a separate page, not as one sentence in the footer. The shipping and return settings in the account must match what the site says.
• A working cart and checkout. A product that cannot be bought is not a product for Google.
• HTTPS on every page the feed links to.

Step 1. The account and website verification

Register the account under the company’s Google account, not the personal email of an employee who may leave. Fill in the store name, country and website URL.

Next comes verifying ownership of the site. Google offers several methods: a meta tag in the homepage code, an HTML file in the site root, or an already connected Google Analytics, Tag Manager or Search Console. The easiest case is when Search Console is already set up under the same Google account: verification goes through without any changes to the site.

In our experience, some versions of the account also require you to “claim” the site for the account as a separate action after verification. It sometimes gets skipped: the site is verified, but products are not accepted. So after this step, check that the website status in the settings is the one the account considers complete.

In the same settings section you fill in shipping and returns. An error here sits at the level of the whole catalog, so check right away that the shipping cost and delivery times in the account are the same as in the cart on the site.

Step 2. Where the account gets products from

There are several ways to submit the catalog, and the choice depends on the size of the store and how fast prices and stock change.

A file at a URL. The store generates XML (or a delimited text file), and the account fetches it on a schedule. The most common option for OpenCart, WooCommerce and similar platforms: there is an export module for almost every one of them.

Google Sheets. For a few dozen items that rarely change.

Automatic collection from the website. Google can collect products from the pages itself if the product pages carry product markup. A quick start, but less control: the feed gets whatever the crawler found and however it understood it.

API. For large catalogs and frequent price updates; this is a developer’s job.

For most stores, the working option is an XML file on a schedule. The main question here is not the format but where the module takes its data from. The right source is the store’s database. The wrong one is a sitemap or third-party exports that live a life of their own. In a cosmetics store we measured on July 31, 2026, a working sitemap with 3,947 products sat next to an outdated one: 2,706 products, and almost every URL in the old sitemap (2,454 of 2,755 unique ones) was repeated three times. A feed built from it would have missed about 1,240 items and brought in duplicates.

Step 3. Required attributes

The minimum set without which an item will not pass has been stable for years:

For some categories Google requires more. The best-known example is apparel and shoes: size, color, gender and age group must be separate values. “Black dress XL” is a title for the system, not three attributes. If this data lives only inside the title in your catalog, the feed is formally filled in, but the items do not pass.

It is worth filling in the optional fields that affect where the product is shown: the category from Google’s product taxonomy, condition (new, used), and the sale price as a separate field rather than a replacement for the main one.

A simplified item in an XML feed (the numbers are illustrative):

<item>
  <g:id>SKU-10482</g:id>
  <g:title>Bypass pruner 20 cm</g:title>
  <g:link>https://example.com.ua/sekator-ploshchynnyi-20</g:link>
  <g:image_link>https://example.com.ua/img/10482.jpg</g:image_link>
  <g:price>1290.00 UAH</g:price>
  <g:sale_price>1090.00 UAH</g:sale_price>
  <g:availability>in_stock</g:availability>
  <g:brand>BrandName</g:brand>
  <g:mpn>PR-20</g:mpn>
</item>

Step 4. Identifiers: GTIN, MPN, brand

Two different identifiers get mixed up here.

id is your internal one. You make it up, and the main requirement is stability. The best source is the SKU from the database. If the id is built from the page URL or a sequence number, then after the URL changes the product is read as new, and its impression and click statistics start from zero.

gtin is the manufacturer’s international code, the one under the barcode (EAN, UPC). It is not made up: either the manufacturer assigned it to the product or it does not exist. For branded products Google expects exactly this code, and in categories where a GTIN is required, an item without one is disapproved, while in others its reach is limited. In a lingerie store we measured on August 1, 2026, the product page markup carried an EAN-format code: with data like that, the feed comes together without questions.

mpn is the manufacturer’s model code. It is used when there is no GTIN.

brand is the manufacturer’s name, not the name of your store. Putting your own store as the brand for every product is a common mistake, and the account notices it.

If a product really has neither a GTIN nor an MPN (handmade, your own production, made to order), there is the identifier_exists attribute with the value “no”. Setting it in bulk on the whole catalog to get rid of a warning is a bad idea: for branded products this is a mismatch the system sees.

Step 5. Price and availability: the feed and the product page must say the same thing

The most common warning in the account is a price or availability mismatch. Google compares the feed not with your database but with what it sees on the product page. If the amount there is different, the item is stopped, even when the database has one price.

The usual sources of mismatch:

• a sale price that the page shows but the feed does not send;
• a discount applied only in the cart or only for logged-in users;
• different prices or currencies in the language versions of the site;
• the feed updates once a day while stock moves every hour.

This is not fixed in the account. The price on the page, in the product markup and in the feed must come from one database field. As soon as it is duplicated by hand somewhere, it will drift apart; the only question is when.

Product markup on the page works as confirmation here: the page tells the machine what the price is and whether the product is in stock. We covered it in detail in “The product page through Google’s eyes”, so we will not repeat it here. For the feed, one thing matters: without markup, Google has to compare the feed data with the page “by eye”. In a garden equipment store with 55,321 product URLs, on July 31, 2026, we did not find a single Product block on the site, and for a catalog like that this is the very first item in the work plan.

The account has a feature that automatically updates price and availability based on the page data. It is useful as insurance, not as a solution: the mismatch remains, it just gets patched after the fact.

Why products get disapproved: the causes we see most often

Besides price, there are a few other typical sources.

The link leads to the wrong product. The costliest and least visible error. In the lingerie store we took 150 random product URLs from the sitemap: 50 of them, a third, returned a redirect, and all 50 led to a different size or color. For the feed this means outright disapproval, and for the shopper it is a paid click that lands on a page for the wrong product.

Images. A placeholder instead of a photo, watermarks, overlaid “sale” text, too low a resolution. Such items are usually disapproved in groups: one error in the image template means hundreds of products.

Empty or identical descriptions and titles. One text for a whole product line, the category name instead of the product name.

Missing category attributes. Apparel and shoes without size, color or gender as separate fields.

Products prohibited or restricted by the policies. Google does not accept some categories at all, and others have special conditions. This is not fixed by editing the feed, only by deciding what not to include in it.

How to read the Diagnostics report

The account shows issues at two levels. The account level covers website verification, shipping, returns and policies. While there is an error there, issues with individual products are secondary. The product level is a list of reasons and the number of items for each.

The list can run to thousands of rows, and it is easy to be scared by it. It is more useful to count not the number of messages but the share of the catalog for each reason. One reason covering 60% of products and forty reasons covering the rest are different tasks with different time costs. A long report usually comes down to a few sources, and each of them is one error in a template or module that gets replicated across the whole catalog.

Then each bulk reason has to be assigned to one of two fixes.

A feed rule in the account. It changes the data on input without touching the site: add a brand, fill in a category from a pattern, drop items with a zero price. It takes effect from the next fetch, that is, within hours. But it does not fix mismatches with the page and does not cure links to another product. And it lives only in this account: it will not get into feeds for other marketplaces.

A fix in the catalog. Slower, but it corrects the data itself and applies to every export at once. The difference shows when the same catalog also goes to Rozetka: the marketplace has its own list of required fields, and when we checked 21 public feeds against Rozetka’s requirements on 5 September 2026, product attributes were missing in 15 of them and the brand in 12.

There are also supplemental data sources: a file on top of the primary one that adds or replaces individual fields. Handy when editing the database takes long. One trap: a supplemental source is matched to the primary one by id. If the primary one takes it from the SKU and the supplemental one from the page URL, the update will not apply at all, and the account will show no error, just zero changed items.

For more on how we break down the report and build a feed for a specific catalog, see the page on setting up Merchant Center and the feed. The technical side (catalog data, product page markup, the source of URLs) is described separately in Google Merchant integration.

Linking to Google Ads

Once the feed is accepted, Merchant Center is linked to the ads account: a link request is sent from one account and approved in the other. After that, products become available for Shopping campaigns and Performance Max in Google Ads.

The product title in the feed works in place of a keyword. If the title is “Model 4521-B black” and people search for “black laptop backpack”, the product will barely appear for that query.

Product identifiers in the feed and in the analytics events on the site must match. Otherwise dynamic remarketing does not build audiences: the system cannot tie a viewed product to an item in the feed.

If campaigns are already running, do not pause them to rebuild the feed. First put the part that passes review into the feed, then add the rest in batches.

The order we recommend

1. The site: contacts, shipping and return policies, a working cart, HTTPS.
2. An account under the company’s Google account, verifying and claiming the site, shipping and returns in the settings.
3. Checking the data before building the feed: is there a SKU, GTIN, brand, do prices on the page and in the database match, do links lead to their own products.
4. The first feed not for the whole catalog but for one category with a few hundred items. Bulk defects are visible even on a sample like that, and fixing them there is many times easier than on tens of thousands of rows.
5. The first fetch, reviewing Diagnostics, fixing the bulk reasons.
6. The rest of the catalog in batches, with an update schedule matched to how fast your stock moves.
7. Linking to Google Ads and launching campaigns.

What Merchant Center will not give you

An accepted feed means the products can be shown. Nothing more. Whether they will be shown and whether they will be bought depends on the price relative to competitors, shipping terms, the campaign budget and the assortment itself. The feed does not make the price competitive and does not replace an ads account that someone manages.

A clean report today does not guarantee a clean report a month from now: the catalog changes, promotions come and go. That is why it is more useful to have one data source for the page, the markup and the feed than to sort through a thousand-row report once a quarter.

If the feed is already connected and the account shows disapprovals, start with a free review of the feed and the disapproval report: we split the report into bulk and one-off reasons and tell you what share of the catalog will pass without changes. We reply within two hours and work under a contract.