Google Merchant Center guide for ecommerce: the complete guide

Merchant Center decides which of your products are allowed to appear on Google at all. Everything downstream depends on it. A Shopping campaign cannot show a product that Merchant Center has disapproved, no matter how much budget sits behind it, and no bid strategy can rescue a title that does not match what people search for.

Think of the account as three separate jobs bundled into one interface. The first job is identity: proving that the website sending the products is the website you own and operate. The second is data: taking your catalogue and expressing it in the fields Google expects, so an item on your store becomes an item Google can match to a query. The third is compliance: continuously checking that what you claim in the data is what a shopper finds on the landing page.

That third job is the one stores underestimate. Google re-crawls your product pages on its own schedule and compares the price, the availability and the currency it finds there against what your feed says. When the two disagree, the item stops showing. Nobody sends you a warning first. The item simply stops earning, and the revenue drop shows up in the ad account where the cause is invisible.

This is why feed work belongs at the front of any Google project and not at the end. If you are spending on Shopping ads while a share of the catalogue sits disapproved, you are paying full price for partial coverage. The most common version of this is a store with a healthy account status at the top level and a long tail of individual items quietly excluded underneath.

One more thing worth knowing early. The account is organised per selling country and currency, so selling into more than one country means more than one set of prices, shipping settings and tax rules, each able to pass or fail on its own. Plan for that before you expand.

Start by verifying and claiming the website, because nothing else in the account works until that is done. Verification proves you control the domain. Claiming ties that domain to this specific Merchant Center account so no other account can use it.

Verification is usually done through the same methods you would use for any Google property: a meta tag in the site's head, an HTML file uploaded to the root, a DNS record, or a link from an existing Google Analytics or Tag Manager container that already has the domain. On a hosted platform, the tag method is normally the least fragile because theme updates rarely touch theme settings, while an uploaded file can disappear in a redeploy. Whichever you pick, keep a note of it. Verification quietly breaking after a site migration is a common reason a healthy account suddenly stops serving.

Use the exact domain your storefront runs on, including whether it uses www. If your store answers on both, make sure one redirects to the other and verify the destination. A mismatch here creates a class of problem that is hard to spot later, because the feed will point at URLs that redirect, and redirect chains slow down the crawl Google uses to check your prices.

While you are in setup, get the business information right. Business name, address, customer service contact, and the country you sell into. This is not paperwork. Google shows some of it to shoppers, and a missing or wrong contact detail is a policy issue in its own right.

Finally, connect Merchant Center to your Google Ads account before you build any campaign. The link is what makes products available to Shopping campaigns. Do it early so that when the data is clean you are not waiting on an approval to start.

Fix the website before you fix the feed, because most account-level suspensions come from the store, not the product data. Google will not show products from a site a shopper cannot safely buy from, and it checks the site itself as part of approving the account.

The requirements are ordinary retail hygiene, and any store that takes them seriously passes. You need a checkout that works end to end and is served over a secure connection, including every page where a shopper enters personal or payment details. You need a clear returns and refunds policy that a person can find without hunting, written in the language of the country you sell into, and it needs to say what a customer actually gets: the window, the condition the item must be in, who pays return shipping, and how a refund is issued. You need contact information that reaches a human. You need billing terms that are visible before a shopper commits, so nothing about the total is a surprise at the last step.

The two policy areas that catch legitimate stores off guard are hidden costs and misrepresentation. Hidden costs means anything that appears late: a handling charge added at the final step, a currency that switches without warning, a subscription enrolment that was not clearly stated. Misrepresentation is broader than lying. Countdown timers that reset, stock counts that are decorative, or a strikethrough price that was never charged all fall inside it. If a claim on your site would not survive a customer reading it carefully, take it down before Google finds it.

Walk your own store as a first-time buyer on a phone before you go further. Add an item, go to the last step before payment, and read every line. Then find the returns policy from a cold start, as if you had never seen the site. If either of those takes effort, fix it now. It costs a morning and it prevents the worst outcome in this whole guide, which is an account suspension that takes your entire catalogue off Google while you appeal.

Pick the connection method that keeps your data fresh with the least manual work, because a stale feed causes more damage than an imperfect one. There are four common routes and they differ mainly in how quickly a change on your store reaches Google.

A platform app or built-in integration is the usual starting point. Your ecommerce platform pushes products directly, mapping its own fields to Google's. It is the fastest to set up and it usually handles price and stock updates automatically. The trade-off is control: the mapping is decided for you, so if your product titles are wrong for search, you often cannot fix them at the source without renaming products in your store.

A scheduled fetch is a file your store or a feed tool generates at a fixed URL that Google collects on a schedule you set. This is the workhorse for stores that want control. You decide what goes in each field, you can transform titles, and you can exclude products that should not be advertised. The trade-off is timing: between fetches, your feed and your store can disagree.

