Product feed optimization for shopping channels and AI agents

A product feed is a structured file of your catalog, one row per sellable item, sent to a channel on a schedule or pushed through an API. Google Merchant Center, Meta's catalog and most marketplaces consume some version of it, and most ecommerce platforms generate it automatically from the product record.

The feed is not your website. Whatever sits in the feed is what the channel knows about you, and anything that lives only on the product page or inside a theme template is invisible to it. That gap is where most feed problems begin.

At a glance: the fields that carry the most weight

• id is the unique, stable key for the item. Never reuse one across different products.
• title is the strongest ranking and matching signal on shopping channels, and the first thing an agent reads.
• description is where attributes either live as usable facts or disappear into brand prose.
• link and image_link point to the variant-specific page and the main image. additional_image_link carries alternates.
• price, sale_price and availability have to match the landing page or items get disapproved.
• brand, gtin and mpn are the identifiers a channel or an agent uses to reconcile your item with the same item sold elsewhere.
• google_product_category is the channel's taxonomy. product_type is your own.
• item_group_id plus color, size, size_system, material and pattern define the variant family and what separates its members.
• product_detail and product_highlight hold attribute pairs and the short bullets shoppers filter on. Most feeds leave both empty.

Meta's catalog uses most of the same field names, including id, title, description, availability, condition, price, link, image_link, brand and item_group_id, which is why a single clean source record can supply both channels. Custom labels, custom_label_0 through custom_label_4, exist for your own segmentation and never appear to a shopper.

A feed with every one of these fields populated correctly is rare. A feed with title, price, image and nothing else populated is common, and it is the version agents cannot work with.

For Google Shopping and Meta catalog ads, optimization is mostly about matching query language, passing policy checks and giving the channel enough signal to bid intelligently. That work is well documented and it still pays. It is also where almost every feed guide ends.

Title structure

Front-load the attributes a shopper types. A workable pattern for apparel is brand, product, key attribute, color, size. For hard goods it is brand, model, spec, quantity. Keep promotional language out entirely, because "free shipping" and "best price" in a title are a common disapproval reason.

Identifiers and disapprovals

Supply gtin, brand and mpn wherever the product has them, and only set identifier_exists to false for genuinely custom or handmade goods. Missing identifiers narrow the surfaces your items are eligible for and weaken the channel's ability to match your product to competing listings.

Images

Use a clean product image with the item filling most of the frame, no watermarks and no overlaid promotional text. Populate additional_image_link with alternate angles, because a single hero shot limits both ad formats and the visual matching that channels run behind the scenes.

Segmentation

Custom labels are the lever most accounts underuse. Tag items by margin band, seasonality, stock depth and bestseller tier, then structure campaigns and budgets against those labels rather than against product categories that mean nothing commercially.

All of this remains correct. It optimizes for a ranking system that treats your feed as a set of ad candidates competing in an auction. None of it makes your data legible to something that reads the feed as a database and filters it against a set of conditions.

Product data optimization for agents means writing your catalog so a machine can answer a constrained question from it without visiting your site. Agents do not rank ten cards and hand the shopper a grid. They filter a candidate set against stated conditions and return two or three items with reasons.

Picture the query "waterproof hiking boots, wide fit, under $150, in a US 11 and in stock". Every clause there is a filter against a field. If width sits only in your description prose, waterproofing is on a spec tab your theme renders, and size reads "11" with no size_system, you are filtered out while holding exactly the right boot in stock.

Shopify's guidance on agentic-ready product data describes the target as structured, machine-parsable and real-time, with variant grouping, precise taxonomy, literal descriptions and live price and inventory. That list is a fair summary of what the current generation of agents can and cannot do.

Being visible in one place is not being visible in the other

Productrise analyzed more than 2 million listings across over 100,000 SERPs in the US and UK between 9 and 31 August 2026. They found 1.28% product overlap between classic Google search and AI Mode, with matched products priced 21.6% higher in AI Mode and the main seller differing on 49.6% of matched products.

Read that as a warning against assuming your Shopping performance carries over. The two surfaces are pulling from the same catalogs and returning almost entirely different products.

Where agents are still weak

