# Agent Selection Checklist

> When an agent compares you against competitors, are you doing what wins the choice?

A self-assessment of what wins the agent's choice once you're eligible: the legibility, completeness, and measurement signals no validator checks.

_Self-assessment, not a measured audit. Which signals agents actually weight is undisclosed; these are reasoned, evidence-typed levers, not guarantees._

<!-- Canonical: https://agentmint.net/tools/agent-selection-checklist/ · v1.1 · By Abdalsalaam Halawa, AgentMint.net · Evidence types are load-bearing: spec-fact | reported | hypothesis (no measured). -->

## Offer legibility

Can an agent read your real, all-in offer (price, variants, unit cost, tax) without starting checkout?

### Make total landed cost (price + shipping + fees) readable before the agent commits to checkout.
- **Evidence:** hypothesis
- **Why:** We expect an agent comparing offers to prefer the one whose all-in cost it can compute up front. If shipping and fees surface only at the final checkout step, the agent either guesses high or drops you. Surface them in text and markup, not just at payment.
- **How to check:** On a cold PDP, can you read total cost to a given destination without starting checkout?
- Priority 3/3 · Effort M
- **Learn more:** https://agentmint.net/make-product-feed-ai-readable/

**What good looks like:** Under the price, one line reads "Total to 90210: $95.99 (item $89.00 + shipping $6.99), no hidden fees," and the number updates with destination and matches what checkout later charges.

Common mistakes:
- Shipping and fees appear only at the final payment step, after a lower price was already shown.
- A 'free shipping over $50' banner with no way to see the real number below that threshold.

Steps:
1. On a fresh PDP visit, try to state the total cost to a real address without starting checkout.
2. If you can't, add a shipping/fee estimator or a text line near the price.
3. Confirm the number matches what checkout charges for that same address.

**For your developer:** Expose the estimate via `Offer.shippingDetails` (schema.org `OfferShippingDetails` with `shippingRate`) or the equivalent feed shipping fields, not only in a JS-rendered cart drawer.

```
{
  "@type": "Offer",
  "price": "89.00",
  "priceCurrency": "USD",
  "shippingDetails": {
    "@type": "OfferShippingDetails",
    "shippingRate": { "@type": "MonetaryAmount", "value": "6.99", "currency": "USD" },
    "shippingDestination": { "@type": "DefinedRegion", "addressCountry": "US" }
  }
}

```

### Name variants with explicit attributes (size/color/material) a machine can disambiguate, not "Style A".
- **Evidence:** hypothesis
- **Why:** We expect agents to match near-literally, so a variant labeled "Option 2" or "The Luna" gives nothing to map to a user's "queen, navy, linen." Explicit attributes in the variant title and structured data should win that match. (Extrapolated from the ACES description-rewrite finding; ACES tested descriptions, not variant names.)
- **How to check:** Read variant names cold. Could you tell which is which without the image?
- Priority 2/3 · Effort M · Applies to: all with variants
- **Learn more:** https://agentmint.net/product-titles-for-ai-agents/

**What good looks like:** A mattress variant is named "Queen, Firm, Cooling Gel," so a shopper searching "queen firm cooling mattress" matches it directly, instead of guessing which of "Model A" or "Model B" fits.

Common mistakes:
- Variants named after internal codes or marketing names ('The Luna') with no attribute stated elsewhere.
- Attribute values shown only in a swatch image or dropdown label, with no matching text.

Steps:
1. Read your variant names cold, without images. Could a stranger tell which is which?
2. If not, rename variants to lead with the attribute a shopper searches for.

**For your developer:** Map each variant attribute to its own structured field (e.g. schema.org `additionalProperty` PropertyValue pairs), not one free-text variant title.

- **Shopify:** Options are free-text per product, not a shared taxonomy, so a shorthand in one listing won't match a shopper's phrasing in another.
- **WooCommerce:** Variations inherit product attributes; use literal terms ('Navy', 'Queen'), not generic ones ('Color 1').

### State unit pricing (per 100 ml, per count, per kg) where it aids comparison.
- **Evidence:** hypothesis
- **Why:** We expect an agent comparing a 500 ml and a 750 ml product to reward the one that hands it a directly comparable unit price, rather than forcing a computation it may skip or get wrong.
- **How to check:** Do consumable/multipack PDPs show a unit price in text?
- Priority 1/3 · Effort S · Applies to: consumables, multipacks, bulk
- **Learn more:** https://agentmint.net/make-product-feed-ai-readable/

**What good looks like:** A 750 ml olive oil bottle shows "$18.00 ($2.40 / 100 ml)" right next to the price, so a shopper comparing it to a 500 ml bottle at $14 doesn't have to do the math.

Common mistakes:
- Multipacks list only the pack price, forcing a manual per-unit calculation.
- Unit price shown on the category/search page but dropped from the PDP itself.

Steps:
1. Check whether consumable or multipack PDPs show a per-unit price in plain text.
2. If missing, add it next to the price, using the same unit competitors use so comparisons line up.

**For your developer:** Carry the value in structured data if your platform exposes a unit-price field, not only as PDP text, so it survives template changes.

- **Shopify:** Unit pricing is a built-in field in some regions (useful for EU per-unit rules); confirm it's enabled, not theme-hidden.
- **WooCommerce:** No native unit-price field; it typically needs a plugin or a custom field rendered near the price.

### Put the current price in parseable text/markup, never only inside an image.
- **Evidence:** hypothesis
- **Why:** We expect agents to read text and JSON, not pixels. A price baked into a hero image or a "sale" badge graphic is invisible to them, so they fall back to the higher struck-through price or skip you.
- **How to check:** With images suppressed, is the current price still readable in the DOM/markup?
- Priority 2/3 · Effort S
- **Learn more:** https://agentmint.net/product-schema-for-ai-shopping/

**What good looks like:** The sale price "$59.99" appears as real text in the page markup, with the struck-through original price also as text, not baked into the promotional banner graphic above it.

