Is je site klaar voor AI-agents? Google heeft er nu een test voor

Jarenlang had je site twee soorten bezoekers: mensen en de crawler van Google. Voor beide 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. Of jouw site daar klaar voor is, was tot voor kort niet te meten. Dat is veranderd.

Google heeft een meetbare agent-readiness-audit in Chrome gezet. Je vindt hem in Lighthouse, de gratis test waarmee Google al jaren sites beoordeelt op snelheid en toegankelijkheid. Rechtsklik op een pagina, kies Inspect, ga naar het tabblad Lighthouse en bekijk de lijst met categorieën: daar staat een nieuwe optie, Agentic Browsing. Inmiddels zit die in de gewone Chrome; bij het verschijnen had je er nog Chrome Canary voor nodig, de dagelijkse testversie. Het is het eerste dat ik van een browserbouwer heb gezien dat de vraag “is mijn site klaar voor gebruik door een AI-agent” vertaalt naar een lijst met checks die je zelf in 30 seconden opstart, zonder dat je daar een tool van derden voor hoeft te kopen.

Het rapport geeft geen score op honderd, zoals de performance-audit dat doet. Je krijgt een breuk: hoeveel van de agent-readiness-checks je pagina haalt. Op de sites waar ik het deze week op losliet, inclusief een paar van mijn eigen klantensites en de Google-pagina die de categorie zelf documenteert, bleef die breuk onder de helft. 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: Google zet de categorie zelf nog weg als in ontwikkeling, en de checks kunnen dus 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 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. Dat kost je klikken, en dus 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 rapport, de accessibility tree, 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. Interessant is het nu vooral voor sites met boekbare diensten, configurators, calculators of een uitgebreide selfservice-omgeving. Voor de bakker, de fysio en de kleine contentsite is de realistische eerste stap simpelweg het rapport één keer draaien en de goedkope accessibility-fixes meepakken.

Drie ideeën in één rapport, met heel verschillende moeite en opbrengst

Het rapport bundelt drie ideeën die elk in een ander stadium van volwassenheid zitten. Scheer je ze over één kam, dan verspeel je zomaar een middag aan het verkeerde werk. Er zit trouwens ook een vierde audit in die niets met agents te maken heeft: cumulative layout shift, de meting die je al kende uit de performance-audit. De redenering erachter is dat een agent die screenshots maakt in de war raakt van een pagina die onder zijn handen verspringt. Zo zet ik de drie nieuwe uit elkaar:

1. De accessibility tree: dit fix je als eerste

Een agent kan jouw pagina op drie manieren lezen. Hij kan een screenshot maken en de pixels door een vision-model halen. Dat werkt, maar het is traag, duur en het breekt zodra content dynamisch wordt. Hij kan de ruwe HTML lezen. Dat is snel, maar het wordt steeds ruisiger, omdat moderne frameworks megabytes aan scripts van derden, advertentieblokken en geneste wrapper-divs rond de eigenlijke content plaatsen. Of hij leest de accessibility tree, de gestructureerde boom die de browser uit je HTML berekent. Elk element heeft daarin een rol (button, link, region), een naam (de zichtbare tekst, of een onzichtbaar label dat in code aria-label heet) en een status (disabled, expanded). Die boom is oorspronkelijk gebouwd zodat screenreaders de pagina konden voorlezen aan een blinde gebruiker. Dezelfde 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 rapport signaleert dezelfde zaken als een reguliere accessibility-audit: icon-only buttons zonder aria-label, divs met een onclick-handler die eigenlijk een <button> hadden 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, en het zijn meteen ook echte accessibility-verbeteringen voor de mensen op je site. Veel Nederlandse sites, ook van serieuze bedrijven, missen deze basis nog. De lat ligt dus laag voor wie het wel oppakt.

Dit is de check die je als eerste moet oppakken. Goedkoop, ondubbelzinnig, en hij betaalt zich in twee richtingen uit: screenreader-gebruikers krijgen een betere site en agents kunnen de call-to-action daadwerkelijk vinden.

2. WebMCP: de moeite waard om te proberen, maar de afnemers ontbreken nog

De tweede check gaat over WebMCP, een voorstel 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 variant van de MCP-servers waar ik de afgelopen maand over heb geschreven. Er zijn twee smaken. Declaratief zet je een paar attributen op een bestaand formulier, waarna de browser daar zelf een toolbeschrijving van maakt: dit is het boekingsformulier, dit zijn de velden, dit gebeurt er als je op versturen klikt. Imperatief registreer je je tools in JavaScript, wat meer controle geeft en meer werk kost.

Belangrijker dan de keuze tussen die twee is de stand van het voorstel zelf. Het ligt bij een community group van het W3C en staat niet op het standaardentraject; de API is tussen twee concepten al een keer verhuisd. Chrome draait het als origin trial, dus je meldt je per domein aan en de proef loopt na een vast aantal releases af. En de kant die er uiteindelijk toe doet ontbreekt nog helemaal: geen van de grote agents roept WebMCP-tools vandaag aan. ChatGPT, Claude, Perplexity en Gemini lezen nog gewoon de DOM of kijken naar screenshots. Google heeft aangegeven dat Gemini in Chrome de eerste afnemer wordt.

