TL;DR: AI-agenten bekijken je site via drie verschillende lenzen (screenshots, ruwe DOM en de accessibility-tree) en de meeste sites zijn per ongeluk onvriendelijk voor alle drie. De oplossingen overlappen met het toegankelijkheids- en Core Web Vitals-werk dat je toch al hoort te doen. Hier vind je een prioriteitenlijst, een audit van vijf minuten en een meet-loop die je vandaag nog kunt draaien.
Een paar weken geleden bouwde ik onze agent-ready-tool. Het idee was simpel: echte klantensites aan een Playwright-agent voeren en kijken hoe die ermee omgaat. Dus wees ik de agent op onze eigen homepage—die ik al talloze keren had verscheept—en vroeg hem de prijzen te vinden.
Hij klikte op de verkeerde CTA. Daarna probeerde hij op een knop te klikken die helemaal geen knop was (een gestylde <div> die we in haast hadden gebouwd). Uiteindelijk gaf hij het op en vroeg mij waar de prijzen stonden.
Ik wist dat onze site hover-states had die het secundaire menu tonen. Een mens beweegt de cursor, het menu verschijnt, klaar. De agent werkte echter met één screenshot van de rusttoestand. Er was geen cursor om te bewegen. Voor hem bestond de hover-only-navigatie letterlijk niet.
Vanaf die dag zag ik AI-agenten niet meer als slimme crawlers maar als een nieuw soort bezoeker met vreemde beperkingen. (Terzijde: ik had maandenlang aangenomen dat ze werkten als Googlebot met wat extra stappen. Daar zat ik de eerste zes maanden van vorig jaar naast.) Wat volgt is wat ik sindsdien heb geleerd, vooral door dingen stuk te maken en te kijken hoe de agenten reageren.
Een AI-agent die op je homepage landt, crawlt niet voor een zoekindex. Hij probeert een taak uit te voeren die een mens hem heeft gegeven. Boek de vlucht. Vergelijk de pakketten. Stop het product in het mandje. Hij heeft minuten, geen uren. En elke mis-klik kost de gebruiker geld in inference-tokens.
Dat verandert het ontwerpprobleem. Een zoekbot kan stil falen en jij merkt er niets van. Een agent faalt hoorbaar, voor de betalende gebruiker, en de volgende keer dat die gebruiker hetzelfde wil, vraagt hij de agent jouw site over te slaan. AI-zoekmachines beginnen zich net zo te gedragen. Als hun crawler geen zeker antwoord uit je pagina kan halen, gaat de klik naar wie wel schoon te parsen is. De kliks die je uit de SERP kreeg, worden vervangen door citaties uit een AI-samenvatting, en citaties win je op leesbaarheid, niet op advertentiebudget.
Wil je een langer verhaal over AI als discovery-kanaal, dan behandelt de silo-pijler ask engine optimization de zoekkant direct. Dit artikel gaat over de andere helft: wat er gebeurt als een agent je site daadwerkelijk probeert te gebruiken.
Dit is het stuk waarvan ik wilde dat iemand het me een jaar geleden had uitgelegd. Er is niet één manier waarop agenten webpagina’s zien; er zijn er drie, en de grote leveranciers combineren ze verschillend.
“Agenten kunnen je website op drie primaire manieren bekijken: screenshots, ruwe HTML en de accessibility-tree. De accessibility-tree is een browser-native API die de DOM herleidt tot wat echt telt: rollen, namen en toestanden van interactieve elementen. Voor een AI-agent fungeert het als een hi-fi kaart die de visuele ‘ruis’ van CSS negeert en zich richt op pure functionaliteit.”
— Kasper Kulikowski & Omkar More, web.dev: Build agent-friendly websites
Zo ziet het landschap er begin 2026 uit. Anthropic’s computer-use is alleen screenshot-based. Claude ziet een afbeelding van 1024×768 px, redeneert in pixel-coördinaten en stuurt de muis. Er gaat geen DOM-input naar Anthropic. OpenAI’s Operator (CUA) legt screenshots over met DOM- en accessibility-tree-data, al legt OpenAI’s eigen lancering de nadruk op de screenshot-loop en komt de DOM-laag vooral uit third-party reverse-engineering. Google’s Project Mariner leest zowel pixels als de onderliggende DOM. Playwright-frameworks zoals browser-use prefereren eerst de accessibility-tree en vallen terug op screenshots als dat mislukt.
De economie weegt hier zwaarder dan de architectuur. Een accessibility-tree-snapshot van een normale pagina is 2 tot 5 KB. Een screenshot van dezelfde pagina is 100 KB of meer. Dat is grofweg 20× tot 50× hogere kosten per stap in inference-tokens. Agenten die kunnen lezen in de accessibility-tree hebben dus een sterke prikkel dat te doen. Sites met een schone tree worden gebruikt. Sites zonder krijgen dure screenshots, meer mislukte acties en worden uiteindelijk overgeslagen.
Je kunt de accessibility-tree van je eigen site nu meteen bekijken. Open Chrome DevTools, ga naar het paneel Accessibility en vink “Enable full accessibility tree” aan. Dat is ongeveer wat een agent zoals browser-use ophaalt. Chrome verbergt standaard genegeerde nodes en naamloze generieke nodes, wat handig is, want precies die elementen bezorgen agenten de meeste moeite.
Citaties zijn de nieuwe kliks, althans voor sommige queries. Volgens Profounds cross-platform-analyse claimt Wikipedia 47,9% van ChatGPT’s top-10-bron-aandeel, Reddit pakt 21% van Google AI Overviews en 46,7% van Perplexity. De verhoudingen schuiven voortdurend (volgens Leapd’s tracking kelderde ChatGPT’s Reddit-aandeel van ~60% naar 10% in zes weken na één Google-parameterwijziging), maar de richting is duidelijk: AI-machines belonen content die ze zeker kunnen parsen en negeren de rest.
“Sommige LLM’s, zoals ChatGPT en Claude, voeren geen JavaScript uit (in tegenstelling tot Gemini), waardoor Server-Side Rendering (SSR) cruciaal is als je wilt dat belangrijke content in hun antwoorden verschijnt.”
— Aleyda Solis, AI Search: Where Are We & What Can We Do About It?
Die ene zin is concreter dan het meeste AI-SEO-advies dat ik lees. Staat je belangrijke content client-side gerenderd, dan zien ChatGPT en Claude die niet. Gemini wel. Wat je er ook van vindt, het is een falsifieerbare engineering-eis, geen “vibe”. Ons stuk the AI crawler playbook duikt dieper in welke crawlers JavaScript draaien en welke niet.
Eerlijkheidshalve: er is geen publieke studie die toegankelijkheidsscores direct correleert met AI-citatie-ratio’s. Het mechanisme is verdedigbaar (de accessibility-tree wordt door zowel agenten als screenreaders gebruikt), maar het empirische verband is niet bewezen. De sterkste aanpalende data komt van accessibility.works’ samenvatting van een onderzoek bij 10.000 sites: WCAG-conforme sites kregen 23% meer organisch verkeer en rankten voor 27% meer keywords dan niet-conforme peers. Methodologie is onderbelicht (geen WCAG-niveau gespecificeerd, geen peer-review), dus ik zie het als suggestief, niet als dragend bewijs.
Je ziet veel “8 dingen”-lijstjes hierover. Zo’n lijst is handig als structuur; hij stopt met nuttig zijn zodra je alle acht als even belangrijk ziet. Dat zijn ze niet. Hier de vergelijking.
| Signaal | Wat een agent ziet als het klopt | Wat breekt als het misgaat | Inspanning |
|---|---|---|---|
| Natieve semantische elementen | <button>, <a>, <h1> verschijnen in de a11y-tree met impliciete rollen |
Gestylde <div>-knoppen verdwijnen volledig uit de tree |
Laag |
| Toegankelijke namen op inputs | “input, type=email, label='Email address'” | “input, type=text” (placeholder alleen maakt geen naam aan) | Laag |
| Zichtbare interactieve targets | Knoppen groter dan ~8 px² (empirisch minimum web.dev) en idealiter 24×24 CSS-px (WCAG 2.5.8 AA) | Vision-modellen filteren kleine targets eruit; muis-coordinate-agenten missen ze | Laag |
| Stabiele layout (lage CLS) | Klik-coördinaten landen op het bedoelde element | Lazy-loaded afbeeldingen verschuiven de pagina; agent klikt op de verkeerde knop | Middel |
| Server-gerenderde content | ChatGPT en Claude zien de volledige HTML bij de eerste fetch | Alleen gehydrateerde content is onzichtbaar voor crawlers zonder JS | Middel-hoog |
| Koptitel-hiërarchie | Eén <h1>, geneste <h2>/<h3> met impliciete heading-rollen |
Visuele headings als <p> = geen document-outline |
Laag |
| Geen ghost overlays / focus traps | Klik-events bereiken het zichtbare element | Transparante lagen slikken kliks; agent kan niet verder | Middel |
| Voorspelbare URL’s en formulieren | Agent kan hervatten na navigatie; form-velden beschrijven zichzelf | SPA-routes zonder history verwarren meerstapstaken | Middel |
Twee signalen domineren: natieve semantische elementen en toegankelijke namen. Als die fout zitten, telt de rest niet. In de paar honderd sites die we sinds de lancering door onze agent-ready-check hebben gehaald, is dit de meest voorkomende fout: een CTA als gestylde <div>, die daardoor volledig uit de accessibility-tree verdwijnt. Ongeveer de helft van de homepages die we auditen heeft er minstens één. De 8-px²-targetvloer van web.dev is empirisch, geen harde modelgrens; vision-encoders voor CLIP-modellen werken eigenlijk met 14×14 of 16×16-patches, dus zie het als gezond minimum.
Dit stuk mis ik in andere agent-readiness-posts. De meeste geven een checklist van 8–30 punten en laten je zelf ploeteren. Dit is wat ik echt doe als ik vijf minuten tussen meetings heb.
Minuut 1. Draai onze gratis agent-ready-check. Die voert je homepage aan een Playwright-agent en rapporteert zaken als een gestylde <div role="button"> zonder tabindex, een verborgen input die focus vangt of een CTA die de agent op de screenshot zag maar niet in de accessibility-tree kon bereiken. Dit is de tool die Lida en ik live zetten na het GPT-hover-state-incident (zij wilde wachten op schonere data; ik shipte de ruwe versie). Hij is gratis en vraagt geen e-mail.
Minuut 2. Open je site in Chrome, ga naar DevTools, kies het paneel Accessibility, en zet de volledige tree aan. Zoek naar nodes met role “generic” en zonder naam. Elk daarvan is een plek waar een agent moet gokken.
Minuut 3. Draai de vibe-coded scanner op dezelfde URL. Die checkt codekwaliteit en vangt patronen die Cursor, Copilot en Lovable standaard uitsturen: <div onClick>-knoppen, ontbrekende form-labels, headings gestyled als paragrafen. (Ik bouwde deze omdat de helft van de sites die we auditen nu AI-gegenereerd is, en die generators kennen semantische HTML nog niet.)
Minuut 4. Draai een Lighthouse-audit. Noteer de CLS-score. Alles boven 0,1 is borderline; boven 0,25 breken agent-kliks regelmatig. Noteer ook de accessibility-score; dezelfde audit pakt ontbrekende labels en contrastproblemen die zowel screenreaders als agenten raken.
Minuut 5. Kies het ergste probleem uit die vier rapporten en schrijf het op. Morgen los je dat ene ding op. Ga niet de hele lijst fixen.
Vijf minuten is het echte budget van de meeste marketing-leads. Heb je meer tijd, mooi, graaf dieper. Heb je die niet, dan is deze loop genoeg om het grootste probleem boven water te krijgen—en dat is meestal alles wat je moet weten.
Drie patronen veroorzaken de meeste fouten die ik zie. De eerste is de gestylde <div> als knop. Hij lijkt op een knop, heeft een hover-state, reageert op click, maar is voor de accessibility-tree geen knop.
“Gebruik geen
<div>,<span>of een ander niet-interactief element. Als je er niet naartoe kunt tabben met een toetsenbord, is het waarschijnlijk een heel slecht idee om het te gebruiken.”— Adrian Roselli, Links, Buttons, Submits, and Divs, Oh Hell
Roselli schreef dit in 2016, een decennium voor iemand “AI-agent” in deze context zei. De keyboard-tab-heuristiek die hij beschrijft, mapt nu één op één op agent-leesbaarheid: als een toetsenbord er niet bij kan, exposeert de accessibility-tree het niet en ziet een Playwright-agent het niet. De rekening voor een decennium aan gestylde DIV-knoppen valt nu.
Het tweede patroon is layout-instabiliteit. Daar liepen we hard tegenaan tijdens onze migratie van .io naar .com. Een paar lazy-loaded hero-afbeeldingen op .com schoven de “Get started”-knop 40 px naar beneden zo’n 800 ms na render. Mensen merkten het amper. Playwright-agenten identificeerden de knop op de oorspronkelijke positie, wachtten een tel en klikten vervolgens op de lege ruimte. Dit is geen theorie: Playwright-issue #6238 documenteert precies dit probleem en staat nog open. De CLS-metric uit Lighthouse is hier mijn graadmeter; alles boven 0,1 is verdacht.
Het derde patroon is ghost overlays. Cookiebanners die niet echt sluiten, GDPR-pop-ups waarvan de transparante backdrop blijft hangen, intercom-widgets met z-index 9999 boven je CTA. Ze onderscheppen kliks die de agent voor iets zichtbaars bedoelde. Web.dev noemt ze expliciet, onze vibe-coded scanner flagt ze.
“Deze apparaten vertrouwen op de Accessibility-Tree—het mechanisme waarmee computers assistieve technologie programmatisch UI-content laten lezen—om te functioneren. Door beproefde, goed ondersteunde markup te gebruiken, maken we ons werk veelzijdig en robuust.”
— Eric Bailey, Truths about digital accessibility
Bailey schreef dit in 2019 over screenreaders en assistive tech. Het stukje waar ik op blijf hangen is “the mechanism computers use”. Hij definieerde de accessibility-tree als een programmeerinterface voor machines, niet specifiek voor mensen met een beperking. De komst van AI-agenten schuift wat vroeger drie banen waren (toegankelijkheid, SEO-crawlability, agent-leesbaarheid) samen tot één: lever een schone, machine-leesbare beschrijving van je interface.
Een uitgebreider verhaal over de SEO-kant vind je in onze accessibility-for-SEO-pijler. Kort gezegd: dezelfde fixes (semantische HTML, toegankelijke namen, stabiele layout) sturen drie pijlen tegelijk.
Als je verder niets uit dit artikel meeneemt, doe dan dit in deze volgorde.
<div> en <span>-knoppen door <button>. Hoogste impact, laagste kosten. Eén fix en je gaat van “onzichtbaar” naar “zichtbaar” voor a11y-tree-first-agenten zoals browser-use, Mariner en Playwright-crawlers.<label for> toe aan elk form-input. Placeholder-tekst is geen toegankelijke naam. Heeft je e-mailveld geen label, dan ziet de agent alleen een naamloze tekst-input.<h1> per pagina. <h2> voor secties. Style geen <p> als heading.
Ik heb teams twee weken aan een llms.txt zien werken vóórdat ze hun gestylde-div-checkout-knop repareerden. Die volgorde is omgekeerd.
Fixes live. Wat nu?
Voor layout-stabiliteit is de Lighthouse-audit de goedkoopste betrouwbare meting. Draai hem vóór en ná, kijk hoe CLS, accessibility-score en INP samen bewegen. (Toen we onze <div>-knoppen vervingen, steeg onze Lighthouse-toegankelijkheidsscore met 14 punten en daalde CLS van 0,18 naar 0,04. Geen gecontroleerd experiment, wel haalbaar op een middag.)
Voor agent-leesbaarheid specifiek: draai de agent-ready-check opnieuw. De tool geeft een parseability-score plus een lijst CTAs die de agent wel of niet bereikte. De metric die ik volg is “CTAs succesvol geïdentificeerd”: als dat geen 100% is, raadt de agent nog steeds.
Voor AI-citaties (de SEO-uitkomst die je echt boeit) gebruik je onze backlinkchecker om vermeldingen in AI-samenvattingen te volgen. Citaties van ChatGPT, Perplexity en AI Overviews lijken qua vorm op backlinks, alleen uit nieuwe bronnen. Werken je fixes, dan zie je die citaties wekenlang langzaam groeien. Onze AI-visibility-audit-methodologie legt de langzame meet-loop uit.
Ik wil de Wil Reynolds-statisticus aankaarten die via Orbit Media rondgaat: “0,8% van het verkeer, 10% van de leads”. Het is een echt, citeerbaar datapunt. Het is ook één bedrijf in één periode, en Reynolds zelf zegt dat het geen universele multiplier is. Ik zie het als bewijs dat AI-verkeer bovengemiddeld converteert, niet als verplichte factor in forecasts. Converteert jouw AI-verkeer 5× beter dan organisch, dan heb je iets. Zo niet, dan geldt de multiplier niet voor jou.
WebMCP is de spec om in de gaten te houden. Hiermee kan een site JavaScript-tools registreren die AI-agenten direct kunnen aanroepen, waardoor de pagina zelf een Model Context Protocol-server wordt. Chrome 146 Canary verscheepte een flag-preview. Edge 147 volgde in maart 2026. De W3C-community-draft verscheen op 2026-04-23.
Ik ben fan, maar ook realistisch over timing. De spec zelf vermeldt: “Het is geen W3C-standaard en staat niet op het W3C-standaardtraject.” Geen grote LLM-leverancier heeft gedocumenteerd WebMCP-tools te consumeren. Cloudflare telde wereldwijd minder dan 15 sites met MCP Server Cards. Dit is op z’n best een verhaal voor over 2–5 jaar.
“De webbrowser is ontworpen voor menselijke gebruikers en developers, niet voor agentische AI-systemen. De meeste webcontent is visueel, met dynamische elementen, complexe layouts en interactie die programmatische toegang bemoeilijkt.”
— Cobus Greyling, The Future of Web Browsing AI Agents
Greylings punt: de agent-friendly checklist (dit artikel) is een workaround voor een fundamentele mismatch die standaarden als WebMCP proberen op te lossen. Misschien heeft hij gelijk. Of WebMCP wint, of llms.txt en Microsofts NLWeb, of iets nieuws alles opslokt—ik weet het niet. Wat ik wel weet: de prioriteitenpiramide hierboven is het werk voor nu, terwijl de standaardlaag uitkristalliseert. Onze visie staat in agentic SEO workflows.
Een site die betrouwbaar gelezen en gebruikt kan worden door AI-agenten (Claude computer-use, OpenAI Operator, Project Mariner, Playwright-crawlers) én mensen. Cruciaal is dat interactieve elementen zich duidelijk tonen via de accessibility-tree, de layout niet verschuift terwijl de agent werkt, en belangrijke content server-gerenderd is zodat crawlers zonder JavaScript die kunnen lezen.
Agenten gebruiken één of meer van drie inputmodaliteiten: screenshots, ruwe HTML of de accessibility-tree. Screenshot-only-agenten (Anthropic computer-use) redeneren in pixels en missen targets onder ~8 px². DOM-bewuste agenten (Project Mariner, Operator) leggen elementdata erbovenop. Accessibility-tree-first-agenten (browser-use, Playwright-crawlers) krijgen een schone structuur maar missen alles wat niet semantisch is blootgelegd.
Bing bevestigt dat schema Copilot helpt content te begrijpen. Google zegt dat structured data voordeel geeft in zoekresultaten. Hard bewijs dat schema AI-citatie-ratio’s verhoogt is gemengd: één studie vond geen correlatie, een andere zag 61,7% citaties bij attribute-rijke schema. Zie het als nuttig voor AI-search, niet als gegarandeerde multiplier.
Een voorgestelde bestandsindeling (vergelijkbaar met robots.txt) die AI-crawlers vertelt waar ze je belangrijke content in schone vorm vinden. Ruim 844.000 sites hadden er in oktober 2025 één. Adoptie is hoog, consumptie laag: Google’s John Mueller en Gary Illyes zeiden publiekelijk dat geen groot AI-systeem het als operationeel signaal gebruikt. Publiceer het als je tien vrije minuten hebt; prioriteer het niet boven je gestylde-div-knoppen fixen.
De snelste route: een audit van vijf minuten. Draai onze agent-ready-check, open Chrome DevTools’ Accessibility-paneel, run een Lighthouse-rapport en een code-scan met de vibe-coded-tool. Die vier samen tonen het grootste issue op je site. Fix dat ene ding en pak dan het volgende.
AI-agenten lezen je site via screenshots, de DOM en de accessibility-tree, in wisselende combinaties per leverancier. De meeste fixes zijn toegankelijkheids-fixes die je toch al hoort te doen: semantische elementen, toegankelijke namen, stabiele layout, server-gerenderde content. De standaardlaag (WebMCP, llms.txt, NLWeb) is echt maar traag; de onsexy fixes zijn urgent.
Draai onze gratis agent-readiness-check om te zien hoe leesbaar je site is voor ChatGPT, Claude en Perplexity. Je krijgt te zien welke CTA’s de agent miste, welke knoppen verdwenen uit de accessibility-tree en welke layout-shifts kliks opeten. Het is de tool die ik had willen hebben op de dag dat GPT onze hover-states niet zag.
no credit card required
No related articles found.