One record, four readers: product information syndication for Google, Meta, onsite search and AI assistants

An outdoor retailer told us this month that two out of three shoppers arriving from ChatGPT land on a product page. Their buying guides get “remixed by AI” with “very subtle attribution,” and the shopper who clicks through skips the guide and lands on the product. The guide became free research for the assistant. The product page became the front door.

Product information syndication is the delivery of one product record to every surface that reads it, and Lily Max does it by deriving the record from the product itself, scoring it per surface, and rendering each reader's version from the same facts, so a change made once lands on Google, Meta, onsite search and AI assistants together. Most retailers do not have that today. They have copies.

The same retailer sends products to ChatGPT through its commerce platform's built-in connection, while a separate tool handles the Google and Meta ad feeds. That is two copies of every product, maintained by two systems, on two schedules. They drift. Nobody notices until a shopper does, because the assistant recommended the fit and material it read in one copy, and the site search is reading the other.

Three machines read a retailer's catalog before a shopper ever sees it: Google's bidder, the AI assistant, and the retailer's own site search. Add Meta's catalog and it is four. This post is about how Lily Max keeps them reading the same thing.

Why does product information syndication drift?

Copies drift because every discovery surface reads a different part of the record first, and every tool that feeds one surface improves its own copy in its own vocabulary. Google Shopping reads the title, the product type and category, and the filterable attributes, and uses them to set the relevance floor in the auction. Meta reads attributes and the description to build the interest signal it targets with. Onsite search reads attributes as facets and the description as match text. An AI assistant reads the whole record as prose and judges whether it answers a question. The mechanics of that last reader are in how AI shopping assistants pick products.

Fix the material on the Google feed and the site facet still says the old thing. The retailer is not careless. Nobody ever asked the four tools to agree, because no system sat above all four.

The record: derived from the product itself

The facts the surfaces need mostly do not exist in the retailer's systems as fields, so Lily Max derives them from the product itself: the images, the existing copy, the category, the materials list. What a jacket works with, which occasion it suits, how a material behaves in rain: none of that is in the PIM, because no upstream process ever asked a merchandiser to write it.

Derivation is the first job in Lily Max, and it targets the fields most listings leave blank. Pattern, closure, silhouette, material and the category path are the ones we find empty most often, and the list runs to eleven fields, each derived per product and checked against the product before it becomes part of the record. The check matters more than the derivation. A wrong fact is worse than an empty field, so correctness carries the heaviest weight in the score every field gets before it is allowed in. The definition of enrichment we work to is in product data enrichment: when the machines are the reader.

How is the record scored per surface?

A set of goal-based agents scores the catalog against what each surface actually reads and ranks the gaps by how much they cost on that surface. The record is the same for every reader; what each surface rewards is not. A missing pattern attribute costs a Google Shopping listing a filtered query. The same missing attribute costs an onsite search facet. It costs the AI assistant nothing directly, but a missing occasion does, because “what should I wear to an outdoor wedding in October” is a question the assistant can only answer from a record that says so.

The scoring runs continuously, never as a one-off project, because catalogs churn and a rewrite done once describes products the retailer has stopped selling within a quarter.

Placement: which fact goes in which field?

After derivation, each fact is placed in the field each surface reads it from, so the title, the details, the highlights and the description each say something different instead of the same phrase four times. This is the part that changed most in 2026. Google stopped grading a listing on its title and description alone and started grading the whole listing. Cram the details into the description and it now reads as duplication. The details belong in the product details and highlights fields, which sit empty in most retailers' listings.

For Google that means the most-searched descriptor first in the title, named attribute pairs in product_detail, short benefit lines in product_highlight, and the sentence that answers the shopper's question at the front of the description, all within the limits in Google's product data specification. For onsite it means the same facts as facets in the words shoppers filter on. For an assistant it means the facts stated explicitly in prose, because an assistant cannot infer occasion from an image and does not try.

What each surface reads first, and what Lily Max renders for it from the one record.

Where do the nine attributes with no field live?

Nine of the 32 attributes shoppers search on have no Merchant Center field of their own, so Lily Max carries them in product_detail, product_highlight or the description, whichever the surface reads. Of the 32 in our working spec, 21 map to a long-standing Merchant Center attribute, and two arrived with the conversational attributes Google announced on 11 January 2026. The remaining nine are mostly contextual and compatibility facts: occasion, room or setting, weather suitability, works-with and substitutes. The full spec, with good and bad values per field, is in product attributes: the working spec.

That is the practical reason those facts get skipped by feed tools: there is no column for them. It is also why they are still available. Lily Max writes all 32 into the record and renders the nine homeless ones into whichever carrier field each surface reads, so the fact exists once and lands four times.

Change a fact once

The property this buys is simple to state. Change a fact once and every version carries it. A material correction made on the record shows up in the Google title, the Meta catalog field, the onsite facet and the prose the assistant reads, on the next render, with the version history recording which run changed it. The retailer keeps its existing feed tool and its existing site search. Lily Max runs inside that stack and writes into it. The first step for a new retailer is a free 30-day read of roughly 500 products from the Merchant Center feed before any spend, which is how we find out whether the record is the problem before anyone pays to fix it.

A seller in Denmark gave us the sharp end of why this matters: their customers research in AI but cannot buy inside it, so the assistant recommends and the product page has to close. If the two disagree, the shopper is the one who finds out.

Results

On a retailer's own site, products carrying the rewritten record produced 28.3% more revenue in a statistically significant A/B test, for a contemporary luxury brand. On Meta Advantage+, a holdout test cross-validated with Meta's own Conversion Lift measured a 21.4% improvement in ROAS for a footwear retailer. Both came from the same kind of record, rendered for two different readers.

Fewer than one in a hundred retail visitors comes from an AI tool today. I find that number reassuring rather than deflating. It means the assistant surface is still cheap to get right, and the record that gets it right is the same one already paying on Google and Meta this quarter.

What's next

Onsite rendering today runs through the retailer's existing search platform rather than through the Lily Max interface, which works and is not where we want it to stay. The next piece is direct facet publishing to the major site search platforms from the record, with the same version history the feed fields already have. After that, refresh scheduling: content is refreshed about four times a year because search-term data takes six to ten weeks to read, and we want the schedule set per category by the read time, with no calendar involved.