Checklist · Evaluate

Agentic readiness checklist: the evaluate stage

An AI agent matches a shopper’s request against what your pages actually say. At the evaluate stage the question is whether the facts it needs, price, availability, sizes and terms, are present as text rather than implied by a picture or a layout.

1. The store refused the product page to the agent

   high

   Find the rule that answered. Your firewall, CDN or bot manager logs the request by URL and time, and the report gives both.

   • Allow the published Ottom user agent, and verified agent traffic in general, through that rule.
   • Set rate limits for product pages high enough for an assistant comparing several products in a minute.
   • Where the origin answers 503 under load, serve a cached product page rather than an error.
   See it on your own store

   1. Copy the product URL the report names.
   2. Open it in a private window with no extensions, from a network your store has not seen you on, such as a phone off wifi.
   3. Fetch the same URL with curl and the published Ottom user agent, and note the status it returns.
   4. Request it five or six times within a minute, the way an agent comparing products would, and check the later answers are still 200.

   Why this stops an agent

2. Price is not readable without running the page

   high

   Emit offers.price and offers.priceCurrency in the server rendered markup for every product.

   • If a pricing app rewrites prices client side, make it also rewrite the structured data, or render the correct price server side.
   • For sale prices, put the price the shopper pays in offers.price. A struck through original belongs elsewhere.
   • Check multi currency and market specific pricing separately. Each variant of the page needs its own correct value.
   See it on your own store

   1. Fetch a product page with curl so scripts do not run.
   2. Search the response for the price you expect to see.
   3. Search for "application/ld+json" and read the offers object. Check price and priceCurrency are present and correct.
   4. Repeat on a product that is on sale, and on one in a second currency if you run multi currency pricing. Those are the cases that break first.

   Why this stops an agent

3. Stock status is not exposed to agents

   high

   Set offers.availability on every product, using the schema.org InStock and OutOfStock values.

   • State availability per variant where variants differ, since a product being partly in stock is not the same as being in stock.
   • Make sure availability reflects the same source of truth as the storefront, not a cached value.
   • Expose stock in your product feed as well as in page markup. Agents commonly read the feed first.
   See it on your own store

   1. Fetch a product page you know is in stock and read the offers object in its JSON-LD.
   2. Check offers.availability is present and set to https://schema.org/InStock.
   3. Now do the same for a product you know is sold out. It should read OutOfStock rather than being absent or still InStock.
   4. For a product with variants, check whether availability is stated per variant or only once for the whole product.

   Why this stops an agent

4. Returns or shipping policy is only in an image

   high

   Publish the policy as page text. Keep the graphic if it suits the brand, and put the words on the page as well.

   • Include the specifics an agent needs to compare you: the return window in days, who pays return postage, and any exclusions.
   • Do the same for shipping: rates, thresholds and delivery times as text.
   • Link the policy pages from your sitemap, since they are rarely linked from navigation in a way an agent will crawl.
   See it on your own store

   1. Open your returns page and try to select the policy text with the mouse. If nothing highlights, it is an image.
   2. Fetch the page with curl and count the words in the response. A policy page with almost no text in the source is this stall.
   3. Do the same for shipping, warranty and any size guide a shopper would ask about.

   Why this stops an agent

5. Variants are not described in structured data

   high

   Add hasVariant entries to the Product markup, one per purchasable combination, each with its own offer carrying price and availability.

   • Name the option axes explicitly so an agent can map a shopper request onto them.
   • Give each variant a stable URL or an identifier so the choice can be referenced later in the journey.
   • Keep the page markup and the feed in agreement about which combinations exist.
   See it on your own store

   1. Pick a product with at least two options, for example size and colour.
   2. Fetch the page with curl and read the JSON-LD. Look for hasVariant entries, each with its own offer.
   3. If only one offer is present, check whether it reflects the cheapest variant, the default variant, or something else. Whichever it is, an agent cannot tell.
   4. Compare with your product feed. A feed that lists the full grid while the page does not is the common shape of this stall.

   Why this stops an agent

6. Product feed is out of date with the storefront

   medium

   Regenerate the feed on publish, so a price change reaches it the same day.

   • If regeneration is expensive, make it incremental rather than infrequent.
   • Include an updated timestamp per product so consumers can reason about freshness themselves.
   • Treat the feed as a projection of the same source of truth the storefront renders from, not as a separate export.
   See it on your own store

   1. Open your feed and note the most recent updated timestamp across all products.
   2. Change a price on one product in your admin, then reload the feed and see how long the change takes to appear.
   3. Compare feed prices with storefront prices for ten products, choosing sale items first.

   Why this stops an agent

7. Products have no GTIN or MPN to match against

   medium

   Populate the barcode field (GTIN, EAN or UPC) on each variant, which most platforms already have a field for.

   • For own brand goods with no GTIN, publish a stable MPN and use it consistently everywhere you list.
   • Expose the identifier in both the feed and the page structured data.
   • Keep identifiers stable across catalogue migrations. An identifier that changes is close to no identifier.
   See it on your own store

   1. Open your feed or a product page JSON-LD and look for gtin, gtin13, mpn or a barcode field.
   2. Check it is populated per variant, not only on the parent product. Different sizes usually have different barcodes.
   3. For own brand products with no manufacturer number, check whether an MPN or SKU is exposed at all.

   Why this stops an agent

Scan your store to find out which of these 7 it actually hits, rather than working through all of them.