QR-codes en AI-crawlers: bereikt ChatGPT jouw landingspagina wel?

Typ een merknaam in ChatGPT search of Perplexity en je krijgt meteen een antwoord, maar de eerlijke vraag achter dat instinct is een andere: bereikt de crawler achter dat antwoord ooit daadwerkelijk de pagina waar je QR-code mensen naartoe moest sturen? Een QR-code is op zichzelf geen stuk content. Het is een vertaallaag van fysiek object naar URL, die via een of meerdere HTTP-redirects wordt opgelost voordat een browser, of een bot, ooit een landingspagina te zien krijgt. Agencies hebben jarenlang die landingspagina geoptimaliseerd voor Google. Veel minder vaak is de vraag gesteld of de redirectketen ervoor überhaupt zichtbaar is voor GPTBot, ClaudeBot, PerplexityBot, of de retrieval-bots die een live ChatGPT- of Perplexity-vraag beantwoorden, en dat is nou net de laag die bepaalt of de campagne van een klant zichtbaar wordt wanneer diens eigen klanten een AI-assistent ernaar vragen.

Waarom deze vraag in 2026 de moeite waard is

Bot-verkeer is geen afrondingsfout meer naast menselijke bezoekers. De Radar-data van Cloudflare liet automatische requests uitkomen op 57,5 procent van het HTML-verkeer over het hele netwerk in juni 2026, de eerste keer dat bots het aantal mensen in die meting overstegen. Een jaar eerder was slechts 22 procent van de crawleractiviteit die Cloudflare classificeerde bedoeld voor AI-training; medio 2026 was dat gestegen naar 52 procent, met daarnaast een snelgroeiend aandeel voor realtime AI-zoekopdrachten en agent-fetches. De onafhankelijke cijfers van Fastly wijzen dezelfde kant op: het volume aan AI-requests op hun netwerk groeide alleen al tussen januari en mei 2026 met ongeveer 30 procent, zo'n 6,5 keer sneller dan de groei van menselijk verkeer in diezelfde maanden.

Niets van dat verkeer scant een QR-code, want een QR-code kan niet gecrawld worden, alleen gescand. Al dat verkeer crawlt URL's. De echte vraag voor een agency is dus niet "kan een AI een QR-code lezen" maar "komt de redirectketen die een QR-code in gang zet ergens uit waar deze crawlers ook daadwerkelijk kunnen komen, de pagina kunnen parsen en er uiteindelijk naar kunnen verwijzen." Dat is een oplosbare technische vraag, en de meeste agencies hebben het antwoord voor hun eigen campagnes nog nooit gecontroleerd.

Wat een AI-crawler echt doet met een redirect

De drie grote AI-labs draaien elk meer dan één crawler, en dat onderscheid is belangrijk. OpenAI beheert GPTBot, die trainingsdata verzamelt; OAI-SearchBot, die pagina's indexeert zodat ze kunnen opduiken in de zoekresultaten van ChatGPT; en ChatGPT-User, die in realtime in actie komt wanneer iemand ChatGPT een live vraag stelt en die een pagina gaat ophalen. Anthropic doet hetzelfde met ClaudeBot voor training, Claude-SearchBot voor indexering, en Claude-User voor live, door de gebruiker getriggerde fetches. Perplexity documenteert PerplexityBot als zijn indexerende crawler (uitdrukkelijk niet gebruikt om de onderliggende modellen te trainen) en Perplexity-User als de realtime fetcher die aan een concrete zoekopdracht hangt. Google vouwt AI Overviews in bij de gewone Googlebot-crawl en reserveert een apart token, Google-Extended, uitsluitend voor de vraag of al gecrawlde content gebruikt mag worden om Gemini en Vertex AI te trainen of te gronden. Het blokkeren van Google-Extended haalt een pagina niet weg uit Search of uit AI Overviews; alleen het blokkeren van Googlebot zelf doet dat.

Geen van allen rendert JavaScript

