19216801.guide

Your robots.txt has no Content-Signal directive. Content Signals (contentsignals.org) is a robots.txt extension that states, separately, whether your content may be used for search, as real-time AI input (which is what shopping agents do), and for training. An explicit signal scores fully; silence scores half.

You can welcome shopping agents while still declining training. Add to the * group (or to each group you care about):

User-agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=no
Allow: /

Keep ai-input=yes; set ai-train however you like. If Cloudflare manages your robots.txt, the equivalent setting lives in AI Crawl Control → Content Signals.

Edit the robots.txt served from your web root (or the CDN/edge rule that generates it) and redeploy. Crawlers cache robots.txt for up to 24 hours, so re-scan after a day.

Nothing usable was found at /.well-known/http-message-signatures-directory. Web Bot Auth is the IETF draft that lets agents sign requests with HTTP Message Signatures; parties that sign publish their Ed25519 public keys in this directory, and verifiers fetch it to check the Signature and Signature-Input headers. Visa's Trusted Agent Protocol, Mastercard's Agent Pay, and Cloudflare's signed-agent verification are all built on it.

Two steps matter for a storefront:

• Verify signatures at your edge so signed agents are let through bot management instead of challenged. On Cloudflare this is the Verified Bots / signed agents setting; other WAFs are adding the same.
• Publish your own directory for any requests you sign (your own agent, service-to-service calls, or a verifier that expects one to exist). Serve it with Content-Type: application/http-message-signatures-directory+json:

{
  "keys": [
    {
      "kty": "OKP",
      "crv": "Ed25519",
      "kid": "2026-01",
      "x": "<base64url-encoded public key>",
      "nbf": 1767225600,
      "exp": 1798761600
    }
  ]
}

Serve the file from the same origin as the storefront, with a long cache lifetime, and rotate keys by adding the new one before removing the old.

