Google Lighthouse Adds an “AI Agent Resource Discovery” Audit: What It Really Means (and What SMEs Should Do Next)

AI agents don’t “browse” the web the same way humans do—and that difference is now starting to show up in mainstream tooling. Google’s Lighthouse 13.5 added an experimental audit for Agentic Resource Discovery (ARD), a proposed way for AI agents to locate the tools, services, and structured capabilities an organization offers. That’s a meaningful milestone: the agentic web is becoming something you can test, validate, and operationalize.

But here’s the catch: Lighthouse’s ARD audit behavior (based on what Search Engine Journal reviewed in the 13.5 code) doesn’t fully reflect the newest version of the ARD proposal. That creates a new class of “false negatives,” where you can implement the latest draft and still see Not Applicable or failure—simply because the audit doesn’t look where the spec now says it should.

This editorial breaks down what changed, why it matters, what can go wrong (especially for SMEs), and how to build a practical, low-risk plan. I’ll also show where AYSA’s AI search visibility system fits: Monitoring, preparing changes, requesting approval, and executing only what you accept—because “agent readiness” is going to be another execution-heavy layer on top of already-complicated Technical SEO.

Concise summary

• Lighthouse 13.5 adds an experimental audit that tries to discover and validate an ARD catalog (agent resource manifest). This is separate from traditional SEO scoring.
• The audit checks specific discovery paths (Robots.txt directive, link tags, HTTP Link header, and a fallback file), and can mark sites Not Applicable if it can’t find a catalog where it expects.
• The ARD proposal has evolved, including a rename of the well-known manifest file location, and Lighthouse may not yet reflect that. That means your implementation can be correct per spec but still not be recognized by Lighthouse.
• For most SMEs, the immediate opportunity isn’t “rank in AI by shipping ARD.” It’s building the operational capability to publish structured, accurate, safe machine-readable resources—without breaking your site or creating security risks.

Key takeaways (what to remember)

• Don’t treat Lighthouse ARD results as Google Search ranking signals. The feature is in an experimental category and not tied to search in the release context described by SEJ.
• Expect mismatches between a moving spec and a shipping audit. Use Lighthouse as one input, not the source of truth.
• Implement defensively. If you decide to publish ARD, consider supporting both current and legacy discovery paths until the ecosystem converges.
• Execution is the hard part. The businesses that win aren’t the ones with the fanciest manifest—they’re the ones who can keep it correct, monitored, secure, and updated.

Table of contents

1. What changed in Lighthouse 13.5 (and what didn’t)
2. The bigger context: from “SEO for pages” to “discoverability for capabilities”
3. ARD in plain English: a “menu” for AI agents
4. Where Lighthouse looks today (and why that can mislead you)
5. The spec moved; the audit may not have
6. ARD vs llms.txt vs WebMCP: don’t mix these up
7. Why this matters for SMEs (even if you never ship ARD)
8. What can go wrong: false negatives, bad manifests, and security debt
9. An SME scenario: the ecommerce brand that “fails” ARD but did the right thing
10. A practical action plan (technical + operational)
11. Where AYSA fits: monitor, prepare, approve, execute
12. What to do next (checklist)
13. Sources and further reading

What changed in Lighthouse 13.5 (and what didn’t)

According to reporting from Search Engine Journal, Lighthouse 13.5 introduces an audit aimed at Agentic Resource Discovery (ARD)—a proposed specification for how AI agents locate an organization’s tools and services. The audit attempts to:

• Find an ARD catalog (manifest) by checking several locations/pointers.
• Validate it against a schema defined by the ARD project.
• Report a pass/fail if found, or “Not Applicable” if Lighthouse can’t find any catalog via its current discovery paths.

SEJ also notes two operational details worth caring about:

• The audit is expected to show up in Chrome DevTools and in PageSpeed Insights (timing may vary by rollout).
• The audit lives under an experimental category (“Agentic Browsing”) and doesn’t produce a classic 0–100 score. It’s tracked as pass ratio, reflecting how early the “agentic web” standards still are.

What didn’t change: this is not presented as a Google Search requirement, and there’s no claim (in the SEJ summary) that ARD directly impacts rankings. Treat it like what it is: an early audit for a developing ecosystem.

