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](https://www.productsup.com/blog/top-5-reasons-for-google-merchant-center-disapprovals-and-how-to-fix-them-in-2026/)).

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](https://searchengineland.com/top-data-errors-that-cause-google-shopping-to-disapprove-products-433993).

• *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.

Target models

• 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

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