Feed delivery methods
The four ways to get product data into Merchant Center, scheduled fetch of a hosted feed URL, manual uploads, the Content API and Shopping app connections, with the pros, cons and right fit for each.
Merchant Center can receive your products four ways: it can fetch a hosted feed URL on a schedule, take manual file uploads, receive live updates through the Content API, or connect to your store through a Shopping app. They differ in freshness, effort and reliability. This guide lays out when each fits, and why a stable hosted feed URL is the low-maintenance default for most merchants.
The four ways in
Every product in Merchant Center arrives through a data source. There are four, and the right one depends on how fresh your data needs to be and how much engineering you want to own:
| Method | How data gets in | Freshness | Effort to run |
|---|---|---|---|
| Scheduled fetch | Google pulls a hosted feed URL on a schedule | Per fetch (hourly–daily) | Low |
| Manual upload | You upload a file (CSV/TSV/XML) by hand or via SFTP | Per upload | Medium–high |
| Content API | Your system pushes updates to Google's API | Near real-time | High (engineering) |
| Shopping app connection | A platform app syncs your store to Merchant Center | Per app sync | Low |
Scheduled fetch (a hosted feed URL)
You host a feed file at a stable URL, and Merchant Center fetches it on a schedule you set. This is the workhorse for most stores.
Pros
- No manual step: set the schedule once and it runs.
- The URL is stable, so the connection survives catalogue changes, re-platforming and staff turnover.
- Easy to inspect: you (and Google) can open the same URL and see exactly what's being served.
Cons
- Freshness is only as good as your fetch interval: a daily fetch against hourly price changes will drift.
- The host must reliably serve current data every time Google pulls.
Fit: the default for the majority of merchants. Set the fetch frequency to match how fast your prices and stock move.
This is exactly where the /tools feed serving URL fits: it gives you one stable, always-current address that serves your enriched, spec-compliant feed. You point Merchant Center's scheduled fetch at it once, and it stays pointed there; the enriched data behind the URL updates continuously without you ever re-doing the Merchant Center connection.
Manual upload
You produce a file (CSV, TSV or XML) and hand it to Merchant Center, either through the interface or by dropping it on an SFTP/Google Cloud Storage location Google watches.
Pros
- Simple to start; no hosting or API needed.
- Fine for small, rarely-changing catalogues.
Cons
- Someone has to remember to do it. Stale uploads are a leading cause of price/availability mismatches.
- Doesn't scale: hand-uploading a large catalogue several times a week is a job nobody keeps up.
Fit: small catalogues, one-off tests, or a supplemental slice of data. Not a durable primary source for an active store.
Content API
Your systems push product updates directly to Google's API as they happen (a new price, a stock change, a delisted item), item by item, in near real-time.
Pros
- The freshest possible data. Price and stock reach Google almost immediately, which minimises mismatch disapprovals.
- Granular: update a single product without re-sending the whole catalogue.
Cons
- Real engineering. You build, host, monitor and maintain the integration, including auth, error handling and retries.
- More ways to break silently: a failed push leaves a product stale with no obvious file to inspect.
Fit: large or fast-moving catalogues with engineering resource, or platforms building Shopping integrations for others.
Shopping app connection
A connector app for your ecommerce platform syncs your store to Merchant Center for you, mapping platform fields to Google's attributes automatically.
Pros
- Fastest setup: often handles website verification and claiming too.
- No files or APIs to manage; the app keeps the sync running.
Cons
- You inherit the app's field mapping, which is frequently generic and leaves titles, categories and identifiers weaker than they could be.
- Less visibility and control over exactly what's sent.
Fit: getting live quickly, especially for merchants without technical resource, with the caveat that the out-of-the-box mapping is rarely optimal.
Deep dive Delivery method vs data quality, two different questions
The most common confusion here is treating delivery and quality as the same decision. They aren't. Delivery is how data reaches Google; quality is what that data says. A real-time Content API push of weak data still shows Google weak data, just faster.
Some consequences worth internalising:
- A fresh pipe doesn't fix thin data. The Content API's near-real-time freshness solves price/availability drift. It does nothing for a vague title, a missing GTIN or a top-level category. Don't reach for the API to fix problems that are actually data-quality problems.
- App connections optimise for setup speed, not feed strength. The generic field mapping that gets you live in ten minutes is the same mapping that leaves your titles as bare product names and your categories guessed. Convenient to start, a ceiling on performance if you never revisit it.
- The delivery method should be invisible and boring. The ideal is a source that's always current, always inspectable, and never needs re-connecting. A stable hosted URL fetched on schedule hits all three; manual uploads fail on "always current"; a bespoke API fails on "boring".
- Separate the two layers deliberately. The durable architecture is an enrichment/quality layer that produces good data, feeding a simple, stable delivery mechanism. That way you improve what Google sees (titles, categories, identifiers) without ever touching how it's delivered, and the enrichment is non-destructive, so your source store data is never overwritten in the process.
Put plainly: choose the delivery method for freshness and maintainability, and treat data quality as a separate, prior problem. The product data spec overview covers the quality side; this page is only about the pipe.
Choosing, in one line each
- Most merchants: scheduled fetch of a stable, always-current hosted feed URL.
- Small or static catalogue: manual upload is fine.
- Large, fast-moving, with engineers: Content API for freshness, but mind the maintenance.
- Need to be live today, no tech resource: a Shopping app connection, with a plan to strengthen the mapping later.
Whichever pipe you pick, the data flowing through it is what determines your results. Get the account set up cleanly first, then make the feed itself as strong as it can be.
Frequently asked questions
What's the most reliable way to keep my feed fresh?
For most merchants, a scheduled fetch of a hosted feed URL that's always current. Google pulls it on your schedule with no manual step, and because the URL is stable the connection never breaks even as your catalogue changes. The Content API pushes updates faster but needs engineering to build and maintain.
How often should Google fetch my feed?
Match fetch frequency to how often your prices and stock change. Fast-moving catalogues want daily or more frequent fetches; a slow feed against a fast-changing site causes price and availability mismatches that get products disapproved.
Can I use more than one delivery method?
Yes. A common pattern is a primary source (scheduled fetch or app connection) plus a supplemental feed for a slice of data that lives elsewhere. What you shouldn't do is have two primary sources fighting over the same products.