---
name: agentic-search-readiness-audit
description: "Run an agentic search readiness audit on a website to find out whether AI agents can complete real tasks on it, using Lighthouse's Agentic Browsing category, an accessibility tree review, a sweep for known agent blockers and timed runs by a real browser agent, then write it up as a Word document with a scorecard and a prioritised fix list. Use this skill whenever someone asks whether AI agents can use their site, mentions agentic search readiness, agent readiness, agentic search optimisation, agent experience or AX, WebMCP, the Lighthouse agentic browsing audit, or says things like 'can ChatGPT agent buy from us', 'test our site with an AI agent', 'why do agents fail on our checkout', 'run an agentic search readiness audit on X', 'run an agent readiness audit on X', or 'are we agent ready'. Use it even when the request sounds quick, because the staged structure and the real task runs are the point, and every stage that cannot be automated produces a ready-to-run manual sheet instead."
---

# Agentic Search Readiness Audit

You are running an agentic search readiness audit: Baseline, Interpret, Sweep, Run, Decide, Score. The output is a structured report in the chat, the same report as a Word document, and a task run sheet the user repeats on a schedule.

Be honest about the split between what you can test and what needs a human. You **can** run Lighthouse, read the accessibility tree, sweep for blockers, check rendering and judge the WebMCP question. You **can** drive real task runs when browser tooling is connected. You **cannot** invent a completion rate, so where no browser is available you produce the run sheet, pre-filled and ready, and say clearly that stage 4 has not run.

## What you need before you start

1. **Domain:** Required, so ask and stop if it is missing.
2. **3 to 5 real tasks** the site exists to support. If not given, propose them from the site's own navigation and primary calls to action, then get a yes before running anything.
3. **Templates to cover:** Homepage plus one of each major template, plus every page on the critical task path. Default to homepage, a category or listing page, a product or service page, and the first step of the primary conversion flow.

Ask once about authenticated flows. Default to public pages only, because testing behind a login means handling credentials and that is the user's decision to make deliberately.

## Browser tooling

Check what is available in this order, and say which one you are using.

1. **Claude in Chrome** (`mcp__claude-in-chrome__*`), preferred when present, because it drives the user's real browser.
2. **Chrome DevTools MCP**, if connected.
3. **Neither:** Complete stages 1 to 3 and 5 from fetched HTML and Lighthouse output the user supplies, then produce the stage 4 run sheet for the user to run by hand. State this in one line and continue. Never simulate a task run.

## Rules that apply throughout

- **Every finding names a location:** Template, element and what a fix would touch.
- **Findings are template-level wherever possible:** Report "unlabelled search button, global header, affects all templates" over a list of URLs.
- **Tables over prose**, and every claim carries its evidence.
- **Never guess a completion rate:** A task that was not run is marked not run.
- Flags: `[!!]` blocks a task, `[!]` degrades a task, `[+]` a strength.

---

## Stage 1: Lighthouse baseline

Run the Agentic Browsing category against each template. If you cannot run Lighthouse yourself, give the user the exact command and ask for the output:

```
npm install -g lighthouse@latest
lighthouse --view --only-categories=agentic-browsing <URL>
```

Record pass or fail per template on the 4 audits: Accessibility tree well-formedness, WebMCP validation, llms.txt recommendations, and layout shift.

**State the caveat in the report, every time:** The category reports a fractional score and pass or fail per audit, so it does not behave like Performance or SEO, the category is experimental and still changing, and a page with no agent features at all can score green. A pass is weak evidence of readiness whilst a fail is strong evidence of a problem.

## Stage 2: Accessibility tree

For each template, get the accessibility tree. With Claude in Chrome, use `read_page` and work from the roles and names it returns. Otherwise, fetch the HTML and infer from the markup, and say that you inferred.

Produce one table of every interactive element on the critical path that fails any of these checks.

| Check | Fails when |
|---|---|
| Has an accessible name | Icon-only buttons, unlabelled links, fields with placeholder-only labelling |
| Is in the tree at all | `div` or `span` with a click handler, no role, no tabindex |
| Name describes the action | "Click here", "Submit", "More", or a name that repeats across different actions |
| Reachable without hover | Menus and controls that only appear on mouseover |

Count them and report the count prominently, because the number is what gets the work scheduled.

## Stage 3: Blocker sweep

Check all 8 across the templates in scope. For each, report present or absent, where, and the fix.