A direct API connection pushes changes as they happen. It suits large or fast-moving catalogues where stock moves through the day and a fetch schedule would leave you selling items that sold out hours ago.

A feed tool sits between your store and Google and gives you rules without engineering time. This is where most growing stores end up, because it lets you build the titles that win searches without touching the titles shoppers see on your site.

Whichever route you take, add supplemental data as a second layer rather than rebuilding the first. A primary feed carries the whole catalogue. A supplemental feed matches on item id and adds or overrides specific fields, which is how you patch missing identifiers, add custom labels for campaign structure, or override a handful of titles without regenerating everything. Keep one primary source of truth and layer on top of it. Two primary feeds fighting over the same items is a problem you will spend a week untangling.

Treat the required attributes as two groups: the ones that decide whether an item is accepted, and the ones that decide whether it gets found. Most stores fill in the first group and ignore the second, then wonder why approved products get no impressions.

The acceptance group is straightforward. Every item needs a stable unique id that never changes for that product, a title, a description, a link to the product page, an image link, a price with a currency, an availability state and a condition. Change an item id and Google treats it as a new product with no history, so whatever generates your ids must be tied to something permanent like the variant SKU, never to a position in a list.

The discovery group is where the money is. The title is the single most important field in the feed, because it is the main text Google matches against a shopper's query. A title that reads well on your product page is often useless in a feed, because your page has a category, breadcrumbs and images doing the explaining while the feed has nothing but the string. Write feed titles in the order a shopper would say them: brand, product, the attribute that distinguishes this variant, then size or quantity. Front-load the words that matter, because the end of a long title carries less weight and may not be shown.

Images deserve the same attention. Use the plain product image with a clean background as the main image, not a lifestyle shot with props and not anything with text, badges or promotional overlays laid on top. Watermarks and added borders are a common cause of image disapprovals in otherwise healthy accounts. Lifestyle shots belong in the additional image field, where they help without risking the item.

Descriptions matter less than titles but they are not decoration. Write the facts a buyer needs in the first couple of sentences, keep marketing language out, and do not paste in shipping or promotional text that will age badly.

For apparel and some other categories you will also need product grouping and variant attributes so that sizes and colours of the same product behave as one family rather than competing with each other.

Send real identifiers wherever they exist, because they are how Google knows your product is the same product other retailers sell. Identifiers affect eligibility, matching quality and which searches your item can appear for.

There are three fields in play. Brand is the manufacturer's brand as a shopper would say it, not your store name unless you are the manufacturer. GTIN is the barcode number that belongs to the product globally. MPN is the manufacturer's own part number for the item.

If you resell products made by other companies, you almost certainly have GTINs available, even if nobody has put them into your store. They are on the packaging and in supplier data. Getting them in is tedious and it pays back, because an item with a correct GTIN can be matched against the same product elsewhere and shown in the places where shoppers compare.

If you make your own products, the situation is different. Own-brand items that genuinely have no barcode do not need a GTIN, but you should say so explicitly in the feed rather than leaving the field silently empty, and supply brand and MPN instead so the item still carries an identity.

The failure mode to avoid is inventing values to make an error go away. A made-up barcode either fails validation or, worse, matches your item to somebody else's product, which produces the strange symptom of ads showing for a product you do not sell. If you do not have a real value, do not fill the field with a placeholder.

Handle this as a data project, not a feed setting. Export your catalogue, sort by whether an identifier exists, and work down by revenue so the products that matter get fixed first. Put the values back into your ecommerce platform in a dedicated field so they survive the next feed rebuild. Then use a supplemental feed only for the leftovers you cannot store natively.

One warning about variants. GTINs are per variant, not per product. A shirt in three sizes has three barcodes. Copying one value across the whole family creates duplicates that Google will notice.

Configure shipping and tax so the total a shopper sees on Google is the total they find at checkout, because a mismatch either suppresses the item or produces a click that never converts. This is the part of setup most often left on defaults, and it is quietly expensive both ways.

Shipping can be handled in two places. You can define shipping services in the account, where you set rates by destination, weight or order value, and every product inherits them. Or you can send a shipping value per item in the feed, which is what you need when certain products carry a surcharge, ship from a different location, or are excluded from a free-shipping offer. Most stores are best served by account-level settings that mirror what the store charges, plus per-item overrides for the exceptions.

Whatever you set must match the store. If your store gives free delivery above a threshold and Merchant Center still shows a base fee plus growth share, you are advertising a worse offer than you actually make and paying for the privilege. If the reverse is true and Google shows free shipping you do not offer, the click arrives, the shopper meets a delivery charge, and the cart is abandoned. Both cost money. Only one of them looks like a problem in the reports.

Tax follows the market. In places where displayed prices include tax, your feed price should be the price a shopper pays and nothing more is needed. In places where tax is added at checkout, you configure tax settings so Google can present the total correctly. Get this wrong and every product in that market carries a price mismatch.