Common mistakes:
- The current price lives only inside a hero image, sale badge, or countdown-timer graphic.
- Suppressing images hides the price entirely instead of just the decoration.

Steps:
1. Disable images (or view page source) and confirm the current price is still readable as text.
2. If it disappears, move the price out of the image into real markup, keeping the image decorative only.

**For your developer:** The price must resolve in the DOM and in `Offer.price`/`priceCurrency`, not only as a CSS background image or `<img>` alt text.

### Make currency and tax treatment explicit near the price (e.g., incl./excl. VAT).
- **Evidence:** hypothesis
- **Why:** We expect cross-border agents to need whether the number already includes tax to compare fairly; ambiguity forces an assumption that can misrank you either way. State currency and tax-inclusiveness in text near the price.
- **How to check:** Does the PDP state currency and tax-inclusiveness in text near the price?
- Priority 1/3 · Effort S · Applies to: cross-border / EU sellers
- **Learn more:** https://agentmint.net/make-product-feed-ai-readable/

**What good looks like:** Near the price, the PDP reads "49.00 EUR incl. VAT" rather than a bare "49.00," so a cross-border shopper doesn't have to guess whether tax is already in the number.

Common mistakes:
- Currency symbol shown but no statement of whether tax is included.
- Tax-inclusiveness stated once on a policy page but never repeated near the price.

Steps:
1. Read the price line alone: does it state currency and tax-inclusiveness?
2. If not, add a short qualifier ('incl. VAT' / 'excl. sales tax') beside the price.
3. Check this holds for every locale you sell into, not just your home market.

**For your developer:** Where supported, express tax-inclusiveness via a `priceSpecification` with an explicit tax flag, not just a text label.

- **Shopify:** Shopify Markets can show different tax-inclusive prices per country; verify the displayed text updates too, not only the number.
- **WooCommerce:** The store-wide 'prices entered with tax' and 'display prices' settings can disagree; a mismatch makes text and markup contradict each other.

