Jarenlang had je site twee soorten bezoekers: mensen en de crawler van Google. Voor allebei heb je geoptimaliseerd. Er komt nu langzaam een derde soort bezoeker bij: AI-agents, assistenten die namens een gebruiker zelfstandig een pagina openen, informatie opzoeken of een formulier invullen. De vraag of jouw site daar klaar voor is, was tot voor kort niet te beantwoorden. Dat is veranderd.
Google heeft in alle stilte de eerste meetbare agent-readiness audit uitgebracht in Chrome. Open Chrome Canary, de testversie van Chrome, rechtsklik op een pagina, kies Inspect, ga naar het tabblad Lighthouse (de gratis test waarmee Google al jaren sites beoordeelt op snelheid en toegankelijkheid) en bekijk de lijst met categorieën: je ziet een nieuwe optie genaamd Agentic Browsing. Het is het eerste dat ik van een grote vendor heb gezien dat de vraag “is mijn site klaar voor gebruik door een AI-agent” vertaalt naar een lijst met checks die iedereen in 30 seconden kan uitvoeren, zonder dat je daar een tool van derden voor hoeft te kopen.
Het report geeft geen score op honderd, zoals de performance-audit dat doet. Het geeft een pass/fail-verhouding over een handvol agent-readiness checks. Voor de meeste sites waar ik het deze week op losliet, inclusief een paar van mijn eigen klantensites en de eigen pagina van Google die het report documenteert, ligt die verhouding ruim onder de één. Niemand is volledig klaar. Zie dit niet als een benchmark, maar als de eerste versie van een checklist waarvan mijn inschatting is dat hij serieus gaat meetellen. Kanttekening: de categorie is experimenteel en zit alleen in Canary; de checks kunnen nog veranderen.
Eerst even nuchter: hoe urgent is dit voor een Nederlandse site?
Voordat je een sprint inplant: agents die zelfstandig websites bedienen zijn in Nederland nog een randverschijnsel. Voor de meeste Nederlandse webshops, dienstverleners en B2B-bedrijven blijft Google Search de komende jaren gewoon het hoofdkanaal. De eerste AI-verschuiving die je nu al wél in je cijfers ziet, is een andere: AI Overviews, ChatGPT Search en Perplexity vatten je site samen zonder dat er iemand doorklikt. Minder klikken, meer AI-antwoorden, minder traditionele GA4-sessies. Agentic browsing, waarbij een agent daadwerkelijk op je site handelingen uitvoert, is de stap daarna.
Waarom er dan nu al naar kijken? Twee redenen. De belangrijkste check in dit report (de accessibility tree, daarover zo meer) is werk dat zich vandaag al uitbetaalt voor gewone bezoekers, los van wat agents ooit gaan doen. En het rapport draaien kost vijf minuten, dus de nulmeting is bijna gratis. Voor wie is het nu al echt interessant: sites met boekbare diensten, configurators, calculators of een uitgebreide selfservice-omgeving. Voor wie nog niet: de bakker, de fysio en de kleine contentsite. Daar is de realistische eerste stap simpelweg het report één keer draaien en de goedkope accessibility-fixes meepakken.
Drie checks, drie verschillende effort/payoff-profielen
Het report bundelt drie verschillende ideeën die elk in een ander stadium van volwassenheid zitten. Als je ze over één kam scheert, verspil je zomaar een middag aan het verkeerde werk. Zo zet ik ze uit elkaar:
| Check | Moeite | Opbrengst | Voor wie nu |
|---|---|---|---|
| Accessibility tree | Laag, uren werk | Direct, telt dubbel (mensen én agents) | Iedereen |
| WebMCP (declaratief) | Laag tot middel | Alleen als je site echte tools heeft | Boekingen, configurators, calculators |
| WebMCP (imperatief) | Hoog, spec beweegt nog | Onzeker | Vrijwel niemand |
| llms.txt | Laag | Onduidelijk, vendors lezen het niet consistent | Alleen bij agent-functionaliteit |
1. De accessibility tree: dit fix je als eerste
Een agent kan jouw pagina op drie manieren lezen. Hij kan een screenshot maken en vision-language inference op de pixels draaien, wat werkt, maar traag, duur en fragiel is bij dynamische content. Hij kan de ruwe HTML lezen. Dat is snel, maar wordt steeds ruisiger omdat moderne frameworks megabytes aan vendor scripts, ad slots en geneste wrapper-divs rond de daadwerkelijke content plaatsen. Of hij kan de accessibility tree lezen, de kleine gestructureerde boom die de browser berekent uit je HTML, waarin elk element een rol heeft (button, link, region), een naam (de zichtbare tekst of een onzichtbaar tekstlabel, in code een aria-label) en een status (disabled, expanded). Die boom is oorspronkelijk gebouwd zodat screenreaders de pagina konden voorlezen aan een blinde gebruiker. Diezelfde structuur blijkt precies wat een agent nodig heeft om te beslissen op welke button hij moet klikken.
De meeste sites hebben een redelijke accessibility tree omdat de meeste teams al wel wat werk voor screenreaders hebben gedaan. Het Lighthouse report signaleert dezelfde zaken als een reguliere accessibility audit: icon-only buttons zonder aria-label, divs met onclick-handlers die eigenlijk <button> elementen zouden moeten zijn, ontbrekende landmark-elementen zoals <main> en <nav>, en linktekst die “klik hier” of “lees meer” zegt zonder context eromheen. Geen van deze fixes kost veel tijd: ze zijn meteen ook échte accessibility-verbeteringen voor de mensen op je site, en de agent-readiness payoff is direct. Eerlijk is eerlijk: veel Nederlandse sites, ook van serieuze bedrijven, missen deze basis nog. Goed nieuws voor wie het wel oppakt, want de lat ligt laag.
Dit is de check die je als eerste moet oppakken. Het is goedkoop, ondubbelzinnig, en het betaalt zich in twee richtingen uit: screenreader-gebruikers krijgen een betere site en agents kunnen de call-to-action daadwerkelijk vinden.
2. WebMCP, alleen nuttig als je tools hebt om aan te bieden
De tweede check gaat over WebMCP, een voorgestelde webstandaard om functies van je site (een boeking, een berekening, een zoekopdracht) als gestructureerde tools aan een agent aan te bieden, rechtstreeks vanuit de webpagina. Het is de in-browser versie van de MCP-servers waar ik de afgelopen maand over heb geschreven. Er zijn twee smaken. Bij declaratieve WebMCP verpak je een formulier of button in MCP-bewuste markup, zodat een agent kan zien: “dit is het boekingsformulier, dit zijn de velden, dit gebeurt er als je op versturen klikt”. Bij imperatieve WebMCP voeren de agent en de pagina een rijkere heen-en-weer conversatie via een JavaScript-API.
Declaratieve WebMCP is écht nuttig als je site echte tools heeft die een agent zou willen gebruiken. De boekingspagina van een dienstverlener, de productconfigurator op een webshop, de calculator op een SaaS-prijspagina. Als de tool visueel al vindbaar is, is het via declaratieve markup beschikbaar maken voor agents maar een kwestie van een klein beetje extra code die de pagina future-proof maakt. Imperatieve WebMCP is bleeding edge: de spec ligt nog niet vast en maar heel weinig agents ondersteunen het op dit moment. De richting is duidelijk, maar het ecosysteem beweegt nog volop en is nergens af of uniform. Ik zou er dit kwartaal niet in investeren.
Als je site contentgedreven is (blog, marketingpagina's, nieuws) en geen tools heeft, is WebMCP niet de check die je score omhoogtrekt. Sla het zonder schuldgevoel over.
3. Het llms.txt-bestand, optioneel en overhyped
De derde check gaat over een llms.txt-bestand, een voorgesteld markdown-bestand aan de root van je site dat een agent snel laat zien welke pagina's belangrijk zijn, welke onderwerpen ze behandelen en wat de agent wel en niet mag doen. De analogie waar iedereen naar grijpt is robots.txt, maar die analogie is misleidend. Elke grote zoekmachinecrawler respecteert robots.txt al 30 jaar. llms.txt is ongeveer twee jaar geleden voorgesteld, en de grote agent-vendors lezen het nog steeds niet consistent.
Opvallend genoeg heeft Google apart aangegeven dat je geen llms.txt nodig hebt om te ranken in de nieuwe AI-features van Search. Dat is het antwoord voor Search. Het Lighthouse Agentic Browsing report stelt een andere vraag, namelijk “weet een agent die jouw site bezoekt wat hij hier kan doen?” Als je site agent-relevante functionaliteit heeft (het soort dingen dat WebMCP ook blootlegt), kost het niets om een llms.txt van een paar regels te publiceren die verwijst naar je sitemap en je API-documentatie. Als je site puur content is, is een llms.txt bezigheidstherapie: de agent kan je sitemap en je robots.txt lezen en daaruit alles afleiden wat hij nodig heeft.
Sla het over tenzij je agent-relevante functionaliteit hebt. Kijk er opnieuw naar zodra de grote vendors het daadwerkelijk gaan respecteren.
Het moment waarop Google zijn eigen test niet haalt
Het nuttigste dat ik in 30 minuten met dit report leerde, is dat de officiële Google-pagina die de nieuwe Agentic Browsing categorie documenteert, zelf meerdere van die checks niet haalt. Niet catastrofaal, maar wel zichtbaar. Buttons zonder correcte aria-labels. Heading-niveaus die springen van h1 naar h3. Het soort details dat een zorgvuldige frontend-audit in een ochtend zou vinden, maar waar bij Google kennelijk nog niemand tijd voor heeft gemaakt.
Dat is het juiste kader voor dit hele report. Niemand is volledig agent-ready, inclusief de mensen die de spec schrijven. De vraag is niet “haalt mijn site alle checks”, maar “werk ik aan de ene check die het snelste rendement oplevert”. Mijn antwoord dit kwartaal is de accessibility tree, omdat die zich in twee richtingen uitbetaalt en het werk ondubbelzinnig is.
Waar dit aansluit bij het grotere verhaal
Ik schreef vorige week over agent discovery als de nieuwe distributielaag boven zoeken, SEO en social, en de week ervoor over skill libraries als het volgende compounding asset binnen een bedrijf. Dit Lighthouse-report sluit op beide aan. Agent discovery heeft een registry-laag, vindplaatsen waar agents tools ontdekken (die van Anthropic, Smithery, Glama, de aankomende Gemini MCP Apps directory). Het heeft ook een laag op paginaniveau, en dat is wat Lighthouse nu begint te scoren. De registry is jouw etalage. De checks op paginaniveau bepalen of de agent de goederen daadwerkelijk kan oppakken zodra hij naar binnen loopt.
Beide kanten doen ertoe. Een goed vermelde MCP-server met een onleesbare accessibility tree op de website die hem host, is een registry-hit die in de praktijk een no-op wordt. Een prachtig gemarkeerde pagina zonder beschikbare tools levert alleen een agent op die netjes langskomt, maar niets kan doen. Het werk dit jaar is om op beide plekken aanwezig te zijn, de registry en de pagina, en om de methodes (de skills) vast te leggen die de agent aanroept zodra hij daar aankomt.
Wat ik deze week daadwerkelijk zou doen
- Draai het Lighthouse Agentic Browsing report op je eigen homepage en je twee belangrijkste conversiepagina's. Installeer Chrome Canary als je het nog niet hebt, open DevTools, ga naar Lighthouse, kies Agentic Browsing, klik op Analyze page. Het hele proces duurt minder dan vijf minuten per pagina.
- Fix eerst de problemen met de accessibility tree. Aria-labels op icon-buttons. Vervang
<div onclick>door<button>. Voeg<main>en<nav>landmarks toe. Herschrijf elke linktekst die “klik hier” zegt. Dit alles verbetert ook je echte accessibility-score, dus het werk telt daadwerkelijk dubbel. - Declaratieve WebMCP als je echte tools hebt. Boekingsformulieren, configurators, calculators, zoekinterfaces. Sla over als je site puur content is.
- Sla
llms.txtvoorlopig over tenzij je agent-specifieke functionaliteit hebt. Kijk er opnieuw naar zodra de grote vendors het daadwerkelijk gaan respecteren. - Draai het report maandelijks opnieuw. De checks zullen evolueren en de scoring wordt vermoedelijk strenger. Mijn inschatting is dat registries dit soort paginasignalen binnen een jaar of twee als ranking-input gaan meewegen. Zeker is dat niet, maar de accessibility-tree check nu halen kost weinig en zet je vooraan als het gebeurt.
Als je een tweede blik wilt op welke van deze punten jouw site het eerst moet fixen, of hulp wilt bij het auditen van een multi-site stack, stuur me een bericht. Mail info@jermayads.nl of gebruik jermayads.nl/contact.