QR-Codes und KI-Crawler: Warum Ihre Redirect-Kette über Sichtbarkeit in ChatGPT entscheidet

Wer einen Markennamen in die ChatGPT-Suche oder in Perplexity eingibt, erhält sofort eine Antwort. Die eigentliche Frage dahinter ist jedoch eine andere: Erreicht der Crawler, der diese Antwort liefert, überhaupt jemals die Seite, zu der Ihr QR-Code die Menschen eigentlich führen soll? Ein QR-Code ist selbst kein Inhalt. Er ist eine Übersetzungsebene von der physischen Welt zu einer URL, die über einen oder mehrere HTTP-Redirects aufgelöst wird, bevor ein Browser oder ein Bot überhaupt eine Landingpage zu sehen bekommt. Agenturen haben jahrelang diese Landingpage für Google optimiert. Deutlich seltener wurde gefragt, ob die davorliegende Redirect-Kette überhaupt für GPTBot, ClaudeBot, PerplexityBot oder die Retrieval-Bots sichtbar ist, die eine Live-Anfrage in ChatGPT oder Perplexity beantworten, also genau die Ebene, die darüber entscheidet, ob die Kampagne eines Kunden auftaucht, wenn dessen eigene Kunden einen KI-Assistenten danach fragen.

Warum diese Frage 2026 relevant ist

Bot-Traffic ist neben menschlichen Besuchern längst kein Rundungsfehler mehr. Die Radar-Daten von Cloudflare bezifferten automatisierte Anfragen im Juni 2026 auf 57,5 Prozent des gesamten HTML-Traffics im eigenen Netzwerk, das erste Mal, dass Bots in dieser Messung Menschen zahlenmäßig übertrafen. Ein Jahr zuvor entfielen nur 22 Prozent der von Cloudflare klassifizierten Crawler-Aktivität auf KI-Training; Mitte 2026 war dieser Anteil auf 52 Prozent gestiegen, mit einem weiteren, schnell wachsenden Anteil für Echtzeit-KI-Suche und Agent-Abrufe. Die unabhängigen Zahlen von Fastly weisen in dieselbe Richtung: Das Volumen an KI-Anfragen im eigenen Netzwerk wuchs allein zwischen Januar und Mai 2026 um rund 30 Prozent, etwa 6,5-mal schneller als das Wachstum des menschlichen Traffics im selben Zeitraum.

Kein Teil dieses Traffics scannt einen QR-Code, denn ein QR-Code kann nicht gecrawlt, sondern nur gescannt werden. All das ist Crawling von URLs. Die eigentliche Frage für eine Agentur lautet also nicht „Kann eine KI einen QR-Code lesen“, sondern „Landet die durch einen QR-Code ausgelöste Redirect-Kette irgendwo, wo diese Crawler tatsächlich hingelangen, den Inhalt parsen und ihn schließlich zitieren können.“ Das ist eine lösbare technische Frage, und die meisten Agenturen haben die Antwort für ihre eigenen Kampagnen noch nie überprüft.

Was ein KI-Crawler bei einem Redirect tatsächlich tut

Die drei großen KI-Labore betreiben jeweils mehr als einen Crawler, und diese Aufteilung ist wichtig. OpenAI betreibt GPTBot, der Trainingsdaten sammelt, OAI-SearchBot, der Seiten indexiert, damit sie in den Suchergebnissen von ChatGPT erscheinen können, und ChatGPT-User, der in Echtzeit aktiv wird, wenn jemand ChatGPT eine Live-Frage stellt und dieser daraufhin eine Seite abruft. Anthropic spiegelt das mit ClaudeBot fürs Training, Claude-SearchBot fürs Indexieren und Claude-User für Live-Abrufe, die durch Nutzer ausgelöst werden. Perplexity dokumentiert PerplexityBot als seinen Indexierungs-Crawler (ausdrücklich nicht zum Training der zugrunde liegenden Modelle verwendet) und Perplexity-User als Echtzeit-Abrufer, der an eine konkrete Anfrage gebunden ist. Google integriert AI Overviews in das gewöhnliche Crawling durch Googlebot und reserviert einen eigenen Token, Google-Extended, ausschließlich dafür, ob bereits gecrawlte Inhalte zum Training oder zur Fundierung von Gemini und Vertex AI verwendet werden dürfen. Das Blockieren von Google-Extended entfernt eine Seite weder aus der Suche noch aus AI Overviews; das bewirkt nur das Blockieren von Googlebot selbst.

