Product Feed & Merchant Center Compliance

The thing that gets your products disapproved is usually not in your feed. The #1 data-related disapproval cause is the feed disagreeing with the landing page Google crawls — a mismatch that is invisible to every validator that only looks at the file, and that no agent builds a check for, because it is not a property of the feed. This pack builds the whole surface: RSS 2.0 output validated offline against Google's product data spec shipped as versioned data, a consistency crawler that compares price, currency, sale window and availability against your real pages, GS1-correct GTIN handling, honest identifier_exists semantics, and page structured data generated from the same object as the feed so the two cannot drift. This pack is currently draft: no clean-room receipt has been published for it yet. When one is, this line will read N of M clean-room builds passed with all 15 acceptance checks — and until it does, treat everything below about the build as design intent, not evidence. What is already true today is that the acceptance suite runs hermetically: no Merchant Center account, no Google API, no network.

Example use cases

• A Rails/Django/Next.js store with a custom storefront that has no platform-supplied Google channel — the merchant is hand-writing a feed template and finding out what is wrong from Merchant Center Diagnostics, one three-day review cycle at a time.
• An agency running Shopping feeds for a dozen clients — the same feed-doctor command, wired into each client's CI, turns "the client emailed saying products vanished" into a build failure on the deploy that caused it.
• A headless commerce build where prices live in one service and pages render in another — exactly the architecture where feed and landing page drift apart quietly, and exactly the one where a consistency crawler pays for itself in a week.
• A handmade/vintage seller with no GTINs — custom goods, antiques and pre-1970 books are the case identifier_exists exists for, and the case everyone gets backwards in both directions.
• A store adding a second target country — the conditional rules (apparel attributes, shipping, tax, currency) are country-scoped, and the pack makes running one pipeline per country a config change rather than a fork.

Why this pack

No "always" claims — agents are stochastic, Google's rules move, and a passing check is not an approval. This is what the pack pre-solves, what it costs, and what you give up.

What a bare agent typically ships that this pack pre-solves (specific bug classes, not a claim that every agent hits every one):

• Valid XML, invalid feed. The output parses, the namespace looks right, and it is non-conforming: an id over 50 characters, an availability value Google retired, a price with a currency symbol in it, a missing availability_date on a preorder. Well-formedness checks pass all of these. A near-miss namespace URI (https:// instead of http://) is the sharpest version — the file parses perfectly and Google ignores every g: attribute in it.
• The consistency check that never gets written. Price mismatch between feed and landing page is ranked the #1 data-related disapproval cause, and structured-data inconsistency between feed and page markup the #2 (Productsup, 2025-12-10). Neither is a property of the feed, so an agent reasoning about "is my feed correct" never gets near them. This pack ships the crawler and a fixture storefront with planted drift to prove it works.
• identifier_exists, wrong in the expensive direction. An agent whose loop is "make the missing-GTIN error go away" sets identifier_exists: no on mass-produced goods. Google downgraded that error from a disapproval to a warning in late 2023, which makes it cheap to get wrong and hard to notice — the feed is accepted, the products just quietly underperform. Invalid-GTIN errors were found affecting 48.43% of merchants (and about 4% of submitted products) in DataFeedWatch's Multichannel Marketing Report 2023, as reported by Search Engine Land, 2023-10-31.
• Structured data that disagrees with the feed it just generated. The agent writes the feed, then writes the product page, computing the price a second time with a second rounding rule — and, when a sale is running, putting the regular price on the page while the feed advertises the sale price. Both look right in isolation. This pack makes them two projections of one object, and the acceptance suite feeds the generated markup back through the checker for every item to prove they cannot diverge.
• A checksum-only GTIN validator. GS1 mod-10 written left-to-right with a fixed weight is correct for one GTIN length and quietly wrong for the other three. And a restricted-prefix GTIN (2…, 02…, 04… — in-store and variable-measure ranges) is arithmetically valid, so a checksum-only check waves it straight through to a rejection.

Scale envelope

Derived from the shipped architecture and the pinned stack, not from a load test. Nothing here is receipt-measured; the pack has no receipt yet, and where a number is an estimate it says so.

• Feed generation is O(n) string building, in memory. At a typical ~700 B to 1.5 KB of XML per item, a 50,000-item feed is roughly 35–75 MB of string — fine for Node's default heap on a small container. First ceiling: about 100,000 items, where the whole-feed-in-memory approach starts to matter more than anything else in the pipeline. Estimate.
• Upgrade path past that ceiling: stream the feed instead of building it (the builder is one function and the <item> loop is the only part that changes), or split by google_product_category into several data sources — Merchant Center accepts multiple. Google's own documented ceiling for a feed file is far higher (4 GB), so this is a Node ceiling, not a Google one.
• The crawler is the real constraint, and it is time, not memory. At the default concurrency of 4 and a 200 ms page fetch, that is ~20 pages/second: 10,000 products in roughly 8–9 minutes, 100,000 in about 1.4 hours. Estimate — your page latency is the whole variable.
• Upgrade path for the crawl: raise concurrency to whatever your own origin tolerates (it is a parameter, and you are crawling yourself, so the limit is your infrastructure and your WAF, not a third party's rate limit); or stop crawling everything — crawl the items that changed since the last run, plus a rotating sample. That is the change most catalogues over ~20,000 items should make on day one.
• Validation is pure CPU over a JSON rule set. It is not the bottleneck at any catalogue size a Node process can hold.
• Storage: none. The pack persists nothing between runs, which is why there is no database in the stack and why verify.sh needs no Docker.
• One feed per target country is an architectural boundary, not a limitation to route around: the conditional rules and the currency check are country-scoped. Three countries is three configs through one pipeline.

What this comfortably covers as shipped: a single-country catalogue in the hundreds-to-tens-of-thousands of SKUs, with the doctor run in CI on every deploy and on a daily cron. What it isn't sized for out of the box: six-figure catalogues crawled in full every night, or multi-channel feed transformation across Google, Meta, Amazon and TikTok — the second one is what the feed-management SaaS category exists for, and this pack does not pretend otherwise.

On token savings: we are not publishing one. Every dollar figure in this catalogue that we stand behind comes from a harness receipt, and this pack does not have one yet. Buy it for the bug classes above — particularly the two that are invisible to any feed-only validator — not for a build-cost estimate we would have to invent.

Verified against

• claude-opus-5
• claude-sonnet-5
• claude-haiku-4-5

Supported stacks

• nextjs-feed

  node	24.18.1
  next	16.2.12
  react	19.2.8
  react-dom	19.2.8
  typescript	6.0.3
  cheerio	1.2.0
  vitest	4.1.10
  @types/node	24.13.3
  @types/react	19.2.18
  @types/react-dom	19.2.4

Estimated buyer token cost

1,331,000 tokens for one build pass (estimate, not a guarantee).