Merchant Center Disapprovals and Single-Source Product Data

Every store that starts sending products to shopping channels eventually meets the same screen: some products have been approved, and some sit waiting with a "disapproved" label. A disapproved product does not show up, its ad does not run, and all the preparation spent on that product goes to waste.

The first reflex is usually to fix them one at a time. The disapproved product's row is opened, the error is read, a field is filled in in the panel, and it is resubmitted. That method works for a handful of products; for a few hundred it cannot be sustained, and worse, the same error comes back with the next update. The reason is that the fix was made to the output itself, not at the place the data comes from.

The text below takes the subject under two headings: which families the reasons for disapproval fall into, and why producing product data from a single source closes most of those families on its own. Because policy texts change over time, we do not list individual policy clauses here; the link in each disapproval row leads to the policy text in force that day, and that is the final reference.

A feed file is not an export; it is a mirror of your product data

In most teams, the feed file is seen as "a file that gets sent out". The right view is the reverse: the file is a mirror of how your product data looks from the outside. A field missing from the file is missing from your product record; a price that looks inconsistent in the file is inconsistent on your site as well.

This point of view has a practical consequence. Fixing a disapproved product in the file is like writing on the surface of the mirror: the next update wipes it off. A lasting fix is made in the product record itself.

The second consequence is on the measurement side. The number of approved products is one of the most honest indicators of catalog health. If a catalog that looks fine on the site gets disapproved when it is sent out, what you are seeing is not a channel problem but a data problem.

The four families of disapproval

Disapproval reasons look crowded, but in practice they split into four families. Once the family is identified, so is the fix.

Missing or invalid field. A mandatory field is empty or not in the expected format: product identifier, brand, condition, category, image link. The fix for this family lies on the data side and is usually made in bulk — if a field is empty on one product, it is often empty on hundreds.

Mismatch. The information in the file does not match the information on the product page: the price differs, the stock status differs, the currency differs. This family is the most insidious, because each side is correct on its own terms.

Policy. The product itself, or its description, falls outside what the channel allows: restricted product groups, copy containing health or results claims, misleading wording. The fix is not data but content, and sometimes the choice of product.

Technical. The file could not be reached, the format is broken, an image link will not open, or the page is closed to crawlers. The fix for this family lies on the infrastructure side, and it usually affects the whole file rather than a single product.

When you first see the list of disapproved products, the job is not to fix them one by one but to sort the rows into these four families. The distribution across families tells you where the work is.

Price and stock mismatch: when the page and the feed drift apart

The two most common members of the mismatch family are price and stock. Both have the same source: the file carries a snapshot of one moment, while the page is live.

On the price side, three typical divergences appear. The first is timing: a promotion has started on the site but the file has not been refreshed yet. The second is scope: the price shown on the page is the promotional price, while the file is sending the list price. The third is additional items: something that appears included in the price on the page is expected as a separate field in the file.

On the stock side, the problem is usually at the variant level. Some of the product's options have sold out while the page keeps showing "in stock", or the reverse. This is a direct consequence of how the catalog is set up — if stock is not held at the lowest variant level, the information sent out cannot be correct either. How to set up variants and stock codes is discussed at length in our article on catalog and variant architecture.

The lasting fix for a mismatch is not to update more often but for both sides to be fed from the same source. Updating more often shrinks the gap; it does not remove it.

Product identifier and brand: which one for which product

Product identifier fields let the channel match your product with other products in the world. Three fields work together: the global product number assigned by the manufacturer, the manufacturer's own part number, and the brand.

The general logic is this: if a product is mass-produced by a manufacturer, it has a global number and you are expected to send it. The business does not make this number up; it is found on the packaging or in the manufacturer's product list.

For products you make yourself, handmade products or made-to-order products, there may be no such number. That is a normal situation, and channels have a separate way to declare it: you state explicitly that the product has no such identifier and use the brand and part number instead. Leaving the field blank and declaring it as "none" are not the same thing; the second is accepted, the first usually produces a disapproval.

The most common mistake in the brand field is entering the store's name as the brand. For a product sold through a dealership, the brand is the manufacturer's brand; when the store name is written in the brand field, the product is matched incorrectly.

Which fields are mandatory for which product group varies from channel to channel and over time. So the right habit is not to memorise the list but to follow the link in the disapproval row to the requirements table in force that day.

Image rules and the three items that trip people up most

Image-related disapprovals usually fall under three headings, and all three are easy to prevent.

Accessibility. The image link must open directly. An address that requires a login, passes through a redirect chain or is closed to crawlers cannot be downloaded by the channel. Checking that image addresses are open to crawling is one of the jobs to do before sending the file.

Elements added on top. Promotional badges, logos, price tags and frames placed on top of the product image are not accepted on most channels. Such images can be used on the site, but a clean product image should be kept separately for the field that is sent out.

Placeholders and quality. Placeholders of the "image coming soon" kind, images that are far too small and frames in which the product cannot be made out are disapproved. Products with variants have an extra trap: sending the same image for every variant leads to the red product being listed with the blue image, and that produces both disapprovals and returns.

Policy disapprovals: restricted products and descriptions that make claims

The policy family is different from the other three: fixing the data is not enough; you have to look at what is being sold or at what is being said.

There are two subsets. The first is the product itself: some product groups cannot be listed on shopping channels at all, and some require documents or additional approval. This is not the store's mistake but the channel's rule; seeing early that a product cannot be sold on that channel is better than chasing disapprovals for months.

The second is the description text. Health-related results claims, wording that asserts certainty, sentences claiming comparative superiority and exaggerated wording that creates urgency can produce policy disapprovals. The trap here is that the same copy looks fine on the site itself; the channel applies its own rules.