Vercels eigen analyse van netwerklogs over het gedrag van AI-crawlers liet zien dat GPTBot en ClaudeBot wel JavaScript-bestanden ophalen, in respectievelijk zo'n 12 en 24 procent van de requests, maar toonde geen enkel bewijs dat een van beide ze ook uitvoert. Dat ene gegeven sluit een hele categorie campagne-landingspagina's uit: alles waarvan de uiteindelijke content client-side wordt opgelost, achter een JavaScript-redirect zit, of via een script pas na het laden wordt ingewisseld, is functioneel leeg voor een training- of indexeringscrawler. Een pagina die er in een browser voor een mens en voor een crawler identiek uitziet, kan voor GPTBot twee compleet verschillende pagina's zijn, want die ziet alleen ooit de ruwe HTML-response.

Hop-limieten: één leverancier publiceert een getal, drie niet

Google is hier ongewoon specifiek: Googlebot volgt tot tien redirects in een keten, maar de eigen ontwikkelaarsdocumentatie van Google raadt aan direct naar de uiteindelijke bestemming door te sturen en, waar dat niet kan, een keten tot maximaal drie of vier hops te beperken. Noch OpenAI, noch Anthropic, noch Perplexity publiceert een hop-limiet voor GPTBot, ClaudeBot of PerplexityBot. Dat gat wordt voortdurend toegedekt: talloze SEO-blogs noemen een specifiek aantal hops dat deze bots zogenaamd tolereren, maar niets daarvan is terug te voeren op een bron van de leverancier zelf, en dit artikel gaat geen verzonnen cijfer herhalen. Het eerlijke standpunt is dat een agency optimaliseert tegen een ongepubliceerde, en heel goed mogelijk strengere, tolerantie dan de royale tien hops die Google toestaat, en dat is op zich al reden genoeg om een keten zo kort mogelijk te houden.

301 of 302, en waarom dat bepaalt wat onthouden wordt

De twee statuscodes dragen onder de HTTP-specificatie (RFC 9110) daadwerkelijk verschillende betekenissen, en dat is geen SEO-folklore. Een 301 vertelt elke client dat de verplaatsing permanent is, en Google's eigen documentatie bevestigt dat de indexeringspijplijn een 301 (of 308) behandelt als een signaal dat de bestemming canoniek moet worden, waarbij de status van de oorspronkelijke URL wordt overgedragen naar de nieuwe. Een 302 (of 307) signaleert een tijdelijke verplaatsing, en Google's pijplijn volgt die elke keer, maar behoudt de oorspronkelijke URL als gezaghebbend in plaats van de bestemming. Geen van de drie AI-labs documenteert of hun crawlers een 301-doel cachen en herverificatie later overslaan, tegenover het elke keer opnieuw doorlopen van een 302-keten vanaf nul. Dat is een redelijke afleiding uit de RFC en het publieke gedrag van Google, geen gedocumenteerd feit voor GPTBot, ClaudeBot of PerplexityBot. Wat wel volgt uit de onderdelen die gedocumenteerd zijn: een QR-code die naar een stabiele, evergreen bestemming wijst, is een legitiem geval voor een 301, en dynamische QR-platformen waarmee een agency de bestemming later kan wijzigen zonder opnieuw te drukken, moeten nog altijd via een zo schoon en kort mogelijke redirect oplossen als het platform toelaat, welke statuscode het ook gebruikt.

Waar de hops in een echte campagne daadwerkelijk oplopen

Een goed gebouwde dynamische QR-redirect is één hop: de code lost direct op naar het korte domein van het platform, dat in diezelfde response eventuele trackingparameters toevoegt en de bezoeker doorstuurt naar de uiteindelijke landingspagina. Dat is de vorm waar de redirects van ScanKit om heen zijn gebouwd, en het is zeer onwaarschijnlijk dat dit een crawler in de problemen brengt, gepubliceerde hop-limiet of niet. De keten wordt lang door gewoonte, niet door noodzaak: een agency hergebruikt een bit.ly-achtige shortener die het al voor social posts heeft en wijst die naar de link van het QR-platform in plaats van rechtstreeks naar de pagina van de klant, het eigen CMS van de klant voegt een eigen redirect toe zodra een pagina wordt verplaatst, en een los tool plakt er via nog een hop UTM-parameters aan vast. Elke toevoeging is onzichtbaar voor een mens op een telefoon, want een mobiele browser lost de hele keten in ruim onder een seconde op, maar niet voor een crawler die door een ongepubliceerd, mogelijk krap, hop-budget heen moet werken. Drie of vier gestapelde redirects zit al in de zone die Google risicovol noemt; bij AI-crawlers is het simpelweg ongemeten terrein. Een QR-platform en een URL-shortener lossen verschillende problemen op, en de een boven op de ander stapelen voor dezelfde link is veruit de meest voorkomende manier waarop een agency onnodige hops toevoegt.