Keiner von ihnen rendert JavaScript

Vercels eigene Analyse von Netzwerk-Logs zum Verhalten von KI-Crawlern ergab, dass GPTBot und ClaudeBot durchaus JavaScript-Dateien abrufen, bei rund 12 beziehungsweise 24 Prozent der Anfragen, jedoch keine Hinweise darauf lieferte, dass einer der beiden sie auch ausführt. Allein diese Tatsache schließt eine ganze Kategorie von Kampagnen-Landingpages aus: Alles, was seinen finalen Inhalt clientseitig auflöst, hinter einem JavaScript-Redirect verbirgt oder über ein Skript nachträglich einblendet, bleibt für einen Trainings- oder Indexierungs-Crawler faktisch leer. Eine Seite, die für einen Menschen und für einen Crawler im Browser identisch aussieht, kann für GPTBot, der stets nur die rohe HTML-Antwort sieht, zwei völlig unterschiedliche Seiten sein.

Hop-Limits: Ein Anbieter veröffentlicht eine Zahl, drei nicht

Google ist hier ungewöhnlich konkret: Googlebot folgt einer Kette von bis zu zehn Redirects, doch die eigene Entwicklerdokumentation von Google empfiehlt, direkt zum endgültigen Ziel weiterzuleiten und, wo das nicht möglich ist, eine Kette auf nicht mehr als drei oder vier Hops zu begrenzen. Weder OpenAI noch Anthropic noch Perplexity veröffentlichen ein Hop-Limit für GPTBot, ClaudeBot oder PerplexityBot. Über dieses Fehlen wird ständig hinweggetäuscht: Zahlreiche SEO-Blogs nennen eine konkrete Anzahl von Hops, die diese Bots angeblich tolerieren, doch keine dieser Angaben lässt sich auf eine Herstellerquelle zurückführen, und dieser Beitrag wird keine erfundene Zahl wiederholen. Die ehrliche Position ist: Eine Agentur optimiert gegen eine unveröffentlichte und möglicherweise strengere Toleranz als die großzügigen zehn Hops, die Google einräumt, und das ist Grund genug, eine Kette so kurz wie irgend möglich zu halten.

301 oder 302, und warum das beeinflusst, was im Gedächtnis bleibt

Die beiden Statuscodes tragen gemäß der HTTP-Spezifikation (RFC 9110) tatsächlich unterschiedliche Bedeutungen, nicht nur laut SEO-Folklore. Ein 301 teilt jedem Client mit, dass der Umzug dauerhaft ist, und Googles eigene Dokumentation bestätigt, dass die Indexierungs-Pipeline einen 301 (oder 308) als Signal behandelt, dass das Ziel kanonisch werden soll, wobei die Bedeutung der ursprünglichen URL auf die neue übertragen wird. Ein 302 (oder 307) signalisiert einen vorübergehenden Umzug, und Googles Pipeline folgt ihm zwar jedes Mal, behält jedoch die ursprüngliche URL als maßgeblich bei, nicht das Ziel. Keines der drei KI-Labore dokumentiert, ob ihre Crawler ein 301-Ziel zwischenspeichern und eine erneute Überprüfung später überspringen, oder ob sie eine 302-Kette jedes Mal von Grund auf neu durchlaufen. Das ist eine plausible Schlussfolgerung aus dem RFC und Googles öffentlichem Verhalten, aber keine dokumentierte Tatsache für GPTBot, ClaudeBot oder PerplexityBot. Was sich aus den dokumentierten Teilen ableiten lässt: Ein QR-Code, der auf ein stabiles, dauerhaftes Ziel verweist, ist ein legitimer Fall für einen 301, und dynamische QR-Plattformen, die es einer Agentur erlauben, das Ziel später zu ändern, ohne neu zu drucken, sollten trotzdem über eine möglichst saubere und kurze Weiterleitung aufgelöst werden, unabhängig davon, welchen Statuscode die Plattform verwendet.

