Kunnen AI-crawlers door JavaScript gerenderde content lezen?
Vaak niet. Googlebot rendert JavaScript in een latere stap, maar de meeste AI-crawlers documenteren dat niet, en Google zelf merkt op dat niet alle bots JavaScript kunnen uitvoeren. Verschijnt je tekst pas nadat scripts zijn uitgevoerd, dan kan een AI-crawler een lege pagina krijgen. Lever de hoofdcontent in de oorspronkelijke HTML met server-side rendering of statische pagina's.
Single-page apps en clientside frameworks zijn overal, en in een browser zien ze er prima uit. Een crawler die alleen de HTML leest die je server stuurt, ziet iets anders: een <div id="root"></div>, een paar scripttags en weinig of geen tekst. Voor AI-antwoorden heeft die pagina niets om te citeren.
Op deze pagina
- Waarom missen AI-crawlers JavaScript-content?
- Hoe controleer ik wat een crawler krijgt?
- Welke pagina's lopen het meeste risico?
- Hoe los ik content op die alleen via JavaScript bestaat?
- Blokkeren login-, toestemmings- en betaalmuurschermen AI-crawlers ook?
- Hoe herkent AISeeWhy pagina's die alleen met JavaScript werken?
Waarom missen AI-crawlers JavaScript-content?
JavaScript uitvoeren is duur. Een crawler moet de scripts downloaden, in een browser-engine uitvoeren en wachten tot data is geladen. Google doet dat voor Zoeken: het crawlt, zet pagina's in de wachtrij voor rendering en rendert ze met headless Chromium wanneer er capaciteit is. Toch raadt Google server-side rendering of prerendering aan, omdat dat sneller is voor gebruikers en crawlers, en merkt het op dat niet alle bots JavaScript kunnen uitvoeren.
OpenAI, Anthropic en Perplexity vermelden in hun crawlerdocumentatie niet dat hun agents JavaScript uitvoeren. Apple zegt dat Applebot pagina's in een browser kan renderen. Zonder duidelijke verklaring is de veilige aanname voor AI-crawlers dat ze alleen de oorspronkelijke HTML lezen.
Hoe controleer ik wat een crawler krijgt?
Kijk naar de ruwe HTML, niet naar de gerenderde pagina. De ontwikkelaarstools van de browser tonen de DOM nadat de scripts zijn uitgevoerd, en dat is niet wat een crawler krijgt. Gebruik de paginabron, of sla de ruwe HTML via de opdrachtregel op en doorzoek die:
curl -s -o page.html \
-A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.4; +https://openai.com/gptbot" \
https://example.com/page
# Is a sentence from your main text in the raw HTML?
grep -c "a sentence from your main content" page.html
Een resultaat van 0 betekent dat de zin niet in de HTML staat die de server stuurde, dus crawlers die geen scripts uitvoeren, vinden hem niet. Een blik op het bestand vertelt de rest: een server-side gerenderd artikel heeft daar de volledige tekst; een clientside schil heeft een leeg root-element en een lijst scripts.
Welke pagina's lopen het meeste risico?
- Single-page apps met React, Vue, Angular of Svelte die alles in de browser renderen.
- Pagina's die hun hoofdtekst na het laden van een API ophalen, zoals productdetails, prijzen of reviews.
- Content in tabs, accordeons of “meer laden”-secties die pas bij een klik wordt opgevraagd.
- Pagina's achter een login, een betaalmuur of een toestemmingsmuur die de crawler niet kan passeren.
- Pagina's die
noindexof de canonieke URL alleen via JavaScript instellen. Google waarschuwt dat het rendering helemaal kan overslaan als hetnoindexin de oorspronkelijke HTML ziet.
Hoe los ik content op die alleen via JavaScript bestaat?
De oplossing is de belangrijke content in het eerste antwoord te sturen. Kies de lichtste optie die je stack toelaat:
- Server-side rendering (SSR): frameworks zoals Next.js, Nuxt, SvelteKit en Angular SSR renderen de pagina op de server en hydrateren hem in de browser.
- Statische generatie of prerendering: bouw de HTML tijdens de deployment voor pagina's die zelden veranderen, zoals artikelen, documentatie en landingspagina's.
- Progressive enhancement: zet tekst, koppen, links, prijzen en JSON-LD in de HTML en gebruik JavaScript alleen voor interactie.
- Neem op wat ertoe doet: als tabs content verbergen, zet dan alles in de HTML en schakel de zichtbaarheid om met CSS of script, in plaats van het bij een klik op te halen.
Je hoeft niet een hele app in één keer om te zetten. Begin met de pagina's die je geciteerd wilt zien: artikelen, documentatie, product- en prijspagina's. Accountgedeelten en dashboards kunnen clientside blijven, want die zitten toch achter een login.
Voorkom dat je crawlers op basis van hun user agent een andere pagina geeft dan gebruikers. Voor iedereen dezelfde HTML renderen is makkelijker te onderhouden en neemt elke twijfel over cloaking weg.
Blokkeren login-, toestemmings- en betaalmuurschermen AI-crawlers ook?
Ja. Een crawler logt niet in, klikt geen cookiebanner weg en lost geen challenges op. Anthropic stelt dat zijn bots CAPTCHA's niet proberen te omzeilen. Vervangt een toestemmingsmanager de pagina in de HTML door een schermvullende overlay, of stuurt hij nieuwe bezoekers eerst door naar een toestemmingspagina, dan krijgt de crawler dat in plaats van je content.
Zorg dat openbare pagina's hun content in de HTML renderen, ongeacht de toestemmingsstatus, met de banner als overlay en niet als vervanging. Houd pagina's die je geciteerd wilt zien buiten loginmuren en controleer dat een crawler niet wordt doorgestuurd naar een aanmeldpagina.
Hoe herkent AISeeWhy pagina's die alleen met JavaScript werken?
AISeeWhy leest de oorspronkelijke HTML zoals elke crawler hem krijgt, zonder scripts uit te voeren. Heeft een pagina bijna geen zichtbare tekst maar wel een framework-root-element en scripts, dan meldt het een P1-bevinding dat de content JavaScript nodig heeft. Het markeert ook redirects die crawlers ergens anders heen sturen dan naar de pagina die een browser krijgt.
Veelgestelde vragen
Rendert Googlebot JavaScript?
Ja. Google crawlt de HTML, zet pagina's in de wachtrij voor rendering en rendert ze met headless Chromium wanneer er capaciteit is. Google raadt nog steeds server-side rendering of prerendering aan.
Voeren de crawlers van ChatGPT, Claude en Perplexity JavaScript uit?
De crawlerdocumentatie van de aanbieders zegt dat niet. Ga er, totdat een aanbieder anders aangeeft, vanuit dat de crawler de oorspronkelijke HTML leest en zorg dat je content daarin staat.
Is dynamic rendering voor bots een goed idee?
Als noodoplossing werkt het, maar het voegt een tweede renderpad toe dat je moet onderhouden. Server-side rendering of statische HTML levert voor iedereen dezelfde content en is op de lange termijn de eenvoudigere oplossing.
Telt JSON-LD dat met JavaScript is toegevoegd?
Google kan het na rendering lezen, maar crawlers die geen scripts uitvoeren zien het niet. Zet JSON-LD in de oorspronkelijke HTML.
Bronnen
- Google Search Central: basisprincipes van JavaScript-SEO
- Apple: over Applebot
- OpenAI: overzicht van de OpenAI-crawlers
- Anthropic: crawlt Anthropic gegevens van het web, en hoe kunnen site-eigenaren de crawler blokkeren?
- Perplexity: Perplexity-crawlers