The bigger context: from “SEO for pages” to “discoverability for capabilities”

Traditional SEO assumes a core unit of value: a page (or a document). You publish pages, search engines crawl them, indexes store them, and ranking systems decide which pages deserve visibility.

Agentic systems introduce a parallel unit of value: a capability.

Instead of asking, “Which page answers this question?” an agent might ask:

• “Which hotel can I book for next weekend within my budget?”
• “Which clinic can accept my insurance and has openings?”
• “Which ecommerce store can ship this item in two days and has free returns?”

Those questions don’t only require content. They require structured access to things that are often not “pages” at all:

• Inventory, pricing, availability
• Booking and checkout flows
• Policies and eligibility rules
• Support workflows

This is why “agent discoverability” is emerging as a technical discipline. In that framing, ARD is less like a new SEO trick and more like a new kind of public product documentation—except it’s written for machines that might take action.

ARD in plain English: a “menu” for AI agents

If you run a business website, you already publish “menus”:

• Navigation menus (for humans)
• Sitemaps (for crawlers)
• Product feeds (for shopping engines)
• API docs (for developers)

ARD is attempting to be a menu for agents: a structured way to list what’s available—tools, endpoints, actions, or services—so an AI system can decide: “This organization can do X. Here’s how to call it. Here are constraints. Here’s the schema.”

That matters because agent workflows increasingly look like this:

1. Discover a capability (the agent learns a tool exists).
2. Evaluate whether it’s relevant and trustworthy (eligibility, constraints, auth).
3. Call the capability (make an API call, submit a form, trigger an action).
4. Verify outcomes (confirmation pages, receipts, state changes).

ARD is squarely in step 1: discovery.

Where Lighthouse looks today (and why that can mislead you)

SEJ’s write-up of the Lighthouse 13.5 code path is the most useful “practical” detail in the entire update because it tells you what the audit actually checks right now. According to SEJ, Lighthouse attempts to locate an ARD catalog by:

• Checking robots.txt for an Agentmap line (a directive in the ARD spec pointing to a catalog).
• Looking for a <link> tag using a relation of ai-catalog.
• Checking the HTTP Link header for the same relation.
• If none exist, falling back to /.well-known/ai-catalog.json.

If Lighthouse can’t find a pointer and doesn’t find the well-known file, SEJ reports it marks the audit as Not Applicable. If it finds a catalog but it fails schema conformance or can’t be loaded, it fails.

Here’s the business implication: the audit can only confirm what it knows how to look for. If the specification changes faster than the audit’s discovery logic, you can end up with a report that looks like “nothing is implemented” even when you’ve implemented the newest draft.

The spec moved; the audit may not have

SEJ reports that the latest ARD spec (as of late August) renamed the well-known manifest path to /.well-known/ard.json and positions the older filename (ai-catalog.json) as optional/legacy. SEJ also notes the Lighthouse code (as of the 13.5 view they reviewed) didn’t appear to check for ard.json or a rel="ard" relation, and it also didn’t check other discovery mechanisms mentioned by the spec (like in-page JSON-LD or DNS-based discovery).

This is exactly how early standards feel in practice:

• A proposal evolves (file names, discovery relations, optional paths).
• Tools implement a snapshot of the proposal.
• Real sites implement a different snapshot.
• Audits start to disagree—not because you’re wrong, but because everyone is at a different version.

Editorial point of view: if you’re an SME, your job is not to “win” the spec race. Your job is to avoid getting trapped by it. Implement in a way that’s resilient to drift, and treat audits as diagnostics—not authority.

ARD vs llms.txt vs WebMCP: don’t mix these up

One reason people get overwhelmed by “agent readiness” is they assume every new file/spec does the same thing. It doesn’t.

SEJ’s source text usefully distinguishes three concepts:

• ARD: for discovering resources (tools, agents, skills, services). It’s about “what can I call?”
• llms.txt: a summary-oriented file intended to help AI systems understand the site’s content (more like “what’s on this site?”)
• WebMCP (as SEJ references separately): a page-level way to expose structured actions an agent can call once it’s already on the site.