Wo sich die Hops bei einer echten Kampagne tatsächlich anhäufen

Eine einzelne, gut gebaute dynamische QR-Weiterleitung ist ein Hop: Der Code löst direkt zur Kurz-Domain der Plattform auf, die im selben Response etwaige Tracking-Parameter anhängt und den Besucher zur finalen Landingpage weiterleitet. Genau so sind die Redirects von ScanKit aufgebaut, und es ist sehr unwahrscheinlich, dass das irgendeinen Crawler stört, ob mit veröffentlichtem Hop-Limit oder nicht. Die Kette wird lang aus Gewohnheit, nicht aus Notwendigkeit: Eine Agentur nutzt einen bit.ly-artigen Shortener weiter, den sie ohnehin für Social-Media-Beiträge hat, und verweist damit auf den Link der QR-Plattform statt direkt auf die Seite des Kunden, das CMS des Kunden fügt bei einer Seitenverschiebung eine eigene Weiterleitung hinzu, und ein separates Tool hängt UTM-Parameter über einen weiteren Hop an. Jede dieser Ergänzungen bleibt für einen Menschen am Smartphone unsichtbar, da ein mobiler Browser die gesamte Kette in deutlich unter einer Sekunde auflöst, nicht jedoch für einen Crawler, der mit einem unveröffentlichten, möglicherweise knappen Hop-Budget arbeitet. Drei oder vier gestapelte Redirects liegen bereits in der Zone, die Google als riskant bezeichnet; bei KI-Crawlern ist das schlicht unvermessenes Terrain. Eine QR-Plattform und ein URL-Shortener lösen unterschiedliche Probleme, und einen davon für denselben Link auf den anderen zu stapeln, ist die mit Abstand häufigste Art, wie eine Agentur unnötige Hops hinzufügt.

1. Der Kamera-Scan des gedruckten QR-Codes.
2. Die Redirect-Domain der QR-Plattform: ein sauberer Hop direkt zum Ziel.
3. Ein zusätzlich gestapelter Agentur-Shortener oder CMS-Redirect des Kunden: ein vermeidbarer zusätzlicher Hop, hier markiert, weil er der am einfachsten zu behebende Fehler ist.
4. Die finale Landingpage, die von einem Crawler erreicht und korrekt gelesen wird.

llms.txt: eine saubere Idee, aber noch kein Hebel

llms.txt ist eine vorgeschlagene Konvention, veröffentlicht von Jeremy Howard von Answer.AI im September 2024, die eine Website dazu auffordert, ihre wichtigsten Seiten in einer reinen Textdatei aufzulisten, damit ein KI-System sie lesen kann. Sie hat keine Rückendeckung durch ein Standardisierungsgremium, und die kanonische llms.txt-Website selbst beschreibt sie als einen für Community-Input offenen Vorschlag, nicht als verabschiedeten Standard. Eine Studie von SE Ranking an rund 300.000 Domains, veröffentlicht im November 2025, fand keine messbare Korrelation zwischen dem Vorhandensein einer llms.txt-Datei und der Häufigkeit, mit der eine Domain von KI-Systemen zitiert wurde, und das Entfernen dieser Variable aus dem Vorhersagemodell verbesserte dessen Genauigkeit sogar. Kein großes KI-Labor hat eine Dokumentation veröffentlicht, die seine Crawler dazu verpflichtet, eine llms.txt-Datei eines Drittanbieters zur Inferenzzeit zu lesen. Nichts davon macht llms.txt schädlich, und ein sauberer Index der wichtigsten Seiten eines Kunden kostet wenig Aufwand, doch eine Agentur sollte es nicht als etwas verkaufen, das die KI-Sichtbarkeit messbar verbessert. Die heute verfügbare Evidenz sagt, dass sie das nicht tut, zumindest noch nicht.

Die robots.txt-Tokens, auf die es wirklich ankommt

Jedes KI-Labor dokumentiert seine eigenen Crawler-User-Agent-Strings, und das sind die tatsächlichen Hebel, nicht llms.txt.

