Google Merchant Center Feed Guide 2026
Say you run a homeware store in Rotterdam. You carry about 4,200 products, you ship to seven European countries, and roughly a third of your revenue arrives through Google Shopping and free product listings. On a Friday afternoon, your Shopping clicks fall off a cliff. Not to zero. To almost zero. Nothing changed on the site. Nobody touched the theme. The developer is on holiday until Tuesday.
That scenario is hypothetical, but the pattern behind it is not. Feeds fail quietly. They rarely throw a loud alarm. A product data source stops fetching, a stock sync flips 3,000 items to out of stock, a CDN starts refusing image requests, or one price rounding change makes your feed disagree with your product page. Google stops serving the items and the dashboard often still looks calm.
This guide is about the surface that most SEO articles skip. Not on-page product markup. The Google Merchant Center feed itself. What Google Merchant Center actually needs, which rules quietly drop your products, how the US and EU differ in ways that matter, and how to diagnose a catalog that stopped serving without telling you.
What will you actually get out of this guide?
You will get a working model of the feed as a second website that Google reads, a field-by-field view of what is required in 2026, the disapproval and suspension reasons that hit normal stores, and a triage order for a feed that goes dark. You will also get three opinions that contradict popular feed advice, plus a plain list of tactics you should skip.
Most feed content online is written for advertisers who want lower cost per click. That is a different job. This one is written for in-house e-commerce SEOs and agency folks who own organic visibility and inherited the feed by accident. If you have ever been handed a Merchant Center login and a spreadsheet and told to "fix Shopping", this is for you.
Here is the scope of this Google Merchant Center guide. We will cover feed structure and required attributes, product identifiers, titles, image rules, why feed data and page data must agree, disapproval reasons, account suspension, EU versus US differences, multi-country catalogs, and a diagnosis path with time estimates. We will not re-teach on-page product structured data. That is a separate surface with its own guide, and mixing the two is exactly how people end up fixing markup for a week while the real problem sits in a broken product data source.
One promise up front. By the end you should be able to open an account you have never seen before and know, within about 45 minutes, whether the problem is the feed, the site, the policy layer, or nothing at all.
What is Google Merchant Center actually doing with your feed?
Google Merchant Center stores your catalog as structured rows and makes those rows eligible to appear across Google surfaces. It is a product database, not a ranking dial. Google matches shopping queries to items in that database, checks each item against policy, and then decides whether to show it. Clean data buys eligibility. It does not buy placement.
Think of the Google Merchant Center feed as a second website. Your storefront is written for humans. The feed is written for a machine that never sees your CSS. Each row is one product. Each column is one attribute. If a row is incomplete or contradicts the page it points to, the row is unreliable, and Google treats unreliable rows the way you would treat a supplier who ships the wrong item twice.
Where do those rows show up? Google's free listings documentation says products can appear at no cost on Google Search, Google Maps, Gemini, YouTube, the Shopping tab, Google Images, and Google Lens. That is a wide surface area, and it is the reason feed work belongs in an SEO plan and not only in a paid media plan. Google also notes that free listings are usually turned on by default, and that the status "doesn't guarantee that your products will be shown to customers."
Read that last part twice. Eligibility is not visibility. Plenty of merchants tick every box, see a green dashboard, and still get thin traffic because their prices, reviews, and shipping terms are simply less attractive than the merchant next to them in the carousel.
Which feed attributes are genuinely required in 2026?
The core required set is small. You need the id attribute, the title attribute, the description attribute, the link attribute, the image_link attribute, the price attribute, and the availability attribute. Google also requires the brand attribute for all new products except movies, books, and musical recording brands, and the availability_date attribute when an item is on preorder.
The Google Merchant Center product data specification also sets hard limits that people trip over. The id attribute maxes out at 50 characters. The title attribute maxes out at 150 characters. The description attribute maxes out at 5,000 characters. Those are not suggestions. A long SKU string from a legacy ERP will truncate or reject.
Then there is the regional layer, which is where US and European teams diverge. Google marks the color attribute, the size attribute, the gender attribute, the age_group attribute, and the item_group_id attribute as required in a specific set of countries, including France, Germany, the United Kingdom, and the United States, for apparel and for variants. If you sell clothing into Germany without item_group_id on variants, you are not "missing an optional field". You are non-compliant.
| Attribute | Status | Common failure |
|---|---|---|
| id | Required, 50 characters max | Reused after a SKU is deleted, which merges two products |
| title | Required, 150 characters max | Truncated mid word by a template |
| link | Required | Points at a redirect chain or a soft 404 |
| image_link | Required | Blocked by hotlink protection on the CDN |
| price | Required | Tax handled the wrong way for the target country |
| availability | Required | Stock sync flips the whole catalog |
| brand | Required for new products, with narrow exceptions | Left blank for own-label goods |
Here is my first unpopular opinion. Do not add 40 optional attributes before the required seven are clean. Too many feed projects start with custom labels, promotion IDs, and lifestyle image sets while a chunk of the catalog still has a broken landing page. Order matters. Required fields first, then identifiers, then the fields that improve matching, then the nice ones. A good technical SEO audit process applies here almost unchanged. You are auditing rows instead of pages.
Do you still need a GTIN on every single product?
No, but you need to be honest about it. Google lists GTIN as strongly recommended when available, and requires the mpn attribute only when your product has no manufacturer-assigned GTIN. If your product genuinely has no brand, GTIN, or MPN, you set the identifier_exists attribute to no. That is the entire rule.
Where Google Merchant Center users get hurt is the shortcut. Somebody gets tired of identifier warnings on 900 resold items and sets identifier_exists to no across the board. The warning disappears. So does the matching quality, because Google can no longer tie your listing to the same product sold by 40 other retailers. Worse, declaring "no identifier" on clearly branded goods is a factual claim about your inventory that is not true.
Never invent a GTIN. Never buy a block of codes and assign them arbitrarily to unrelated products. Invalid check digits get caught, and a fake identifier is a false statement about your product, not a tidy data quality issue.
Who should not bother chasing identifiers
If you sell handmade goods, custom furniture, one-off vintage pieces, or made-to-order items, stop. Set identifier_exists to no, fill in the brand attribute with your own name, and move on. You will spend two weeks on this and gain nothing. Spend those two weeks on images instead.
How should you write product titles that earn Shopping clicks?
Write titles the way a good shelf label reads. Lead with brand, then the product name, then the attribute that decides the purchase, then the variant. Keep the important words in the first 60 to 70 characters, because that is roughly what a shopper sees before truncation. Use the full 150 characters only when the extra detail is genuinely useful.
A workable pattern for most catalogs looks like this. Brand, product type, key spec, color, size. For a kettle that is "Bosch Electric Kettle 1.7L Stainless Steel Brushed Silver". For a shoe it is "Adidas Samba OG Leather Trainers White Black UK 9". Boring. Boring works.
Now the contrarian bit. Keyword stuffing product titles is oversold advice. The idea that you should cram five query variants into every title comes from an era when matching was cruder. Today Google reads the whole record, including the description attribute, the product_type attribute, the google_product_category attribute, and the page behind the link. A title packed with "cheap best buy discount" reads badly to a human, drags your click-through rate down, and puts you closer to the editorial rules about gimmicky formatting.
What does help is matching how people phrase the query in each market. British shoppers search "trainers", Americans search "sneakers". Germans search "Turnschuhe". That is a genuine title decision, and it is worth grounding in real data rather than instinct. Our keyword research guide and the breakdown of search intent and micro-intents both apply directly, because a Shopping query is just a transactional query with a price attached.
What image rules quietly drop your products?
Images cause more silent losses than any other field. Google Merchant Center requires the image URL to start with http or https, comply with RFC 3986, and be crawlable. Google has announced a new minimum of 500 by 500 pixels for all product images, with enforcement starting January 31, 2027, and recommends 1,500 by 1,500 pixels or above. Maximum file size is 16MB and maximum resolution is 64 megapixels.
Google Merchant Center accepts JPEG, WebP, PNG, non-animated GIF, BMP, and TIFF. The content rules are stricter than most teams realize. Google prohibits watermarks, logos, and brand names that are not part of the product, calls to action such as "buy", price information, promotional text, borders and overlays, and placeholder images. The product should fill roughly 75% to 90% of the frame. Apparel should show the item worn by a person. Each variant needs its own image.
Two rules deserve extra attention. First, Google says not to scale up an image or submit a thumbnail. Upscaling a 300 pixel legacy asset to 800 pixels does not create detail, and it looks exactly like what it is. Second, AI-generated images must retain their IPTC DigitalSourceType metadata. If your pipeline strips metadata during compression, you may be quietly breaking that requirement.
The practical image workflow
Export at 1,500 by 1,500 or larger on a white or transparent background. Compress to keep pages fast without visible artifacts. Convert legacy assets to a modern format where it helps. Our free image resizer and image compressor cover the quick one-off jobs when you are testing a fix before you rebuild the pipeline. For the strategy behind it, read our guide to optimizing images for web and SEO.
The failure I would check first is not size at all. It is access. Hotlink protection, bot filtering, and aggressive WAF rules on a CDN will happily serve images to a browser and refuse them to Googlebot. The feed looks perfect. The images never load. Test the image URL from outside your network before you blame the resolution.
Why must your feed data and your product page agree?
Because Google checks. If your feed says 49.99 EUR and your landing page says 54.99 EUR, the item is misleading, and Google will disapprove it. The same applies to stock status, currency, and condition. Feed and page are two statements about one fact, and they have to match at the moment a shopper clicks.
Google Merchant Center runs a safety net for this called automatic item updates, or automations. They are on by default. Google crawls your landing pages and can update the price attribute, the sale_price attribute, the availability attribute, and the condition attribute using structured data markup, with machine learning extractors as a fallback. Google is blunt that automations are "not a replacement for regular updates of your product data" and that they address temporary mismatches for a small share of products.
So treat automations as an airbag, not a steering wheel. If your feed refreshes once a day and your prices change hourly, you have a pipeline problem that no crawler will paper over. One documented trap worth knowing: multiple strikethrough prices on a page can confuse the crawler. If your template shows an RRP, a member price, and a flash price all at once, expect trouble.
On markup, one point and then we move on. Google Search Central states that "providing both structured data on web pages and a Merchant Center feed maximizes your eligibility to experiences and helps Google correctly understand and verify your data." Product markup is the on-page half of that pair, and we cover the fundamentals of markup in our JSON-LD schema markup guide. The feed is the half this article is about.
The other agreement to check is technical. The link attribute must resolve to a live, indexable page. Redirect chains, geolocation bounces, and stale URLs after a replatform quietly break thousands of rows at once. If you have migrated recently, our guide to redirects and site migration SEO covers the pattern, and a healthy XML sitemap and indexing setup helps confirm those product URLs are actually being crawled. You can build one quickly with our XML sitemap generator.
Which disapproval reasons actually bite normal stores?
Google groups its rules into prohibited content, prohibited practices, restricted content, and site requirements. Most disapprovals at ordinary retailers are not exotic. They cluster into price mismatch, stock mismatch, image problems, missing return or contact information, restricted categories, and editorial failures such as a broken landing page or an inaccurate display URL.
Here is the ranked list I would work through, based on how often each one appears and how cheap it is to fix.
- Price and tax mismatch. Usually a currency or VAT handling bug. Fix in the feed logic, not per item.
- Availability mismatch. Usually a sync lag. Shorten the refresh interval before you argue with the policy.
- Image issues. Blocked, too small, watermarked, or promotional overlays added by a marketing team.
- Missing return policy or contact details. A site problem, not a feed problem.
- Restricted content. Alcohol, supplements, medical devices, knives. Real rules, often correctly applied.
- Editorial and site requirements. Broken pages, gimmicky formatting, display URLs that do not match the destination.
Second contrarian opinion. Stop chasing 100% approval. If 3% of a 10,000 item catalog is disapproved and those items are genuinely restricted goods or discontinued lines, that is a healthy number. Teams routinely burn three weeks appealing 40 items worth a rounding error in revenue while an image bug suppresses 2,000 profitable ones. Sort your disapprovals by revenue potential, fix the top of the list, and accept a tail.
What gets a whole Google Merchant Center account suspended?
Misrepresentation. Google treats it as egregious and states that "your Google accounts will be suspended upon detection and without prior warning, and you won't be allowed to promote with Google Shopping again." The most common triggers at legitimate retailers are boring ones. Missing or hard-to-find return and refund policies, no clear business contact details, and undisclosed costs at checkout.
That policy language is deliberately harsh, and reinstatement is not routine. So build the trust layer before you obsess over feed fields. Four pages fix most of it.
- A returns and refunds page written in plain language, linked from the footer and the product page, not buried in a help center.
- A contact page with a real address, a working email, and a phone number where you have one.
- An about page that explains who you are and what you sell.
- Shipping costs and delivery times shown before the final checkout step, with no fee appearing at the last moment.
Google's free listings requirements make this explicit. You need to add return policy information to your website, and you need shipping settings or the shipping attribute in your product data. That requirement covers a long list of countries, including the United States, the United Kingdom, Germany, France, and Canada.
When you do appeal, document the state of your site at the moment of the appeal. A dated screenshot of the returns page and the contact page saves a lot of arguing, and our free website screenshot generator is enough for that. While you are there, run a general SEO report on the domain and read our on-page SEO checklist, because site requirement failures and on-page failures overlap heavily. Page experience matters too, since a landing page that will not load is an editorial failure as much as a ranking problem. Our guide to Core Web Vitals and page experience covers that ground.
How do European feeds differ from US feeds?
The single biggest difference is tax. Google's product data specification tells US and Canadian merchants not to include any taxes in the price attribute, including sales tax, GST, VAT, or import tax. For all other countries, including every EU market and the UK, you include VAT or GST in the price. Get this backwards and every item in that country is mispriced.
That one rule causes more European Google Merchant Center pain than anything else, because most platforms store a net price and a tax rate separately. If your export logic was written by a US-based agency, check it today.
| Topic | United States | European Union and UK |
|---|---|---|
| Price and tax | Exclude sales tax from the price attribute | Include VAT in the price attribute |
| Currency | USD, matching the landing page | EUR, GBP, PLN, SEK and others, matched per country |
| Language | English | One title and description per market language |
| Apparel fields | Required in the US | Required in France, Germany, and the UK |
| Energy labels | Not applicable | The certification attribute, referencing the EU EPREL database |
Methodology note on that table. Every row comes from Google's published product data specification and free listings documentation, not from third-party commentary.
Two European specifics are worth flagging. First, Google states that from April 2025, for products targeting EU countries, merchants use the certification attribute to reference graphical energy efficiency data from the EU EPREL database. That affects appliances such as dishwashers, refrigerators, and televisions. If you sell white goods into the EU and you are still passing an energy efficiency class string, you are on old guidance.
Second, price presentation. Several EU markets require you to disclose the lowest prior price when you advertise a reduction, under national implementations of EU consumer law. I am not going to quote a rule number, because the detail varies by country and this is a question for your legal team rather than your feed team. But it does mean your sale_price handling has a compliance dimension in Europe that it does not have in the US.
How do you run one catalog across many countries and currencies?
Run one clean source of product data, then split by target country. Each country needs the right currency, the right tax treatment, the right language, and a landing page that shows all three. The feed and the page must agree per country, not on average. A single global feed that ignores this will look fine in the dashboard and convert badly.
The Google Merchant Center order of operations that works. Build a canonical source with every language variant and every price stored as its own field. Generate a country-specific output from it. Set the shipping and returns configuration per country. Only then think about feed labels and rules.
Third contrarian opinion. Feed rules and supplemental feeds are frequently used to hide a broken product information system. They create a second source of truth that nobody documents, and 18 months later nobody can explain why the German titles are different. Use rules for genuine market adaptations. Do not use them to patch missing data that should exist upstream.
The most common technical killer in multi-country setups is geolocation redirection. If a crawler requesting your Dutch product URL gets bounced to a US page with a dollar price, you have created a mismatch that no feed edit will fix. Serve the requested URL. Offer a country switcher instead of forcing one.
A note on South Korea
Korea is a high-value market with expensive clicks, and Google Shopping does operate there alongside Naver. If you target it, you need Korean-language titles and descriptions, prices in KRW, and a returns process that a Korean shopper can actually use. Translating titles alone is not enough. If you cannot support the market operationally, skip it.
Who should not bother going multi-country
If you cannot ship to a country profitably, or you cannot handle returns from it, do not add it to your feed. An approved listing that leads to a checkout which rejects the address is a wasted click and a customer service ticket. Depth in three markets beats presence in fifteen.
How do you diagnose a Google Merchant Center feed that silently stopped serving?
Work outside in. Check whether the data source is still fetching, then whether items expired, then whether a destination got switched off, then whether a whole class of items got disapproved, then whether the site itself changed. Most silent failures are a fetch failure or an expiry cascade, not a policy action.
Here is the triage order I would use, with rough time estimates for a mid-sized catalog.
- Check the last successful fetch, 5 minutes. If the scheduled fetch failed, everything downstream is noise. A feed URL behind a login, a changed file name, or a 403 from your own firewall are the usual causes.
- Check item counts over time, 5 minutes. A sharp drop in active items points at expiry or a truncated export. A stable count with falling impressions points elsewhere.
- Open the feed file itself, 10 minutes. Download it and read it. If it is XML, format it so you can actually see the structure. Our XML formatter handles that, and our JSON to XML converter helps when your pipeline emits JSON and your scheduled fetch expects XML.
- Check destinations, 5 minutes. Confirm free listings are still enabled. A colleague toggling a setting during a paid campaign change is more common than you would think.
- Group the disapprovals, 15 minutes. One reason affecting thousands of items is a logic bug. Fifty reasons affecting one item each is a normal tail.
- Test five landing pages and five image URLs, 10 minutes. Load them from outside your office network. Check price, stock, currency, and whether the image returns.
- Check shipping and returns configuration, 10 minutes. A removed shipping service can make items ineligible in one country while others carry on.
- Only then read the account notifications. They are useful, but they lag, and starting there sends you chasing whichever message is loudest rather than whichever problem is largest.
Two things that look like feed failures and are not. A seasonal demand collapse, which shows falling impressions with a stable item count and stable position. And a competitor price move, which shows stable impressions with falling clicks. Both get misdiagnosed as technical faults every year.
Which feed problems should you simply ignore?
Ignore warnings on low-value items, ignore optional attributes that do not affect matching for your category, and ignore the urge to fix a 12-item tail before a catalog-wide bug. Warnings are advisory. Errors and disapprovals cost you money. Treat them differently.
Specific things I would not spend a day on. Filling in the material attribute for hardware. Adding custom labels before you have a paid campaign that uses them. Rewriting descriptions by hand for products with no search demand. Building a custom feed pipeline when you sell 60 products on Shopify and the official Google and YouTube app already exports a valid feed.
That last one matters. If you run a small catalog on Shopify, WooCommerce, BigCommerce, PrestaShop, or Shopware, use the platform integration first. Feed management platforms such as Channable, DataFeedWatch, and Feedonomics earn their keep at scale, with complex transformations or many markets. Below a few hundred products in one country, they are usually an expense with no matching return. The honest downside of platform apps is limited transformation logic, so you will outgrow them. Outgrowing a free tool is a good problem.
How do free listings differ from Shopping ads in practice?
They share one feed and one policy set. The difference is the lever. With ads you can bid your way past a data weakness. With free listings you cannot, so data quality, price competitiveness, and shipping terms are the only inputs you control. That makes free listings a genuinely organic channel and a legitimate part of an SEO remit.
Because free listings appear on Search, Images, Lens, YouTube, Maps, and Gemini, they interact with the wider shift toward answers that never send a click. If you are thinking about how product discovery is changing, our zero-click search survival guide is a useful companion. Products can also surface in the Business Profile products module, which is where feed work meets local presence. Our guide to local SEO and Google Business Profile covers that side.
What should you fix first? A 30-day order of work
Fix the trust layer, then the required fields, then images, then agreement between feed and page, then market-specific rules. In that order. Each stage removes a class of failure that would otherwise mask the next one.
Week one. Returns page, contact page, about page, shipping costs shown before checkout. Budget one day of content work and one of development.
Week two. Audit the seven required Google Merchant Center attributes across the whole catalog. Fix the logic that generates them, not the individual rows. Budget two to three days.
Week three. Images. Confirm crawlability first, then resolution, then content rules. Budget two days plus whatever your asset pipeline needs.
Week four. Agreement checks. Sample 50 products across price bands and countries. Compare feed price, page price, currency, and stock. Then set your refresh frequency to match how fast your prices really move.
Frequently asked questions
Is Google Merchant Center free to use?
Yes. The account costs nothing and free product listings cost nothing. Google's documentation says products can appear at no cost across Search, Maps, Gemini, YouTube, the Shopping tab, Images, and Lens. You only pay when you run Shopping ads on top. That is why feed quality belongs in an organic budget and not only a media budget.
How long does Google take to review a new feed?
New items go through review before they can serve, and it usually takes a few business days rather than hours. Do not resubmit repeatedly while you wait, because that does not speed anything up. Use the time to fix your returns and contact pages, which are the most common reasons a new account runs into trouble later.
My products are approved but get almost no impressions. Why?
Approval only means eligibility. Google states plainly that free listings status does not guarantee that your products will be shown. Low impressions usually mean weak matching data, uncompetitive pricing, or thin demand for those products. Check your titles first, then compare your delivered price against the merchants who do appear for the same query.
Do I really need a GTIN for every product?
No. Google lists GTIN as strongly recommended when available and requires the mpn attribute only when a product has no manufacturer-assigned GTIN. For genuinely unique goods, set the identifier_exists attribute to no. Do not invent codes and do not blanket-set that field to silence warnings on branded stock.
Can one feed serve both the US and the EU?
One source of data can, but the output has to differ per country. Prices, currency, tax treatment, and language all change. Google requires US and Canadian prices to exclude tax while other countries include VAT or GST. Generate a country-specific output from a single canonical source rather than sending one file everywhere.
Should EU prices in the feed include VAT?
Yes. Google's product data specification tells merchants outside the US and Canada to include VAT or GST in the price attribute. Your landing page has to show the same figure. If your platform stores net prices, the conversion belongs in the export logic, applied per country, not as a manual override in a spreadsheet.
How often should I refresh my product data?
Match your refresh rate to how quickly your prices and stock actually change. A stable catalog can run daily. A fast-moving one with flash pricing needs something closer to real time through an API integration. Automatic item updates exist as a safety net, and Google says they are not a replacement for keeping your own data current.
What image size should I use for product feeds?
Aim for 1,500 by 1,500 pixels or larger, which is Google's own recommendation. Google has announced a minimum of 500 by 500 pixels for all product images with enforcement from January 31, 2027. Keep files under 16MB, avoid watermarks and promotional text, and never upscale a small legacy image to meet the requirement.
My account was suspended for misrepresentation. What now?
Read the policy carefully, because Google treats misrepresentation as egregious and suspends without prior warning. Before appealing, fix the underlying cause. That usually means a clear and easily discoverable returns policy, visible contact details, an about page, and full disclosure of costs. Then submit one careful appeal with evidence rather than several rushed ones.
Do I still need product markup on the page if I have a feed?
Yes, and Google says so directly. Search Central states that providing both structured data on web pages and a Merchant Center feed maximizes your eligibility and helps Google verify your data. Markup also powers automatic item updates. The two are complementary surfaces, so treat them as one project with two halves rather than as alternatives.
Where does this leave the Rotterdam homeware store?
Back to our hypothetical Friday afternoon. Working the triage order, the store owner checks the last successful fetch and finds it failed three days ago, right after a hosting migration renamed the export file. No policy action. No penalty. One broken URL, 4,200 items expiring quietly, and a third of revenue gone by the weekend.
That is the honest shape of most Google Merchant Center emergencies. Not policy drama. Plumbing. Which is why the highest-value habit in this whole discipline is dull. Watch active item counts and last fetch status daily, and you will catch almost every catastrophe within 24 hours instead of days.
My prediction for the next two years. As shopping answers move further into Gemini, Lens, and image-led surfaces, the quality of your image assets and identifier coverage will matter more than clever title formulas. The merchants who win will be the ones whose product data is simply true and complete. Boring, again.
Priority next step, one thing only. Open your account, find the last successful fetch time, and confirm your active item count matches your live catalog. If those two numbers disagree, you have found this quarter's project. What is the strangest silent feed failure you have had to track down? The weird ones are always the most instructive.
Primary sources used in this article: Google's product data specification, Google's free listings documentation, and Google's misrepresentation policy.