PageSpeed Insights Agentic Browsing: What 3/3 Means

If you work in technology or digital marketing, you will probably recognise the image above before reading its caption. It is a PageSpeed Insights report. Performance, Accessibility, Best Practices, and SEO are familiar. The fifth green result, Agentic Browsing 3/3, may not be.

I encountered it while testing a newly published article for Upwork Goldmine, one of my side projects. Even for someone accustomed to PageSpeed reports, the extra category was new. That should not be surprising. The web tooling around generative AI and browser agents is moving quickly.

Here is the direct answer: Agentic Browsing is an experimental Lighthouse diagnostic for how well software agents can understand and interact with a web page. It is not a Core Web Vital, a Google Search ranking factor, or a requirement for AI Overviews.

That boundary matters everywhere. It matters more in financial services, where a technically accessible page may contain rate disclosures, eligibility information, repayment options, or actions that can affect a customer's money.

What changed in PageSpeed Insights

PageSpeed Insights uses Lighthouse for its lab analysis. Lighthouse 13.3 added the Agentic Browsing category to its default configuration in May 2026, and PageSpeed Insights subsequently began surfacing it.

Chrome describes the category as a set of deterministic checks for machine interaction. The current design looks at several layers:

• agent-centric accessibility, including programmatic names and accessibility-tree integrity;
• visual stability, including Cumulative Layout Shift;
• discoverability through a root-level llms.txt;
• WebMCP tool registration, form coverage, and schema validity where the experimental capability is available.

Unlike the familiar 0–100 Lighthouse categories, Agentic Browsing uses a pass ratio. The fraction reports how many applicable readiness checks passed in that run.

The standards are still moving. Chrome explicitly says the category is experimental. WebMCP is a W3C Community Group report, not a W3C Standard or a document on the W3C Standards Track. A prudent team should treat the result as an early engineering diagnostic, not as a durable certification scheme.

What a live 2/3 to 3/3 result taught me

The first run on the Upwork Goldmine article showed 2/3. The page already scored 97 for mobile Performance and 100 for SEO, so the missing point was not evidence of a generally poor page.

The failed check came from /llms.txt. The file already had a heading, a summary, and URLs, but its resources were plain text. The emerging proposal expects real Markdown links inside structured resource lists. Converting those URLs to Markdown-link syntax removed the warning, and the redeployed page returned 3/3.

The relevant structure was simple:

# Site name

> A short summary that helps a model understand the site.

## Primary pages