1. De camerascan van de gedrukte QR-code.
2. Het redirectdomein van het QR-platform: één schone hop rechtstreeks naar de bestemming.
3. Een shortener van de agency of een CMS-redirect van de klant daar bovenop gestapeld: een vermijdbare extra hop, hier gemarkeerd omdat het de makkelijkste fout is om te herstellen.
4. De uiteindelijke landingspagina, bereikt en correct gelezen door een crawler.

llms.txt: een net idee, nog geen hefboom

llms.txt is een voorgestelde conventie, gepubliceerd door Jeremy Howard van Answer.AI in september 2024, die een site vraagt om zijn belangrijkste pagina's in een plain-textbestand te vermelden zodat een AI-systeem het kan lezen. Er staat geen standaardisatieorgaan achter, en de canonieke llms.txt-site zelf omschrijft het als een voorstel dat openstaat voor input van de community, niet als een aangenomen standaard. Een onderzoek onder zo'n 300.000 domeinen door SE Ranking, gepubliceerd in november 2025, vond geen meetbare correlatie tussen het hebben van een llms.txt-bestand en hoe vaak een domein werd geciteerd door AI-systemen, en het weglaten van die variabele uit hun voorspellende model verbeterde de nauwkeurigheid ervan zelfs. Geen enkel groot AI-lab heeft documentatie gepubliceerd waarin het toezegt dat zijn crawlers een llms.txt-bestand van derden lezen op het moment van een query. Niets daarvan maakt llms.txt schadelijk, en een net overzicht van de belangrijkste pagina's van een klant kost weinig moeite om te maken, maar een agency moet het niet verkopen als iets dat de AI-zichtbaarheid meetbaar verbetert. Het bewijs dat vandaag beschikbaar is, zegt dat het dat niet doet, in elk geval nog niet.

De robots.txt-tokens die er echt toe doen

Elk AI-lab documenteert zijn eigen crawler-user-agent-strings, en dat zijn de daadwerkelijke hefbomen, niet llms.txt.

