Agentic Browsing: why did the form fail after passing Lighthouse?

Where to start testing a browser agent on your site

I recommend starting with one task whose outcome you can inspect. For an inquiry form, check that visitors can recover from an error and that a valid inquiry reaches the receiving system.

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.

Lighthouse: 2/2 in September, 3/3 in October; Cloudflare 20/100

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.

Follow-up, 12 October 2026: The new Lighthouse 13.4.1 record shows 3/3 for both the homepage and this article. The accessibility-tree audit still passed and CLS remained 0. Because /llms.txt is now published, its audit changed from N/A to a pass. The three WebMCP checks remained N/A.

The move from 2/2 to 3/3 changed the denominator: a new check became applicable after publishing the file. The first two checks were still good.

The 12 October 2026 follow-up reports are available for inspection: homepage HTML and JSON; article HTML and JSON. These were collected using Lighthouse 13.4.1 and Chrome 154 against the live pages; they are not form-submission tests.

The same URL received 20/100, at Basic Web Presence, in the Cloudflare Agent Readiness scan. This is the archived 10 September result, not a new Cloudflare score from October.

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␠: the symbol ␠ denotes one space before and after the three letters.

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.

Measure verified completion, not just a passing audit

An operational completion measure is the number of tasks verified in the destination system divided by the number of documented attempts. In the controlled September 10 case, the invalid input yielded 0 accepted inquiries from one attempt. After the correction, one corrected inquiry was accepted from one attempt in the local receiver. Each is a single case observation, not an estimated success rate for browser agents.

To estimate a meaningful completion rate, define tasks, conditions, model/browser versions and repeated attempts first. Count only outcomes checked at their destination. Chrome's evals guidance explains why AI-driven outcomes need repetition; the accepted test inquiry here supports only this case.

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 to 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

To choose the next check, I would start with what remains unknown: can the agent access the page, discover the capability it needs, or complete the task? Each question calls for a different test.

The results complement each other. A low Cloudflare score does not invalidate the passing Lighthouse checks: the tools examine different capabilities. Use the table to choose the check that answers your question.

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.
• Also test dropdowns/date pickers, slow responses and network interruptions; ensure retries don't create duplicate outcomes.
• If a CAPTCHA or human-verification step blocks the run, record it as BLOCKED with the reason, not as a confirmed agent task failure.
• For WebMCP actions, inspect tool exposure, input and results in Chrome DevTools for agents and repeat the evaluation.

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

Chrome’s agent-ready toolkit can help choose which scenarios to run after each change and where to include an agent.

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