Introduction
A product feed isn't done once you build it. If anything, delivering it reliably every single day is far harder.
Generating thousands of SKUs in full every time gets heavy, and the truly nasty part is that when a feed stops, it stops quietly. There's no error screen — ad exposure just fades away.
This article explains the caching that keeps feed generation light, and the health checks that watch for whether delivery has stopped.
Caching to handle large SKU counts lightly
Why caching is needed
Google Merchant Center (GMC) periodically fetches the feed URL you registered. Fetching thousands of SKUs from Shopify and building XML on every one of those visits means non-trivial processing time and server load.
But feed contents don't flip minute to minute. Even when prices or inventory change, reflecting them into GMC every few hours is plenty practical. So let's reuse the generated result — that's the idea behind caching.
Fetch and build XML for all SKUs on every URL hit. Heavy processing, with timeout risk
Hold and reuse the generated result for a few hours. Keep load down while serving a fresh-enough feed
Keeping "just-right freshness" with a TTL
The cache gets a TTL (time to live). In this project we used a few hours. When the TTL expires, the feed is rebuilt on the next access and then reused for a set period again — over and over.
Too short and generation fires constantly, driving up load; too long and out-of-stock products stay listed forever. Judging that "just-right freshness" is the operational balancing act. The faster your inventory moves, the shorter you'll want the TTL.
Splitting large SKU counts with page size
At the scale of tens of thousands of SKUs, cramming everything into one XML becomes unreasonable, memory-wise. So we control the page size and make it possible to generate and serve the feed in splits.
By capping how many items we handle at once, we can return the feed stably no matter how much the SKU count grows, without straining memory. It's reassuring to bake in a design that withstands catalog growth from the start.
A mechanism to notice when it stops
Feeds stop quietly
As mentioned up top, the scary thing about feeds is that failure is invisible. A Shopify spec change, an API error, a cache inconsistency — the causes vary, but they all surface as "the ads had stopped by the time I noticed."
Feed stops = ads stop
GMC gets its product information from the feed. If the feed goes empty or can't be fetched, listed products vanish and neither Shopping ads nor free listings get delivered. It's a failure that hits revenue directly.
Watching generation with a health-check API
So we built a dedicated health-check API that confirms the feed is generating properly. It actually attempts to generate the feed and reports health against criteria like whether the product count falls within an expected range and whether required fields are present.
A monitoring service calls the health-check API at a fixed interval
Confirm the feed can be generated and the count isn't zero or an abnormal value
On a sharp count drop or generation failure, alert the person in charge
Treating a sharp count drop as an anomaly
The key is to watch not just "did it generate," but the change in product count. If a feed that normally holds thousands suddenly drops to a few dozen one day, that's a clear sign of trouble.
Cases where generation succeeds but the contents are hollow happen more often than you'd think. That's exactly why looking beyond "is it non-zero" to "is it extremely low compared to usual" lets you catch quiet failures early.
Conclusion
Feed operations rest on two pillars: "build it light" and "notice when it stops."
- Caching: reuse the generated result with a few-hour TTL to keep load down while staying fresh
- Page-size control: split large SKU counts and withstand catalog growth
- Health-check API: regularly monitor generation success and count to detect quiet failures
- Treat a sharp count drop as an anomaly to prevent hollow-feed accidents
The feed is a revenue-critical mechanism — if it stops, the ads stop too. For how the feed itself is built, see automated product feeds and mapping design; for the safeguards that protect listing quality, see managing feed quality.