• OpenAI: GPTBot (training), OAI-SearchBot (indexering voor ChatGPT search), ChatGPT-User (live, door de gebruiker getriggerde fetch; OpenAI's eigen documentatie merkt op dat robots.txt-regels hier mogelijk niet op dezelfde manier gelden als bij GPTBot).
• Anthropic: ClaudeBot (training), Claude-SearchBot (indexering), Claude-User (live fetch, zelfde realtime kanttekening), plus een niet-standaard Crawl-delay-richtlijn die Anthropic ondersteunt voor ClaudeBot.
• Perplexity: PerplexityBot (indexering; Perplexity raadt aan deze toe te laten zodat de pagina in zijn antwoorden kan verschijnen), Perplexity-User (live fetch, die robots.txt over het algemeen negeert omdat een mens, niet de crawler, deze in gang zette).
• Google: gewone Googlebot-regels gelden zowel voor Search als voor AI Overviews; Google-Extended raakt uitsluitend de training en grounding van Gemini en Vertex AI, nooit het verschijnen in Search of AI Overviews.

Voordat een oplage naar de drukker gaat, loont het om het live robots.txt-bestand van de klant te openen en te controleren of geen van deze tokens wordt geblokkeerd door een oude, te brede "disallow all bots"-regel die is overgeërfd van een vorige developer, want die ene regel maakt een landingspagina in één klap onzichtbaar voor elk AI-systeem, hoe schoon de redirectketen ervoor ook is.

Weet het AI-systeem überhaupt dat er een QR-code bij betrokken was

Nee, en het is de moeite waard om precies te zijn over waarom. Elke crawler en retrieval-bot die hierboven beschreven staat, haalt een bestemmings-URL op. Geen enkele documentatie van OpenAI, Anthropic, Perplexity of Google noemt een QR-code, een camerascan, of enig fysiek medium, omdat geen van hen een mechanisme heeft om te weten hoe een URL werd bereikt, of dat nu via een QR-scan was, een getypt adres, of een klik vanaf een andere pagina. De QR-code zelf is, en zal altijd blijven, onzichtbaar voor een AI-systeem, door hoe het in elkaar zit. Wat wel zichtbaar is, en wat daadwerkelijk gecrawld en geciteerd wordt, is welke URL de redirectketen ook maar oplevert, op precies dezelfde voorwaarden als wanneer iemand die op een andere manier had bereikt. Een agency heeft geen AI-systeem nodig dat "begrijpt" dat een pagina uit een QR-campagne kwam; het heeft nodig dat de bestemming een gewone, crawlbare, goed gebouwde pagina is, bereikt via een keten die kort en stabiel genoeg is om niet in de weg te zitten.

Een checklist voor AI-zichtbare QR-campagnes, vóór het drukken

Loop dit na voordat een campagne naar de drukker gaat, niet nadat een klant vraagt waarom die zijn eigen actie niet kan terugvinden in ChatGPT.

• Breng de keten waar mogelijk terug tot één hop: QR-code rechtstreeks naar het redirectdomein van het platform, rechtstreeks naar de uiteindelijke pagina, met trackingparameters toegevoegd in die ene response in plaats van een tweede redirect.
• Als een shortener van de agency of een CMS-redirect van de klant daarbovenop echt onvermijdelijk is, houd de totale keten dan op maximaal twee hops, want drie of meer zit al voorbij wat Google zelf veilig noemt, en nog verder in gebied dat geen enkel AI-lab documenteert.
• Gebruik een permanente redirect voor een stabiele, evergreen bestemming, en bedenk dat een aangepast domein voor de QR-link niets verandert aan dit crawlergedrag, maar wel één hop van een derde partij wegneemt door de redirect te plaatsen op infrastructuur die de agency of klant al zelf beheert.
• Controleer of de uiteindelijke landingspagina zijn echte content in de eerste HTML-response toont, niet achter een client-side redirect of een script dat pas na het laden content inwisselt, want GPTBot en ClaudeBot halen scripts op zonder ze uit te voeren.
• Controleer het live robots.txt-bestand op het bestemmingsdomein voor GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot, Claude-SearchBot en Claude-User, en verwijder elke blanket bot-blokkerende regel die dateert van vóór de campagne.
• Behandel llms.txt als optionele netheid, geen vinkje dat AI-citaties beweegt, gebaseerd op het bewijs dat vandaag beschikbaar is.
• Los van crawlbaarheid moet de bestemmingspagina een citatie nog altijd op eigen merites verdienen, en dat is een contentvraag: zie wat een QR-landingspagina daadwerkelijk laat converteren zodra een bezoeker, mens of anderszins, die heeft bereikt.

Veelgestelde vragen

Volgen AI-crawlers zoals GPTBot en PerplexityBot de redirects van een QR-code?

Ja. Geen van deze crawlers weet of geeft erom dat er een QR-code werd gescand; ze vragen simpelweg de URL op die ze krijgen, en volgen redirects op dezelfde manier als elke HTTP-client, tot aan welke hop-tolerantie ze intern ook hanteren.

Hoeveel redirect-hops kan een AI-crawler volgen voordat hij het opgeeft?

Alleen Google publiceert een getal: Googlebot volgt tot tien hops, met een officiële aanbeveling om een keten tot maximaal drie of vier te beperken. OpenAI, Anthropic en Perplexity publiceren geen hop-limiet voor GPTBot, ClaudeBot of PerplexityBot, dus behandel hun tolerantie als onbekend en ontwerp voor de kortst mogelijke keten in plaats van uit te gaan van een specifiek cijfer dat elders wordt genoemd.

Kunnen ChatGPT of Perplexity content lezen achter een JavaScript-redirect?

Nee. Analyse van netwerklogs laat zien dat GPTBot en ClaudeBot JavaScript-bestanden wel ophalen maar niet uitvoeren, dus een redirect of content-wissel die alleen client-side gebeurt, is onzichtbaar voor deze crawlers, ook al werkt het prima in de browser van een mens.

Moet een QR-code een 301- of 302-redirect gebruiken voor zichtbaarheid in AI-zoekresultaten?

Gebruik een 301 voor een stabiele, evergreen bestemming; die signaleert een permanente verplaatsing en is de statuscode die Google's eigen indexeringspijplijn behandelt als aanwijzing voor canonicalisatie. Een 302 is alleen de juiste keuze zolang een bestemming écht tijdelijk is, want noch Google, noch, voor zover gedocumenteerd, enig AI-lab behandelt die als signaal om ranking of citaties te consolideren op de nieuwe URL.

Wat is llms.txt, en helpt het een QR-campagne om door AI geciteerd te worden?

Het is een voorgestelde conventie om de belangrijkste pagina's van een site in een plain-textbestand te vermelden, zonder steun van een standaardisatieorgaan en zonder bevestiging van een leverancier dat enige grote AI-crawler het leest op het moment van een query. Een onderzoek onder zo'n 300.000 domeinen vond geen meetbaar citatievoordeel van het hebben van zo'n bestand. Het toevoegen ervan is onschadelijk, maar het moet niet verkocht worden als iets dat de AI-zichtbaarheid verbetert.

Welk aandeel van het webverkeer bestaat vandaag de dag uit AI-crawlers?

In juni 2026 mat Cloudflare Radar automatische requests op 57,5 procent van het HTML-verkeer op zijn netwerk, de eerste keer dat bots het aantal mensen in die telling overstegen, waarbij crawlen met alleen als doel AI-training in het voorgaande jaar steeg van 22 naar 52 procent van de crawleractiviteit. Deze cijfers veranderen snel, dus behandel elk afzonderlijk percentage als een momentopname van het genoemde meetvenster, niet als een vaste constante.

Schaadt het blokkeren van GPTBot in robots.txt de zichtbaarheid van een QR-campagne in ChatGPT?

Ja, direct. Het blokkeren van GPTBot stopt de trainingscrawler van OpenAI, en het blokkeren van OAI-SearchBot haalt een pagina weg uit de zoekresultaten van ChatGPT (OpenAI noemt ongeveer een dag voordat die wijziging effect heeft). De indexeringsbots van Claude en Perplexity moeten los gecontroleerd worden, want het blokkeren van de crawler van het ene lab heeft geen invloed op die van het andere.

Helpt een aangepast domein op de QR-redirect voor de crawlbaarheid door AI?

Indirect. Een aangepast domein verandert niets aan hoe een crawler een redirect behandelt, maar het haalt doorgaans wel een hop van een derde partij uit de keten, door de redirect te plaatsen op infrastructuur die de agency of klant al zelf beheert, en dat is één hop minder voor elk hop-budget van elke crawler.

Moeten agencies QR-landingspagina's anders bouwen voor AI-zoekresultaten dan voor klassieke Google SEO?

Grotendeels niet anders, alleen strikter. De hygiëne van de redirectketen, server-side gerenderde HTML, en een open robots.txt, die een pagina al betrouwbaar crawlbaar maken voor Google, zijn dezelfde fundamenten die AI-crawlers nodig hebben. Het verschil zit in de tolerantie: Google publiceert royale limieten en herstelt soepel van de meeste fouten; de AI-labs publiceren daar niets van, dus moet diezelfde goede praktijk strikter worden toegepast, zonder gepubliceerde veiligheidsmarge om op terug te vallen.

De korte versie

Een QR-code is onzichtbaar voor elke AI-crawler en retrieval-bot die bestaat, en dat zal altijd zo blijven, omdat geen van hen enige manier heeft om te weten hoe een URL werd bereikt. Wat ze wel zien, crawlen en mogelijk citeren, is de bestemming waar de redirectketen van de code op uitkomt, op dezelfde voorwaarden als elke andere pagina op het web. GPTBot en ClaudeBot halen JavaScript op zonder het uit te voeren, dus een pagina die alleen client-side rendert, is voor hen functioneel leeg. Alleen Google publiceert een hop-limietgetal; de AI-labs doen dat niet, wat betekent dat de veiligste zet is om een redirectketen terug te brengen tot één hop in plaats van uit te gaan van een specifieke tolerantie. Een 301 is de juiste keuze voor een stabiele bestemming; llms.txt is optionele netheid zonder tot nu toe gemeten citatievoordeel; en de robots.txt-tokens voor GPTBot, ClaudeBot, PerplexityBot en hun realtime tegenhangers zijn de daadwerkelijke hefbomen die het waard zijn om op het domein van een klant te controleren vóór de volgende drukoplage, niet nadat een klant vraagt waarom zijn eigen campagne niet te vinden is.