Your sitemap (https://19216801.guide/sitemap.xml) is reachable and we sampled 3 URLs, but none looked like a product URL and no child sitemap was named after products. Agents use the sitemap to enumerate the catalog without crawling.

Make product entries recognisable: either keep product URLs on a conventional path (/products/…, /product/…, /p/…, /item/…) or split products into a child sitemap whose filename contains "product" (for example sitemap-products-1.xml). Compressed (.xml.gz) sitemaps are skipped; serve plain XML.

Requesting https://19216801.guide with Accept: text/markdown returned HTML. Agents that support content negotiation get a page that is a tenth of the size and needs no parsing. This is worth one point and is a nice-to-have.

When the Accept header prefers text/markdown, respond with a Markdown body and Vary: Accept:

GET /products/trail-runner-2 HTTP/1.1
Accept: text/markdown

HTTP/1.1 200 OK
Content-Type: text/markdown; charset=utf-8
Vary: Accept

# Trail Runner 2
**$129.00** · In stock · SKU TR2-BLK-10

Lightweight waterproof trail shoe. Sizes 6–13. Free shipping over $75, 30-day returns.

The simplest place to do this is edge middleware (a Cloudflare Worker, Vercel or Netlify middleware, or a Next.js route) that converts the rendered HTML or renders a dedicated template. If you are on Cloudflare, the "Markdown for Agents" option in AI Crawl Control does the conversion for you.

No profile was found at /.well-known/ucp. The Universal Commerce Protocol (ucp.dev) is how an agent discovers, in one request, that your store can be shopped programmatically: which services you expose, over which transports (REST and MCP), and whether checkout is supported. It is the largest single item in the transactability pillar, and without it (or an attested ACP integration) your AUR is capped at 79.

A complete profile declares a shopping service with an endpoint and a checkout capability:

{
  "ucp": {
    "version": "2026-01-11",
    "services": {
      "dev.ucp.shopping": {
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specification/overview",
        "rest": {
          "schema": "https://ucp.dev/services/shopping/openapi.json",
          "endpoint": "https://www.example.com/api/ucp"
        },
        "mcp": {
          "schema": "https://ucp.dev/services/shopping/mcp.json",
          "endpoint": "https://www.example.com/api/ucp/mcp"
        }
      }
    },
    "capabilities": [
      {
        "name": "dev.ucp.shopping.checkout",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specification/checkout",
        "schema": "https://ucp.dev/schemas/shopping/checkout.json"
      },
      {
        "name": "dev.ucp.shopping.order",
        "version": "2026-01-11",
        "spec": "https://ucp.dev/specification/order",
        "schema": "https://ucp.dev/schemas/shopping/order.json"
      }
    ],
    "payment_handlers": []
  }
}

Serve it as application/json from the storefront origin. The endpoints must exist and speak the protocol; the MCP one is tested by the next check. Check ucp.dev for the current version string and schema URLs.

Serve the profile from the storefront origin and implement the shopping service behind it; most of the work is the checkout capability, which maps onto your existing cart and checkout APIs.

No MCP server answered tools/list at /api/mcp. This is the conventional storefront endpoint (Shopify's Storefront MCP lives here) where an agent can search the catalog, read policies, and manage a cart without scraping.

Expose an MCP server over Streamable HTTP at that path with tools such as search_shop_catalog, get_product_details, search_shop_policies_and_faqs, get_cart, and update_cart. tools/list must be callable without authentication.

If you already run the UCP MCP endpoint, mounting the same server at /api/mcp is enough.

Nothing was found at /.well-known/mcp/server-card.json. The server card is the MCP discovery document that lets an agent find your server, its transport endpoint, and how to authenticate, without reading documentation.

Publish a JSON document describing the server (field names follow the current MCP server-card draft; adjust to the version you target):

{
  "serverInfo": { "name": "example-storefront", "title": "Example Storefront", "version": "1.0.0" },
  "description": "Search the Example catalog, read policies, and manage a cart.",
  "transport": { "type": "streamable-http", "endpoint": "https://www.example.com/api/mcp" },
  "capabilities": { "tools": {} },
  "authentication": { "required": false }
}

Serve it as application/json with CORS enabled, and keep the endpoint in sync with the one your UCP profile names.

No API catalog was found. RFC 9727 defines /.well-known/api-catalog, a linkset that points agents at your APIs and their descriptions (OpenAPI, MCP, UCP) in one place.

Serve this as application/linkset+json:

{
  "linkset": [
    {
      "anchor": "https://www.example.com/",
      "service-desc": [
        { "href": "https://www.example.com/api/openapi.json", "type": "application/vnd.oai.openapi+json" }
      ],
      "service-doc": [
        { "href": "https://www.example.com/developers", "type": "text/html" }
      ],
      "service-meta": [
        { "href": "https://www.example.com/.well-known/ucp", "type": "application/json" },
        { "href": "https://www.example.com/.well-known/mcp/server-card.json", "type": "application/json" }
      ]
    }
  ]
}

Also advertise it from the homepage with a Link header, which we accept on its own:

Link: </.well-known/api-catalog>; rel="api-catalog"

No MerchantReturnPolicy structured data was found on the product offer, the homepage, or the organization. A written policy page is good; machine-readable terms let agents compare return windows and fees across stores without reading prose.

Attach it to the product Offer (preferred, since that is where agents are when deciding) or to the Organization/OnlineStore on the homepage:

"hasMerchantReturnPolicy": {
  "@type": "MerchantReturnPolicy",
  "applicableCountry": "US",
  "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
  "merchantReturnDays": 30,
  "returnMethod": "https://schema.org/ReturnByMail",
  "returnFees": "https://schema.org/FreeReturn",
  "refundType": "https://schema.org/FullRefund",
  "merchantReturnLink": "https://www.example.com/policies/refund-policy"
}

Use MerchantReturnNotPermitted for final-sale items and MerchantReturnUnlimitedWindow if you accept returns indefinitely. Keep it consistent with the written policy page.