• OpenAI: GPTBot (Training), OAI-SearchBot (Indexierung für die ChatGPT-Suche), ChatGPT-User (Live-Abruf, ausgelöst durch Nutzer; OpenAIs eigene Dokumentation merkt an, dass robots.txt-Regeln hier möglicherweise nicht in gleicher Weise gelten wie bei GPTBot).
• Anthropic: ClaudeBot (Training), Claude-SearchBot (Suchindexierung), Claude-User (Live-Abruf, mit demselben Echtzeit-Vorbehalt), zusätzlich eine nicht standardisierte Crawl-delay-Direktive, die Anthropic für ClaudeBot unterstützt.
• Perplexity: PerplexityBot (Indexierung; Perplexity empfiehlt, ihn zuzulassen, um in den eigenen Antworten zu erscheinen), Perplexity-User (Live-Abruf, der robots.txt in der Regel ignoriert, da ein Mensch und nicht der Crawler ihn ausgelöst hat).
• Google: Die gewöhnlichen Googlebot-Regeln gelten sowohl für die Suche als auch für AI Overviews; Google-Extended betrifft ausschließlich das Training und die Fundierung von Gemini und Vertex AI, niemals das Erscheinen in der Suche oder in AI Overviews.

Vor einem Druckauftrag lohnt es sich, die aktuelle robots.txt-Datei des Kunden zu öffnen und zu prüfen, dass keiner dieser Tokens durch eine alte, zu weit gefasste „disallow all bots“-Zeile blockiert wird, die von einem früheren Entwickler übernommen wurde, denn diese eine Zeile bringt eine Landingpage für sämtliche KI-Systeme gleichzeitig zum Schweigen, egal wie sauber die davorliegende Redirect-Kette ist.

Weiß das KI-System überhaupt, dass ein QR-Code im Spiel war

Nein, und es lohnt sich, genau zu sein, warum. Jeder oben beschriebene Crawler und Retrieval-Bot ruft eine Ziel-URL ab. Keine der Dokumentationen von OpenAI, Anthropic, Perplexity oder Google erwähnt einen QR-Code, einen Kamera-Scan oder irgendein physisches Medium, weil keiner von ihnen einen Mechanismus besitzt, um zu wissen, wie eine URL erreicht wurde, sei es durch einen QR-Scan, eine eingetippte Adresse oder einen Klick von einer anderen Seite. Der QR-Code selbst ist und bleibt für ein KI-System konstruktionsbedingt unsichtbar. Sichtbar, und tatsächlich gecrawlt und zitiert, ist einzig die URL, zu der die Redirect-Kette auflöst, und zwar unter denselben Bedingungen, als hätte eine Person sie auf beliebig anderem Weg erreicht. Eine Agentur braucht kein KI-System, das „versteht“, dass eine Seite aus einer QR-Kampagne stammt; sie braucht ein Ziel, das eine gewöhnliche, crawlbare, gut gebaute Seite ist, erreicht über eine Kette, die kurz und stabil genug ist, um nicht im Weg zu stehen.

Eine Checkliste vor dem Druck für KI-sichtbare QR-Kampagnen

Gehen Sie diese Liste durch, bevor eine Kampagne in den Druck geht, nicht erst, wenn ein Kunde fragt, warum er seine eigene Aktion in ChatGPT nicht finden kann.