### Make sale pricing and its validity window legible, matching checkout.
- **Evidence:** hypothesis, [Google: Merchant listing structured data](https://developers.google.com/search/docs/appearance/structured-data/merchant-listing) (2026-07-08)
- **Why:** A sale the agent can't see or date isn't a selection lever. We expect expressing the sale price and its window (the markup's priceValidUntil, the ACP feed's sale_price_start/end_date) to let an agent surface an honest, time-bounded deal.
- **How to check:** Is the sale price and end date readable in text/markup, matching checkout?
- Priority 2/3 · Effort S · Applies to: sellers who run sales
- **Learn more:** https://agentmint.net/make-product-feed-ai-readable/

**What good looks like:** The PDP states "Now $39, was $52, through July 15" in text, and the same end date appears in structured data, so nothing needs to be assumed.

Common mistakes:
- A sale badge with no end date, so it reads as permanent, or already expired, to a cautious agent.
- The markup's sale window disagrees with what checkout charges after the stated date.

Steps:
1. Check whether your sale's start/end dates appear in visible text, not only in markup.
2. Confirm the same dates are set in your structured data and feed.
3. Test checkout on the end date itself to confirm the price reverts as stated.

**For your developer:** Use `priceValidUntil` on your Offer markup and the matching feed sale-date fields, kept in sync with the actual price-change job.

```
{
  "@type": "Offer",
  "price": "39.00",
  "priceCurrency": "USD",
  "priceValidUntil": "2026-07-15"
}

```

## Delivery & returns signals

Can an agent turn your shipping and return terms into a dated, per-destination answer it trusts?

### Make delivery time concrete enough for an agent to compute an ETA, not "ships soon."
- **Evidence:** hypothesis, [Google: Shipping policy structured data](https://developers.google.com/search/docs/appearance/structured-data/shipping-policy) (2026-07-08)
- **Why:** Structured data expresses handlingTime plus transitTime as ranges, not literal dates; the agent assembles "arrive by ~X." We expect that if those fields are vague or absent, the agent can't answer "when will it arrive?" and defers to a competitor that can.
- **How to check:** From your handling and transit data, can you derive a delivery estimate to a test ZIP? If not, an agent can't either.
- Priority 3/3 · Effort M · Applies to: all shipping physical goods
- **Learn more:** https://agentmint.net/make-product-feed-ai-readable/

**What good looks like:** A PDP states "Ships in 1-2 business days, arrives in 3-5 more days" next to the shipping tab, and the same handling and transit ranges are set in the shipping markup, not left as a vague "ships soon."

Common mistakes:
- 'Ships soon' or 'fast shipping' badges with no handling or transit range stated anywhere.
- A handling range set in structured data that quietly disagrees with the prose delivery estimate.

Steps:
1. Write your actual handling time and transit time as day ranges, not a vague phrase.
2. State both ranges in PDP text near the shipping details.
3. Set the same ranges in your shipping structured data so text and markup agree.

**For your developer:** Set both `handlingTime` and `transitTime` as day ranges on the shipping markup, not left blank or open-ended, matching whatever estimate the PDP text states.

### Show shipping cost before checkout, not only at the payment step.
- **Evidence:** hypothesis, [Google: Shipping policy structured data](https://developers.google.com/search/docs/appearance/structured-data/shipping-policy) (2026-07-08)
- **Why:** We expect an agent to treat unknown shipping as a risk and prefer a merchant whose cost or free-shipping status is visible up front, the shipping-specific case of the total-cost rationale. The mechanism exists (shippingRate, feed shipping.price); the differentiator is surfacing it early.
- **How to check:** Is shipping cost to a destination visible on the PDP before you enter checkout?
- Priority 2/3 · Effort M
- **Learn more:** https://agentmint.net/make-product-feed-ai-readable/

**What good looks like:** Below the price, a line reads "Shipping to 90210: $5.99, arrives in 4-6 days," computed before checkout starts, using the same rate a shopper is actually charged later.

Common mistakes:
- Shipping cost stays hidden until the final payment step, after the shopper already compared prices.
- A 'calculated at checkout' label with no way to preview even an estimate earlier.

Steps:
1. Check whether shipping cost to a real destination is visible before checkout starts.
2. If not, add a shipping estimator or a stated flat rate near the price.
3. Confirm the number matches what checkout actually charges for that address.

**For your developer:** Surface the same `shippingRate` used at checkout on the PDP itself, not only inside a JS-rendered cart drawer a crawler may not execute.

- **Shopify:** Rates typically calculate at checkout unless a shipping-estimator block is added to the product template.
- **WooCommerce:** Shipping is often computed only inside cart/checkout via shipping zones by default; showing a rate on the PDP usually needs an explicit estimator.

### Express order cutoff times so "order by X for Y delivery" is machine-legible.
- **Evidence:** hypothesis, [Google: Shipping policy structured data](https://developers.google.com/search/docs/appearance/structured-data/shipping-policy) (2026-07-08)
- **Why:** cutoffTime, a sibling of handlingTime and transitTime on the shipping delivery-time markup, is exactly the field that lets an agent tell a user "order in the next 3 hours to get it Thursday." We expect omitting it to forfeit the most persuasive, time-sensitive selection moment.
- **How to check:** Does your shipping data include a cutoff time, and does the PDP echo it in text?
- Priority 2/3 · Effort M · Applies to: all with same-day dispatch cutoffs
- **Learn more:** https://agentmint.net/make-product-feed-ai-readable/

**What good looks like:** A same-day-dispatch store states "Order within 3h 20m for dispatch today" in plain text on the PDP, with the time zone named, matching the cutoff set in the shipping data.

Common mistakes:
- A cutoff time exists in the shipping data or policy but is never echoed on the PDP itself.
- The stated cutoff has no time zone, so a shopper in a different zone misreads it.

Steps:
1. Confirm your shipping data includes a cutoff time for same-day dispatch.
2. Echo that cutoff on the PDP in plain text, with the time zone stated.
3. Test an order placed near the cutoff to confirm the displayed time matches actual dispatch.

**For your developer:** Set cutoffTime alongside handlingTime and transitTime on your shipping delivery-time markup (siblings, not nested), and keep it in the same time zone the storefront displays, so the PDP text and the markup can't quietly disagree.

### Carry the returns window in BOTH prose and structured data, and keep the numbers equal.
- **Evidence:** hypothesis, [Google: Return policy structured data](https://developers.google.com/search/docs/appearance/structured-data/return-policy) (2026-07-08)
- **Why:** An agent relaying "can I return it?" trusts a page where human-readable prose and the machine field (merchantReturnDays / feed return_deadline_in_days) agree. We expect a markup-only or prose-only window to read as a half-answer that invites doubt.
- **How to check:** Does the returns page state the window in words, and does the markup carry the same number?
- Priority 2/3 · Effort M
- **Learn more:** https://agentmint.net/make-product-feed-ai-readable/

**What good looks like:** A returns page opens with "Return within 30 days of delivery," and the same number, 30, is set as merchantReturnDays in the page's structured data, so neither figure can quietly drift from the other.

Common mistakes:
- The returns page prose says 30 days while the structured data still carries an old 14-day figure.
- A return window stated only in markup, with no matching sentence a shopper can actually read.

Steps:
1. Find your stated return window in both prose and structured data.
2. Confirm the two numbers match exactly.
3. When the policy changes, update both in the same edit, not one now and the other later.

**For your developer:** Keep `merchantReturnDays` (or the feed's `return_deadline_in_days`) wired to the same source value as the prose sentence, ideally one shared field.

### State return cost and who pays it explicitly.
- **Evidence:** hypothesis, [Google: Return policy structured data](https://developers.google.com/search/docs/appearance/structured-data/return-policy) (2026-07-08)
- **Why:** "Free returns" vs. "customer pays return shipping" can decide a comparison. The fields exist (returnFees, returnShippingFeesAmount); we expect the differentiator to be making the answer unambiguous rather than a buried "conditions apply."
- **How to check:** Can you tell, from the PDP/returns page alone, exactly who pays to return?
- Priority 2/3 · Effort S
- **Learn more:** https://agentmint.net/make-product-feed-ai-readable/

**What good looks like:** A returns page states "Returns are free; we email a prepaid label" or "Return shipping costs $6.95, deducted from your refund," leaving nothing for a shopper to infer.

Common mistakes:
- 'Conditions apply' sits next to a return-cost claim, with the actual condition never named.
- Marketing copy advertises free returns while the policy page still lists a shopper-paid fee.

Steps:
1. Read your returns page and find the exact sentence stating who pays.
2. If it hedges with 'conditions apply,' name the condition or drop the hedge.
3. Match the stated cost to what your returnFees/returnShippingFeesAmount markup actually carries.

**For your developer:** Set `returnFees` and, where a flat fee applies, `returnShippingFeesAmount` to the real number your process charges, not a template placeholder.

### State the return method (mail / in-store / kiosk).
- **Evidence:** hypothesis, [Google: Return policy structured data](https://developers.google.com/search/docs/appearance/structured-data/return-policy) (2026-07-08)
- **Why:** Method changes real-world convenience and thus the agent's recommendation. returnMethod encodes it; we expect leaving it implicit to force the agent to omit a detail users care about.
- **How to check:** Is the return method named in text and markup?
- Priority 1/3 · Effort S · Applies to: all (esp. omnichannel)
- **Learn more:** https://agentmint.net/make-product-feed-ai-readable/

**What good looks like:** A returns page states "Mail it back with the prepaid label, or drop it at any of our stores," so an omnichannel shopper knows both options exist before buying.

Common mistakes:
- Return method left unstated, so a shopper can't tell whether an in-store return is even possible.
- In-store returns exist but are mentioned only on a separate store-locator page, never the returns page.

Steps:
1. State the return method(s) you actually support in plain text on the returns page.
2. If you support more than one (mail, in-store, kiosk), name all of them, not just the default.

**For your developer:** Set `returnMethod` to match every option you genuinely support, not just the single value your template shipped with.

### Make the refund type legible (full refund / exchange / store credit).
- **Evidence:** hypothesis, [Google: Return policy structured data](https://developers.google.com/search/docs/appearance/structured-data/return-policy) (2026-07-08)
- **Why:** A shopper asking an agent "do I get my money back?" needs a clear answer; refundType supplies it. We expect ambiguity here to read as a weaker guarantee than a competitor who states "full refund."
- **How to check:** Does the returns page state the refund type plainly?
- Priority 2/3 · Effort S
- **Learn more:** https://agentmint.net/make-product-feed-ai-readable/

**What good looks like:** A returns page states "You'll receive a full refund to your original payment method within 5 business days," not just "returns accepted," so a shopper knows exactly what comes back.

Common mistakes:
- 'Returns accepted' with no statement of refund, exchange, or store credit.
- Store credit is the real outcome, but marketing copy implies a cash refund.

Steps:
1. Check your returns page for a plain statement of refund type.
2. If it only says 'returns accepted,' add whether the outcome is a refund, exchange, or store credit.
3. Confirm marketing copy doesn't promise an outcome the policy doesn't deliver.

**For your developer:** Set `refundType` to the outcome you actually deliver; a mismatch against the prose reads as a bait-and-switch, not just a gap in the markup.

### Keep delivery and return terms consistent across prose, structured data, and feed.
- **Evidence:** hypothesis
- **Why:** We expect that when PDP prose, JSON-LD, and the product feed disagree on shipping cost or return window, the agent must arbitrate, and may distrust all three or pick the worst-case reading. Consistency removes that friction.
- **How to check:** Diff the same SKU's shipping/return values across prose, markup, and feed.
- Priority 3/3 · Effort M
- **Learn more:** https://agentmint.net/make-product-feed-ai-readable/

**What good looks like:** A quarterly check confirms one SKU's stated shipping cost and return window match exactly across the PDP text, the JSON-LD markup, and the product feed, with zero diffs found.

Common mistakes:
- The product feed still lists an old flat shipping rate after the PDP price was updated.
- Structured data was set once at launch and never revisited after a later policy change.

Steps:
1. Pick a sample SKU and pull its shipping/return values from prose, markup, and feed side by side.
2. Flag any diff and trace it back to whichever source is stale.
3. Add a recurring check after every policy change, rather than a one-time fix.

**For your developer:** Route prose, structured data, and feed for shipping and return values from one shared source, rather than three separately maintained copies.

### Make your data answer "can this arrive by [date]?" per destination.
- **Evidence:** hypothesis, [Google: Shipping policy structured data](https://developers.google.com/search/docs/appearance/structured-data/shipping-policy) (2026-07-08)
- **Why:** The highest-intent delivery question is destination- and date-specific. shippingDestination plus per-region transitTime let an agent answer it; national "3-5 days" boilerplate cannot. We expect per-destination completeness to be the differentiator.
- **How to check:** Pick two distant ZIPs. Can your data produce a distinct, credible ETA for each?
- Priority 3/3 · Effort L · Applies to: all shipping physical goods
- **Learn more:** https://agentmint.net/make-product-feed-ai-readable/

**What good looks like:** A team tests two distant ZIP codes and confirms the shipping data returns a distinct, credible transit estimate for each, rather than one national "3-5 days" figure applied everywhere.

Common mistakes:
- One blanket '3-5 business days' claim applied to every destination, including remote or international ones.
- Per-region transit data exists in the backend, but the PDP text still shows only the national default.

Steps:
1. Pick two test destinations: one near a fulfillment center, one far from it.
2. Check whether your shipping data produces a different, credible estimate for each.
3. If both show the same generic range, add per-destination transit data before claiming precision you lack.

**For your developer:** Set `shippingDestination` and per-region `transitTime` distinctly, rather than one nationwide range applied to every destination.

### State free-shipping / free-returns thresholds as concrete numbers.
- **Evidence:** hypothesis, [Google: Shipping policy structured data](https://developers.google.com/search/docs/appearance/structured-data/shipping-policy) (2026-07-08)
- **Why:** "Free shipping on qualifying orders" is unusable to an agent; a numeric threshold (the markup's orderValue) lets it tell a user "add $12 for free shipping." We expect that concrete, conversion-relevant nudge to tip selection.
- **How to check:** Is any free-shipping threshold stated as a number in text/markup?
- Priority 2/3 · Effort S · Applies to: merchants with free-shipping thresholds
- **Learn more:** https://agentmint.net/make-product-feed-ai-readable/

**What good looks like:** A cart banner states "Add $12.00 more for free shipping," with a live running total, rather than a static "free shipping on qualifying orders" claim with no number attached.

Common mistakes:
- 'Free shipping on qualifying orders' with the actual qualifying amount never stated anywhere.
- The threshold appears on a seasonal promo banner but is absent from the PDP itself.

Steps:
1. Find your free-shipping and free-returns thresholds and confirm each is a stated number.
2. Add the number to the PDP or cart, not only a seasonal promo banner.
3. Set the same number in structured data so it survives when the banner is swapped out.

**For your developer:** Set `orderValue` to the real numeric threshold; a promo banner alone gives an agent nothing to compute against.

## Product content for comparison

Is your content complete and specific enough to win a within-category comparison?

### Fill the specs your category's leaders expose: completeness vs. category norms, not just vs. "required."
- **Evidence:** hypothesis
- **Why:** We expect an agent comparing within a category to favor the item whose attributes it can actually compare on; the ones your peers fill and you leave blank are silent losses. This is a "vs. peers" judgment no validator holds.
- **How to check:** List the attributes the top 3 competing listings expose; find your gaps.
- Priority 3/3 · Effort L
- **Learn more:** https://agentmint.net/how-ai-agents-choose-products/

**What good looks like:** A running shoe listing fills weight, drop height, midsole material, and width options because the top 3 competing listings in that category all fill those same fields, not because a generic checklist required them.

Common mistakes:
- Filling only the platform's 'required' fields and leaving every optional attribute blank.
- Never checking what attributes category leaders expose, so gaps go unnoticed.

Steps:
1. Pull up the top 3 competing listings for your category and list every attribute they show.
2. Compare against your own listing and fill any gap you can answer truthfully.
3. Repeat this check periodically; category norms shift as competitors add fields.

**For your developer:** Where your platform supports structured custom attributes, use them instead of burying the same facts only in free-text description.

### Write descriptions that answer the questions agents relay from users (fit, compatibility, use-case).
- **Evidence:** hypothesis, [ACES (arXiv:2508.02630)](https://arxiv.org/abs/2508.02630) (2026-07-08)
- **Why:** We expect agents to pass along real user questions ("will this fit a 15-inch laptop?"). Copy that answers them in buyer language is the substance ACES reports description rewrites can shift recommendation share (simulation); marketing fluff that dodges them is not.
- **How to check:** List the 5 questions buyers ask about the product; does the description answer each?
- Priority 3/3 · Effort L
- **Learn more:** https://agentmint.net/how-ai-agents-choose-products/

**What good looks like:** A backpack description states "fits laptops up to 15 inches, including a 2-inch cushioned sleeve," because that's the exact question buyers ask, instead of "sleek design for the modern professional."

Common mistakes:
- Descriptions built from marketing adjectives with no answer to a concrete buyer question.
- The real answer exists in a spec table but is never restated in prose.

Steps:
1. List the 5 questions buyers most often ask about this product (fit, compatibility, use-case).
2. Check whether the description answers each in plain sentences.
3. Rewrite any gap in buyer language, not internal jargon.

**For your developer:** If the answer lives only in a table or spec component, mirror the key facts as plain sentences too; some text-extraction paths skip table markup.

### Make claims specific and verifiable (materials, dimensions, certifications), not vague superlatives.
- **Evidence:** hypothesis
- **Why:** We expect agents and their citation layer to prefer checkable specifics ("100% merino, 320 gsm, OEKO-TEX certified") over "premium quality," which carries no comparable signal. Specifics also raise citability, how likely an agent is to quote you.
- **How to check:** Scan the description for unverifiable adjectives; replace them with measurable facts.
- Priority 2/3 · Effort M
- **Learn more:** https://agentmint.net/how-ai-agents-choose-products/

**What good looks like:** Instead of "premium quality fabric," the description states "100% merino wool, 320 gsm, machine washable," each a fact a shopper could check against the product on arrival.

Common mistakes:
- Vague superlatives ('luxurious', 'best-in-class') standing in for a measurable fact.
- A real certification or spec exists but only in a downloadable sheet, not the page text.

Steps:
1. Scan your description for adjectives with no attached number or fact.
2. Replace each with the actual material, dimension, weight, or certification.
3. Where you hold a real certification, name it exactly, not a paraphrase.

**For your developer:** Real materials and certifications can also ride as `additionalProperty` PropertyValue pairs on the Product markup, alongside the prose.

```
{
  "@type": "Product",
  "additionalProperty": [
    { "@type": "PropertyValue", "name": "Material", "value": "100% merino wool" },
    { "@type": "PropertyValue", "name": "Fabric weight", "value": "320 gsm" }
  ]
}

```

### Lead titles with the words shoppers type (category + attribute + use-case), not brand-only names.
- **Evidence:** hypothesis
- **Why:** We expect agents to match queries to titles near-literally; a brand-first title ("The Luna") loses to "organic cotton weighted sleep mask." This extends the ACES description-rewrite finding to titles, labeled an extrapolation, not itself measured.
- **How to check:** Would your title match the exact phrase a shopper would type? Rewrite if not.
- Priority 2/3 · Effort M
- **Learn more:** https://agentmint.net/product-titles-for-ai-agents/

**What good looks like:** A sleep mask is titled "Organic Cotton Weighted Sleep Mask, Adjustable Strap" rather than "The Luna," matching the words a shopper searching for one would actually type.

Common mistakes:
- Brand-first, feature-absent titles ('The Luna', 'Aria Pro') that carry no category or use-case words.
- Titles that repeat internal SKU naming instead of shopper vocabulary.

Steps:
1. Write down the exact phrase a shopper would type to search for this product.
2. Compare it word for word to your current title.
3. Rewrite to lead with category and key attribute, keeping brand secondary.

**For your developer:** Keep the rewritten title consistent across the page title/`name` field and your product feed's title attribute; a mismatch undermines both.

### Test query-conditional description rewrites where they plausibly help, expecting concentrated, not universal, gains.
- **Evidence:** reported, [ACES (arXiv:2508.02630)](https://arxiv.org/abs/2508.02630) (2026-07-08)
- **Why:** ACES reports a one-shot rewrite changes nothing in ~75% of category-model pairs but produces large gains in ~25% (outliers to +23.6%). Treat rewriting as a targeted experiment, not a blanket promise (simulation).
- **How to check:** Pick candidate SKUs, rewrite descriptions to match likely queries, and measure via the win-rate protocol.
- Priority 2/3 · Effort L
- **Learn more:** https://agentmint.net/research/description-rewrite-experiment/

**What good looks like:** A team picks 10 candidate SKUs, rewrites each description to answer a specific likely query, then runs the win-rate protocol before and after, expecting most SKUs to show no change and a few to move meaningfully.

Common mistakes:
- Rewriting every description at once and declaring victory without measuring any of them.
- Treating one SKU's win as proof the same rewrite will work everywhere.

Steps:
1. Pick a small batch of candidate SKUs where a query-specific rewrite plausibly helps.
2. Rewrite descriptions to match the likely query, keeping the same facts, no new claims.
3. Measure win rate per engine, before and after, using the same prompt each time.

**For your developer:** Serve the same rewritten copy to crawlers and human visitors alike; a query-conditional rewrite only bots see is cloaking, not testing.

### Don't self-label offers "Sponsored" to court agents; earn legitimate endorsement instead.
- **Evidence:** reported, [ACES (arXiv:2508.02630)](https://arxiv.org/abs/2508.02630) (2026-07-08)
- **Why:** Counterintuitively, ACES found agents penalize a "Sponsored" tag (baseline 10% → 8.9% Claude / 8.0% GPT-4.1 / 7.9% Gemini) and reward platform endorsements (up to 42.6% for Gemini). Chasing paid-looking tags can backfire; earn genuine endorsement instead (simulation).
- **How to check:** Audit whether any self-applied "sponsored/ad" styling touches agent-visible content; remove it.
- Priority 3/3 · Effort S
- **Learn more:** https://agentmint.net/how-ai-agents-choose-products/

**What good looks like:** A store removes a leftover "Sponsored" ribbon component from an old paid-placement test, and instead pursues an editor's-pick or verified-seller badge it can honestly earn.

Common mistakes:
- An 'Ad'/'Sponsored' badge component left active on organic product pages after a test ends.
- Assuming a paid-looking tag signals credibility to an agent, when the opposite may hold.

Steps:
1. Audit templates and past A/B tests for any sponsored/ad styling still touching agent-visible pages.
2. Remove it from organic listings.
3. Pursue legitimate endorsement or verified-seller programs instead, where you genuinely qualify.

**For your developer:** Check for leftover sponsored/ad-label attributes or classes from ad-platform integrations that persisted onto the canonical PDP markup.

## Trust & policy signals

Do your reviews, identity, and policies read as credible depth an agent can weigh?

### Carry review count and recency in the review structured data, truthfully.
- **Evidence:** hypothesis, [ACES (arXiv:2508.02630)](https://arxiv.org/abs/2508.02630) (2026-07-08)
- **Why:** aggregateRating/review presence is eligibility; depth is selection. ACES reports rating is a strong lever (+0.1 lifted selection ~10%→15-20%, simulation), so we expect complete, recent, distributed review data to help: a fake or thin rating is both a rule violation and a weak signal.
- **How to check:** Does the markup carry a truthful count and recent reviews, not a lone average?
- Priority 3/3 · Effort M · Applies to: all with reviews
- **Learn more:** https://agentmint.net/how-ai-agents-choose-products/

**What good looks like:** A PDP states "4.6 stars from 1,842 reviews, 214 in the last 90 days" next to the average, so a shopper (and an agent) can see both scale and freshness, not a bare number with no count behind it.

Common mistakes:
- Only the average star rating is shown, with no review count anywhere near it.
- Old reviews are never refreshed, so the same three testimonials sit there for years.

Steps:
1. Check whether your PDP shows a review count and a recent-activity signal, not just an average.
2. If either is missing, add the count and a rolling recent-reviews figure near the rating.
3. Confirm the markup's count matches what a shopper can actually read on the page.

**For your developer:** `AggregateRating` needs `reviewCount` alongside `ratingValue`; individual `Review` entries with `datePublished` (a sibling property on `Product`, not nested inside `aggregateRating`) are what carries recency.

```
{
  "@type": "Product",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "1842"
  },
  "review": [
    {
      "@type": "Review",
      "datePublished": "2026-06-02",
      "reviewRating": { "@type": "Rating", "ratingValue": "5" }
    }
  ]
}

```

### Make seller identity and contact reachable in ≤2 hops from a product page.
- **Evidence:** hypothesis
- **Why:** We expect trust-weighting agents and their citation layers to discount a store whose ownership, address, or contact route is buried or absent. Clear Organization identity and a crawlable contact path signal a real, accountable merchant.
- **How to check:** From a PDP, can you reach seller identity and a contact method in two clicks/links?
- Priority 2/3 · Effort S · Applies to: all (esp. lesser-known brands)
- **Learn more:** https://agentmint.net/how-ai-agents-choose-products/

**What good looks like:** From a running-shoe PDP, a shopper reaches the store's legal business name, mailing address, and a working contact form or support email within two clicks, footer then contact page, with nothing further to hunt for.

Common mistakes:
- Contact is a chat widget only, with no static page listing a business name or address.
- The legal entity name differs from the storefront name and is never reconciled anywhere.

Steps:
1. From a live PDP, click through to find your business name, address, and a contact method.
2. Count the hops. If it takes more than two, add a direct footer link.
3. Confirm the same business name appears on the contact page, checkout, and any policy pages.

**For your developer:** Mirror the same details in `Organization` schema (`name`, `address`, `contactPoint`) site-wide, not only as unmarked text on a page nothing links to.

### Keep policy pages as crawlable prose, not PDF-only or JS-only accordions.
- **Evidence:** hypothesis
- **Why:** Having the policy page is table stakes; this is about whether an agent can read the terms. We expect a returns policy locked in a PDF or a script-driven accordion to be text the agent never parses, so your good policy earns no credit.
- **How to check:** With JS disabled, is the full policy text present in the HTML (not a PDF link)?
- Priority 2/3 · Effort M
- **Learn more:** https://agentmint.net/ai-crawlers-robots-llms-txt/

**What good looks like:** A returns policy loads as full HTML paragraphs on first request, visible with JavaScript disabled and without opening a separate PDF, even though the page still displays it inside a collapsed, click-to-expand section.

Common mistakes:
- The policy exists only as a downloadable PDF linked from the page, not as page text.
- An accordion component fetches the policy text only after a click, so it's absent from the initial page load.

Steps:
1. Disable JavaScript (or view page source) and check whether the full policy text is already present.
2. If it only appears as a PDF link, publish the same text as an ordinary page too.
3. If an accordion hides it, confirm the text ships in the initial HTML, collapsed visually, not fetched on click.

**For your developer:** Render the policy text server-side in the initial HTML response; a JS-only accordion that fetches content on interaction can leave it invisible to a crawler that never clicks.

### Earn platform-endorsement signals legitimately (editor's-pick, verified-seller, genuine badges).
- **Evidence:** reported, [ACES (arXiv:2508.02630)](https://arxiv.org/abs/2508.02630) (2026-07-08)
- **Why:** ACES found endorsement is one of the strongest content/signal levers it tested: the highest absolute selection probability, 42.6% for Gemini. The honest, durable path is qualifying for real platform endorsements and verified-seller status, not faking badge markup (simulation).
- **How to check:** List the endorsement/verification programs you qualify for on each surface; pursue the legitimate ones.
- Priority 3/3 · Effort L
- **Learn more:** https://agentmint.net/how-ai-agents-choose-products/

**What good looks like:** A store applies through a marketplace's official verified-seller program, qualifies on its own merits, and displays the badge that program actually issues, rather than designing a lookalike graphic that implies the same thing.

Common mistakes:
- A custom 'verified' or 'trusted' badge is designed in-house, styled to resemble an official program's mark.
- A paid ad placement is treated as if it were the same thing as a genuine editorial or platform endorsement.

Steps:
1. List the verification or editor's-pick programs relevant to your category and check which you already qualify for.
2. Apply through each program's official process, rather than approximating its look.
3. Remove any self-designed badge that isn't issued by a real accreditor.

### Render the full ratings distribution on the PDP, not just an average.
- **Evidence:** hypothesis, [ACES (arXiv:2508.02630)](https://arxiv.org/abs/2508.02630) (2026-07-08)
- **Why:** We expect a full star-distribution to read as more credible depth than a bare average, and it gives a rating-sensitive agent (ACES rating lever, simulation) more to weigh. Truthfulness is mandatory; the differentiator is completeness of what's shown.
- **How to check:** Does the PDP show rating count and distribution, not only "4.6 stars"?
- Priority 2/3 · Effort M · Applies to: all with reviews
- **Learn more:** https://agentmint.net/how-ai-agents-choose-products/

**What good looks like:** Beside "4.6 stars," a PDP shows a five-row bar breakdown, "68% five-star, 20% four-star..." down to one-star, so a shopper (or an agent relaying the detail) sees the shape of opinion, not only its average.

Common mistakes:
- Only the single average and count are shown, with no per-star breakdown anywhere.
- The breakdown exists only as an image, with no accompanying numbers a text-only reader could pick up.

Steps:
1. Check whether your PDP shows a per-star breakdown, not only the average and count.
2. If missing, add the percentages or counts per star rating near the existing summary.
3. Keep the breakdown as real text or accessible markup, not only a graphic.

**For your developer:** Schema.org's `AggregateRating` carries only the overall `ratingValue` and count; there's no dedicated property for a per-star breakdown, so render it as visible page content rather than expecting it to live in structured data.

## Price position awareness

Do you know, and honestly monitor, where your total cost sits against competitors?

### Know where your total cost sits vs. comparable offers for the queries you want to win.
- **Evidence:** reported, [ACES (arXiv:2508.02630)](https://arxiv.org/abs/2508.02630) (2026-07-08)
- **Why:** ACES found price is a real but model-varying lever; you can't judge your position without watching competitors' all-in prices for your target queries. This is competitive awareness, which no on-site validator can provide (simulation).
- **How to check:** For your top target queries, list where your landed cost ranks vs. the offers agents surface.
- Priority 3/3 · Effort L
- **Learn more:** https://agentmint.net/how-ai-agents-choose-products/

**What good looks like:** A team keeps a simple sheet ranking their landed cost against three to five named competitor offers for each of their top ten target queries, updated on a fixed monthly schedule, not checked only when someone happens to notice.

Common mistakes:
- Pricing decisions are made from instinct, with no competitor tracking behind them.
- Only list price is compared, ignoring shipping and fees that change the real landed total.

Steps:
1. List your top target queries and, for each, note your landed cost and three to five competitor totals.
2. Record where you rank for each query.
3. Repeat on a fixed schedule so drift gets caught, not just a one-time snapshot.

### Treat price competitiveness as a monitoring habit, and never cloak prices to agents vs. users.
- **Evidence:** hypothesis, [Google: Merchant Center product data spec](https://support.google.com/merchants/answer/7052112) (2026-07-08)
- **Why:** Awareness is legitimate; showing agents a different price than humans see is a dark pattern and breaks Google's parity rule, risking disapproval and trust loss. We expect the honest play to be monitoring and competing, not manipulating.
- **How to check:** Confirm the agent-visible price equals the human-visible price; keep a routine price-position check.
- Priority 2/3 · Effort M
- **Learn more:** https://agentmint.net/make-product-feed-ai-readable/

**What good looks like:** A monthly spot check fetches the same PDP with a plain browser and with a bot-style request, confirms both return the identical price, and logs the result alongside that period's competitor comparison.

Common mistakes:
- Price or availability differs by requester identity, which reads as a parity violation, not clever targeting.
- A single one-off price check is treated as sufficient instead of a recurring habit.

Steps:
1. Fetch your PDP as a normal shopper and again as a bot-like request; confirm the prices match exactly.
2. If they differ, remove whatever logic branches price by requester identity.
3. Fold this check into your recurring competitor price-position review.

**For your developer:** Never branch price, stock, or content logic on user-agent or IP to detect bots; keep pricing keyed only to destination and currency, since a human/agent mismatch is a rule violation, not a growth tactic.

### Account for model-specific price sensitivity: the same discount moves engines differently.
- **Evidence:** reported, [ACES (arXiv:2508.02630)](https://arxiv.org/abs/2508.02630) (2026-07-08)
- **Why:** ACES ln(price) coefficients differ by model (Gemini most price-sensitive at −2.190; Claude/GPT-4.1 near −1.6), so a markdown that meaningfully shifts share on one engine may barely move another. Don't assume one price strategy wins everywhere (simulation).
- **How to check:** When testing a price change, measure win-rate impact per engine, not blended.
- Priority 2/3 · Effort M
- **Learn more:** https://agentmint.net/gemini-shopping-ranking/

**What good looks like:** Before rolling out a discount everywhere, a team tests it on one engine at a time, then compares that engine's win rate before and after, rather than assuming every engine will respond the same way to the same markdown.

Common mistakes:
- One blanket discount is rolled out everywhere and judged from a single blended, all-engine number.
- The engine most price-sensitive today is assumed to stay that way after a model update.

Steps:
1. Run a price test isolated to one engine using the win-rate protocol.
2. Compare that engine's before-and-after win rate, not a blended average across engines.
3. Re-check sensitivity per engine after major model updates, since it can shift.

## Measurement

Do you measure whether agents actually pick you, and re-test when models change?

### Run the manual agent-win-rate protocol across ChatGPT, Gemini, and Perplexity.
- **Evidence:** hypothesis
- **Why:** The only honest way to know if a change helped is to measure whether agents actually recommend or buy your product, across engines, with a repeatable prompt and sampling protocol. We expect no validator to do this; it's our methodology.
- **How to check:** Execute the /research/methodology/ protocol and record win rate per engine.
- Priority 3/3 · Effort L
- **Learn more:** https://agentmint.net/research/methodology/

**What good looks like:** A team writes a fixed list of realistic shopping prompts per target query, runs each one against ChatGPT, Gemini, and Perplexity on the same day, and logs a plain win/no-win result per engine in a shared sheet.

Common mistakes:
- A single one-off prompt is treated as proof, instead of a fixed, repeatable prompt set.
- Results from different engines run weeks apart are compared as if they were simultaneous.

Steps:
1. Write a fixed set of realistic prompts covering your top target queries.
2. Run the same prompts against every engine on the same day.
3. Log a win/no-win result per engine and repeat on a set cadence.

### Re-test after every major model update: behavior reshuffles.
- **Evidence:** reported, [ACES (arXiv:2508.02630)](https://arxiv.org/abs/2508.02630) (2026-07-08)
- **Why:** ACES documents that model updates can drastically reshuffle market shares (e.g., Gemini 2.5 Flash Preview → 2.5 Flash). A win measured last quarter can silently evaporate; schedule a re-test on each major update (simulation).
- **How to check:** Confirm a trigger/cadence that re-runs the win-rate protocol on major model releases.
- Priority 3/3 · Effort M
- **Learn more:** https://agentmint.net/research/methodology/

**What good looks like:** A team keeps a short watchlist of which model version each engine is currently running, and re-runs the win-rate protocol within a set window whenever a major update lands, comparing fresh results against last quarter's.

Common mistakes:
- A win measured months ago is assumed to still hold with no re-test after model updates.
- A competitor's product starts appearing more often, but the shift is never traced back to a recent model release.

Steps:
1. Track which model version each engine is currently serving.
2. When a major update is announced, schedule a re-test within a fixed window.
3. Compare fresh results against your last baseline, not just a gut sense of change.

### Track whether your store appears in AI answers for category queries, not just referral traffic.
- **Evidence:** hypothesis
- **Why:** Referral analytics tell you when an agent already sent a buyer; answer-presence tells you whether you're even in the consideration set. We expect both to matter: presence is the leading indicator no on-site tool reports.
- **How to check:** For your top category queries, log whether each engine names or links your store over time.
- Priority 2/3 · Effort M
- **Learn more:** https://agentmint.net/research/methodology/

**What good looks like:** For each top category query, a team logs whether every engine names or links their store at all, tracked separately from whether that mention ever produced a click, updated on the same cadence as the win-rate protocol.

Common mistakes:
- Referral-traffic analytics alone stand in for measurement, missing sessions where an agent considered but didn't link you.
- No presence at all is confused with low presence, which calls for a different fix.

Steps:
1. List your top category queries.
2. For each engine, log whether your store is named or linked, independent of clicks.
3. Track this presence over time, alongside, not instead of, referral traffic.

### Define agent win rate for your catalog and measure it with honest error bars.
- **Evidence:** hypothesis
- **Why:** Without a defined metric, "AI is working" is a vibe. We expect agent win rate (the share of agent shopping sessions where your product is recommended or bought) to be the honest KPI; there's no incumbent definition, so define it with stated uncertainty.
- **How to check:** Write your win-rate definition, sampling, and error bars; hold results to it.
- Priority 2/3 · Effort M
- **Learn more:** https://agentmint.net/glossary/agent-win-rate/

**What good looks like:** A team writes down its win-rate definition ("share of sampled sessions where our SKU appears in the top three recommendations"), states its sample size, and reports a range rather than a single confident figure.

Common mistakes:
- A single win-rate number from a handful of runs is quoted as if it were precise.
- The definition changes between reporting periods without anyone noting it, so trend claims become meaningless.

Steps:
1. Write your win-rate definition and sample size before you start measuring.
2. Report a range, stating the sample behind it, not a bare point figure.
3. Keep the definition fixed across periods so results are actually comparable over time.

### Audit where you land when an agent renders results as a grid: position bias is strong and provider-specific.
- **Evidence:** reported, [ACES (arXiv:2508.02630)](https://arxiv.org/abs/2508.02630) (2026-07-08)
- **Why:** ACES found grid position is a powerful lever (bottom-right ~4.5% → top row ~5× for Claude Sonnet 4) and that bias varies by provider and persists even headless. You can't fully control placement, but you can measure where you land and which signals move it (simulation).
- **How to check:** In win-rate sessions, record your rendered position and correlate it with the signals you changed.
- Priority 3/3 · Effort M
- **Learn more:** https://agentmint.net/how-ai-agents-choose-products/

**What good looks like:** During a win-rate session, a team also records the on-screen position (top row vs. bottom row) whenever results render as a grid, logged per engine so a position swing isn't mistaken for a content win or loss.

Common mistakes:
- A position swing gets read as a content win or loss, when it may just be where the grid placed you.
- Position bias is assumed to work identically across engines, when it reportedly varies by provider.

Steps:
1. When a grid layout renders, record your on-screen position alongside the win/no-win result.
2. Log position per engine rather than blending it into one figure.
3. Look for correlation between position and signals you've changed, without assuming causation you can't isolate.

## Changelog
- 2026-07-08 · v1.1: Deepened all 35 items with what-good-looks-like examples, common mistakes, verification steps, developer notes, platform-specific notes, and code snippets where useful.
- 2026-07-08 · v1.0: Initial release: 35 selection items across 6 categories.