babylist.com

When we requested your homepage as Meta-ExternalAgent, Bytespider, and AURbot, the response was a block, a challenge page, or an empty shell instead of the page a browser gets.

• aurbot: challenge (200)
• bytespider: challenge (200)
• meta-externalagent: challenge (200)

Blocks like this almost never come from robots.txt. They come from bot management at the edge (Cloudflare Bot Fight Mode or "Block AI bots", Akamai Bot Manager, DataDome, HUMAN/PerimeterX, Kasada, Imperva) or from a hosting firewall. The response headers usually name the layer that challenged the request; add an allow rule there for the shopping agents.

Cloudflare: in Security → Bots (or AI Crawl Control), set the AI bots control to allow the shopping agents, and make sure Super Bot Fight Mode is not challenging verified bots. For anything still caught, add a WAF custom rule with the action Skip (skipping bot management and managed challenges) for:

(http.user_agent contains "ChatGPT-User") or (http.user_agent contains "OAI-SearchBot") or (http.user_agent contains "Claude-User") or (http.user_agent contains "PerplexityBot") or (http.user_agent contains "meta-externalfetcher") or (http.user_agent contains "AURbot")

Other WAFs: look for a "known bots" or "verified bots" category and allow it; otherwise allow-list the user agents above. Rate-limit rules scoped to product or search paths are a frequent hidden cause.

If an outcome below reads js-shell, that agent was not blocked: it received an empty JavaScript app shell with no product content. Server-render the page so the content is in the HTML.

On Shopify, the storefront CDN is Shopify's and you cannot edit its WAF. Blocks of this kind usually come from a bot-blocking or anti-fraud app, a password-protected store, or a Cloudflare proxy placed in front of the domain (Shopify Plus). Remove the app, disable the password, or add the allow rule at that proxy.

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.

On Shopify, robots.txt is generated from the theme. In Online Store → Themes → Edit code, add a robots.txt.liquid template (Add a new template → robots.txt) if you do not have one, keep the default groups, and append your rules after the loop. SEO apps that "manage" robots.txt for you are a common source of AI-bot blocks; check their settings too.

Nothing usable was found at /.well-known/http-message-signatures-directory (HTTP 404). 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
    }
  ]
}

On Shopify, themes cannot serve files under /.well-known/, so treat this as out of scope unless you run a proxy (Shopify Plus with Cloudflare) that can answer the path. It is worth 2 points.

Requesting https://www.babylist.com 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.

On Shopify, themes cannot vary the response on Accept, so this is only possible behind a proxy (Shopify Plus). Skip it otherwise.

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.

On Shopify, you do not build this yourself: Shopify publishes the UCP profile, the UCP MCP endpoint, and the Storefront MCP server for stores with the agentic storefront enabled. In the admin, turn on the agentic storefront and catalog syndication (Settings → Apps and sales channels, or the agentic commerce / "Sell with AI agents" settings depending on your admin version), confirm the online store is not password-protected, and keep the store on a plan that includes agentic commerce features. Allow a little time to propagate, then re-scan.

https://www.babylist.com/api/ucp/mcp did not return a tool list (HTTP 404). The endpoint must speak MCP over Streamable HTTP: accept a JSON-RPC POST and answer with JSON or an SSE stream.

Test it the way we do:

curl -sS -X POST https://www.babylist.com/api/ucp/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

• tools/list must work without authentication; require auth on the tool calls that need it, and advertise it through OAuth discovery (see that fix).
• Return 200 with Content-Type: application/json (or text/event-stream), never a 405 for POST or an HTML page.
• Make sure the URL in the UCP profile (services → dev.ucp.shopping → mcp.endpoint) points at this endpoint exactly.

On Shopify, you do not build this yourself: Shopify publishes the UCP profile, the UCP MCP endpoint, and the Storefront MCP server for stores with the agentic storefront enabled. In the admin, turn on the agentic storefront and catalog syndication (Settings → Apps and sales channels, or the agentic commerce / "Sell with AI agents" settings depending on your admin version), confirm the online store is not password-protected, and keep the store on a plan that includes agentic commerce features. Allow a little time to propagate, then re-scan.

No MCP server answered tools/list at /api/mcp (HTTP 404). 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.

On Shopify, you do not build this yourself: Shopify publishes the UCP profile, the UCP MCP endpoint, and the Storefront MCP server for stores with the agentic storefront enabled. In the admin, turn on the agentic storefront and catalog syndication (Settings → Apps and sales channels, or the agentic commerce / "Sell with AI agents" settings depending on your admin version), confirm the online store is not password-protected, and keep the store on a plan that includes agentic commerce features. Allow a little time to propagate, then re-scan.

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"

None of /.well-known/agent-card.json, /.well-known/agent.json, and /.well-known/agent-skills/index.json was found. An A2A agent card tells other agents that your store has an agent of its own and what it can do; an Agent Skills index lists reusable skill files. Either satisfies this one-point check.

A minimal A2A agent card at /.well-known/agent-card.json:

{
  "name": "Example Shopping Assistant",
  "description": "Find, compare, and buy Example products.",
  "url": "https://www.example.com/a2a",
  "version": "1.0.0",
  "protocolVersion": "0.3.0",
  "capabilities": { "streaming": true },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain", "application/json"],
  "skills": [
    {
      "id": "find-products",
      "name": "Find products",
      "description": "Search the catalog by query, size, colour, and price.",
      "tags": ["shopping", "search"]
    }
  ]
}

Or, if you publish skills rather than an agent, serve /.well-known/agent-skills/index.json listing each skill's name, description, and the URL of its SKILL.md. Only publish a card for an endpoint that actually answers.

We could not find a return/refund and shipping policy page. We look for links on the homepage whose text or path mentions returns/refunds and shipping/delivery, plus your platform's standard paths, and require the page to load (200, HTML). Agents read these to answer "can I send it back" and "when will it arrive" before they recommend a purchase.

• Give each policy its own URL (not a tab inside an FAQ accordion, not a PDF).
• Link both from the homepage footer with plain anchor text: "Returns" / "Refund policy" and "Shipping".
• Keep the pages public and server-rendered; a 200 with an empty JavaScript shell does not count.

On Shopify, write the policies under Settings → Policies (Refund policy and Shipping policy). Shopify publishes them at /policies/refund-policy and /policies/shipping-policy, which we check directly; also add them to the footer menu under Online Store → Navigation.

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.

On Shopify, add the object to the theme's product JSON-LD block, with the window and fees as theme settings, and link merchantReturnLink to {{ shop.refund_policy.url }}.