• Reduzieren Sie die Kette wo immer möglich auf einen Hop: QR-Code direkt zur Redirect-Domain der Plattform, direkt zur finalen Seite, wobei Tracking-Parameter in genau diesem einen Response angehängt werden statt über einen zweiten Redirect.
• Falls ein Agentur-Shortener oder ein CMS-Redirect des Kunden zusätzlich wirklich unvermeidbar ist, begrenzen Sie die gesamte Kette auf maximal zwei Hops, denn drei oder mehr liegen bereits jenseits dessen, was Google selbst als sicher bezeichnet, und noch weiter in einem Terrain, das kein KI-Labor überhaupt dokumentiert.
• Verwenden Sie für ein stabiles, dauerhaftes Ziel eine permanente Weiterleitung, und denken Sie daran, dass eine eigene Domain für den QR-Link an diesem Crawler-Verhalten nichts ändert, jedoch einen Drittanbieter-Hop entfernt, indem die Weiterleitung auf Infrastruktur läuft, die die Agentur oder der Kunde bereits kontrolliert.
• Bestätigen Sie, dass die finale Landingpage ihren tatsächlichen Inhalt bereits im initialen HTML-Response rendert, nicht hinter einem clientseitigen Redirect oder einem Skript, das den Inhalt erst nach dem Laden einblendet, denn GPTBot und ClaudeBot rufen Skripte ab, ohne sie auszuführen.
• Prüfen Sie die aktuelle robots.txt der Ziel-Domain auf GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot, Claude-SearchBot und Claude-User, und entfernen Sie jede pauschale Bot-Sperrzeile, die älter ist als die Kampagne.
• Behandeln Sie llms.txt nach dem heutigen Stand der Evidenz als optionale Ordnungsmaßnahme, nicht als Checkbox, die KI-Zitationen beeinflusst.
• Über die Crawlbarkeit hinaus muss sich die Zielseite eine Zitation noch aus eigener Kraft verdienen, was eine Frage des Inhalts ist: siehe was eine QR-Landingpage tatsächlich konversionsstark macht, sobald ein Besucher, ob Mensch oder nicht, sie erreicht hat.

Häufig gestellte Fragen

Folgen KI-Crawler wie GPTBot und PerplexityBot den Weiterleitungen eines QR-Codes?

Ja. Keiner dieser Crawler weiß oder interessiert sich dafür, dass ein QR-Code gescannt wurde; sie fordern schlicht die URL an, die ihnen übergeben wird, und folgen Weiterleitungen genauso wie jeder andere HTTP-Client, bis zu welcher Hop-Toleranz auch immer sie intern anwenden.

Wie vielen Weiterleitungs-Hops folgt ein KI-Crawler, bevor er aufgibt?

Nur Google veröffentlicht eine Zahl: Googlebot folgt bis zu zehn Hops, mit der offiziellen Empfehlung, eine Kette auf maximal drei oder vier zu begrenzen. OpenAI, Anthropic und Perplexity veröffentlichen kein Hop-Limit für GPTBot, ClaudeBot oder PerplexityBot. Behandeln Sie deren Toleranz daher als unbekannt und planen Sie die kürzestmögliche Kette, statt irgendeine andernorts genannte konkrete Zahl anzunehmen.

Können ChatGPT oder Perplexity Inhalte hinter einem JavaScript-Redirect lesen?

Nein. Die Analyse von Netzwerk-Logs zeigt, dass GPTBot und ClaudeBot JavaScript-Dateien abrufen, sie jedoch nicht ausführen. Ein Redirect oder ein Inhaltswechsel, der nur clientseitig stattfindet, bleibt für diese Crawler unsichtbar, auch wenn er im Browser eines Menschen einwandfrei funktioniert.

Sollte ein QR-Code für die Sichtbarkeit in der KI-Suche einen 301- oder einen 302-Redirect verwenden?

Verwenden Sie für ein stabiles, dauerhaftes Ziel einen 301; er signalisiert einen dauerhaften Umzug und ist der Statuscode, den Googles eigene Indexierungs-Pipeline als Hinweis auf Kanonisierung behandelt. Ein 302 ist nur dann die richtige Wahl, wenn ein Ziel wirklich vorübergehend ist, denn weder Google noch, soweit dokumentiert, irgendein KI-Labor behandelt ihn als Signal, Ranking oder Zitation auf die neue URL zu konsolidieren.

Was ist llms.txt, und hilft es einer QR-Kampagne, von KI zitiert zu werden?

Es handelt sich um eine vorgeschlagene Konvention, die wichtigsten Seiten einer Website in einer reinen Textdatei aufzulisten, ohne Rückendeckung durch ein Standardisierungsgremium und ohne Bestätigung eines Anbieters, dass irgendein großer KI-Crawler sie zur Inferenzzeit liest. Eine Studie an rund 300.000 Domains fand keinen messbaren Zitations-Vorteil durch das Vorhandensein einer solchen Datei. Sie einzurichten ist unschädlich, sollte aber nicht als etwas verkauft werden, das die KI-Sichtbarkeit verbessert.

