TECHNISCHE SEO PROTOCOL & STANDAARDEN 13 apr. 2026 5 min leestijd

Caching strategieën voor websites die AI-bots bedienen

Reinier Sierag
Reinier Sierag Oprichter Kobalt
Caching strategieën voor websites die AI-bots bedienen — Technische SEO

De drie lagen van een effectieve caching-strategie

Ik ga je een geheim vertellen dat eigenlijk helemaal geen geheim is: de meeste trage websites zijn niet traag vanwege slechte code. Ze zijn traag vanwege afwezige of verkeerd geconfigureerde caching.

Caching is gelaagd. Er is geen magische knop die alles oplost. Een goed werkende caching-infrastructuur bestaat uit drie lagen die samenwerken.

De eerste laag: object caching (Redis), dicht bij je applicatie. Razendsnel, microseconden. De tweede laag: full-page caching (Nginx of Varnish), die complete HTML-responses opslaat. Milliseconden. De derde laag: CDN-caching aan de rand van het netwerk. Voor de eindgebruiker het snelst van allemaal, omdat het verzoek je origin-server nooit bereikt.

Die volgorde is ook de volgorde van impact. Begin bij laag een. Werk naar buiten.

BELANGRIJK INZICHT

AI-crawlers gedragen zich als onbekende bezoekers: geen cookies, geen sessietokens, geen authenticatie. Ze zien altijd de anonieme versie van je pagina. Zorg er dus voor dat die anonieme versie gecached wordt en correct is. Dit punt wordt verbazingwekkend vaak over het hoofd gezien.

Object caching met Redis

Redis is mijn favoriete stuk infrastructuur. Dat klinkt misschien raar (wie heeft er een favoriete cache-laag?), maar als je twintig jaar lang hebt gezien hoe databasequeries websites traag maken, dan leer je Redis waarderen.

Object caching slaat resultaten van databasequeries en zware berekeningen op in het geheugen. Bij de volgende request wordt de gecachte waarde gebruikt. In Laravel configureer je Redis als cache-driver in je `.env` en gebruik je de `Cache`-facade. Bij WordPress installeer je Redis Object Cache.

  • Stel zinvolle TTL-waarden in. Productdata die zelden verandert: een uur of meer. Voorraadstatus: kortere TTL. Logisch nadenken, niet alles op dezelfde waarde gooien.
  • Cache selectief. Niet alles hoeft gecached. Focus op de queries die het vaakst worden uitgevoerd en het langst duren.
  • Implementeer cache-invalidatie. Product bijgewerkt? Cache voor die entry clearen. Event-gedreven, niet "elke nacht alles weggooien".
  • Monitor cache hit rates. Onder de 70 procent? Dan is er iets mis met je strategie of je TTL-waarden.

Full-page caching voor HTML-responses

Full-page caching slaat de complete HTML-output op. Voor anonieme bezoekers en AI-crawlers is dit de meest effectieve techniek. De PHP-applicatie hoeft niets te doen. De webserver serveert de gecachte HTML direct.

Bij Kobalt gebruiken we Nginx met FastCGI cache. Cache-sleutels op basis van URL, host en schema, maar expliciet zonder cookies of sessievariabelen voor anonieme bezoekers.

Cruciale headers: `Cache-Control: public, max-age=3600` voor pagina's die een uur gecached mogen worden. `CDN-Cache-Control` voor CDN-specifieke instructies. En let op: als je `Cache-Control: no-cache` of `private` stuurt, instrueer je niet alleen browsers maar ook CDN's en AI-crawlers om niet te cachen. Dat is zelden wat je wilt voor publieke pagina's.

CDN-configuratie en edge caching

Een CDN plaatst kopieen van je pagina's op servers wereldwijd. Bezoekers en crawlers krijgen content van de dichtstbijzijnde server. De latentie daalt drastisch.

Maar wacht. Is dat eigenlijk wel zo simpel?

Niet helemaal. Er zijn valkuilen.

  1. Configureer cache-regels per content-type. Statische assets (CSS, JS, afbeeldingen): maanden cachen. HTML-pagina's: korter, afhankelijk van hoe vaak de content verandert.
  2. Gebruik cache-purging bij content-updates. Pagina bijgewerkt? Purge-request naar je CDN, zodat de nieuwe versie direct wordt geserveerd.
  3. Activeer Brotli-compressie. Beter dan gzip, ondersteund door alle moderne browsers en HTTP-clients. Gratis winst.
  4. Stel correcte Vary-headers in. Meertalige site? Gebruik `Vary: Accept-Language` om separate cache-entries per taal te maken. Anders serveer je Nederlandse content aan Engelse bezoekers. Dat is me overkomen. Het was niet mijn beste moment.

Cache warming: de stille held

Cache warming is het proactief opbouwen van je cache voordat bezoekers en crawlers komen. Zonder cache warming kan een AI-crawler aankomen op het moment dat je cache leeg is (na een deployment of TTL-expiratie). Dan genereert je origin-server een koude, trage response. Precies op het moment dat het ertoe doet.

Bij Kobalt implementeren we cache warming als onderdeel van de deployment-pipeline. Na elke deployment draait een script dat de meest bezochte pagina's opvraagt en de cache opbouwt. De site gaat pas live als de cache warm is. Dat klinkt als een detail, maar het maakt een enorm verschil.

RESULTAAT

Voor een SaaS-klant met veel AI-bot verkeer implementeerden we een cache warming-script dat elke nacht de complete sitemap doorloopt. De cache hit rate steeg naar 94%. De gemiddelde TTFB daalde naar 45ms. AI-crawlers zagen nooit meer een koude cache. Dat is het verschil tussen "we doen aan caching" en "we doen caching goed".

Caching is niet ingewikkeld, maar het vereist aandacht en discipline. De moeite die je er eenmalig in steekt, betaalt zich terug bij elke bezoeker en elke bot. Wil je weten of jouw caching goed werkt? Onze gratis AEO-scan meet het voor je.

Veelgestelde vragen

Kan caching problemen veroorzaken voor gepersonaliseerde content?

Ja, als je het verkeerd configureert. Full-page caching hoort alleen op pagina's die voor alle anonieme bezoekers gelijk zijn. Winkelwagentjes, accountpagina's, gepersonaliseerde aanbevelingen: die mag je nooit full-page cachen. Gebruik cookies of authenticatie-checks in je cache-sleutel om onderscheid te maken.

Hoe weet ik of mijn caching correct werkt voor AI-crawlers?

Check je server-logboeken op requests van GPTBot, ClaudeBot en PerplexityBot. Let op responsietijden: als gecachte requests significant sneller zijn dan niet-gecachte, werkt het. Controleer ook via `curl -I` of de `X-Cache: HIT` header aanwezig is bij gecachte responses.

Wat is de optimale TTL voor HTML-pagina's?

Hangt van je content af. Een blogpost die maanden niet verandert: 24 uur of meer. Een homepage met actuele promoties: 30 tot 60 minuten. De gouden regel: combineer een langere TTL met actieve cache-invalidatie bij updates. Dan krijg je de beste balans tussen snelheid en actualiteit.

Hoe scoort jouw website op AI-gereedheid?

Krijg binnen 30 seconden je AEO-score en ontdek wat je kunt verbeteren.

Gratis scan

DEEL DIT ARTIKEL

LINKEDIN X

GERELATEERDE ARTIKELEN