Naar inhoud springen
SilktideHelp

Inhoud leesbaar zonder JavaScript

De hoofdinhoud van je pagina – de alinea’s, koppen, tabellen en prijzen waarvoor een bezoeker komt – moet aanwezig zijn in de HTML die je server bij het eerste verzoek terugstuurt. Verbetering met is prima. Inhoud die alleen verschijnt nadat JavaScript is uitgevoerd, is onzichtbaar voor de meeste AI-crawlers en daarmee ook voor de assistenten die daaruit citeren.

Stel in dit hele document dat Fernwood zijn marketingsite heeft herbouwd als een single-page app (SPA). In een browser ziet het er compleet uit. Paginabron toont een bijna lege <div id="root"></div>. Die lege huls is wat GPTBot, ClaudeBot, PerplexityBot en vergelijkbare crawlers ontvangen.

Waarom dit werkt

Traditionele zoekmachines hebben dit grotendeels opgelost: Google rendert JavaScript voordat het indexeert. Antwoordsystemen nog niet. De crawlers die ChatGPT, Claude, Perplexity en vergelijkbare systemen voeden, halen doorgaans de ruwe HTML-respons op en stoppen dan – ze wachten niet tot je framework hydrateert, voeren je bundel niet uit en volgen geen routes aan de clientzijde. Silktides eigen crawl-vergelijking (gerenderde pagina vs. ruwe HTML) is precies op dat gedrag gebouwd; zie Inhoud zonder JavaScript.

De fout treedt stil en volledig op:

  • Een pagina die goed scoort in Google kan volledig ontbreken in AI-antwoorden, omdat de assistenten de tekst nooit hebben ontvangen.
  • Elke andere AEO-investering op die pagina – gestructureerde gegevens, machineleesbare data, antwoord-eerst-schrijven – is waardeloos als de crawler nooit de inhoud ziet waarnaar die signalen verwijzen.
  • Bezoekers bij wie scripts falen of worden geblokkeerd, zien dezelfde lege huls, en de First Contentful Paint (FCP) lijdt zelfs wanneer scripts uiteindelijk slagen.

Dit is een probleem van sitearchitectuur, geen probleem van paginabewerking. Eén URL met de hand herstellen repareert niet het sjabloon dat de volgende honderd oplevert.

Zo controleer je wat een crawler ziet

Bevestig het probleem voordat je iets wijzigt. Drie manieren, in volgorde van kracht:

  1. Silktides controle. Inhoud zonder JavaScript vergelijkt de betekenisvolle hoofdtekst van de gerenderde pagina met de ruwe HTML die tijdens het crawlen is vastgelegd. Het markeert pagina’s waar de ruwe tekst zowel onder ~10% van de gerenderde tekst ligt als absoluut gezien piepklein is – een echte lege huls, niet een pagina die zichzelf slechts verrijkt.
  2. Bekijk de bron, niet DevTools Elementen. In de browser toont 'Paginabron weergeven' wat de server heeft gestuurd. Het deelvenster Elementen toont de DOM nadat JavaScript is uitgevoerd. Als je artikeltekst in Elementen staat maar ontbreekt in Paginabron, zullen crawlers die JS overslaan deze niet zien.
  3. Haal op zonder browser. Vanuit een terminal: curl -sL https:\/\/fernwood.example\/pricing | head. Of gebruik een tekstbrowser. Als de prijstabel in die output ontbreekt, ontbreekt hij ook voor de crawler.

Bevestig ook dat de crawler überhaupt toegang heeft – een perfecte HTML-respons is nutteloos als robots.txt de AI-crawler blokkeert, of als een firewall deze in de praktijk blokkeert (AI-crawlers in de praktijk geblokkeerd).

Hoe los je dit op

Kies de aanpak die bij je stack past. Alle drie leveren hetzelfde resultaat: de eerste HTML-respons bevat de inhoud.

1. Server-side rendering (SSR)

