An agent-readability audit gives a growth team another list of things to fix. The useful question is which findings explain a real failure on a task that matters.
Can an agent locate the right product specification? Can it distinguish a general return policy from an exception? Can it reach the correct signup destination without choosing the wrong plan?
Those questions give you a practical way to evaluate agent access without assuming that a better audit score creates more demand.
Vercel Developers has described a website auditing tool with automated checks, agent-behavior visualizations, remediation prompts, and CLI access. That announcement provides a reason to investigate this dimension of website quality. It does not establish that its scores predict task success or revenue.
The workflow below is an editorial recommendation for evaluating audit findings through observed task completion. No results from running it are reported here.
Start with a decision worth making
Define what the test will help you decide before running an audit. A useful decision might be whether to fix ambiguous policy content, change a product-page template, or add agent task checks to launch QA.
Choose a small set of public pages that represent meaningful customer decisions. Include a common template and at least one page with an exception, such as a product with different eligibility requirements. Exceptions help reveal whether an agent handles the details that determine a correct answer.
Keep the investment proportionate to the evidence. If you have no reliable indication that customers use agents in this journey, treat the work as a bounded exploration. Existing customer problems should still compete for the same engineering time.
Define success before watching a run
Turn each customer question into a task with an answer key. Avoid broad prompts such as “understand this product.” They leave too much room for subjective grading.
For each task, record:
- The starting page and exact instruction.
- The correct answer or destination, including relevant exceptions.
- The page evidence that supports the answer.
- The stopping point and allowed actions.
- The conditions that count as failure.
For a hypothetical subscription site, a task could ask an agent to identify which plan supports a stated requirement and navigate to that plan’s signup page. Success requires both the right plan and the right destination. A confident recommendation of an ineligible plan fails even if navigation works perfectly.
Use public, non-sensitive tasks. For conversion-path checks, stop before submitting information, placing an order, or creating another external commitment. Reaching the appropriate destination is a narrower claim than completing a purchase; label the result accordingly.
Establish an independent baseline
Run the task suite before changing pages. Use multiple independent agent models if the intended decision concerns agent access broadly. A result from one model only supports a narrower conclusion.
Keep task wording, starting pages, available capabilities, and action limits consistent. Record the model version and test date. Repeat runs because a single success does not establish reliability.
Use correct completion without human intervention as the primary measure. Report the successful runs and total runs, alongside results for each task. An overall percentage can hide a serious policy failure behind several easy lookup successes.
Separate failures into categories that suggest different fixes: missing information, incorrect interpretation, navigation failure, or an incorrect action. Preserve enough of the observed path to explain the category. A final wrong answer alone may not reveal where the problem started.
Use the audit to explain failures
Compare observed failures with the audit findings. An auditor may point to a shared cause across several pages.
Suppose agents repeatedly miss a product restriction. Inspect whether the restriction is absent, inconsistently stated, or difficult to find in the page representation available to the agent. Those are different problems and may require different changes.
Prioritize findings that connect to a consequential task failure. A sensible starting order is:
- Incorrect product or policy interpretation.
- Inability to reach the correct destination.
- Repeated difficulty retrieving necessary information.
- Audit warnings with no observed task failure.
This order is an operating recommendation, not a validated scoring model. Adjust it to the consequences of failure on your site.
Check the existing SEO, accessibility, content, and performance backlog for overlapping work. A clearer policy page may solve several problems at once. Give the fix one owner and a concrete acceptance criterion.
Test a bounded change
Select comparable pages with similar templates and task complexity. Change one page in each pair while leaving the other unchanged. Where practical, randomly choose which page receives the change. Run the same task suite before and after the change on both groups.
Compare the change in completion on edited pages with the change on comparison pages. If both improve similarly, the result provides weaker evidence that the page edit caused the improvement. Report the underlying counts; a small test can identify promising fixes without establishing a precise effect.
Keep evaluators unaware of which pages changed where practical, and grade against the predefined answer key. If a shared template update affects the comparison pages, they are no longer unchanged controls; choose a different comparison or narrow the conclusion.
Start fresh agent sessions for each run to reduce carryover from earlier answers. Avoid changing several unrelated elements together if you need to understand which fix helped.
Review human usability, page performance, accessibility, search indexability, and factual accuracy alongside agent results. Where traffic supports it, monitor human conversion too. A small test may be unable to detect a conversion effect, so an unchanged rate should not be treated as proof of no harm.
Decide what the result earns
Define the decision rule before seeing the results. Consider the severity of the original failure, whether improvement repeats across runs and agents, the implementation cost, and any regression.
A higher audit score with unchanged task completion gives you little reason to expand the work. Better completion across independent agents, beyond changes observed on comparison pages, supports a website-quality improvement. Improvement on one model warrants a more limited claim and further testing if broader compatibility matters.
Watch for three common traps: rewriting content to satisfy the auditor while introducing ambiguity for people, averaging away consequential failures, and presenting agent-attributed activity as incremental growth.
Even a reliable fix may have little commercial value if few customers encounter the affected task. Evidence of better task completion can justify a targeted quality change. A larger growth investment needs evidence about usage and downstream outcomes.
Evidence and limitations
The source basis is a Vercel Developers announcement describing an agent-readability audit tool. The available evidence contains vendor feature claims, not controlled effectiveness results. The evaluation workflow in this article is an editorial recommendation; it is not attributed to Vercel Developers.
The tool’s scoring methodology, referenced research, coverage, and relationship to business outcomes have not been established here. No experiment results are reported in this article.
Any results from this workflow would apply to the pages, tasks, agent versions, and conditions tested. Improvements in audit scores, correct task completion, attributed activity, and incremental revenue are separate claims; evidence for one does not establish the others.
Source basis
- Vercel Developers announcement describing website audits for AI-agent readability; feature descriptions are vendor claims.
- Editorially proposed evaluation of agent task completion; no controlled results or validated business impact are supplied.