Lighthouse AI Agent Discovery: A Practical Guide

Lighthouse AI agent discovery checks help developers inspect whether a website exposes usable discovery resources. The new ARD audit in Lighthouse 13.5 validates a discovered catalog; it does not measure brand mentions, search rankings, or citations. Use its findings to improve technical reliability, then measure actual AI visibility separately.

What changed in Lighthouse 13.5?

Lighthouse 13.5.0, released on September 18, 2026, adds an Agent Resource Discovery schema audit and groups it with the existing llms.txt audit under agent discoverability. The release notes describe an expected rollout to Chrome DevTools and PageSpeed Insights, not proof that every installation already includes it. Check the version in your own report. Official Lighthouse 13.5 release.

This is a useful development for teams building machine-accessible websites, but it creates a reporting trap. A technical validation result can look like a verdict on whether an AI assistant will recommend a business. Those are different questions.

This guide focuses on interpreting and investigating the new check. It complements our three-layer AI visibility measurement guide, rather than replacing content audits, live answer observations, or conversion tracking.

What does the ARD audit actually validate?

Agentic Resource Discovery is a proposal for describing and discovering resources such as tools and agents. It is not simply another name for indexing ordinary blog posts. The specification is still evolving, so implementations and documentation must be compared by version. ARD specification.

In Lighthouse 13.5, the ard-schema audit examines a discovered ai-catalog.json resource using its bundled conformance validator. If there is no explicit discovery signal and no successfully retrieved catalog, the audit returns not applicable. An explicitly advertised catalog that cannot be loaded is a failure. Loaded content is checked for validation errors and warnings. Versioned audit implementation.

The discovery code looks for an Agentmap entry in robots.txt, an HTML link, an HTTP link header, or the fallback path /.well-known/ai-catalog.json. Its HTML and header checks use the ai-catalog link relation. These are the behaviors of this particular release, not a timeless deployment recipe. Versioned discovery implementation.

Before adding any manifest, identify a real resource that should be discoverable and the client expected to consume it. A marketing site with no agent integration should not invent endpoints, publish private URLs, or expose administrative functions merely to change an audit result.

How should you interpret pass, fail, and not applicable?

Treat the result as evidence about the tested configuration, not about every AI system. The following triage table is our recommended operational workflow, not a Google ranking formula.

Finding	What to investigate	What not to conclude
Catalog passes validation	Whether its descriptions and destinations remain accurate	The brand will be cited
Catalog is advertised but cannot load	URL, response, redirects, deployment and access rules	The content itself is low quality
Catalog has validation issues	The specific errors and the validator version	Every client rejects the resource
Audit is not applicable	Whether a catalog is intended and how this version discovers it	The site is invisible to AI
Result differs between tools	Versions, browser, configuration and captured response	One tool proves the other dishonest

Avoid silently removing not-applicable checks from a spreadsheet while keeping yesterday's denominator. Report the number tested, passed, failed, and not applicable separately. That makes a change in coverage visible before someone interprets it as improvement.

For example, imagine an integration team publishes a catalog URL that redirects to a login screen. Fixing the response may resolve a technical issue. It still provides no evidence that a buyer saw a recommendation. This is an illustrative debugging scenario, not a GEOCARA customer result.

Is agentic browsing a new Google SEO score?

No. Chrome describes the Agentic Browsing category as experimental and based on proposed standards. Its reporting uses a pass ratio rather than the familiar weighted 0-100 category score. It evaluates deterministic signals related to machine interaction. Chrome's scoring documentation.

Do not rename that ratio "Google AI visibility" in a client dashboard. Keep it next to the test version and URL, not next to revenue as though the two were directly comparable.

Google Search separately states that pages need ordinary Search eligibility to appear as supporting links in AI Overviews or AI Mode, and that no special AI file or schema is required for those features. Meeting eligibility requirements does not guarantee inclusion. Google Search Central guidance.

The practical implication is prioritization: an accidentally blocked product page, an incorrect canonical, or an unreadable explanation deserves investigation independently of an optional discovery manifest. A new diagnostic should widen your evidence, not erase existing SEO responsibilities.

Where does llms.txt fit?

llms.txt is a separate, emerging convention for presenting a concise machine-readable overview of a website. Chrome's documentation currently describes a missing file returning 404 as not applicable, while a server error retrieving it is flagged. Official llms.txt audit documentation.

When you maintain one, give it an owner. Review whether each linked page is public, current, canonical, and useful. Remove retired offers and links to staging environments. Never include credentials, private customer material, signed account links, or instructions that bypass access controls.