De server rendert elke pagina op aanvraag naar HTML; JavaScript hydrateert daarna voor interactiviteit. Dit is het standaardpad voor frameworks die dit al ondersteunen:

  • Next.js – gebruik de App Router met Server Components, of getServerSideProps / getStaticProps in de Pages Router. Lever geen client-only root die inhoud pas na mount ophaalt.
  • Nuxt – universal / SSR-modus (standaard), niet ssr: false.
  • Remix, SvelteKit, Astro (SSR-modus) en equivalenten – zelfde idee: de documentrespons bevat de hoofdtekst.

Vuistregel: als een useEffect / onMounted-fetch het artikel op de pagina plaatst, verplaats die datafetch naar de server.

2. Static site generation (SSG)

Bouw pagina’s vooraf als platte HTML bij publicatie. Ideaal voor inhoud die niet per bezoeker verandert – blogposts, documentatie, marketingpagina’s, prijzen. Astro, Eleventy, Hugo, Next.js output: 'export', en Nuxt generate produceren allemaal bestanden die een crawler volledig zonder JavaScript kan lezen.

SSG is meestal de goedkoopste winst voor marketing- en contentsites: geen renderkosten per verzoek, en de HTML op schijf is precies wat de crawler krijgt.

3. Pre-rendering als brug

Als je het framework nog niet kunt wijzigen, kan een pre-renderingdienst of build-stap een gerenderde HTML-snapshot aan crawlers (en vaak aan eerste bezoekers) serveren terwijl de SPA voor interactieve sessies blijft draaien. Beschouw dit als een brug, niet als eindbestemming: snapshot-actualiteit, cache-invalidatie en geauthenticeerde routes worden allemaal een onderhoudslast. Geef de voorkeur aan het corrigeren van de rendermodus zodra dat kan.

Googles eigen richtlijnen over JavaScript-SEO en web.dev’s Rendering op het web behandelen hetzelfde spectrum – SSR, SSG en progressive enhancement – vanuit het zoekmachineperspectief.

Wat in de eerste HTML moet staan

Niet elke pixel. De inhoud die een citaat zou weergeven:

  • Het artikel- of paginalichaam – koppen, alinea’s, lijsten, tabellen.
  • Prijzen, limieten en andere feiten die je wilt dat assistenten herhalen.
  • Gestructureerde gegevens in een <script type=\"application\/ld+json\">-blok in de initiële HTML – JSON‑LD dat pas na hydratatie wordt geïnjecteerd is even onzichtbaar als de lopende tekst.
  • Canonieke URL, titel en metabeschrijving in <head>.

JavaScript kan nog steeds de menu’s, personalisatie, grafieken die een al aanwezige tabel verrijken, en progressieve functionaliteit beheren. De Silktide-controle is bewust soepel over verrijking: pagina’s die hun hoofdinhoud als HTML serveren en daar gedrag bovenop leggen, slagen.

Veelvoorkomende faalpatronen

  • Client-only SPA’s – Create React App, Vite-SPA’s en vergelijkbare setups die een lege huls leveren en routes in de browser ophalen. De oplossing is SSR/SSG, niet meer clientcode.
  • Inhoud achter “Meer laden” of tabbladen die nooit in HTML verschijnen. Als de enige manier om sectie drie te bereiken een klik is die deze ophaalt, bereiken crawlers sectie drie nooit. Gebruik liever echte URL’s of neem de inhoud op in de initiële respons.
  • “Het werkt in Google, dus we zitten goed.” Googlebot-rendering is geen vervanging voor leesbaarheid door AI-crawlers. Google wel halen en bij GPTBot falen is een veelvoorkomende, onzichtbare tweedeling.
  • De crawler blokkeren en JavaScript de schuld geven. Controleer altijd toegang voor AI-crawlers en effectieve bereikbaarheid naast deze techniek.

Hoe Silktide helpt

Als Silktide je inhoud niet zonder JavaScript kan lezen, kunnen de assistenten die jou als bron noemen dat ook niet.

Gerelateerd

Laatst bijgewerkt

Was deze pagina nuttig?

Inhoud leesbaar zonder JavaScript | Silktide Help