Wie hoch ist der Anteil von KI-Crawlern am heutigen Web-Traffic?

Bis Juni 2026 maß Cloudflare Radar automatisierte Anfragen mit 57,5 Prozent des HTML-Traffics im eigenen Netzwerk, das erste Mal, dass Bots in dieser Zählung Menschen zahlenmäßig übertrafen, wobei allein das Crawling zu KI-Trainingszwecken im vorangegangenen Jahr von 22 auf 52 Prozent der Crawler-Aktivität anstieg. Diese Zahlen verändern sich schnell, behandeln Sie daher jeden einzelnen Prozentwert als Momentaufnahme des jeweils genannten Messzeitraums und nicht als feste Konstante.

Schadet das Blockieren von GPTBot in robots.txt der Sichtbarkeit einer QR-Kampagne in ChatGPT?

Ja, unmittelbar. Das Blockieren von GPTBot stoppt den Trainings-Crawler von OpenAI, und das Blockieren von OAI-SearchBot entfernt eine Seite aus den Suchergebnissen von ChatGPT (OpenAI gibt an, dass diese Änderung rund einen Tag benötigt, um wirksam zu werden). Die Indexierungs-Bots von Claude und Perplexity müssen unabhängig davon geprüft werden, denn das Blockieren des Crawlers eines Labors hat keinen Einfluss auf den eines anderen.

Hilft eine eigene Domain für den QR-Redirect der Crawlbarkeit durch KI?

Indirekt. Eine eigene Domain ändert nichts daran, wie irgendein Crawler einen Redirect behandelt, entfernt jedoch in der Regel einen Drittanbieter-Hop aus der Kette, indem die Weiterleitung auf Infrastruktur läuft, die die Agentur oder der Kunde bereits kontrolliert, was für jeden Crawler oder jedes Hop-Limit-Budget ein Hop weniger bedeutet.

Sollten Agenturen QR-Landingpages für die KI-Suche anders bauen als für klassisches Google-SEO?

Größtenteils nicht anders, nur strenger. Die Hygiene der Redirect-Kette, serverseitig gerendertes HTML und eine offene robots.txt, die eine Seite bereits zuverlässig für Google crawlbar machen, sind dieselben Grundlagen, die auch KI-Crawler benötigen. Der Unterschied liegt in der Toleranz: Google veröffentlicht großzügige Limits und verzeiht die meisten Fehler; die KI-Labore veröffentlichen davon nichts, weshalb dieselbe gute Praxis strenger angewendet werden muss, ohne veröffentlichten Sicherheitsspielraum, auf den man sich zurückziehen könnte.

Kurz gesagt

Ein QR-Code ist für jeden existierenden KI-Crawler und Retrieval-Bot unsichtbar und wird es immer bleiben, weil keiner von ihnen eine Möglichkeit hat zu wissen, wie eine URL erreicht wurde. Was sie sehen, crawlen und möglicherweise zitieren, ist das Ziel, zu dem die Redirect-Kette des Codes auflöst, unter denselben Bedingungen wie bei jeder anderen Seite im Web. GPTBot und ClaudeBot rufen JavaScript ab, ohne es auszuführen, sodass eine Seite, die nur clientseitig rendert, für sie faktisch leer ist. Nur Google veröffentlicht eine Hop-Limit-Zahl; die KI-Labore tun das nicht, was bedeutet, dass die sicherste Vorgehensweise darin besteht, eine Redirect-Kette auf einen Hop zu reduzieren, statt irgendeine konkrete Toleranz anzunehmen. Ein 301 ist für ein stabiles Ziel die richtige Wahl; llms.txt ist optionale Ordnung ohne bislang gemessenen Zitations-Vorteil; und die robots.txt-Tokens für GPTBot, ClaudeBot, PerplexityBot und ihre Echtzeit-Pendants sind die tatsächlichen Hebel, die es sich lohnt, auf der Domain eines Kunden vor dem nächsten Druckauftrag zu prüfen, nicht erst, wenn ein Kunde fragt, warum seine eigene Kampagne nicht gefunden werden kann.