How AgentScore finds your product pages
Most of AgentScore's store checks hang on one thing: finding a single product page on your site. Here is exactly how the scanner looks for it, in the order it looks, and what you can do so it (and every AI agent) finds your products the first time.
Why one product page matters
To check your prices, product data, add-to-cart button and checkout, AgentScore first has to find a product, starting from your home page. What it finds also decides whether your site counts as a store, a software (SaaS) site or neither, and so which checks apply.
The search lives in one function, discoverKeyPages in the scanner's discover.ts. It looks for three key pages: a product page, a pricing page and the cart. It tries four places in a fixed order, and stops looking for a kind of page once it has one.
- Home page links By URL pattern or link text, in the HTML as served
- Sitemap Product sitemaps first when there's an index
- Product cards A price, a picture and a link, on the home page
- Common paths /cart or /pricing, only when the site looks like it has one
Step 1: links on your home page
The scanner reads every <a href> in your home page's HTML as your server sends it, before any JavaScript runs. It keeps links to your own site (with or without www.) and ignores #, mailto:, tel: and javascript: links. Each link's text is its words, or its aria-label or title when it has none, so an icon-only cart link with aria-label="Cart" counts.
Each link is then sorted, cart first, then pricing, then product:
- Cart: a URL segment such as
/cart,/basket,/bagor/warenkorb, or link text that is exactly a cart word, such as "Cart", "View cart", "Panier" or "カート". - Pricing: a segment such as
/pricing,/plansor/preise, or link text that is exactly "Pricing", "Plans", "Compare plans" and their equivalents. - Product: a URL shaped like a product page.
"Shaped like a product page" means a /product/, /products/, /p/, /item/, /items/, /dp/ or /catalog/product/ segment followed by at least two more characters, or a path ending in -p- and a number. Anything with a segment such as /collections/, /category/, /blog/, /search/ or /pages/ is ruled out, as are the home page itself and index.html.
| Link on the home page | Counts as |
|---|---|
/products/brass-desk-lamp | Product |
/lighting/brass-desk-lamp-p-1042.html | Product |
/collections/lighting/products/brass-desk-lamp | Nothing: it's under /collections/ |
/brass-desk-lamp | Nothing yet (see step 3) |
An icon link to /cart labeled "Cart" | Cart |
The first link of each kind wins. Up to two more product links are kept in reserve: if the product checked is sold out, the scanner tries the next, as a shopper would (what scanning 600 stores taught us explains why).
That third row catches people out. Some store themes link to products inside a collection path. Those links aren't taken as product pages, but if the store publishes a product sitemap, it usually gets found in the next step anyway.
Step 2: your sitemap
If something is still missing, the scanner reads the sitemap that the Valid sitemap check found: one named in robots.txt, or /sitemap.xml, or /sitemap_index.xml. It reads up to 10 MB of it, keeping whatever arrived if the download is slow, and up to 5,000 URLs.
Many platforms publish a sitemap index that points to several child sitemaps. The scanner sorts the children so those with "product" in their address come first (many platforms name them that way), then reads the first two. Every URL in a product sitemap counts as a product page, whatever it looks like. Other URLs are sorted with the same rules as home page links, by URL only. The cart is never taken from a sitemap.
Worth knowing: because only the first two child sitemaps are read, a product sitemap that isn't named with the word "product" may be missed if your index lists other sitemaps first. See XML sitemaps for AI agents.
Step 3: product cards on your home page
Plenty of stores use plain product URLs such as /brass-desk-lamp and have no product sitemap. For them, the scanner looks at your home page the way a person does: for product cards. This step only runs when steps 1 and 2 found no product.
It works on the HTML as served, with scripts and styles removed:
- Find each element whose own text contains a price, such as
$19.99,19,99 €,1 299 krorPLN 49. The currency can come before or after the amount. - From there, step outward through up to six levels of the page, looking for the smallest block that holds a picture (
<img>or<picture>) and between one and three links to your own site. Links to the home page, the cart, pricing or a product-shaped URL don't count toward the three. - If a block has more than three links, it's a grid or a menu, not a card, so the scanner gives up on that price.
- Count the first link in each card. Links that appear in more cards rank higher.
<div class="card">
<a href="/brass-desk-lamp"><img src="lamp.jpg" alt="Brass desk lamp"></a>
<a href="/brass-desk-lamp">Brass desk lamp</a>
<span class="price">$89.00</span>
</div>It needs at least three different card links before it trusts the pattern. Then it opens up to three of them, in order, and keeps the first that is really a product page. A page counts when it has any of these:
- Product structured data: JSON-LD with
"@type": "Product", or schema.org Product microdata - An Open Graph type of
product - A button whose text is an add-to-cart phrase, such as "Add to cart", "In den Warenkorb" or "Buy now"
- A link with add-to-cart text, when the page also shows a price
The other card links become the reserve products. A product found this way counts as linked from your home page, because it is.
Two limits are worth stating. A price split across elements, such as a currency symbol in one <span> and the number in another, isn't read as a price. And product grids built only by JavaScript aren't in the served HTML, so they can't be found here. That's the same thing an AI agent that reads HTML would miss, which is why JavaScript-only content is worth fixing in its own right.
Step 4: common paths, and the site type
Last, the scanner tries a well-known address for what's still missing, but only where it makes sense. If it found a product but no cart, it tries /cart. If it found neither a product nor a pricing page, it tries /pricing. A probe counts only when it returns a 200 and an HTML page, and only when that page is really there. If the address sends the scanner back to your home page, it doesn't count. Nor does it count when your site sends the same page for any address, as single-page apps and some "not found" pages do: the scanner checks this by opening one made-up address, and a probe that gets the same page back counts only if it shows prices or a pricing heading (or a cart heading for /cart) that the made-up address doesn't.
Then it labels the site:
- Store A product page or a cart was found. Store checks such as product data, add-to-cart and checkout apply.
- SaaS A pricing page was found, but no product or cart. The sign-up button on the pricing page is checked instead.
- Other None of the three. Store and pricing checks are marked not tested, never failed.
The pages it settles on are then fetched as a browser and as an AI assistant for the checks themselves, as how AgentScore works describes.
Make your products easy to find
An AI agent landing on your home page has the same problem, with less patience. The fixes are the same:
- Link to products in plain HTML. Ordinary
<a href>links to products, categories and the cart on your home page. See link your key pages from the home page. - Publish a product sitemap with "product" in its name, listed early in your sitemap index.
- Put prices in the HTML as text, next to the product's picture and link. Prices AI agents can read covers the details.
- Mark product pages up as products, with Product structured data and a real add-to-cart button.
If your report says "no product or pricing page was found" and you run a store, one of these is usually missing.