Be realistic about the current state. Agents handle single-axis variation reasonably and struggle when size, pack count and style vary together on the same product. Some large retailers actively block agent traffic, so the set of products agents can see is not the set of products that exist.

That weakness is an argument for expressing complexity as real fields rather than as strings inside a title. More on how agents behave is in our overview of AI shopping agents.

Variant grouping breaks more feeds for agents than any other issue. The mechanic is simple: every variant of the same product shares one item_group_id, and each row carries the attribute values that make it different from its siblings.

Simple does not mean common. Most platform exports get some part of this wrong, and the damage is invisible in Shopping reporting because a poorly grouped feed still serves ads.

The five ways it breaks

• Parent-only rows. One row per product with "S, M, L" jammed into the title. The agent sees a single item and has nothing to commit a size to.
• Orphan variants. One row per variant, each with a unique id and no item_group_id. Twelve rows that read as twelve unrelated products, so "the black one in a medium" cannot be resolved.
• Grouped but undifferentiated. item_group_id is set correctly, but color and size are blank or identical across rows because the export only mapped the first option. The group exists and carries no information.
• Inconsistent vocabulary. "L", "Large", "lg" and "12" describing the same size across one catalog, with size_system and size_type left empty so there is no way to interpret them.
• Pack count hidden in the title. "Dog food 12 pack" with no multipack value. An agent asked for a twelve pack is matching a number inside a string rather than reading a field.

What good looks like

• Every variant of a style shares one item_group_id, and no group has only one member when the product genuinely has variants.
• Rows in a group differ on exactly the attributes that vary, and those attributes are populated on every row.
• size_system and size_type are set, so "11" is unambiguous and a wide fitting is a field rather than a word in the title.
• multipack and is_bundle carry quantity and bundling instead of the title doing that work.
• Each variant's link opens the product page with that variant preselected, and the price on that page matches the row.

If you run on Shopify, the mapping from the admin to the feed is where this usually goes wrong rather than the data itself. That mapping is covered in detail on our page about Shopify agentic commerce.

Product catalog optimization is the layer above individual fields: how the whole catalog is categorized and described, so a ranking system and a filtering system can both place your items correctly. Two things dominate it, taxonomy depth and description style.

Taxonomy precision

Set google_product_category to the deepest node in the published taxonomy that is still accurate for the product. A hiking boot filed under a top-level apparel node sits in the same bucket as belts and scarves, and the channel has to guess what it is looking at.

Depth also changes how an agent narrows. Category is usually the first filter applied, before price or attributes, so a shallow value removes you from consideration before any of your good attribute data is read.

Use product_type for your own breadcrumb path, something like "Footwear > Boots > Hiking > Men's", and keep it consistent across the catalog. It carries detail the channel taxonomy does not have, and it is free.

Literal versus marketing descriptions

Compare two openers for the same boot. The first: "Built for the weekend warrior who refuses to slow down, this is our most-loved boot yet." The second: "Waterproof full-grain leather hiking boot with a seam-sealed membrane, 5 mm lug depth, available in standard D and wide EE widths, US 7 to 14."

Both are honest. Only the second contains values a machine can test a condition against. Keep the brand line if it earns its place, and put it after the attributes rather than in front of them.

Better still, stop relying on the description field alone. Google's product_detail attribute takes section name, attribute name and attribute value triples, which turns "induction safe" from a sentence into a field. product_highlight takes the three or four short statements shoppers actually filter on.

The same principle applies to media. A product video with no structured metadata is an opaque file to an agent, which is the problem our page on catalog video for AI search deals with directly.

An agent may read your data and act on it within seconds. Price and availability therefore have to be true at read time, not true at the moment the feed was last built.

A scheduled fetch that runs once a day means your feed can be a full day stale. That produces two distinct failures: an agent recommends something you no longer have, and the channel disapproves items for mismatches between feed price and landing page price. Push updates through the platform's API for anything that moves quickly rather than waiting for the next fetch. Scheduled fetch options and API update quotas both change, so read the current limits in Google's Merchant API documentation before you design around a particular refresh rate.

Set availability honestly. The values in_stock, out_of_stock, preorder and backorder mean different things, and marking a three-week backorder as in_stock is the fastest way to have an agent build a cart that collapses at checkout.

Feed rules

