Skip to content

How do I get my products approved in Merchant Center?

By cartscaling Reviewed 4 min read

The short answer

Get four things right and approval usually follows. A website with contact details, returns and a checkout that works. A verified and claimed domain. Product data with every required attribute filled honestly. Then a first review you leave to run. Rushing a resubmission is the most common way to slow it down.

Approval is a sequence, and the site comes before the products

New accounts often submit a feed on day one and spend three weeks confused. The order matters, because the review looks at the whole shop, not only the file.

First the website has to look like a real shop to someone who has never seen it. Contact details a person could actually use, a returns and refunds policy written in plain language, delivery information with costs and timeframes, and terms a shopper can find before paying.

Second the domain has to be verified and claimed in the account, so the products can point at pages you have proved you control.

Third the product data has to be complete for the categories you sell, which is a bigger job than it sounds if the catalogue was built quickly.

Fourth the feed is submitted and reviewed. Only then do you have an approval question at all.

Stores that work in that order tend to clear review once. Stores that work in reverse tend to collect disapprovals, fix one thing at a time, and wait for a new review after each attempt, which turns a week into a month.

If the store is new and light on content, spend the waiting time filling out those pages properly. It is the same work either way, and doing it first makes the rest faster.

What the shop itself has to show before products can pass

Think of it as the reviewer opening your store cold and trying to buy something. Everything they need has to be findable without asking.

A checkout that completes. If payment fails, if the cart errors on mobile, or if a required field rejects a valid address, the review stops there. Test a real purchase on a phone before submitting anything.

Prices that do not change on the way to payment. Extra charges added at the last step, or a currency that switches, undermine the whole account rather than a single product.

A returns policy that says what a customer can return, how long they have, who pays for the return and how the refund arrives. Vague wording is worse than a strict policy stated clearly.

Contact information that is real. A form is not enough on its own for many stores. An address, an email or a phone number that a person answers builds the case that the shop exists.

Security on the pages that take personal data, which for a modern hosted store is usually handled for you, but is worth confirming if the store runs custom pages.

None of this is exotic. It is the same set of things a cautious shopper looks for, which is exactly the point of the rules.

Complete product data is what turns a submission into an approval

The data specification is long, but for most stores approval hinges on a short list.

A stable unique identifier for each item that does not change when the product is edited. Changing identifiers makes history disappear and can look like an attempt to reset a rejection.

A title that describes the product as a shopper would name it, not an internal code. A description that describes the product rather than repeating shipping promises. A link to the exact page for that item, not the collection it sits in.

An image of the product on a plain background, at a decent size, without promotional text, borders or watermarks over it.

Price and availability that match the page exactly for the country you sell to.

Brand, and an identifier such as a barcode where the product has one. For clothing, size, colour, age group and gender. For variants, the grouping field that ties them together so the same shirt in four colours is understood as one product family.

Category values that place the item in the right part of the catalogue, chosen as specifically as the list allows.

Fill these honestly rather than creatively. Padding a title with extra keywords or claiming a category that flatters the product tends to produce a rejection later, and rejections are slower to undo than they are to avoid.

The first review, the waiting, and the temptation to resubmit

After the first submission there is a review period. Products can sit in a pending state while it happens, and nothing you do will speed it up.

Use the time. Check the feed for warnings, which are not disapprovals but do predict them. Fix the products missing optional attributes, because complete items compete better later. Set up the sync so price and stock update often enough for a store your size.

Do not resubmit the same data repeatedly, and do not delete and recreate products to force a fresh look. Both make the account look unstable and neither shortens the wait.

If the outcome is a rejection, read the specific reason and change that specific thing. Then request one review. A single well prepared review request is faster than three hopeful ones, and repeated requests on unchanged data can lead to harsher outcomes.

Once products are approved, keep them that way with a routine. Approval is not permanent. Policies change, your prices change, stock changes and site updates break things. A weekly look at the issue list catches problems while they affect ten products rather than the whole catalogue.

Finally, keep one person accountable for the account. Approval problems usually appear where nobody is quite sure whether the store team, the developer or the marketing team owns the feed.

Worked example, not a result

A first submission timeline for a new store

Day 1
Policy pages written, checkout tested on a phone
Day 2
Domain verified and claimed
Day 3
Feed submitted with all required attributes
Day 4 to 10
Products in review, warnings cleaned up
Day 11
Approved items live, three issues remain
Day 12
One fix applied, one review requested

Worked example, not a result

Related questions

Only for products that have one from the manufacturer. Handmade or own-brand items without an assigned identifier have a way to be declared as such, and using that field correctly is better than inventing a number.

You can submit them with the correct availability, and they will not serve while unavailable. What causes trouble is submitting them as in stock, because the page and the data then disagree.

Not much. Hosted platforms make the feed easier to produce and keep synced, but the requirements are the same either way. What matters is that the data is complete and the page matches it.

Keep reading

Want this answered for your store?

Send it. The plan looks at your numbers, not the general case.

Store, name, email and phone. A person replies from a real inbox. Privacy

Get your free growth plan