The practical takeaway: ARD is not a replacement for content strategy, technical SEO, Schema markup, or conversion optimization. It’s an additional layer—primarily relevant if your business has callable capabilities that can be represented safely and consistently.

Why this matters for SMEs (even if you never ship ARD)

If you’re running a clinic, a local services company, an ecommerce store, or a SaaS business, you may be thinking: “This feels enterprise-y. Why should I care?”

You should care for three reasons.

1) The measurement layer is expanding

When a concept appears in Lighthouse, it tends to become operationally “real” for teams: it lands in DevTools workflows, it ends up in PageSpeed Insights reports, and it becomes something stakeholders ask about.

Even if ARD never becomes a direct ranking factor, it can become a procurement factor (partners asking “do you support agent discovery?”) or a trust factor (platforms preferring structured, validated capabilities).

2) Your competitors will operationalize agent discoverability

The competitive gap won’t be “who has a manifest.” It will be:

• Who keeps their machine-readable data accurate?
• Who can deploy safely without breaking conversions?
• Who can monitor changes and regressions weekly?

That’s an execution contest—exactly where most small teams struggle.

3) “Agent surfaces” will create new paths to revenue

As agents route users to actions (book, buy, compare, request quote), businesses that are easier to understand and safer to transact with will get more of that flow. Whether those referrals look like classic SEO Clicks or something else, the underlying requirement is the same: be machine-legible and trustworthy.

If you’re thinking about Attribution and visibility, start with AI search visibility rather than chasing any single new file format.

What can go wrong: false negatives, bad manifests, and security debt

New audits create new failure modes. Here are the ones I expect SMEs and agencies to run into first.

1) “Not Applicable” doesn’t mean “you’re not ready”

Per SEJ’s analysis, Lighthouse marks ARD as Not Applicable when it can’t find a catalog via its current discovery logic. If you implemented the latest ARD manifest path and Lighthouse hasn’t caught up, you could be fine—but the audit won’t confirm it.

How to handle it: treat Not Applicable as “not detected by this tool,” not “missing in reality.” Validate using your own fetch tests and (if you implement both new and legacy discovery paths) verify both work.

2) Schema conformance failures can become busywork

A schema conformance audit is binary: you either match the schema or you fail. That’s useful, but it can become operational debt fast if:

• the schema changes upstream weekly,
• your site deploy cadence is monthly,
• multiple teams own different capabilities, and
• no one owns the manifest.

SEJ notes Lighthouse added an automated check for upstream schema/test changes. That’s a signal you should do something similar internally: monitor spec drift, not just your site’s performance.

3) Security and abuse risk increases when you advertise “callable” tools

Any time you publish a machine-readable catalog of endpoints and capabilities, you make discovery easier—not only for helpful agents, but also for abuse. This isn’t a reason to avoid ARD forever, but it’s a reason to raise your baseline maturity:

• Rate limiting
• Authentication where appropriate
• Clear separation between “public info” and “state-changing actions”
• Logging, anomaly detection, and rollback plans

If your organization isn’t comfortable with these basics, shipping an agent-facing manifest may create more risk than upside.

4) Brand risk: agents may over-assume what you can do

ARD is about discovery, but discovery can be misinterpreted. If an agent sees something in your catalog and assumes it can complete a workflow—then fails—you get the blame (even if the integration is experimental).

The mitigation is boring, but effective: keep your published capabilities narrow, accurate, and aligned with what your site can consistently support.

An SME scenario: the ecommerce brand that “fails” ARD but did the right thing

Imagine a 15-person ecommerce brand selling home fitness equipment. They have:

• Product pages and collections (classic SEO)
• A returns policy and warranty info (content + trust)
• Inventory and shipping estimates (operational truth)

The founder asks their agency: “We keep hearing about AI agents. Let’s be discoverable.”

The agency implements an ARD manifest based on the newest draft they can find. They publish it to the newest well-known path. They validate it internally. Everything is correct.

Two weeks later, a developer runs Lighthouse and sees: ARD audit: Not Applicable.