Merchant Center feed rules and Meta's catalog rules transform data after it leaves your platform. Typical uses are mapping your internal category strings to the channel taxonomy, prepending brand to title, setting a static value where the export sends null, and splitting a combined size field into size and size_system.

Rules are the right tool when the source system cannot be changed this quarter. They are the wrong tool as a permanent architecture, because each one is a piece of product truth that lives outside your catalog.

Supplemental feeds

A supplemental feed joins on id and overwrites or adds fields on items that already exist in the primary feed. It is the fastest way to add fields your platform refuses to export: product_detail pairs, product_highlight bullets, custom labels, corrected google_product_category values and sale price schedules.

It cannot create new items, so the primary feed still has to be complete. Document every rule and supplemental feed you add, or the next person inherits a feed nobody on the team can explain.

You can find out whether your feed has an agent problem in about an hour, with the feed file and a spreadsheet. Nothing here needs developer time.

Run this on your own feed this week

1. Export the current primary feed from Merchant Center or your platform and open it in a spreadsheet.
2. Count rows where item_group_id is blank, then divide by total rows. Anything above a few percent on a catalog that has variants is a grouping problem.
3. Pick a product you know has twelve variants and filter to its item_group_id. You should see twelve rows differing only on the attributes that vary.
4. Count distinct values in the size column. If "L", "Large" and "lg" all appear, your vocabulary is broken.
5. Count rows where google_product_category has fewer than three levels in its path.
6. Read the description field for your ten highest-spend SKUs, cold. Can you state material, dimensions, fit and compatibility from the field alone?
7. Take five products and compare feed price and availability against the live product page right now. Log every mismatch.
8. Ask two AI assistants your top three buying questions, once naming your brand and once not, and note whether they return the right product, the right variant and the right price.

Easy fixes, doable in under a week

• Populate item_group_id across every variant family. Good looks like: every row in a family shares one group id, and no family with real variants has a single member.
• Normalize size and color vocabulary with a feed rule. Good looks like: one value per concept across the catalog, with size_system and size_type set.
• Deepen google_product_category on your top 200 SKUs. Good looks like: the deepest accurate node, applied by a rule so it survives the next export.
• Rewrite the description opener on your top 50 SKUs. Good looks like: the first two sentences carry material, dimensions or capacity, fit and compatibility, with the brand line after them.
• Add a supplemental feed with product_detail and product_highlight. Good looks like: the four attributes shoppers filter on exist as fields rather than as prose.

The easy fixes patch the feed. The harder work fixes the catalog that produces the feed, and that is the only version of this that holds past the next platform migration.

The harder work

• Fix at source rather than in rules. Getting attributes into the product record means touching the PIM or the platform, agreeing what each field means and backfilling thousands of SKUs. Rules stop being needed once this is done.
• Define an attribute schema per category. Boots need width, waterproofing and lug depth. Coffee needs roast, origin and grind size. Somebody has to decide the required fields per category and enforce them at product creation, or the gaps reappear with every new range.
• Move from scheduled fetch to pushed updates. Real-time price and inventory is an engineering project with a queue, retries and monitoring behind it, not a setting.
• Tag your product media. Video carries more of the product story every year, and most of it ships with no structured metadata, so an agent sees a file rather than a claim about the product.
• Give the taxonomy an owner. Decide who approves a new attribute and who maintains the category mapping, or the catalog drifts back inside two quarters.

Where QuickAds fits

We do two things here, and they are separate purchases. The first is the Shopify catalog fix: variant grouping so every family shares a group id with properly differentiated rows, taxonomy mapped to the deepest accurate node, product fields rewritten literally so attributes are parseable, and live price and stock sync so the feed, the page and the structured data agree. That is the work described above, run on your store instead of handed to you as a list.

The second is creative. We ship 100+ creatives a month on a 5-7 day turnaround, with creative intelligence trained on 32M+ ads informing the concepts, and we have managed over $200M in ad spend. For catalog video we generate product video per SKU with structured metadata and schema attached, so agents and AI search can parse what is in the video.

The wider position: we cover creative intelligence, strategy, production and campaign management across the chain. Analytics-only tools read performance and stop. Premium production shops make assets and stop. Software starts at $299/mo and managed engagements start at $5,000/mo, and you can see the full model on our creative as a service page.