- [Product overview](https://example.com/product): What the page contains.
- [Documentation](https://example.com/docs): How to use the product.

That small repair is useful first-hand evidence because it reveals what Lighthouse currently expects. It should not dominate the interpretation. The change proved that a proposed machine-facing entry point was well formed. It did not prove that any model fetched it, cited the article, preferred the brand, or used it for training.

Passing a machine-readiness check is evidence that an entry point is well formed. It is not evidence of distribution, trust, permission, or successful task completion.

Agentic Browsing, SEO, E-E-A-T, and Core Web Vitals are different layers

The PageSpeed interface places the categories next to one another, which makes them easy to conflate. A responsible interpretation keeps four questions separate.

1. Can people use the page well?

Core Web Vitals measure real-world user experience through:

• Largest Contentful Paint (LCP): loading performance;
• Interaction to Next Paint (INP): responsiveness;
• Cumulative Layout Shift (CLS): visual stability.

Google recommends evaluating these field metrics at the 75th percentile. The target thresholds remain 2.5 seconds or less for LCP, 200 milliseconds or less for INP, and 0.1 or less for CLS.

The green Performance score in a Lighthouse lab run is useful for debugging. It is not the same as passing Core Web Vitals in the field. In the evidence image, PageSpeed Insights says “No Data” for real-user experience because that URL did not have sufficient Chrome User Experience Report data. A 97 lab score cannot fill that evidence gap.

2. Can search systems discover and understand the page?

Technical SEO still depends on crawl access, canonical URLs, internal links, sitemaps, meaningful metadata, structured data where appropriate, and people-first content.

Chrome's own Agentic Browsing introduction says that when agents are searching for websites, the principles of SEO still apply. Adding llms.txt does not replace robots.txt, an XML sitemap, canonical tags, or clear information architecture.

There is an especially important 2026 distinction: Google Search says it does not use llms.txt for Google Search or its generative AI features. Maintaining the file neither helps nor harms Google visibility or ranking. Chrome's experimental PageSpeed category may test the file for other agentic systems, but a 3/3 result should not be sold as “AI SEO.”

3. Is the content worthy of trust?

Google describes E-E-A-T as experience, expertise, authoritativeness, and trustworthiness, with trust the most important element. It is not a single PageSpeed metric or a specific ranking factor.

For financial content, the standard should be higher because the information may affect financial stability. A useful implementation note therefore shows:

• who performed the work;
• what changed;
• the date and test context;
• the before-and-after evidence;
• the primary sources used;
• the limits of the conclusion.

An llms.txt file can point to this evidence. It cannot create the evidence.

4. Can a software agent interact safely?

This is where Agentic Browsing starts to extend beyond conventional SEO. Accessibility semantics and layout stability help an agent identify controls reliably. WebMCP proposes a way for a page to expose functions as tools with natural-language descriptions and structured schemas.

That can make machine interaction more reliable. It also raises a different class of risk. The WebMCP draft itself discusses prompt injection, tool poisoning, misrepresentation of intent, privacy leakage, and same-origin boundaries.

For a lender or payment provider, “the agent can find and invoke the control” is not an adequate acceptance criterion.

This is one form of the AI security asymmetry financial institutions should prepare for: the institution must preserve customer intent and control evidence even when an adversarial interaction does not respect the same boundaries.

Is Agentic Browsing another AMP cycle?

AMP is a useful analogy, but not a forecast.

AMP was a specific implementation for fast mobile pages. For a period, it also carried a distribution advantage: Google once required AMP for eligibility in the mobile Top Stories carousel. In 2021, Google removed that requirement and opened Top Stories to eligible non-AMP pages. AMP content still works, but the platform-specific advantage changed.

The lesson is not that financial institutions should have chased AMP harder, nor that they were right to dismiss it. Firms that adopted it could benefit from its speed and distribution window; firms that waited avoided maintaining a parallel implementation after the requirement receded.

The more useful lesson is to distinguish a temporary mechanism from a durable direction.

The current Agentic Browsing score, its denominator, llms.txt, and WebMCP may all change. The underlying direction is less fragile: customers are increasingly asking software agents to find, compare, interpret, and eventually act on web information. Those agents need accessible semantics, stable interfaces, authoritative source material, and controlled ways to perform consequential actions.

I would not make “achieve 3/3” an executive objective for a bank. I would fund the durable capabilities beneath it and use the experimental audit as an inexpensive learning signal.

Why financial-services teams may defer this work

Many financial institutions have capable web teams but a rationally crowded backlog. Revenue releases, regulatory commitments, security remediation, accessibility, uptime, and conversion work compete for the same delivery capacity. Technical SEO can become an occasional remediation exercise. An experimental agent-readiness category is even easier to classify as optional.

That decision is understandable, but waiting has a cost.

Customers increasingly begin financial journeys outside a provider's owned interface. They compare accounts, seek repayment options, check eligibility, understand charges, and look for complaint routes through search engines and AI assistants. If public information is hard for machines to retrieve or interpret, the institution gives intermediaries more room to summarize it inaccurately.

The immediate opportunity is not autonomous lending or unattended payments. It is more basic:

• make public product and service information unambiguous;
• preserve the same meaning for humans, search systems, and agents;
• make ownership, dates, disclosures, and source pages easy to verify;
• ensure agent-facing summaries do not bypass the canonical legal wording;
• create a controlled path for future machine interaction.

Financial-services firms do not need to expose transactional tools merely because the audit exists. They do need a view on which public journeys should become agent-readable and which actions must remain behind authentication, consent, and human confirmation.

What llms.txt should do

The llms.txt proposal defines a concise Markdown file at the root of a domain. Its recommended structure includes:

1. one H1 naming the project or site;
2. an optional blockquote with the essential summary;
3. optional explanatory text;
4. H2 sections containing Markdown lists of important links;
5. an optional section literally named Optional for secondary context.

The file should act as a curated map, not a dump of every URL. For a financial institution, a useful first version might point to:

• product overview and eligibility pages;
• current rates, fees, and disclosures;
• repayment and hardship-support information;
• fraud and security guidance;
• grievance and complaint routes;
• accessibility and privacy statements;
• dated research or operating perspectives;
• a fuller context file where appropriate.

The descriptions matter. “Click here” provides little retrieval value. “Current personal-loan rates, fee definitions, and the date on which they took effect” is more useful to both people and machines.

What llms-full.txt adds

llms-full.txt is a useful but optional companion convention. It can provide consolidated long-form context when the concise index would otherwise point to many separate pages.

For this website, the full file contains:

• first-party company and product context;
• the complete readable text of published perspectives;
• canonical URLs and publication dates;
• primary-source references attached to those perspectives;
• explicit interpretation boundaries.

It should not contain customer data, internal policy, secrets, authenticated content, unpublished pricing, model prompts, or instructions that weaken existing access controls.

There is also no reason to assume every model consumes llms-full.txt. Its value is optional retrieval convenience for systems that choose to use it, not guaranteed adoption and not Google Search optimization.

The four files that should not be confused

File or signal	Primary purpose	What it does not do
robots.txt	Gives crawler-access directives	Does not provide a curated explanation of the site
sitemap.xml	Lists canonical crawlable URLs and update signals	Does not explain which pages matter most to an agent
llms.txt	Curates important context in readable Markdown	Does not grant access, control indexing, or prove model use
llms-full.txt	Consolidates optional long-form context	Does not replace canonical pages or their disclosures

Structured data is another layer. It helps eligible systems interpret entities and page meaning, but it should describe visible canonical content rather than invent a machine-only version of the product.

A practical implementation sequence for regulated firms

The safest approach is progressive.

Stage 1: inventory the public journey

Map the pages a customer or agent may use before authentication: product information, pricing, help, servicing, complaints, security, and contact routes. Record the owner, canonical source, review date, and any legally required wording.

Stage 2: fix the human-readable foundation

Use semantic HTML, descriptive headings, named controls, stable layouts, keyboard access, meaningful errors, and explicit image dimensions. Accessibility is for people first; the same structure also gives agents a better machine view.

Stage 3: align search and agent context

Confirm robots directives, sitemaps, canonicals, internal links, metadata, and structured data. Then add a concise llms.txt using real Markdown links. Add llms-full.txt only where consolidated context has a clear use.

Stage 4: validate claims and drift

Run PageSpeed Insights and inspect the specific audits, not only the fraction. Test from a clean deployment. Re-run after information-architecture, rendering, or content-pipeline changes. Keep dated evidence.

Stage 5: govern any machine action separately

Before exposing transactional tools, define:

• authentication and authorization;
• explicit user intent and confirmation;
• limits and step-up controls;
• idempotency and reversal;
• sensitive-data minimization;
• approved tool descriptions and schemas;
• logging, monitoring, and dispute evidence;
• fallback to a human-supported journey.

A public mortgage explainer and a tool that initiates a payment are not the same risk class. Their agent-readiness roadmaps should not be identical.

A verification checklist

For a public content or product page:

• Run mobile and desktop PageSpeed Insights tests.
• Separate CrUX field evidence from Lighthouse lab evidence.
• Inspect every Agentic Browsing warning instead of reporting only the fraction.
• Serve /llms.txt as plain UTF-8 text from the domain root.
• Use one H1 and real Markdown links under H2 sections.
• Keep summaries aligned with visible canonical pages.
• Link the founder, author, or accountable institutional owner where appropriate.
• Include publication and review dates for material claims.
• Maintain robots.txt, sitemap.xml, canonicals, and structured data independently.
• Exclude private, authenticated, customer, and secret information.
• Treat WebMCP as experimental and complete a security review before exposing tools.
• Re-test the deployed URL after every fix.

What a 3/3 result does and does not justify

It is reasonable to say:

• the tested page passed all applicable checks displayed in that PageSpeed run;
• a prior llms.txt formatting warning was removed by adopting the expected Markdown-link structure;
• the result is reproducible evidence of that implementation state.

It is not reasonable to say:

• the site “ranks for AI”;
• every AI agent will read or cite it;
• the result improves Google ranking;
• the website passes Core Web Vitals;
• the institution is ready for autonomous financial transactions;
• the result satisfies accessibility, security, privacy, conduct, or regulatory obligations.

The most credible teams will publish both halves.

The operating takeaway

Agentic Browsing is early, but the direction is useful. The exact PageSpeed category may evolve or disappear; that would not remove the need for software agents to understand controls and complete tasks on the web.

For financial services, the response should not be to chase a new badge or revive the old habit of treating every experimental web feature as an SEO project. It should be to make public information easier to verify while keeping consequential actions inside explicit governance.

The 3/3 result is therefore a conversation starter. It shows that one emerging machine-facing entry point is correctly formed. The real work is aligning accessible design, trustworthy content, current disclosures, customer intent, and controlled action before an agent reaches a customer's money.

Primary sources

1. Lighthouse Agentic Browsing scoring — Chrome for Developers
2. A developer toolkit to make your website agent-ready — Chrome for Developers
3. Lighthouse v13.3.0 release — GoogleChrome on GitHub
4. The llms.txt proposal — llmstxt.org
5. WebMCP Draft Community Group Report — W3C Web Machine Learning Community Group
6. About PageSpeed Insights — Google for Developers
7. Understanding Core Web Vitals and Google Search — Google Search Central
8. Optimizing your website for generative AI features on Google Search — Google Search Central
9. Creating helpful, reliable, people-first content — Google Search Central
10. More time, tools, and details on the page experience update — Google Search Central

Regulatory references are an operating interpretation, not legal advice. Requirements should be confirmed for the institution, activity, and jurisdiction at deployment.