Google Merchant Center feed: a product-data-first setup guide
Set up a Google Merchant Center feed from clean product data, map variants, read diagnostics, separate processing from approval, and keep offers fresh.
A Google Merchant Center feed is the handoff between your product data and Google's commerce systems. A successful fetch can still produce the wrong variant, a stale price, or a product that never becomes visible. The fix starts upstream. We treat the feed as an output of a normalized product record, then use Merchant Center to validate delivery, processing, eligibility, and freshness. Here is how to choose a source, map products and variants, troubleshoot failures, and keep the data current.
Start with product truth, not a feed file
A product feed is a destination-specific representation of your catalog. It is usually a file, a spreadsheet, an ecommerce-platform connection, or API input. A product data source is the registered path through which Merchant Center receives that representation.
The source should not become your master catalog. Keep a canonical record upstream with clear ownership:
- your ecommerce platform or ERP for price, inventory, and the live product URL;
- a PIM or approved content system for titles, descriptions, and category attributes;
- a DAM for approved images and video;
- supplier or manufacturer records for specifications;
- a product data layer for normalized values, provenance, and channel outputs.
This separation prevents a manual correction in one Google file from becoming a second, ungoverned version of a product. It also gives you one record to reuse for marketplaces, structured product data, internal search, and AI shopping surfaces.
Choose the source that matches your operating model
Merchant Center supports several ways to add products. The right choice depends on where your product data is governed and how quickly it changes.
| Source | Use it when | Main risk to control |
|---|---|---|
| Connected ecommerce platform | Your storefront is complete, structured, and already owns the product record | Connector mappings and sync delays can hide missing attributes |
| Hosted file, such as CSV, TSV, or XML | Your pipeline can produce a complete, validated catalog snapshot | A broken URL, permission, delimiter, or schema change can stop a refresh |
| Google Sheets | A small team manages a small catalog with infrequent changes | Manual edits and sharing permissions create drift |
| Merchant API | You have engineering ownership and frequent product or inventory changes | Accepted API input still needs processing and approval |
| Automatic website discovery | Your product pages expose reliable structured data and you want Google to find products from the site | Google can only extract what the pages and markup make explicit |
Google documents these methods in its product upload guide. A connector can be the right choice for a simple store. A normalized file or the Merchant API gives you more control when multiple systems contribute to one product record. Use one deliberate owner for each item. Running a connector, an automatic source, and a separate primary feed for the same products makes source precedence harder to reason about.
For a primary source, send the full set of active products you want Google to manage. Google recommends using one primary source for your products. A primary source can add or remove products, set language and country targeting, and apply data rules. If a product disappears from the latest primary snapshot, treat that as a product-removal event in your pipeline and alert on unexpected row-count drops.
Build one normalized row per sellable variant
Google needs product attributes. Your systems usually store them in different shapes. Normalize them before mapping to feed columns or API fields.
At minimum, give every active item a stable identity and a complete offer:
| Product-data layer | Google feed fields | What to keep stable |
|---|---|---|
| Identity | id, brand, gtin, mpn | The ID must continue to identify the same sellable item |
| Content | title, description, link | Copy and URL should describe the same product or variant |
| Offer | price, availability, condition | Currency, stock state, and condition must match the offer a shopper can buy |
| Media | image_link, additional_image_link | The primary image must represent the submitted item |
| Taxonomy | product_type, google_product_category | Map only after your internal category is controlled |
| Variant relationship | item_group_id, color, size | The parent relationship and option values must be explicit |
These attributes are part of Google's product data specification. Requirements vary by product and destination, so carry the target country and marketing method alongside the product record.
Consider a waterproof commuter jacket with a navy, medium variant. The normalized record should make these relationships explicit:
product_id: northline-commuter-jacket
variant_id: northline-commuter-jacket-navy-m
sku: NL-JKT-NVY-M
item_group_id: northline-commuter-jacket
brand: Northline
title: Northline Waterproof Commuter Jacket, Navy, Medium
color: navy
size: M
price: 148.00 USD
availability: in_stock
link: https://example.com/products/northline-commuter-jacket?variant=navy-m
image_link: https://example.com/images/northline-jacket-navy-m.jpgThe id in the output should identify the sellable variant, not only the product family. The item_group_id joins variants that shoppers understand as one product. Price, inventory, image, URL, and identifiers belong to the variant whenever they differ.
Do not use a title to infer relationships. A navy medium jacket and a navy large jacket need separate offer states even when they share a product page. A two-pack is a different offer from a single unit. An accessory is a related product, not a variant. Your canonical model should represent those distinctions before Google receives the data.
Register and submit a primary data source
In Merchant Center, open Settings → Data sources → Product sources → Add product source. Choose the method that owns your normalized output, then set:
- target countries;
- content language;
- data source label, when you need country or campaign grouping;
- marketing methods and destinations;
- the source name and file name, if the method requires them.
The data source setup instructions list the current fields and source types. A file URL must point directly to the data file. It cannot point to a page that renders the file in HTML. The file also needs the exact filename and extension configured in Merchant Center when you use SFTP or a similar upload path.
Before the first submission, validate a sample and the whole export:
- every row has a unique, stable
id; - each variant has the right parent relationship and option values;
- every URL resolves to the matching product or variant page;
- price, currency, availability, and condition are internally consistent;
- image URLs are reachable and match the item;
- delimiters, headers, encodings, and line breaks are valid;
- target country and language rules are applied to the right records.
For scheduled files, give Google's crawlers access to the file and its directory. Google says scheduled files must be smaller than 4 GB, must not block Googlebot or AdsBot-Google, and must use a supported file format. Configure the fetch schedule after the export is ready so the first scheduled fetch does not capture an intermediate file.
A supplemental source can add or override fields on products that already exist in a primary source. It cannot add or remove products on its own. Keep it as a controlled overlay for a narrow need, such as a custom label or a fast price and availability update. The primary record and its stable ID remain the join layer.
Separate submission, processing, approval, and visibility
These are different states. Treating them as one status is the source of many false success reports.
| State | What it proves | What it does not prove |
|---|---|---|
| Submitted or fetched | Merchant Center received the file or API input | The row parsed correctly or the product can serve |
| Processed | Google parsed the item and produced a product record | The item passed policy, landing-page, or image review |
| Approved | The product data is eligible for a destination | The product is currently visible in every destination |
| Visible | The product is appearing in the selected surface | The source will stay current or the offer will remain in stock |
For file sources, the Latest update report shows the upload status, attribute problems, and file-level issues. Google says this report checks basic file and data problems. The Products → Needs attention area contains the broader set of product and account issues.
The same distinction applies to API integrations. A successful productInputs.insert call means the input was accepted and processing started. It does not mean Google approved the product. The Merchant API product guide exposes the processed product and its status separately.
An item can also be approved and still not be visible. Google's product table separates Status from Visibility. A product may have approved data while another destination, account, policy, or store-availability issue prevents it from appearing. Read both fields before changing a feed that already processed successfully.
Diagnose from the source outward
Start with the earliest failed stage. Do not rewrite titles when Google never fetched the file.
| Symptom | Inspect first | Practical correction |
|---|---|---|
| Fetch or upload failed | URL, permissions, file extension, response content, SFTP filename, crawler access | Return the raw file directly, fix access, and publish a complete valid file |
| Processing errors | Header names, delimiter count, line breaks, encoding, required fields, invalid values | Validate the whole file before resubmitting; include a known-good row and a variant in validation |
| Products missing | Primary-source snapshot, IDs, exclusions, target country, source ownership | Compare expected IDs with the submitted snapshot and investigate unexpected removals |
| Wrong variant or image | id, item_group_id, color, size, variant URL, image URL | Map each sellable item as its own row and keep option values and media aligned |
| Price or availability disapproval | Product page, structured data, checkout, currency, shipping context | Reconcile the same offer across feed, page, structured markup, and checkout |
| Approved but not visible | Visibility, destination, account diagnostics, policy, store availability | Fix the visibility blocker instead of resubmitting unchanged data |
| Stale image or offer | Last update, source fetch time, image crawl, cache, upstream publish time | Measure the full lag and shorten the slowest step |
Google's data-source troubleshooting guide recommends starting with the source's processing report. For price and availability, compare the row with the landing page and checkout. Google's landing-page requirements say the product page should clearly show the title, description, image, price, currency, availability, and a way to buy the submitted product or variant. A valid file cannot repair a page that shows a different offer.
Record each failure with the source version, product ID, variant ID, timestamps, processing result, status, visibility, and owner. That turns a vague “feed issue” into a traceable data change.
Set freshness by field risk
One schedule for every field is easy to administer and wrong for most catalogs. Price and availability can change several times in a day. Product copy and specifications usually change through an approval workflow. Images change when a new asset is approved.
Set refresh targets by risk:
- Price, availability, and inventory: event-driven updates or the most frequent reliable schedule your source supports.
- New products and discontinued products: publish as part of the primary catalog snapshot, with an alert for unexpected additions or removals.
- Titles, descriptions, and attributes: update after approval, then on a predictable daily or event-based cadence.
- Images: update after asset approval and URL validation. Keep the old image available until the new URL is reachable.
- Country, language, and destination settings: change through controlled configuration, followed by a targeted diagnostic review.
Record four timestamps for every important item: source update, output publish, Merchant Center fetch, and processed-product update. The gap between them is your freshness lag. Alert when it exceeds the promise you make to shoppers or when the primary file's row count changes sharply.
A scheduled file is not real-time delivery. An API can accept an update quickly, while the processed product still takes time to appear. Google also says new products can take up to two days to appear after submission in some data-source setups. Build monitoring around observed processing and visibility, rather than promising an instant change after upload.
Where Catalog fits
Merchant Center is a channel destination. Catalog is the product-data layer upstream of that destination.
We help brands collect product facts from their existing systems, normalize identities and variants, enrich missing structured attributes, keep records synchronized, and publish live machine-readable product objects to AI commerce surfaces. That same normalized record can feed a Google output without turning Google into the place where product truth is maintained.
Use a feed-management workflow when your source data is already reliable and you mainly need destination mapping. Use Catalog when the underlying problem is that product data is fragmented, thin, inconsistent across variants, or difficult for AI systems to interpret. Catalog works beside your storefront, PIM, ERP, DAM, and channel feeds. It gives each output a better-controlled product record to consume.
For a broader view of the source-to-channel model, read our guide to ecommerce product data. For channel mapping and ongoing distribution, see product feed management. Those are separate concerns from the Google source lifecycle described here.
FAQ
Is a Google Merchant Center feed the same as a data source?
A feed is the product data you send. A data source is the registered method Merchant Center uses to receive it, such as a file, Sheet, connected platform, or API. One source can receive repeated updates.
Why did my feed process successfully while products remain disapproved?
Processing validates the file and basic product data. Approval also considers product policies, landing pages, images, price, availability, and other destination requirements. Start with Products → Needs attention and the item-level issue details.
How often should a Google Merchant Center feed update?
Update price and availability as often as those values change. Refresh slower fields after approval or on a daily schedule. Choose the cadence that keeps the offer on Google aligned with the offer shoppers can buy.
Should I use a supplemental source for my whole catalog?
No. A supplemental source is an overlay for products already present in a primary source. Keep the complete catalog and product lifecycle in the primary source, then use supplemental data for scoped additions or overrides.
A reliable Google Merchant Center feed starts upstream. Run a Catalog audit before you add another destination or another layer of manual fixes.