This second subset is directly tied to how product descriptions are written. Descriptions that give measurable information instead of claims, and that explain what the product is and what need it meets, cause no trouble on the policy side and are also read better by automated systems. We gave examples of how this is done in the article where we explain how product descriptions are read in AI search.

Single-source architecture: site, shopping channel and marketplace from one place

A large share of disapproval rows is closed by a single structural decision: keeping product data in one source and producing every output from that source.

In practice this means the following. The product's name, description, attributes, price, stock and images are defined in one place — usually the product record in the store's admin panel. The site page is produced from this record, the shopping channel feed is produced from this record, the marketplace file is produced from this record. No separate hand-maintained spreadsheet is kept for any channel.

The cost of separate hand-maintained spreadsheets does not show immediately. On a promotion day the price changes in the panel but not in the spreadsheet; two weeks later the disapproval list swells and nobody remembers why. The more places the same information is written separately, the higher the chance that they drift apart.

The structured data on the page should also be produced from the same source. If the page copy, the markup and the feed file all come out of the same product record, the three cannot contradict one another; if they are written separately, it is a coincidence when they do not. Where markup fits into this whole is discussed in our article on structured data and trust signals.

Can the marketplace file and the shopping channel feed be the same file

The short answer: they are produced from the same source, but they are not the same file.

Every channel has its own field names, mandatory fields, category vocabulary and formatting rules. The category code one expects has no equivalent in the other; the description length one accepts is exceeded in the other. Trying to send one file to two places means missing data on both sides.

The right setup has two layers. At the bottom sits the product record — the single version of all the information. On top sits a transformation layer per channel: it maps the fields to the names that channel expects, translates the category vocabulary and applies the formatting rules. When a piece of information changes, it changes in one place and every channel is updated at the same time.

Where this layer sits depends on the infrastructure; some platforms offer the transformation built in, others need a separate tool. Whichever it is, the rule stays the same: the information has a single correct version, and the channel files are derived from that version.

Turning the approval rate into a measured metric

The disapproval list should be read not as a list of problems but as an indicator. A single number is enough for that: how many of the submitted products are actively live.

Recording this number at regular intervals gives you three things. First, it shows whether a fix has worked. Second, it warns you that something has broken when there is a sudden drop — usually a platform update or a policy change. Third, read together with the distribution of disapproval reasons across families, it tells you where the work is.

The same measurement needs to be kept separately per channel. A high approval rate on one channel does not mean it will be high on another; the rules differ.

On the advertising side this measurement has a direct counterpart: you cannot build a campaign for a product that is not live, and the budget plan is drawn up accordingly. We describe this side of ad management on our ad management service page.

The order for resubmitting a disapproved product

Once the fix has been made, this is the order to follow.

1. Identify the family. Place the disapproval row in one of the four families; handle every product in the same family together.
2. Fix it at the source. Make the fix in the product record, not in the file; otherwise it comes back with the next update.
3. Check the page. In the mismatch family, make sure the page has been updated too; both sides have to be correct at the same time.
4. Refresh the file. Open the file itself and check that the update has actually reached it.
5. Wait and record. Re-review is not instant; record the result and check whether the same family recurs.

The fifth step is the one skipped most often. When no record is kept, the same error resurfaces a few months later and the work is done from scratch.

How product data, markup and channel files are produced from a single source is defined among the work items of our ecommerce setup service. If you would like to sort through your own disapproval list with us, you can write to us.

Frequently Asked Questions

My product was disapproved and I fixed it; how long until it is approved?

It would not be right to give an exact time; re-review varies with the channel's own processes, the disapproval family and the size of the catalog. What is certain is that it is not instant. The right thing to do while waiting is to check whether the fix has actually reached the file: many "it just won't get approved" cases come down to the fix being made in the panel while the file was never refreshed. Disapprovals in the policy family are a separate matter; there, the fix usually means changing the copy or the product selection rather than filling in a field.

How do I submit a product that has no global product number?

Not by leaving the field blank, but by declaring explicitly that the product has no such identifier. Channels have a separate field for this, and when it is used correctly the product is accepted without a number. In that case the brand and the manufacturer's own part number become more important; together they carry the product's identity. For handmade, made-to-order and one-off products this route is the usual solution. The one thing not to do is make up a number: if the number belongs to another product, your product is matched incorrectly, and even if the result is not a disapproval, it is a wrong listing.

Should I build the feed by hand or automatically?

If the catalog is limited to a few dozen products and prices rarely change, a hand-built file can work. In every other situation automatic generation is needed, because a hand-built file is a snapshot of one moment, while price and stock change every day. The real criterion is not the number of products but how often things change: in a store with a hundred products that runs a promotion every week, a hand-built file cannot be sustained. A middle route is also possible: the file is generated automatically, and only a small rule layer for channel-specific exceptions is added on top.

What should we do if the account is suspended?

First read the reason, then stop trying to submit products. A suspension usually stems from a finding on the policy side, and that finding is often related not to a single product but to the overall state of the site: contact information that cannot be found, return and delivery conditions that are not accessible, a checkout that does not show the expected information. The right order is to genuinely fix the reported issue on the site, publish the pages in a way that documents the fix, and then request a review. Repeating the same request without making the fix drags the process out.

Can there be a small difference between the price on the channel and the price on the site?

In practice even a small difference is treated as a mismatch and can produce a disapproval; what you should aim for is for the two sides to be exactly the same. The difference is usually not deliberate: a rounding rule, the order in which a promotion is calculated or a difference in when the file refreshes creates it. The lasting fix is for the final price shown on the page and the price sent in the file to come out of the same calculation. In addition, the extra items that appear next to the price on the page — such as shipping — need to be placed correctly in the channel's own fields; when they are added into the price field, a mismatch shows up as well.