Wat de Lighthouse-audit voor agentic browsing wel en niet bewijst
Lighthouse controleert technische voorwaarden, niet het slagen van een klanttaak. De experimentele categorie toont geslaagde checks, geen gewogen agent-ready-score van 0 tot 100.
Een rapport kan aantonen dat tools zijn geregistreerd en toch niets zeggen over de vraag of een agent de juiste offerte maakt. Gebruik Lighthouse daarom als technische controle naast een taaktest. Dat onderscheid voorkomt dat een groen rapport een onbruikbare implementatie goedkeurt.
Welke versie en welke score?
De Agentic Browsing-categorie verscheen in de release notes van Lighthouse 13.3.0. De Chrome-documentatie noemt Chrome 150 of later voor het testen van de categorie en de WebMCP-origin trial voor de WebMCP-audits.
Het resultaat is geen gewogen cijfer van nul tot honderd zoals bij andere Lighthouse-categorieën. Je ziet een verhouding van geslaagde controles en afzonderlijke bevindingen. Dat is bruikbaar om technische wijzigingen te volgen; de controles bewijzen niet dat je website iedere agenttaak aankan.
Lees een bevinding als begin van onderzoek
De gedocumenteerde controles betreffen onder meer toolregistratie, relevante toegankelijkheidskenmerken, layoutstabiliteit en de aanwezigheid van llms.txt. Een bestand of registratie is daarbij een waarneembaar technisch feit; de praktische waarde vraagt een andere test.
| Bevinding | Wat weet je nu? | Wat test je aanvullend? |
|---|---|---|
| De verwachte tool staat in de lijst | Registratie is tijdens deze run gezien | Kiest de agent hem voor de bedoelde vraag? |
| Een schemafout is opgelost | Die technische fout is verholpen | Betekenen invoervelden wat de gebruiker bedoelt? |
| Labels zijn aanwezig | Bedieningselementen hebben namen | Kan iemand de hele taak correct afronden? |
| llms.txt is aanwezig | Het bestand is vindbaar voor deze controle | Is de inhoud actueel en bruikbaar voor jouw toepassing? |
Gebruik de aanwezigheid van llms.txt dus niet als bewijs van betere zoekzichtbaarheid. Evenmin bewijst een gevonden tool dat de backend correcte rechten controleert. Die conclusies vallen buiten wat deze audit waarneemt.
Een lege toollijst is nog geen diagnose
Bij dynamische registratie maakt het uit wanneer Lighthouse de pagina observeert. Een tool die pas na inloggen of een routewisseling verschijnt, kan ontbreken in een run op de openbare startpagina. De registratie-audit is informatief: onderzoek de context voordat je ‘WebMCP werkt niet’ concludeert.
Noteer daarom URL, accountstatus, browser- en Lighthouse-versie en relevante trialconfiguratie. Herhaal een meting onder dezelfde voorwaarden. Verander je tegelijkertijd account, route en browser, dan is een verschil in het rapport moeilijk toe te schrijven.
Voeg één echte taak toe
Neem een fictieve zakelijke bestelomgeving. Lighthouse ziet create_quote_draft, maar het klantdoel is: maak een concept voor vijf reserveonderdelen onder account A, zonder het te versturen. Die doelstelling bevat aantallen, eigenaarschap en een expliciete grens die een toollijst niet controleert.
Laat de agent die opdracht uitvoeren in een testomgeving. Controleer daarna het opgeslagen concept: juiste artikelen, aantal vijf, account A en status concept. Controleer ook dat er geen bericht is verzonden. Herhaal met een ontbrekend artikel en een account zonder rechten. Een plausibel antwoord in de chat is niet voldoende bewijs.
Maak twee aparte releasevoorwaarden
Onze praktische aanbeveling: gebruik technische checks om fouten vroeg te vinden en taaktests om de gebruikersbelofte te toetsen. Leg beide uitkomsten vast. Een regressie in registratie hoort een andere diagnose te krijgen dan een agent die de verkeerde hoeveelheid kiest.
De waarde van Lighthouse zit in concrete, herhaalbare signalen. Je haalt er meer uit door een bevinding aan een testbare vraag te koppelen dan door de verhouding geslaagde checks als einddoel te presenteren.
Bronnen
Lees ook
Benieuwd hoe jouw site ervoor staat? Doe de gratis AI-Ready Scan, of lees het verschil tussen WebMCP, MCP en llms.txt.