Agentic Readiness Audit

Why this audit exists

A modern website is no longer only visited by humans and crawled by search engines. It is also interpreted by AI agents that can analyze a page, choose an action, click, fill a form, compare options or prepare a recommendation.

That changes the problem. A site can be well ranked, visually polished and still fragile for an agent. The main button may be implemented as a fake interactive element. A form may be visible but poorly exposed in the accessibility tree. A component may shift after hydration. An action may be obvious to a human but ambiguous in the DOM.

The agentic readiness audit measures this gap: what the interface appears to enable, what the HTML actually exposes, what the accessibility tree makes understandable, and what an agent can execute reliably.

This work follows a public shift in the web platform. Google now describes agents as a new type of visitor capable of interpreting, planning and executing actions. Its documentation recommends semantic, accessible, stable websites with consistent signals across visual rendering, the DOM and the accessibility tree: Build agent-friendly websites.

The Agentic Readiness Score

For organizations that want an initial reading before an engagement, Pagup also exposes an Agentic Readiness Score. It does not replace the audit, but it makes the reference model public: DOM stability, visual / accessibility coherence, actionable semantics, hydration risk and journey determinism.

What Lighthouse measures and what the Pagup audit adds

The arrival of Agentic Browsing in Lighthouse changes the market vocabulary. It gives teams a first set of observable signals: accessibility, stability, programmatic names, llms.txt, WebMCP and quality of selected interactive elements.

But Lighthouse does not replace the Pagup audit. It checks point signals. The agentic readiness audit verifies complete journeys: understanding the offer, following the right path, choosing a CTA, filling a form, interpreting a confirmation and returning to the right context.

The audit therefore separates three levels:

• technical signal: what Lighthouse or a similar tool can detect;
• journey risk: what may prevent an agent from completing a real task;
• representation risk: what may cause an agent to misqualify the organization, its offer or its proof.

Related reading: Lighthouse Agentic Browsing audit: what your site passes, misses and does not measure and Lighthouse Agentic Browsing vs Pagup Score matrix.

What the audit measures

The audit does not try to guess whether a site will “please” an AI system. It verifies observable technical properties.

1. DOM and visual stability

We compare the initial page state, the hydrated state and the post-interaction state. The goal is to identify changes that may move, hide or redefine a critical action.

A button that shifts between identification and click is not just a UX problem. It is an execution risk. Chrome also documents visual stability as important for agents relying on screenshots or coordinate-based interaction: Layout stability.

2. Screenshot, DOM and accessibility-tree coherence

A modern agent does not only read text. It combines several signals: visual rendering, HTML structure, DOM, accessible names, roles, states and relationships.

We verify whether those channels tell the same story. Something that looks like a button should be a button. A visible input should have an accessible name. A CTA inside a product card should be unambiguously associated with the right product.

3. Actionable semantics

We inspect the quality of action elements: <button> for actions, <a> for navigation, <label> connected to fields, name attributes, explicit CTA text, and states such as aria-expanded or aria-current when needed.

An agent must understand not only that something can be activated, but what that activation triggers.

4. Hydration risk

Over-hydrated interfaces can create divergence between what the server delivers, what the browser renders and what JavaScript changes afterwards. The audit identifies critical content injected too late, actions absent from the initial HTML, unstable menus, forms dependent on fragile client state and errors that reduce interface predictability.

This is especially important in a machine-first website architecture, where critical content and actions should be available before JavaScript enhancements.

5. Accessibility-map quality

Accessibility first serves humans using assistive technologies. But it also forces the interface to be named, structured and intentional.

We audit unnamed buttons, unlabelled fields, poorly connected modals, form errors not associated with fields, ambiguous menus and interactive elements hidden from the accessibility tree.

6. Interaction determinism

An agent must be able to complete a task without losing context. We examine step clarity, confirmations, errors, redirects, disabled states, irreversible actions and the relationship between goal, interface and result.

A strong agentic journey is not just clickable. It is predictable.

7. Visual hierarchy and affordances

Size, proximity, contrast, visual order and button consistency influence agent behaviour. We verify whether primary, secondary and dangerous actions are clearly distinguished, and whether clickable elements look and behave like clickable elements.

8. Machine discoverability and WebMCP readiness

The audit also checks machine entry points: sitemap, robots, structured data, llms.txt, internal linking, resource hierarchy and potential WebMCP readiness.

WebMCP remains experimental, but Chrome presents it as a way to expose structured tools to agents so they can act with more speed, reliability and precision: WebMCP early preview.

Typical deliverables

Depending on scope, the audit may include:

• a map of critical agentic journeys;
• a comparison between initial HTML, hydrated DOM, visual rendering and accessibility tree;
• a risk matrix by template;
• a prioritized list of non-actionable or ambiguous elements;
• HTML, ARIA, CSS and frontend recommendations;
• a hydration-risk assessment;
• a remediation plan by priority;
• test recommendations to prevent regressions.

When this audit becomes a priority

This audit becomes relevant when:

• your site includes forms, funnels, filters, booking flows, carts, configurators or complex interfaces;
• you are preparing a redesign and want to avoid rebuilding an agent-fragile interface;
• your site depends heavily on client-side JavaScript;
• your critical journeys change depending on loading, viewport or user state;
• you want to know whether the site is actually ready for the agentic web, beyond a simple llms.txt file.

What this service is not

This is not a ranking promise. It does not predict how every market agent will behave.

It also does not replace a full digital readability diagnostic. It addresses a specific layer: the operational capacity of the site to be understood, navigated and operated by agents.

Next step

If the problem seems broad, the right entry point remains the strategic digital readability diagnostic. If the risk is already localized in the interface, forms, components or frontend architecture, you can open a brief focused on agentic readiness.