To get your store found by shopping agents, your product data has to be readable without a human looking at the page. That means complete structured markup on every product, a clean and current product feed, unambiguous price and stock fields, and shipping and returns terms stated as data rather than buried in a policy page.
Automated shopping assistants are increasingly the layer between a buyer and a catalog. They do not browse. They query, compare fields, and recommend. A store with beautiful photography and thin structured data is invisible to that process, however well it converts human visitors. This article covers what agents actually read and the order to fix it in.
To Get Your Store Found by Shopping Agents, Know What They Read
An agent answering “find me a 12-cup stainless French press under $60 that ships in two days” is matching fields, not reading prose. It needs to resolve, per product:
- A stable product identity and a canonical URL
- A specific title and a description with real attributes in it
- Price, currency, and whether that price is current
- Availability, as a value rather than a badge image
- A product identifier — GTIN, MPN, or your own consistent SKU
- Attributes that matter for filtering: size, material, capacity, colour, compatibility
- Shipping cost and delivery timeframe
- Return window and conditions
- Images with a reliable URL
If any of those live only inside page design, a JavaScript tab, or a PDF, they do not exist as far as an agent is concerned.
Start With Structured Product Markup
Structured data is how you state those facts in a machine-readable format alongside the visible page. The widely supported vocabulary is schema.org, usually implemented as JSON-LD in the page head.
For a store, the markup that matters most is the Product type with a nested Offer. At minimum, populate:
| Field | Why agents need it |
|---|---|
name | Matching the query to the product |
description | Attribute extraction when fields are missing |
sku / gtin / mpn | Resolving the same product across sources |
brand | Filtering and trust signals |
image | Presentation in agent results |
offers.price + priceCurrency | Price comparison and budget filters |
offers.availability | Excluding what cannot be bought |
offers.priceValidUntil | Knowing whether the price is stale |
offers.shippingDetails | Delivery-time filtering |
offers.hasMerchantReturnPolicy | Return-policy filtering |
additionalProperty | Everything else: capacity, material, dimensions |
Two rules make the difference between markup that helps and markup that hurts. First, the structured data must match what the page shows a human — mismatches get the markup distrusted or ignored. Second, it has to be generated from your real product records, not hand-written once, or it drifts out of date the first time you change a price.
Most ecommerce platforms emit some product markup by default, and it is usually incomplete. Check an actual product page with a structured data testing tool rather than assuming the platform handles it.
Do not request or display reviews you do not have
Review and rating fields are part of the vocabulary, and the temptation is to populate them. Leave them empty until you have genuine reviews from real customers. Fabricated ratings are a trust problem, a policy problem, and an easy thing for an agent ecosystem to detect and penalise.
Fix the Feed, Not Just the Pages
Structured markup covers agents that crawl your pages. Many commerce surfaces instead ingest a product feed — a structured file listing your whole catalog. Both routes matter, and the feed is often the one that is quietly broken.
A healthy feed has:
- Every sellable product, and nothing else. Out-of-stock items should be marked, not silently dropped and re-added, which looks like churn.
- Current prices. Feed updates should be automated against your product database, ideally at least daily.
- Specific titles. “Cast Iron Skillet 10 Inch Pre-Seasoned” beats “Our Best Skillet.” Agents parse titles for attributes.
- Populated identifiers. Missing GTINs are the single most common reason products get excluded from comparison surfaces.
- Correct variant structure. Each buyable variant needs its own row with its own identifier, price and availability. A single parent row with “sizes available” is unusable.
- Category mapping. Map to the taxonomy each destination expects rather than only your internal categories.
Run a feed diagnostic before anything else. Most stores discover a meaningful share of their catalog is being rejected for reasons nobody has looked at in a year.
The Details That Decide Agent Recommendations
Once your data is readable, the comparison is on substance. Agents weight the things buyers ask them to weight, and those are mostly the unglamorous fields.
Shipping, as data. Delivery speed and cost are primary filters. If your shipping terms are a paragraph on a separate page, state them in structured form too — per region if they differ.
Returns, as data. Return window, who pays return postage, and any restocking condition. An agent asked for “easy returns” needs a value to compare.
Stock accuracy. An agent that recommends an unavailable product produces a failed purchase, and ecosystems learn from that. Accurate availability is a ranking input, not an administrative detail.
Variant completeness. If a buyer asks for a specific size and only the parent product is exposed, you lose the match entirely.
Price consistency. Price in the markup, the feed, the page and checkout must agree. Mismatches are a strong distrust signal.
A Practical Sequence to Get Your Store Found by Shopping Agents
Work in this order. Each step makes the next one more effective.
- Audit one product end to end. Take a representative product and list every field above. Note which are present in the markup, which only in the page design, and which are absent entirely. This tells you whether you have a template problem or a data problem.
- Fix the product template. Correct the structured data output once, at the template level, so every product inherits it.
- Backfill the data gaps. Identifiers, dimensions, materials, compatibility. Tedious, and the highest-leverage work in the whole list.
- Repair the feed. Resolve rejections, populate identifiers, restructure variants, automate the refresh.
- Publish shipping and returns as structured data. Not only as policy pages.
- Verify checkout works without a human. Test the path on mobile, as a new visitor, with no account. Agent-assisted purchases fail at the same places human purchases fail — forced account creation, surprise fees at the last step, broken payment options.
- Re-test and monitor. Validate the markup on a sample of products monthly, and watch feed rejection counts as an ongoing metric rather than a one-off cleanup.
What Not to Do
Do not cloak. Serving different data to automated requests than to humans is detectable and gets stores excluded.
Do not block everything in robots.txt by reflex. Decide deliberately which automated agents you want reading your catalog. Blanket blocking makes your products unfindable on the surfaces you are trying to reach.
Do not treat this as an SEO side project. Search optimisation targets a human clicking a result. Agent readiness targets a machine resolving fields. The work overlaps but the completeness bar is much higher — a human forgives a missing material field, an agent filters you out on it.
Do not inflate attributes. Specifications that do not match the product produce returns and distrust, and both are measurable.
Readable Data Is the Whole Job
Getting found by shopping agents is not a new marketing channel so much as a data hygiene standard. Complete structured markup, a clean feed, honest attributes, accurate stock, and a checkout that works without hand-holding. Stores that have those will be considered. Stores that do not will not appear at all, regardless of how good the products are.
Start with the single-product audit in step one — it takes under an hour and usually reveals the whole pattern. For a full catalog-level pass against the field list above, see the Technical SEO Audit & Roadmap page on this site.