Google Just Added an Agent Readiness Score to Lighthouse. Most Fashion Brands Will Fail It.
Something I've been running on client sites over the past few weeks is Google's new Agentic Browsing audit in Lighthouse. It shipped quietly in mid-May 2026 as part of Lighthouse 13.3 and most ecommerce teams haven't noticed it yet. Those on Chrome 150 or later already have it in their DevTools with no setup required. Those on an older version need to enable a flag first.
What the audit is and what it isn't
Lighthouse has always measured how well your site performs for human visitors. Page speed, accessibility, best practices, SEO. The agentic browsing category adds a different question. How well can an AI agent navigate and interact with your site?
This matters because AI shopping agents don't browse the way humans do. They don't see your creative direction or respond to your photography. They read your site's underlying structure. The audit is Google's first formal attempt to score that readiness in a standardised way.
A few things worth being clear about before you run it. The audit doesn't produce a 0 to 100 score the way performance or accessibility does. It returns a pass/fail ratio across a set of checks, and a set of informational signals. The category is marked as experimental in Google's own documentation, and the standards it's measuring against are still being finalised. So don't treat a failing score as a catastrophe. Treat it as directional.
What the audit checks
The audit runs four areas. Three of them are things you can act on now. One is future infrastructure worth understanding but not rushing.
The accessibility tree
This is the one I'd prioritise first, and it's the one most fashion brands are most likely to have gaps in.
AI agents don't read your webpage the way a human does. They read what's called the accessibility tree. That is the underlying structural representation of your page that screen readers use for visually impaired visitors. Every button, input, form field, and navigation element has a node in that tree. If a node has no label, the agent doesn't know what it does. If a button just says "button" in the tree, the agent can't decide whether to click it. If your navigation relies on visual layout rather than semantic HTML, the agent is effectively navigating blind.
The Lighthouse audit checks whether programmatic labels exist on every interactive element, whether the tree itself is intact and not corrupted by JavaScript rendering, and whether elements the agent needs to interact with are actually visible and reachable in the tree rather than hidden behind dynamic states.
The useful thing about this check is that fixing it for agents also fixes it for screen readers. The accessibility work you've been putting off for compliance reasons turns out to also be the work that makes your site legible to AI shopping agents. Same fix. Two reasons to do it.
For most Shopify stores I audit, the gaps here are concentrated in a few places. Unlabelled icon buttons. Form fields where the label is visually obvious but not programmatically connected. Custom dropdown components that don't expose their state to the tree. None of these are difficult to fix. They're usually quick wins once someone with theme access has a list of what needs addressing.
Cumulative Layout Shift
CLS has been in Lighthouse for years as a Core Web Vital. For agents, it creates a specific failure mode that's worth understanding separately from the general performance argument.
When your page shifts after initial load such as a large image loading and elements shifting unexpectantly, an agent that was about to click a button may click the wrong thing because the element moved. For a human, that's a minor annoyance. For an agent executing a programmatic interaction, it's a broken action. The agent clicks what it calculated to be the add-to-cart button and clicks something else entirely because the layout shifted between calculation and execution.
For drop-model brands where checkout speed matters and agents may eventually be executing purchases autonomously the moment stock goes live, this is a meaningful risk. The fix is the same one Google has been recommending for two years: reserve space for late-loading elements, avoid injecting content above existing content, and stabilise your layout before interaction elements become available.
If you've already done CLS work for Core Web Vitals, you've largely done it for agents too.
llms.txt
The audit checks for the presence of an llms.txt file at the root of your domain. Think of it as a Markdown summary of your site's structure and purpose, written for AI models rather than crawlers. A robots.txt tells crawlers which pages to access. An llms.txt tells AI models what your site is and what it's for.
I'll be honest that I'm still working out how much practical weight this carries for fashion brands specifically. Google's own John Mueller has signalled scepticism about it. The audit flags its absence but doesn't heavily penalise you for it. For now I'd treat it as a low-effort addition that does no harm and may do some good, rather than a strategic priority. Create a simple Markdown file at yourdomain.com/llms.txt describing what your brand does, what products you sell, and what your primary commercial actions are. Takes about twenty minutes. Then move on to the higher-leverage work.
WebMCP
WebMCP is the most significant of the four checks and the furthest from being production-ready for most brands.
The Web Model Context Protocol is a proposed browser standard that lets a website explicitly expose its capabilities to AI agents. Instead of an agent having to guess where your search field is, or try to infer how your add-to-cart button works by reading the accessibility tree, WebMCP lets you declare those interactions natively in a structured format the agent can call directly.
A WebMCP-enabled checkout tells the agent: here is the add-to-cart action, here are the required parameters, here is how to call it. The agent doesn't have to navigate your site visually. It reads the capability declaration and executes it.
For a drop-model brand, the commercial implication is significant. When Universal Cart and autonomous checkout via AP2 are fully operational, the brands with WebMCP-declared checkout flows will be the ones agents can transact with cleanly and reliably. Brands without it are asking agents to navigate a checkout by inference, which introduces failure modes at exactly the moment you can least afford them.
The important qualification: as of right now, very few AI agents actually call WebMCP tools. Native browser support across Chrome and Edge isn't expected until the second half of 2026. The audit flags it, but it's early infrastructure rather than something you need shipped before your next drop.
What I'd recommend is treating WebMCP as a planning horizon item rather than an immediate build. Understand what your highest-value agent interactions would be such as search, add-to-cart, size selection, checkout. Scope what WebMCP declarations for those interactions would look like. Build it into your next significant frontend development cycle rather than bolting it on as an emergency project.
How to run the audit
If you're on Chrome 150 or later, open DevTools on any page, go to the Lighthouse tab, and you'll see Agentic Browsing as a category checkbox alongside Performance, Accessibility, and SEO. Select it and click Analyze page load.
You can also download the beta Google Chrome Canary - only use this for testing as this is in beta - https://www.google.com/intl/en_uk/chrome/canary/ - in the Inspect > Lighthouse section you will see the agentic option - run accessibility as well as the two gp hand in hand.
Run it on your highest-traffic PDP first, then your collection pages, then checkout. These are the pages where agent interaction matters most and where failures have the highest commercial consequence.
The results will return pass/fail status on each of the four checks with specific guidance on what failed and why. The accessibility tree failures are usually the most detailed and the most actionable. Start there.
What to do with the results
I'd sequence this work in roughly three phases based on effort and immediate impact.
The accessibility gaps are the starting point. They're the most likely to be failing, they have the clearest fix path, and the work benefits both agent readability and real human visitors using assistive technology. Pull the audit results, give your developer a specific list of what failed, and work through it methodically. For most Shopify stores this is a theme-level task, not a platform rebuild.
CLS fixes come second if you haven't already done them for Core Web Vitals. Check your Lighthouse performance score first. If CLS is already in good shape, this is already done. If not, it usually comes down to a small number of specific page elements. Header banners, late-loading product images, dynamically injected content. Fix them at the source.
Ship the llms.txt file when you have thirty minutes. It's low effort and removes one audit flag. Keep it simple: what your brand is, what you sell, what your primary commercial actions are. Don't overthink it.
WebMCP goes on the roadmap. Have the conversation with your development team about what your key agent interactions would be and what it would take to declare them. Don't build it this week. Understand the scope so you're not starting from zero when native browser support lands later this year.
Why this matters for drop-model brands specifically
The agentic browsing audit is Google making something visible that has been invisible. The question of whether AI agents can reliably navigate your checkout has been unanswerable until now. There's been no standardised way to check it and no formal signal that it mattered commercially.
That's changed. The audit exists. The category is in the default Lighthouse configuration on Chrome 150. Google has a dedicated crawler identity for when its AI agents are visiting sites. There's an AI Assistant channel in GA4 for attributing agent traffic. Universal Cart is rolling out this summer.
The infrastructure is assembling around a specific question: when an agent evaluates whether to recommend your brand and complete a transaction on a customer's behalf, can it actually do it? Not whether it can find you. Whether it can transact with you.
The audit tells you the answer for your site right now. Most fashion brands haven't checked. Most will find gaps they didn't know existed. The accessibility work in particular tends to sit in the same gap as structured data work somewhere between technical SEO and ecommerce management.
Run the audit. Read the results. Fix what's failing in the accessibility tree first.
Everything else follows from there.