HTTP/2 en HTTP/3: snellere protocollen voor AI-crawlers

Waarom het protocol ertoe doet

De meeste discussies over AI-gereedheid gaan over content. llms.txt, Schema.org, leesbaarheid, E-E-A-T. Allemaal terecht.

Maar er is een laag eronder waar bijna niemand het over heeft: het HTTP-protocol. De manier waarop een crawler überhaupt bij je content komt. En die laag maakt een groter verschil dan je denkt.

HTTP/1.1 is het protocol dat het web groot heeft gemaakt. Het is ook meer dan 25 jaar oud. Elke request vereist een aparte verbinding of wacht zijn beurt af in een wachtrij. Dat was prima toen webpagina's uit tien bestanden bestonden. Maar moderne websites laden honderden resources. En AI-crawlers die meerdere pagina's tegelijk willen ophalen, lopen keihard tegen die limieten aan.

Ik had hier zelf ook lang niet over nagedacht, eerlijk gezegd. Tot ik bij een klant zag dat de crawler structureel maar de helft van de pagina's ophaalde. Niet door rate limiting. Niet door robots.txt. Gewoon door een trage protocol-laag.

HTTP/2: multiplexing als gamechanger

HTTP/2 werd in 2015 gestandaardiseerd en lost het grootste probleem van HTTP/1.1 op: head-of-line blocking. In HTTP/1.1 moest elke request wachten op de vorige. In HTTP/2 kunnen meerdere requests gelijktijdig over één TCP-verbinding lopen. Multiplexing.

Voor AI-crawlers betekent dit: minder verbindingen nodig, minder TCP-handshakes, minder overhead. Een crawler die meerdere pagina's van jouw domein wil ophalen, doet dat met HTTP/2 significant efficiënter. Meer pagina's in minder tijd. Hogere kans dat jouw content volledig geïndexeerd wordt.

• Multiplexing: meerdere requests parallel over één verbinding.
• Header compression (HPACK): scheelt bandbreedte bij herhaalde requests.
• Server push: de server stuurt resources proactief naar de client. Handig voor kritische CSS en JS.
• Prioritering: de client geeft aan welke resources prioriteit hebben.

HTTP/3 en QUIC: het protocol dat pakketverlies overleeft

HTTP/3 gaat een stap verder. Waar HTTP/2 nog op TCP draait, gebruikt HTTP/3 QUIC: een transportprotocol gebouwd op UDP.

Waarom is dat belangrijk? Bij HTTP/2 over TCP geldt: als één pakket verloren gaat, stopt de hele verbinding totdat dat pakket opnieuw verstuurd is. TCP head-of-line blocking. QUIC lost dit op door elke stream onafhankelijk te houden. Een verloren pakket in stream A blokkeert stream B niet.

Voor AI-crawlers die vanuit datacenters werken (soms met hoge retransmissie-rates) heeft QUIC een meetbaar effect. Bovendien: snellere verbindingsopbouw. 0-RTT voor bekende servers, tegenover minimaal 1-RTT voor TCP + TLS.

Klinkt als details? Dat is het ook. Maar het zijn de details die het verschil maken als een crawler besluit of hij 50 of 200 pagina's van je site ophaalt.

Hoe schakel je het in?

HTTP/2 inschakelen is eenvoudig. HTTP/3 vergt iets meer werk, maar is goed gedocumenteerd.

Nginx

Voeg http2 toe aan het listen-directief in je server-block. Voor HTTP/3 heb je een extra module (quic) en een UDP-listener op poort 443 nodig. Vergeet de Alt-Svc header niet zodat clients weten dat HTTP/3 beschikbaar is.

Apache

Apache ondersteunt HTTP/2 via mod_http2. Activeer met LoadModule en voeg Protocols h2 http/1.1 toe aan je VirtualHost. HTTP/3 is nog experimenteel in Apache. Gebruik voor HTTP/3 liever Nginx of een CDN.

Cloudflare (de makkelijke weg)

Niet aan serverbeheer willen zitten? Cloudflare ondersteunt standaard HTTP/2 en HTTP/3 en termineert de verbinding bij het edge-netwerk. Jouw originserver kan gewoon HTTP/1.1 blijven spreken. Cloudflare doet de rest.

Dit is de oplossing die ik het vaakst adviseer aan klanten zonder ops-team. Soms moet je gewoon een bunt leggen in plaats van een homerun slaan. Cloudflare is die bunt: niet spectaculair, maar effectief.

Veelgestelde vragen

Het protocol is de fundering van je huis. Je kunt de mooiste kamers hebben, maar als de fundering niet deugt, maakt het niet uit hoe mooi je hebt geschilderd.