Agentic Browsing: the audits passed. The form still failed its recovery test.

What is Agentic Browsing, and who should test it?

Agentic Browsing means an AI agent operates a browser to complete a task: booking a demo, filling a form or placing an order.

I recommend starting with the action that matters most to your customer. For SaaS, that might be trial registration; for services, requesting a quote.

Define the finish line first. “The agent clicked submit” records an action. “The receiving system contains the correct inquiry” defines a checkable result.

The work also helps human visitors. An unclear field or unhelpful error message makes recovery harder for anyone using the form.

The live site: 2/2 in Lighthouse, 20/100 in Agent Readiness

The public homepage at https://nirlevi.com/ was also audited directly. Agentic Browsing returned 2/2, with CLS measuring 0.

The accessibility tree passed. WebMCP checks and llms.txt were N/A. Inspect the complete report and raw JSON.

Other categories returned Performance 75, Accessibility 97, Best Practices 100 and SEO 100. These are homepage lab results, not measurements of this article.

The same URL received 20/100, at Basic Web Presence, in the Cloudflare Agent Readiness scan.

I would not turn the tool’s 12 recommendations into an automatic development backlog. First decide which capabilities this site should provide.

An API catalog adds little without a public API. A useful form error, on the other hand, immediately helps a visitor recover.

The scan observation record preserves the displayed results. The local recovery experiment follows, with reproducible input and a verified repair.

The case: rejected input with no useful explanation

The inquiry form on this site had a small mismatch between browser and server validation. The input was SEO : three letters with a space at either end.

The browser required minlength="5", which that value satisfied. The server trimmed the outer spaces, counted three characters and rejected it.

Rejecting the request was correct. The defect was the explanation: the form said sending was unconfirmed and suggested retrying or emailing directly.

Retrying unchanged input cannot solve this. The visitor needs to know which field to correct, and an agent needs that same information.

This edge case was selected after inspecting the code. It exposes an existing recovery defect; it does not measure how often visitors encounter it.

Meanwhile, Lighthouse returned 2/2 on the same code: the accessibility tree passed and CLS measured 0. Four additional checks were N/A.

Inspect the complete baseline report or its raw JSON. Other categories remain visible as measured in the local environment.

The fix: identify the error and let the visitor recover

The fix keeps the server rule and applies it in the browser too. Short input stops at the field before submission.

• Browser and server share the same message validation function.
• The field receives aria-invalid and an explanation connected with aria-describedby.
• Focus returns to that field, while existing entries remain intact.
• The interface shows success only after the server confirms acceptance.

In the retest, invalid input stopped in the browser. Replacing it with “בדיקת נראות האתר בחיפוש” produced one accepted inquiry in the test receiver.

The completion evidence is the accepted record, alongside the request log. A success message alone would not establish that.

The follow-up report stayed at 2/2. What changed was the ability to correct the form and continue.

I would keep this case in the form’s regression checks. It exercises a recovery path that the initial page audit never entered.

The audit checklist: concrete fixes and the next test

Lighthouse helps identify technical obstacles. Open the finding, repair its cause, then exercise the task that depends on it.

Chrome’s documentation describes an experimental category requiring Chrome 150 or later. Its fraction counts passing checks; it is not a weighted 0–100 score.

<label for="request">What should we review?</label>
<textarea id="request" name="goal"
  aria-invalid="true" aria-describedby="request-error"></textarea>
<p id="request-error">Write a few words about your request.</p>

# Example company

Product documentation and support for customers.

## Documentation
- [Getting started](https://example.com/docs): Setup instructions.

Agent Readiness vs Agentic Browsing vs a task test

I use this comparison to choose the next test. The question is what evidence the decision needs, rather than which tool gives the highest number.

The results complement each other. A low Cloudflare score does not invalidate the passing Lighthouse checks; both leave the actual user outcome to verify.

How to run a test you can repeat

Open the exact page in Chrome, enter DevTools and select Lighthouse. Enable Agentic Browsing, run the audit and save the report.

If the category is absent, check your Chrome and Lighthouse versions. The CLI is another option, used for this example.

npx lighthouse@13.4.1 https://example.com/ \
  --only-categories=agentic-browsing \
  --output=json --output=html --output-path=./audit

Record the URL, date, versions, authentication state and emulated device. Otherwise, changed conditions can be mistaken for the effect of a repair.

• Submit valid input and inspect the record in the receiving system.
• Enter invalid input: is the required correction clear, and are the other entries retained?
• Correct and resubmit: does the exact requested result exist?
• Test a retry after a delay or disconnection, checking for duplicate outcomes.

Use a test environment or coordinated test data for commercial forms. A booking test should produce a test booking without an accidental charge.

Is the defect in the website or the testing tool?

An agent failure starts an investigation. First check whether the tool supports the action and whether its instruction matched the interface.

The form mismatch appeared in both the code and the interface. That supports a site fix. A failed tool instruction alone would not.

How does this relate to GEO, and what comes first?

Agentic Browsing concerns completing actions. GEO concerns visibility in AI answers. They address different goals, even when they involve the same website.

Google Search says its AI features need no special files and that it ignores llms.txt. An audit pass promises neither a mention nor a ranking.

My recommended order: choose a valuable action, fix its obstacles, then decide whether WebMCP adds something useful to that path.

Use the test template to hand development an actionable finding: input, defect, repair and acceptance criteria. For answer visibility, use the AI measurement guide.

Frequently asked questions