Can agents find your site and its capabilities?
The page registers no tools via the WebMCP browser API (navigator.modelContext).
Fix: Expose your actions to AI agents with the WebMCP browser API: register tools via navigator.modelContext.registerTool. Optionally also publish a /.well-known/webmcp.json tool catalog as a discovery signpost.
Couldn't analyse the homepage: The server returned a bot-protection challenge page (matched "/_incapsula_resource") instead of your site. AI agents are likely served the same challenge.
Fix: Allow well-behaved crawlers (or our User-Agent) through your CDN/WAF bot-management rules and re-run — server-side fetchers and some AI crawlers are otherwise served a challenge instead of your content.
Crawled 4 of 12 discovered pages beyond the homepage.
Lighthouse Agentic Browsing audits ran.
Could not identify a known website platform (custom stack or unrecognised).
Can agents understand your content?
Homepage ignored Accept: text/markdown and returned HTML.
Fix: Serve a markdown version of high-value pages when the client asks for text/markdown. AI summarisers, chatbots and IDE agents prefer markdown — fewer tokens, no DOM noise.
Couldn't analyse the homepage: The server returned a bot-protection challenge page (matched "/_incapsula_resource") instead of your site. AI agents are likely served the same challenge.
Fix: Your CDN/WAF served our scanner a bot-protection challenge instead of the page, so its content could not be analysed. Allow well-behaved crawlers (or our User-Agent) through your bot-management rules and re-run. AI agents that drive a real browser may still reach the page, but server-side fetchers (and some AI crawlers) will see the same challenge.
All 4 reachable key pages have both a <title> and <h1>.
All 4 pages return ≥80 words of visible text without JavaScript.
Can agents actually operate the page?
4 of 14 agent-critical accessibility audits failed (Links do not have a discernible name, `[aria-*]` attributes do not match their roles, Elements with an ARIA `[role]` that require children to contain a specific `[role]` are missing some or all of those required children., `[role]`s are not contained by their required parent element) — an agent may be unable to identify or operate the affected elements.
Fix: Fix the failing agent-accessibility audits listed below (accessible names on controls, valid ARIA roles/relationships, nothing interactive hidden from the tree).
Lighthouse flagged this audit — agents may be unable to perceive or operate the affected elements.
Fix: Remove ARIA attributes that aren't allowed on the element's role.
Lighthouse flagged this audit — agents may be unable to perceive or operate the affected elements.
Fix: Ensure ARIA roles that need specific children contain them (e.g. list → listitem).
Lighthouse flagged this audit — agents may be unable to perceive or operate the affected elements.
Fix: Ensure ARIA child roles are nested inside their required parent role.
Lighthouse flagged this audit — agents may be unable to perceive or operate the affected elements.
Fix: Give every link discernible text (avoid bare icons / "click here") so agents know where it goes.
A well-formed [accessibility tree](http://goo.gle/lighthouse-agentic-a11y) helps AI agents to navigate and interact with the page.
The page registers no tools via the navigator.modelContext browser API, so an AI agent has no structured way to operate it.
Fix: Expose your site’s actions to AI agents with the WebMCP browser API: call navigator.modelContext.registerTool({ name, description, inputSchema, execute }) from your page so an agent can invoke them. Implement it directly, or with a library like the @mcp-b polyfill (https://mcp-b.ai). Spec: https://github.com/webmachinelearning/webmcp.
Lighthouse accessibility score: 70/100. Agents read the page through its accessibility tree, so this is a proxy for how navigable your site is to an AI agent.
Fix: Resolve the failing accessibility audits below — each one removes an element or relationship an agent would otherwise be blind to.
Uses ARIA roles only on compatible elements passed.
`button`, `link`, and `menuitem` elements have accessible names passed.
`[aria-hidden="true"]` is not present on the document `<body>` passed.
`[aria-hidden="true"]` elements do not contain focusable descendents passed.
`[role]`s have all required `[aria-*]` attributes passed.
`[role]` values are valid passed.
`[aria-*]` attributes are valid and not misspelled passed.
`[aria-*]` attributes have valid values passed.
Buttons have an accessible name passed.
Document has a `<title>` element passed.
0.01
0.030 (field data from CrUX) — good.
398ms (field data from CrUX) — good.
2 forms missing annotations
Lists the [WebMCP tools](http://goo.gle/webmcp-docs) registered at the time of analysis.
No tool catalog was found at /.well-known/webmcp.json (or /.well-known/webmcp). The catalog is a community convention, not part of the WebMCP standard, so this does not affect WebMCP presence.
Fix: Consider also publishing a tool catalog at /.well-known/webmcp.json: a JSON document with a "spec" of "webmcp/0.1" and a "tools" array, where each tool declares a name and a clear description. It is a community convention (optional, not part of the WebMCP standard) that lets crawlers and agents discover your tools without executing JavaScript.
Can agents safely transact?
No Strict-Transport-Security header on the homepage.
Fix: Add `Strict-Transport-Security: max-age=15768000; includeSubDomains` so browsers and agents refuse to downgrade to http for at least six months.
Found 1 http:// reference in the homepage HTML — browsers will block these resources.
Fix: Update every http:// resource URL to https:// (or use protocol-relative `//`). Common offenders: image CDNs and legacy embed snippets.
/.well-known/oauth-authorization-server returned the site's HTML app shell — treating as not published.
Fix: Publish /.well-known/oauth-authorization-server so AI agents discovering your OAuth setup can negotiate flows automatically. Required if your site offers an authenticated API.
/.well-known/oauth-protected-resource returned the site's HTML app shell — treating as not published.
Fix: Publish /.well-known/oauth-protected-resource so AI agents discovering your OAuth setup can negotiate flows automatically. Required if your site offers an authenticated API.
No Web Bot Auth signature headers — sites can't verify agent identity.
Fix: Web Bot Auth (IETF HTTP Message Signatures over Signature / Signature-Input) lets you cryptographically verify which agent is hitting you. Several CDNs offer turn-key support; otherwise skip until vendor support matures.
No Content-Security-Policy header on the homepage.
Fix: Add a Content-Security-Policy. Even a strict default-src directive cuts XSS blast radius dramatically. Start in report-only mode to find violations.
No Referrer-Policy header on the homepage.
Fix: Add `Referrer-Policy: strict-origin-when-cross-origin` so outbound links don't leak full URLs (including query strings) to third parties.
No `X-Content-Type-Options: nosniff` header.
Fix: Add `X-Content-Type-Options: nosniff` to prevent browsers (and some agents) from re-interpreting your responses as a different content type.
No X-Frame-Options header and no CSP frame-ancestors directive.
Fix: Add `X-Frame-Options: SAMEORIGIN` (or a CSP frame-ancestors directive) to prevent your site being framed by a phishing host.
Homepage scheme is https:.
http://boots.com → https://www.boots.com/ (2 hops).
No stack-trace markers in the first 5KB.
Valid for 142 more days (Dec 10 23:59:59 2026 GMT, issuer: Sectigo Public Server Authentication CA OV R36).
Server / X-Powered-By headers don't leak product version.