AI-zoekagents zoals ChatGPT Atlas bekijken een website niet zoals een menselijke bezoeker. Ze lezen de accessibility tree, de gestructureerde laag die browsers al decennia opbouwen voor screenreaders. Nu die laag ook door AI-agents wordt gebruikt om pagina's te begrijpen en straks via WebMCP zelfs acties uit te voeren, duiken SEO-teams er actief in om fouten op te sporen.
OpenAI bevestigt in de Publishers and Developers FAQ dat ChatGPT Atlas paginastructuur en interactieve elementen interpreteert via ARIA-rollen en labels. Microsoft's Playwright MCP, een veelgebruikt framework voor agent-browsing, werkt bewust met accessibility snapshots in plaats van screenshots. Dat maakt de accessibility tree de nieuwe, onzichtbare plek waar zichtbaarheid in AI-zoekresultaten wordt beslist.
Wat de accessibility tree precies doet
De accessibility tree ontstaat automatisch uit de DOM van een pagina. Elk element krijgt een rol, een naam en een status, informatie die een screenreader hardop voorleest aan een gebruiker die de pagina niet ziet.
Een AI-agent doet in feite hetzelfde: hij scant deze laag om te bepalen wat een knop doet, welk formulierveld waarvoor dient en welke tekst als hoofdcontent geldt. Ontbreekt die informatie, dan blijft de pagina voor een agent net zo onduidelijk als voor een screenreadergebruiker.
Tien praktijkchecks die SEO's nu uitvoeren
Vanuit deze inzichten is een reeks concrete audits ontstaan die technische SEO-teams inmiddels toepassen op belangrijke pagina's.
- Een agent-leesbaarheidsaudit op de belangrijkste conversiepagina's
- Opsporen van content die wel in de DOM staat maar niet in de tree terechtkomt door JavaScript-rendering
- Testen of conversiepaden straks bruikbaar zijn voor agentacties via WebMCP
- Concurrenten benchmarken op machineleesbaarheid
- Controle van kop- en landmarkstructuur, zoals navigatie- en hoofdcontentgebieden
- Ankerteksten herstellen via de toegankelijke naam van een link
- Afbeeldingen en alt-teksten checken op bruikbaarheid voor AI-extractie
- ARIA-snapshots opnemen in CI/CD-pijplijnen als regressietest
- Voor- en na-vergelijkingen van de tree bij een sitemigratie
- Toegankelijkheidsfixes prioriteren op basis van SEO-impact
De meest fundamentele check is de eerste: een pass/fail-lijst per pagina waarbij elke primaire call-to-action een knop of link met duidelijke naam moet zijn, elk formulierveld een gekoppeld label nodig heeft en navigatie en hoofdcontent in eigen landmarks staan.
Toegankelijkheid eerst, SEO-winst als bijeffect
Wie aan de accessibility tree gaat sleutelen puur voor SEO-doeleinden, vergeet waar deze laag oorspronkelijk voor bedoeld is. De W3C-richtlijnen voor webtoegankelijkheid, inclusief het nieuwe WCAG 3.0-concept, zijn geschreven voor mensen die op assistive technology vertrouwen.
Slordige ARIA-labels verwarren niet alleen een AI-agent, ze misleiden ook een screenreadergebruiker die niet kan controleren of de informatie klopt. Alleen al in 2025 werden in de Verenigde Staten meer dan 8.600 toegankelijkheidsrechtszaken aangespannen, en sommige kantoren scannen sites systematisch op zoek naar overtredingen.
Bedrijven met een groot publiek of een gereguleerde sector doen er goed aan een gecertificeerd accessibility-specialist in te schakelen. SEO-winst mag daarbij hooguit een bijeffect zijn, nooit het startpunt.
Zo controleer je jouw eigen site
Twee methoden zijn direct bruikbaar zonder technische voorkennis. Gratis online tools kunnen de volledige tree van een live URL vastleggen en als JSON-bestand exporteren voor snelle analyse.
Wie liever precies wil zien welke broncode een probleem veroorzaakt, gebruikt Chrome DevTools. Open het Elements-paneel, klik op de Accessibility-zijbalk en schakel de optie voor de volledige-pagina accessibility tree in om elk element te inspecteren op rol, naam en status.
Bron: Search Engine Land