Now the business thinks the agency did nothing, the agency thinks Lighthouse is broken, and everyone wastes a week in meetings. This is how technical initiatives die: not from complexity, but from mistrust created by conflicting tools.

The solution isn’t to argue about who’s right. The solution is an operational pattern:

• Define a “compatibility window” (support both new and legacy discovery paths when practical).
• Validate with more than one method (fetch tests, schema tests, and the Lighthouse audit if applicable).
• Document the expected results (“Lighthouse may show Not Applicable until it updates”).
• Monitor continuously so you catch regressions early.

This is exactly the kind of operational work AYSA is designed to systematize: monitor, prepare, approve, execute—without turning every change into a fire drill.

A practical action plan (technical + operational)

Most businesses don’t need a heroic “agent transformation.” They need a staged plan that builds capability without betting the company on an unstable spec.

Step 1: Decide whether ARD is even relevant for you (right now)

ARD is most relevant if you have at least one of these:

• Public tools or APIs (even if lightly documented)
• Structured actions users routinely complete (booking, quoting, returns initiation)
• Partner integrations where discovery matters (affiliates, platforms, marketplaces)

If your website is mostly informational and you don’t have stable, callable services, your best ROI is still:

• technical SEO hygiene
• clear product/service pages
• strong Internal linking and IA
• schema where it helps

Those fundamentals remain the foundation of AI visibility because agents still need trustworthy source material.

Step 2: Inventory your “capabilities” and pick one safe starting point

Before you publish anything machine-readable, list what you could credibly expose. For SMEs, safe starters are usually read-only or low-risk:

• Store locations and hours
• Service catalog and pricing ranges
• Booking availability (if stable and protected)
• Shipping/returns rules (policy truth, not marketing)

Avoid advertising endpoints that change user state (payments, account actions) until you have strong authentication and monitoring.

Step 3: Implement for compatibility, not ideology

Because Lighthouse and the ARD proposal may differ, a pragmatic implementation approach is to support multiple discovery paths when feasible and not harmful. SEJ’s report suggests Lighthouse looks for:

• robots.txt Agentmap directive
• link rel="ai-catalog" in HTML
• HTTP Link header with that relation
• /.well-known/ai-catalog.json fallback

Meanwhile, the spec reportedly moved to /.well-known/ard.json. The practical stance is: until the ecosystem converges, consider publishing both (or at least ensure redirects and pointers are consistent), and document what you did.

Note: This editorial is not legal or security advice. If you’re exposing sensitive capabilities, get a security review.

Step 4: Validate beyond Lighthouse

Lighthouse is helpful, but it’s not the spec. Build a minimal validation routine:

• Fetch the manifest from every intended location (including from outside your network to catch CDN/auth issues).
• Validate JSON format and schema conformance (using the project’s conformance tests if available to you—SEJ notes Lighthouse used the ARD project’s tests as reference).
• Confirm correct HTTP headers (content-type, caching behavior).

If Lighthouse doesn’t detect it, log that as a tooling mismatch and move on—don’t rip out correct implementations just to appease a lagging audit.

Step 5: Add monitoring and change control (this is where most teams lose)

Agent discoverability isn’t a “set it and forget it” file. It’s a contract with machines. Contracts require governance:

• Monitoring: alerts when files go missing, return 404/500, or change unexpectedly
• Approvals: changes reviewed by marketing + dev + security where needed
• Rollbacks: ability to revert if something causes errors or abuse

This is exactly why we built AYSA Monitoring as a core layer: you can’t manage visibility in AI surfaces without managing reliability of the underlying assets.

Step 6: Keep the focus on outcomes: visibility + conversions

Even if ARD becomes common, it won’t matter if:

• your pages don’t explain the offer clearly,
• your policies are confusing,
• your site is slow or fragile,
• your conversion paths break on mobile.

The “agentic web” will reward businesses that are both discoverable and usable. Don’t let a new manifest distract you from the basics.

Where AYSA fits: monitor, prepare, approve, execute

At AYSA.ai, we treat AI search (and agent discovery) as an execution problem, not a speculation problem.

Here’s the operating model that works for SMEs and lean teams:

• Monitor what matters: key technical assets, indexability, and AI visibility signals. Start here: AYSA Monitoring
• Prepare changes safely: generate implementation tasks and drafts (for technical files, structured data, content updates) without immediately pushing them live.
• Ask for approval: you (the business) decide what ships. This is the “Approved Execution” model—no surprises, no silent deploys.
• Execute accepted changes: once approved, AYSA helps apply changes consistently and track impact over time.

For ARD specifically, AYSA’s role isn’t to chase an unstable spec for you. It’s to make sure if you decide to implement it, you can do it with:

• clear ownership
• repeatable validation
• monitoring and alerts
• measurable impact tied to business KPIs

If you’re exploring tooling, see AYSA’s AI SEO tools, and if you want to operationalize this across a team, review pricing and the ongoing playbooks in our blog.

What to do next (checklist)

If you’re a founder, marketer, or agency lead, here’s a practical next-step list that doesn’t assume you’ll ship ARD tomorrow.

For SMEs

1. Separate hype from tooling: treat Lighthouse’s ARD audit as experimental diagnostics, not a ranking mandate.
2. Inventory capabilities: list what you can safely expose to machines (read-only first).
3. Clean up fundamentals: make sure your top pages, policies, and conversion paths are clear and fast—agents will rely on them too.
4. Choose a governance owner: someone must own machine-readable assets (sitemaps, feeds, structured files, and now possibly ARD/llms.txt).
5. Set up monitoring: at minimum, alert on 404s/500s and unexpected changes to well-known files.
6. Adopt approved execution: don’t let experimental changes ship without review. Use a system that prepares and requests approval before executing.

For agencies

1. Write a “version drift” clause into your delivery: explain that specs and audits may not match yet, and define what “done” means.
2. Ship compatibility implementations: where reasonable, support both current and legacy discovery paths to avoid tool mismatches (document everything).
3. Productize monitoring: don’t sell ARD as a one-time task. Sell it as a maintained asset with alerts and reviews.
4. Don’t conflate discoverability with performance: ensure you still measure leads, sales, and revenue—not just “audit passes.”

Sources and further reading

• Search Engine Journal: Google Lighthouse Adds Audit For AI Agent Resource Discovery (primary reporting used for this editorial)
• SEJ: AI Search coverage (context and ongoing reporting)
• SEJ: Technical SEO coverage (implementation and diagnostics context)
• SEJ: SEO coverage (broader SEO context)
• SEJ: SEO News (for follow-up updates as the ecosystem evolves)

Note on primary specifications: SEJ references ARD proposal details (including file naming changes and discovery mechanisms). This editorial does not link directly to the ARD spec repository because it was not included in the provided research context. If you’re implementing ARD, consult the latest primary spec directly and validate against its conformance tests.

Related AI SEO resources

Continue the AI search topic inside AYSA.

Use these pages to connect the article with AI SEO tools, AI visibility monitoring, AI Overviews and approved website execution.

AI SEO tools The commercial hub for AI SEO, AI search optimization and approved execution. AI search monitoring Track AI visibility, answer-engine mentions and the next actions worth approving. AI Overviews SEO Prepare clearer, more structured pages without promising guaranteed inclusion. SEO, AEO and GEO visibility A plain-English explanation of the search visibility layer AYSA prepares for.

Execution hubs

Turn this topic into a website action plan.

Use these AYSA hubs to move from reading to technical fixes, AI visibility monitoring, research, glossary context and approval-first SEO execution.

Technical SEO Open the related AYSA hub for deeper context and next-step workflow. AI search visibility Open the related AYSA hub for deeper context and next-step workflow. Monitoring Open the related AYSA hub for deeper context and next-step workflow. SEO research Open the related AYSA hub for deeper context and next-step workflow. Business owners Open the related AYSA hub for deeper context and next-step workflow. SEO glossary Open the related AYSA hub for deeper context and next-step workflow.

Written by

Marius Dosinescu

Marius Dosinescu is the founder of AYSA.ai, an entrepreneur focused on SEO automation, ecommerce growth, authority building and approved website execution for businesses that want organic growth without specialist overhead.

Author profile Dosinescu.ro

Share inShare on LinkedIn cpCopy article link fShare on Facebook @Share by email