Google Merchant Center Feed: The Complete 2026 Guide

Two things make 2026 no ordinary year for anyone feeding product data to Google: since December 2024, the EU’s General Product Safety Regulation (GPSR) has required additional disclosures in the feed — and on August 18, 2026, Google shuts down the Content API for Shopping for good. If you feed your product data programmatically and haven’t migrated by then, you lose your Google Shopping visibility that day, without warning.

Most Merchant Center guides don’t cover either topic. They explain title optimization, images, GTINs — useful, but tactical. This guide goes further: from required attributes through systematic error troubleshooting to the two structural issues that will decide your visibility over the next twelve months.

What Is a Google Merchant Center Feed?

A Google Merchant Center feed is the structured data source through which an online store submits its product information to Google — the foundation for Google Shopping ads, free product listings, and increasingly Google’s AI-powered shopping features. The feed consists of individual product entries with standardized attributes (ID, title, price, availability, image, GTIN, and others) that Google checks against its product data specification before a product goes live.

Technically, a feed can be submitted three ways: as a file upload (CSV, TSV, XML, XLS/XLSX), via a scheduled fetch from a URL, or programmatically through an API. All three paths go through the same data quality check, which can take up to 72 hours — one reason freshly uploaded products don’t appear instantly.

Required Attributes & Data Quality

Eight attributes form the baseline Google won’t even evaluate a product without: ID, title, description, link, image, availability, price, and brand. For products sold in the EU and several other regions, one more attribute is functionally mandatory even though many guides skip it: unit pricing, required whenever a product is sold by weight, volume, length, or area.

The GTIN row deserves attention: products with a correct GTIN score, on average, 20 to 40 percent better in Shopping auctions than identical products without one — an attribute officially labeled “recommended” that behaves like a hard requirement in practice.

Completeness beats volume: a feed with the eight required attributes, GTIN, and correct unit pricing performs more reliably than a feed with 40 half-filled optional fields. Google weighs consistent, verifiable data more heavily than sheer data volume.

Troubleshooting Feed Errors Systematically

The Diagnostics page in Merchant Center (under Products → Diagnostics, labeled “Needs attention” in the newer interface) lists every issue with its cause and the affected products. Most rejections fall into four recurring categories:

1. Price mismatch — The feed price doesn’t match the landing page price, usually from delayed sync during a sale.
2. Availability mismatch — A product is reported “in stock” while the store itself shows it as sold out.
3. Blocked or broken link — robots.txt blocks the crawler, the URL redirects elsewhere, or the landing page returns an error status.
4. Insufficient data quality — Missing required attributes, generic images, or titles that don’t identify a category.

File uploads also carry a hard 4 GB per-file limit; when an error appears without a clear cause, waiting a few hours and re-uploading often resolves it, since Google-side processing hiccups don’t always surface immediately.

GPSR Disclosures in the Feed

Since December 13, 2024, the EU’s General Product Safety Regulation (GPSR) has applied to most non-food consumer products. For Google Merchant Center, that means: alongside the classic product attributes, you now need manufacturer information and, if the manufacturer isn’t established in the EU, details on the “responsible person.”

The responsible person can be the manufacturer itself, an EU importer, an authorized representative, or — if none of those are established in the EU — a fulfillment provider. You need that person’s name, postal address, and email, plus product-specific warnings and safety information where relevant.

In practice: if you already maintain GPSR data for Amazon or your own store, pull the same structured information into your Google feed instead of capturing it a second time. This is exactly where a single source of truth beats maintaining separate data islands per channel — more on that in the feed architecture section below.

Content API to Merchant API: The Migration by August 2026

This is the most underestimated deadline for anyone feeding product data programmatically — through a custom system integration, a bespoke store integration, or a PIM system.

Only programmatic integrations are affected. If you manage products exclusively through manual file uploads or Google Sheets, the API migration doesn’t touch you directly — those paths remain unchanged. For stores on standard platforms like Shopify, Shopware, or WooCommerce, the respective Google Shopping plugins typically handle the migration automatically; the question worth asking your plugin vendor is when that update ships.

The risk concentrates in custom integrations: in-house middleware, a self-built PIM interface, or an older agency integration that’s been running unchanged for years. That needs an actual migration plan, not hope for automatic compatibility. The Merchant API itself is modular — products, inventory, accounts, data sources, and reporting are separate sub-APIs you can connect individually, which means less overhead in the medium term than the monolithic Content API, but a deliberate migration decision in the short term.

Feed Architecture as Your Catalog Grows

Everything above assumes product data is maintained manually in the feed or transformed through simple rules. That works reliably up to a few hundred SKUs. Once you’re past several thousand products, multiple suppliers, or multiple sales channels (Google, Amazon, comparison shopping engines, your own store), the question becomes strategic: where does data ownership actually sit, and how many systems maintain the same information in parallel?

Three architectures typically compete for that role:

Manual maintenance directly in the feed — workable up to just under a thousand products with a stable catalog. Every change to title, category, or GPSR data has to be pushed by hand; error risk grows linearly with catalog breadth.

Attribute rules in Merchant Center — cover recurring transformations (title templates, category mapping, brand backfill), but don’t solve the underlying problem when the source data itself (store platform, ERP) is incomplete or inconsistent. Rules transform data; they don’t repair missing raw data.

A central PIM system as the single source of truth, generating feeds for every channel automatically — Google, Amazon, your own store, and comparison engines all pull from the same, channel-adapted data foundation. This pays off once product data is maintained by multiple people or systems and cross-channel inconsistencies are already visible — not before. A PIM system for a catalog of two hundred stable products is overengineering.

If you run multiple sales channels in parallel, the decision shouldn’t rest on the feed alone but on your overall system landscape — a topic covered in more depth in the comparison of leading e-commerce platforms.

Using Automation & Attribute Rules Correctly

Attribute rules let you define conditions — “only products in category X,” or “only when the title contains a specific term” — and automatically set or correct attributes based on them. Before applying a rule in production, you can test it in preview mode or against a separate copy of the feed, without putting the live catalog at risk.

Good first automations are usually: backfilling missing brand values per manufacturer category, normalizing titles to a fixed pattern (brand + product type + core attribute + size), and pulling GTINs from a separate master-data table when they’re missing at the source. Larger transformations — full GPSR data, or channel-specific pricing logic — belong further upstream, in the source data, rather than in a feed rule, because otherwise they’re only correct in the Google feed while Amazon and your own store keep showing stale data.

Checklist: 15-Minute Feed Health Check

FAQ

Conclusion

A Google Merchant Center feed in 2026 isn’t just a marketing checklist item anymore — it’s a technical and legal systems question. Keep required attributes and unit pricing clean, don’t skip GPSR disclosures, and settle early whether a custom integration needs to migrate before August 18, 2026, and you’ll keep visibility while a good chunk of the competition only notices these three points once products start disappearing from the catalog.

The strategic question underneath isn’t “how do I optimize my feed,” but “where does my product data actually live, and how many systems are maintaining the same information redundantly.” As your catalog grows, that answer determines long-term visibility more than any single attribute tweak.

References

1. Product Data Specification - Google Merchant Center Help
2. Unit pricing measure [unit_pricing_measure] - Google Merchant Center Help
3. Set up attribute rules - Google Merchant Center Help
4. Merchant API - Google Merchant Center Help
5. Migrate from Content API for Shopping to Merchant API - Google for Developers
6. Fix Merchant Center disapprovals for product data quality - Google Merchant Center Help
7. General Product Safety Regulation (GPSR) - European Commission