Introduction
Search for a product name on Google and you get that panel of photos and prices labelled "Shopping." Getting your own products in there means handing product data to Google Merchant Center (GMC for short — the console where you register product information with Google). That bundle of data is the product feed.
Most stores hand feed generation to a dedicated app. For the apparel-and-gear EC site I worked on, we deliberately skipped the app and built our own XML feed (a text file that lists data in a fixed, machine-readable format) on the site side instead. The catalogue runs to several thousand SKUs — the unit you get when you count products down to individual colours and sizes — and prices and stock move every day.
This article covers why we chose to build it ourselves, and how the system that keeps thousands of SKUs current every day is put together. No programming details ahead. If you come away with a feel for where the data comes from, how it gets converted, and how it reaches Google, that's plenty.
Why we built the feed ourselves instead of using an app
Some adjustments simply aren't in the app's settings screen
Feed generation apps are well made, and they work from day one. The flip side of that convenience is that you can't step outside the set of options the app provides. Requests like "change how the title is assembled for this product group only" or "exclude anything carrying a particular tag" hit a dead end the moment there's no matching field on the settings screen.
Build it yourself and you decide the conversion rules from product data to feed. Rules you can rearrange to suit how you actually sell. That was the main motivation. The conversion logic itself isn't complicated, so even a non-engineer can work through the spec while an AI agent (a development assistant you direct through conversation) handles the implementation.
One place to manage feeds for several sites
This project ran several EC sites off the same product foundation. Each site carries a slightly different range of products, in a different display language and currency.
With an app, every new site adds another subscription and another round of setup. Building it ourselves lets one mechanism emit a different feed per site. Point the fetch URL at a particular site and you get that site's content back. Managing it all in one place cut a noticeable amount of routine work.
The same feed powers free listings, not just ads
People assume the product feed exists for Shopping "ads." The same feed also drives Google's free listings — the slots where products appear in search results without any ad spend.
Keep the feed in good shape and your products stay visible in search results even during periods when no campaign is running. The feed isn't an accessory to advertising; it's the foundation of your acquisition. Seen that way, building it properly rather than leaving it entirely to an external app starts to look worthwhile.
How the feed gets built and reaches Google
One URL returns the XML
The mechanism itself is simple. Hit a single URL, /api/merchant/feed.xml, and it returns XML in a format GMC can read. On the GMC side you just register that URL. From there GMC fetches it at regular intervals and pulls in the latest product data.
Product names, stock, and prices are pulled out together
One URL converts everything into Google's format
Stored for a few hours and reused
Fetches the URL periodically and feeds Shopping ads and free listings
In short: between Shopify, which holds the product data, and Google, which wants to receive it, we placed a single window that translates and hands it over.
Product data comes from Shopify
Shopify holds the correct values for stock and price. The feed generation endpoint queries Shopify's admin-side data window (the Admin GraphQL API) and receives product names, descriptions, prices, stock status, images, and GTINs (the international identification numbers printed on product barcodes) in one go.
We use GraphQL — a way of querying that lets you name exactly the fields you want and get them back together — because it collects everything in a single request. Fetching field by field would make the retrieval alone slow for several thousand SKUs. The larger the catalogue, the more that difference shows up in processing time.
Converting to XML that matches Google's spec
The product data we fetch can't be handed to GMC as it is. GMC expects fixed field names (title, description, link, image_link, price, availability, and so on), each with its own formatting rules.
So each Shopify product is converted, one at a time, into a block of XML that follows that spec. Deciding which piece of product data maps to which field is what determines feed quality, more than anything else. The mapping design article covers that in detail.
Three things that matter once it's running
Caching, so thousands of items aren't rebuilt every time
Fetching thousands of SKUs from Shopify and converting them to XML on every visit means a heavy process runs each time GMC comes to collect the URL. If retrieval and conversion take too long, GMC can time out and the feed never loads at all.
So the generated result is stored for a few hours and reused. Feed contents don't change by the minute, so that's enough. Capping how many items are handled at once, and generating in chunks, also means the response stays reliable as the catalogue grows. That design is covered in caching and health checks.
If the feed stops, the ads stop
This one is easy to overlook: when the feed stops, the ads stop. If the feed fails to generate or comes back empty, GMC can no longer list the products, and ad delivery cuts out along with it.
The awkward part is that this failure never appears on screen. No red error in the admin — just a shrinking number of listed products and sales that slide over a few days. That's why you need a way to confirm from the outside that the feed is still being generated properly, in the form of a dedicated health-check URL.
Quality control to cut disapprovals
GMC reviews every product you hand it. If a required field is missing, or the product runs into a listing policy, that product is disapproved and never appears.
Disapprovals steadily reduce how many products are listed
One or two disapprovals are hard to spot, but they stack up, and the number of listed products can drop by several hundred. Tracing "the ads aren't performing like they used to" back to a pile of accumulated disapprovals is a common story.
Reliably excluding draft and unpublished products, and checking for missing required fields before anything is handed over. Those quality-control details are covered in managing feed quality.
Summary
Building the Google Shopping product feed yourself, rather than relying on an app, means the conversion rules, the exclusion conditions, and support for multiple sites can all be designed around how you actually operate.
- Why build it yourself: conversion rules that aren't limited to an app's settings, plus central management of several sites
- How it works: fetch product data from Shopify, convert it to XML matching Google's spec, and serve it from a single URL
- What matters in operation: keep it light with caching, catch stoppages with health checks, and cut disapprovals with quality control
The feed isn't an accessory to advertising — it's the foundation of acquisition, and it works for free listings too. Since ads stop when it stops, it's worth building carefully and watching continuously.
Each theme is explored in the sub-articles below.
Mapping Product Data to the Feed Specification
How titles, GTINs, categories, and stock status are converted into Google's format.
Feed Caching and Health-Check Operations
Caching that keeps large catalogues light, and monitoring that catches a stopped feed.
Managing Feed Quality — Exclusions and Validation
Excluding products that shouldn't be listed, and validating data to reduce disapprovals.