| Blocker | How to detect it |
|---|---|
| Unstable layouts | CLS from stage 1, plus images and embeds without dimensions |
| Non-semantic buttons | `<div`/`<span` with `onclick`, or click handlers bound in JS to non-interactive elements |
| Unlabelled controls | From stage 2 |
| Transparent overlays | Full-viewport absolutely positioned elements with low or zero opacity, consent layers that persist |
| Heavy client-side rendering | Compare raw HTML against rendered DOM. Flag when primary content or controls are absent from the raw HTML |
| Hover-only interactions | `:hover` rules that reveal navigation or controls with no focus equivalent |
| Infinite scroll | Scroll-triggered loading with no pagination and no end state |
| Blanket CAPTCHAs | CAPTCHA or bot challenge on non-sensitive pages, and 403s to common agent user agents |

Also check `robots.txt` and any WAF behaviour for rules that block agent user agents, and report those separately, because they are owned by a different team and fixed in a different place.

## Stage 4: Real task runs

The stage that produces evidence. Run each task 3 times.

For each run record: Outcome (completed, partial, failed), the step it stopped at in plain language, what it clicked instead, elapsed time, and whether the 3 runs agreed.

Rules:

- **3 runs minimum per task**, because agents are non-deterministic and one failure proves nothing.
- **Write instructions as a customer would say them**, with a real constraint, so the agent either finishes or fails rather than wandering.
- **Never take an action with real consequences:** Stop at the step before payment, submission, account creation or any irreversible click, and record that you reached it. Say so in the report.
- **Do not enter credentials, payment details or personal data:** If a task requires them, mark it as reached-the-gate and stop.

Also check for prompt injection exposure: Look at user-generated content, reviews and third-party embedded content on the task path, and flag anything rendering untrusted text into a page an agent will read. Note that prompt injection is number one on the OWASP LLM Top 10 with no complete fix, so the finding is about reducing exposure.

## Stage 5: WebMCP decision

Give a yes or no with reasons. Default to **not yet** and justify it, because the blockers in stage 3 affect every agent today whilst WebMCP depends on a proposed standard settling and on agents adopting it.

Recommend it sooner when any of these hold: The site has a genuinely complex transactional flow where inference is hard, measurable agent traffic with a commercial reason to court it, or spare front-end capacity and an appetite for a standards bet. Mention Google's webmcp skill for delegating the implementation, once.

Never recommend WebMCP while stage 2 has unresolved `[!!]` findings. Say why in one line.

## Stage 6: Scorecard and fix list

Score each task path out of 100.

| Component | Weight |
|---|---|
| Task completion rate across runs | 0.40 |
| Accessibility tree integrity on the path | 0.25 |
| Blocker count from stage 3 | 0.20 |
| Layout stability | 0.10 |
| llms.txt and discoverability basics | 0.05 |

Where stage 4 did not run, score what is measurable, mark completion as pending, show the formula so the user can finish it, and do not present a total as though it were complete.

Order fixes by **how many templates each one clears**, not by severity in isolation. Give every fix an owner: Front-end engineering for semantics, labels and rendering, engineering and design together for layout stability, whoever owns the WAF for bot rules, and the site owner for llms.txt.

## Summary section

Snapshot table, one line per task: Score or partial score, the step that failed, top action. Then up to 5 priority actions with the templates each clears. Then open questions, 4 to 6 bullets.

Close with the standing caveat, verbatim: Agent behaviour varies by agent, by run and by week, so this is a directional read of where your site blocks tasks today, and the completion rate is a sample.

## Then produce the file

**Word document** of the full report. Use the docx skill if available, otherwise python-docx. Body DM Sans 12 with Calibri fallback, headings in dark cornflower blue, header rows bold with a light fill, flags as bold labels, a cover line with the domain, the date and the single most important finding, page numbers in the footer. Name it `<domain>-agentic-search-readiness-audit-<month-year>.docx`.

If stage 4 ran by hand, also produce the run sheet as a spreadsheet: One row per task per run, with columns for outcome, stopping step, what it clicked, elapsed time and notes.

Tell the user where the files are.

## Where to take it next

Mention once, at the end, only if the user seems likely to want more: Re-running stage 4 monthly on the top task so the completion rate becomes a trend line, extending the audit behind the login once credential handling is agreed, and running the same tasks through a second agent to separate site problems from agent problems.