Praktisch betekent dat het volgende. Heeft je site echte tools, dus een boekingspagina, een productconfigurator of een prijscalculator, dan is de declaratieve route een uurtje werk en een prima experiment. Verwacht er dit kwartaal alleen nog geen verkeer van. De imperatieve route zou ik laten liggen tot de spec stilstaat, want elke verhuizing van de API is werk dat je opnieuw moet doen.

Is je site contentgedreven (blog, marketingpagina's, nieuws) en heb je geen tools, dan trekt WebMCP je score sowieso niet omhoog. Sla het zonder schuldgevoel over.

3. Het llms.txt-bestand: optioneel, en er wordt te veel van verwacht

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 vergelijking waar iedereen naar grijpt is robots.txt, en juist die vergelijking zet je op het verkeerde been. Aan robots.txt houden de grote zoekmachinecrawlers zich al 30 jaar, en het is inmiddels ook formeel als RFC vastgelegd. llms.txt is ongeveer twee jaar geleden voorgesteld, en de grote aanbieders van agents lezen het nog steeds niet consistent.

Google heeft apart aangegeven dat je geen llms.txt nodig hebt om te ranken in de AI-features van Search. Het bestand staat in Googles eigen optimalisatiegids in het rijtje dingen die je kunt overslaan, met als argument dat AI Overviews en AI Mode uit dezelfde index putten als de klassieke ranking. Opvallend, want in dezelfde periode zette datzelfde bedrijf een llms.txt-check in Lighthouse. Tegenstrijdig hoeft dat niet te zijn, want het rapport stelt een andere vraag: weet een agent die jouw site bezoekt wat hij hier kan doen? Heeft je site agent-relevante functionaliteit (het soort dingen dat WebMCP ook blootlegt), dan kost het niets om een llms.txt van een paar regels te publiceren die verwijst naar je sitemap en je API-documentatie. Is je site puur content, dan is een llms.txt bezigheidstherapie: uit je sitemap en je robots.txt haalt een agent alles wat hij nodig heeft.

Sla het over tenzij je agent-relevante functionaliteit hebt. Kijk er opnieuw naar zodra de grote aanbieders het daadwerkelijk gaan lezen.

Het moment waarop Google zijn eigen test niet haalt

Het nuttigste dat ik in 30 minuten met dit rapport leerde, is dat de officiële Google-pagina die de nieuwe Agentic Browsing-categorie documenteert zelf meerdere van die checks niet haalt. Niet catastrofaal, 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 meteen het juiste kader voor dit hele rapport. Niemand is volledig agent-ready, ook de mensen die de spec schrijven niet. De vraag is niet of jouw site alle checks haalt, maar of je werkt 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 iets dat binnen een bedrijf jaar op jaar in waarde aangroeit. Dit Lighthouse-rapport sluit op beide aan. Agent discovery heeft een registry-laag, vindplaatsen waar agents tools ontdekken (die van Anthropic, Smithery, Glama, de aangekondigde Gemini MCP Apps directory). Daarnaast is er een laag op paginaniveau, en dat is wat Lighthouse nu begint te scoren.

Beide kanten doen ertoe. Een goed vermelde MCP-server op een site met een onleesbare accessibility tree levert een vermelding op waar in de praktijk niets uit volgt. Een keurig gemarkeerde pagina zonder beschikbare tools levert een agent op die netjes langskomt en vervolgens niets kan doen. Het werk dit jaar is om op beide plekken aanwezig te zijn, in de registry en op de pagina, en om de methodes vast te leggen die de agent aanroept zodra hij daar aankomt.

Wat ik deze week daadwerkelijk zou doen

• Draai het Lighthouse Agentic Browsing-rapport op je eigen homepage en je twee belangrijkste conversiepagina's. Open DevTools, ga naar Lighthouse, kies Agentic Browsing, klik op Analyze page. Wil je ook de WebMCP-checks zien, zet dan eerst de vlag chrome://flags/#enable-webmcp-testing aan. Zit je nog op een oudere Chrome, dan haal je Chrome Canary erbij. 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 gewone accessibility-score, dus het werk telt daadwerkelijk dubbel.
• Declaratieve WebMCP als je echte tools hebt, en dan als experiment. Boekingsformulieren, configurators, calculators, zoekinterfaces. Reken er dit jaar nog niet op dat een agent ze ook echt aanroept. Sla over als je site puur content is.
• Sla llms.txt voorlopig over tenzij je agent-specifieke functionaliteit hebt. Kijk er opnieuw naar zodra de grote aanbieders het daadwerkelijk gaan lezen.
• Draai het rapport 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.