A practical maintenance rule is to update the file alongside navigation and documentation changes, then check the deployed response. Do not spend a week polishing an AI summary while the linked pricing page contains contradictory terms.

Keep the scopes distinct: robots.txt expresses crawl instructions, a sitemap lists URLs for discovery, and a curated summary describes content. None substitutes for testing the actual page response. Our GEO content audit checklist covers that wider page-level review.

How can you run a useful investigation?

Start with one representative public URL and one clear question: is a resource we intentionally advertise discoverable and usable in the tested configuration? The workflow below is an engineering recommendation, not a claim that every site needs ARD.

1. Record the environment. Save the Lighthouse version, browser version, URL, date, and selected categories. Note authentication, consent state, and redirects.
2. Preserve the report. Keep the full diagnostic output privately so another developer can inspect the exact finding instead of a cropped badge.
3. Inspect the advertised destination. Confirm which discovery signal selected it. Request the URL and inspect the status, content type, final URL, and body.
4. Check public versus private boundaries. A public description may point to an authenticated service, but it must not contain the credentials needed to use it.
5. Compare matching versions. Read the released validator and the intended specification revision. Do not assume a current example is compatible with an older installed tool.
6. Fix the smallest demonstrated problem. Correct a broken destination or malformed document before redesigning the entire site.
7. Retest the same conditions. Store before-and-after findings, including any unchanged failures or not-applicable checks.

Also test the negative case. If the intended resource disappears, does monitoring catch that failure? A single successful deployment check is less useful if nobody notices a later redirect, authentication change, or expired endpoint.

Do not treat a request with a crawler-like user-agent as proof that an official crawler can access the site. It can reveal a response difference, but network identity, firewall rules, and actual request logs require separate evidence.

How do you turn the findings into business priorities?

Separate three work queues: public page reliability, intentional agent integrations, and observed marketing outcomes. Assign each issue to the team that controls it instead of giving the content team every red audit row.

A useful issue record includes the affected URL, expected behavior, observed response, responsible owner, reproduction steps, and acceptance check. Add a customer-impact hypothesis, but label it as a hypothesis until measured.

For a content-led business, a broken comparison page may matter more than an absent optional catalog. For a software provider distributing an agent integration, a bad resource description could be directly relevant to the integration's usability. The same technical finding can therefore receive different priorities without changing the facts.

Use the free AI visibility checker for a separate website-readiness baseline, and consult the GEOCARA scoring methodology before interpreting that number. Do not present a GEOCARA readiness score as a Lighthouse result or claim that the checker currently runs this specific ARD audit.

What should you measure after the fix?

Choose the outcome before shipping the change. For a catalog repair, the immediate outcome might be successful retrieval and validation under the same test configuration. For a documentation rewrite, it might be whether a controlled task yields the correct answer from the intended integration.

If the commercial goal is AI search visibility, maintain a separate fixed set of relevant questions and document actual mentions and cited URLs. Keep engine, language, market, and collection method consistent. An API observation and a consumer-product session should not be mixed without labels.

For business impact, use properly collected website referrals and completed actions such as verified registrations or qualified demo requests. Exclude your own QA activity where identifiable. Missing analytics access means the outcome is unknown, not zero.

Avoid causal claims from one before-and-after screenshot. A model update, different prompt, or concurrent content change can explain a different answer. Report the technical fix as completed when its acceptance test passes; report commercial improvement only when the separate evidence supports it.

Frequently asked questions

Should every website publish an ARD catalog?

No. First establish whether your site offers a resource that a relevant agent or registry should discover. An ordinary content site should not fabricate an integration solely to obtain a passing check.

Why might two Lighthouse reports disagree?

Compare tool and browser versions, selected categories, authentication, and the response captured during each run. A useful comparison requires equivalent conditions, not just the same domain name.

Should we remove a catalog when it fails validation?

Investigate the failure first. Removing an intentionally supported discovery resource could break existing consumers. Fix the demonstrated issue and confirm compatibility with the clients you actually support.

Can a valid catalog expose a security problem?

Schema validity is not a security review. Inspect published fields for private URLs or secrets and enforce authorization at the service itself. A discovery document must not become an access-control workaround.

How should agencies describe this work to clients?

Describe a versioned technical compatibility check with documented findings and fixes. Keep recommendations, citations, referrals, and conversions in separate evidence categories rather than promising a ranking increase.

Your next action

Review one important page, capture the installed audit version, and investigate only the resources your team intentionally exposes. Record a reproducible fix and verify it after deployment. Then use the GEO hub to connect technical readiness with content quality and independently measured visibility. Passing a technical check is progress; proving customer discovery requires another measurement.