The price mismatch check itself is worth understanding. Google compares the feed price against what it reads on the landing page. Currency has to agree. A page that shows a price only after a script runs, or that displays a member price to some visitors, can read differently to a crawler than it does to you. If mismatches keep appearing on products whose prices are correct, look at how the price is rendered on the page rather than at the feed.

Finally, keep promotions honest. When a sale price is in the feed it must be live on the page for the whole time the feed claims it, and the original price has to be one you genuinely charged.

Work disapprovals by lost revenue, not by count, because a hundred discontinued accessories matter less than four bestsellers. Export the affected items, join them to your own sales data, and sort by what each product earned in the last full season. That list is your work queue.

Sort the issues into three types as you go. Account-level problems affect everything and come first. These are the policy and site issues from earlier, and while one is open, everything else you fix is theoretical. Item-level policy problems are the next tier: a product Google considers restricted, an image with promotional text, a claim in the description that crosses a line. Data quality problems are the third tier: missing identifiers, invalid values, broken links, price and availability mismatches.

Before you fix anything, read the reported reason and then look at the actual product page rather than the feed. A surprising share of disapprovals are the page's fault. The link redirects. The item is out of stock and the theme hides the price. The page requires a country selection before it shows anything. The image is served from a host that blocks automated requests. None of those are visible in the feed, and all of them produce feed errors.

Group the fixes. Individual items are rarely broken individually. If forty products fail on the same reason, one rule or one change in your platform usually clears all forty, and doing it that way means the fix holds the next time the catalogue rebuilds.

Then resubmit and wait for the recheck rather than editing repeatedly. Each edit restarts the review, so a fix applied three times in a morning takes longer to clear than one applied properly and left alone. Keep a note of what you changed and when, so that if the same reason returns you know whether the fix failed or the cause is somewhere else.

For genuinely restricted products, stop trying. If a category cannot be advertised in your market, no amount of rewriting will change that, and repeated attempts put the whole account at risk. Exclude those items from the feed deliberately and put the effort into the channels that can carry them.

Once your data is accurate, make sure your products are eligible for the unpaid listings as well as the ads, because the work is already done and the incremental cost is nothing. Google shows product results in places that do not require a bid, and the source of that data is the same Merchant Center account.

The reason to do this second rather than first is that unpaid placements amplify whatever your data says. Accurate stock and prices earn free visibility. Wrong ones earn free complaints. So clean first, then opt in.

What helps here overlaps with what helps in ads but is not identical. Availability accuracy matters more, because an unpaid listing has a longer life than an impression you paid for and a shopper who clicks through to a sold-out item remembers the store, not the surface. Structured data on the product page matters more too, because it gives Google a second, independent reading of your price and stock that agrees with the feed. When the page and the feed say the same thing, items are far less likely to be caught by an automated check.

Ratings and reviews are their own track. Product review content can appear alongside listings when it is supplied in the format Google expects, either directly or through a review platform that already integrates. If you have review volume sitting in an app and doing nothing outside your product pages, that is usually an afternoon of setup for a visible gain.

Measure the unpaid side separately. Traffic from these placements lands in your analytics like any other organic click and gets buried unless you look for it deliberately. Keep an eye on which products earn impressions without spend, because that list is a useful signal about where your titles and images are genuinely competitive, and it often reveals products worth promoting that your campaign structure has been starving.

Unpaid visibility is not a substitute for a campaign on products where you need volume. Treat it as a side benefit of good data rather than a channel you can steer.

Put Merchant Center on a schedule, because the account degrades on its own. Catalogues change, suppliers rename things, themes get updated, and a feed that was perfect in March fails quietly in June. The stores that never have a Google emergency are the ones that spend twenty minutes a week on this.

A weekly pass is enough for most stores. Check the count of active items against the number of products you expect to be advertising, because the gap between those two numbers is the fastest indicator that something broke. Look at new disapprovals since last week and clear anything on a product that matters. Confirm the feed actually fetched on schedule, since a fetch that has been failing for a fortnight leaves the entire catalogue stale.

Once a month, go deeper. Review the items that have been excluded for a long time and decide whether to fix them or drop them. Check that products discontinued on the store have left the feed, since advertising items you cannot ship is an expensive habit. Compare a sample of feed prices against live pages by hand, especially after any pricing change or promotion. Look at which products get impressions and which never do, and treat the silent ones as a title problem until proven otherwise.

Build the calendar into it. Before a promotional period, get sale prices and any promotion data in early enough to be reviewed, because submitting on the morning of a sale means the offer goes live after the traffic arrives. After a season ends, take the seasonal items out rather than leaving them to fail.

Finally, keep a short written record of how the account is put together: which feed comes from where, what rules are applied, who verified the domain, which products are excluded on purpose. When something breaks a year from now, or when the person who set it up moves on, that one page saves days.