Warum Ihr QR-Code so lange zum Weiterleiten braucht (und wie Sie das beheben)

Warum Ihr QR-Code so lange zum Weiterleiten braucht (und wie Sie das beheben)

Ein Scanner öffnet die Kamera, der QR-Code wird in Sekundenbruchteilen decodiert, und dann... ein Ladekreis. Zwei Sekunden. Drei. Die Seite lädt endlich, oder auch nicht, und der Scanner hat sein Smartphone längst wieder eingesteckt. Wer schon einmal beobachtet hat, wie eine Kundenkampagne trotz gut gestaltetem Code an guter Position schwächer performt als erwartet, kennt einen der am meisten übersehenen Gründe dafür: die Geschwindigkeit der Weiterleitung.

Jeder dynamische QR-Code hängt von einer Kette kleiner technischer Schritte ab, die zwischen dem Scan und der erscheinenden Seite ablaufen. Die meisten Agenturen schauen sich diese Kette nie genauer an, weil sie unsichtbar ist, solange man nicht gezielt danach sucht. Dieser Leitfaden erklärt, was in dieser Lücke tatsächlich passiert, welche Teile davon wirklich relevant sind, und wie Sie Ihren eigenen Weiterleitungs-Stack prüfen, bevor Sie zehntausend Codes drucken, die alle auf denselben langsamen Link zeigen.

Was zwischen einem Scan und einer geladenen Seite tatsächlich passiert

Ein statischer QR-Code, der eine Ziel-URL direkt ohne Tracking-Schicht codiert, schickt das Smartphone des Scanners unmittelbar zu dieser Adresse. Ein dynamischer QR-Code, wie ihn ScanKit und die meisten ernstzunehmenden Kampagnen-Tools erzeugen, codiert stattdessen eine kurze Tracking-URL. Das macht das Ziel auch nach dem Druck noch änderbar, und genau das führt zu der Weiterleitungskette, um die es in diesem Artikel geht.

Der Ablauf sieht so aus:

1. Die Kamera decodiert den QR-Code und übergibt die URL an das Betriebssystem.
2. Das Betriebssystem öffnet entweder den Standardbrowser des Smartphones oder, falls der Scan aus einer App wie Instagram, TikTok oder einer Messaging-App heraus erfolgt ist, den integrierten In-App-Browser dieser App.
3. Der Browser löst den Domainnamen auf (DNS-Abfrage) und handelt eine sichere Verbindung aus (TLS-Handshake).
4. Der Browser ruft die Tracking-URL auf. Der Server protokolliert den Scan und antwortet dann mit einer HTTP-Weiterleitung zum eigentlichen Ziel.
5. Gibt es eine zweite Tracking-Schicht in der Kette, etwa ein separates Analytics-Pixel oder einen Drittanbieter-Linkverkürzer zwischen QR-Plattform und Ziel, wiederholen sich die Schritte 3 und 4.
6. Der Browser folgt der letzten Weiterleitung und beginnt, die Zielseite zu laden.

Keiner dieser Schritte ist für sich genommen langsam. Das Problem ist, dass sie sequenziell ablaufen statt parallel, und jeder einzelne einen vollständigen Roundtrip zu einem Server erfordert, bevor der nächste beginnen kann. Schon zwei oder drei aufeinanderfolgende Hops reichen aus, damit sich ein Scan, der sich instantan anfühlen sollte, plötzlich kaputt anfühlt.

301 oder 302: der Weiterleitungstyp, den die meisten falsch einsetzen

Jede Weiterleitung trägt einen HTTP-Statuscode, der dem Browser (und Suchmaschinen) mitteilt, um welche Art von Weiterleitung es sich handelt. Für QR-Kampagnen sind vor allem 301 und 302 relevant, und Agenturen greifen dabei überraschend oft zum falschen.

Eine 301 (Moved Permanently) signalisiert dem Browser, dass sich das Ziel dauerhaft geändert hat. Browser dürfen diese Antwort unbegrenzt zwischenspeichern und die Weiterleitung beim nächsten Besuch komplett überspringen, indem sie direkt zum zwischengespeicherten Ziel springen, ohne den Server erneut zu prüfen.

Eine 302 (Found), oder ihre strengere Variante 307 (Temporary Redirect), teilt dem Browser mit, dass der Umzug vorübergehend ist. Der Browser soll bei jedem Aufruf erneut beim Server nachfragen, statt das Ziel zwischenzuspeichern.

Dieser Unterschied ist bei dynamischen QR-Codes enorm wichtig, denn der ganze Sinn eines dynamischen Codes ist es, das Ziel nach dem Druck noch ändern zu können. Sendet Ihre QR-Plattform (oder ein nachgeschalteter Linkverkürzer) eine 301, kann ein Smartphone, das den Code einmal gescannt hat, das alte Ziel lokal zwischenspeichern und Ihre Aktualisierung schlicht nie sehen, selbst nachdem Sie die Kampagne im Dashboard geändert haben. Der Scanner blickt dann nicht auf einen Fehler in Ihrer Kampagne, sondern auf einen veralteten Cache, dessen Ablauf Sie nicht kontrollieren.

Verwenden Sie 302 oder 307 für jeden QR-Code, dessen Ziel sich ändern könnte. Reservieren Sie 301er für den seltenen Fall, dass das Ziel eines Codes wirklich dauerhaft ist und Sie möchten, dass Suchmaschinen oder Aggregatoren es als maßgeblich behandeln. Wenn Sie eine bestehende QR-Plattform oder einen vorgeschalteten Weiterleitungsdienst prüfen, kontrollieren Sie die Response-Header und nicht nur die Marketingtexte, um zu bestätigen, welcher Typ tatsächlich gesendet wird.

Wie viel kostet jeder Hop wirklich?

An dieser Stelle wird ein Großteil der Ratschläge im Netz vage oder erfindet Zahlen, die einer Prüfung nicht standhalten. Hier ist, was sich tatsächlich messen lässt, und was nicht.

DNS-Abfrage und TLS-Handshake verursachen reale, messbare Kosten, schwanken aber zu stark, um eine einzelne Zahl zu nennen. Sie hängen vom Netzwerk des Scanners ab (4G, 5G, öffentliches WLAN), davon, ob die Domain bereits vom Resolver des Mobilfunkanbieters zwischengespeichert ist, und davon, ob Ihr Weiterleitungsdienst hinter einem CDN liegt. Eines zeigen die Daten aber klar: TLS-Handshakes werden spürbar schneller abgeschlossen, wenn eine Domain hinter einem CDN-Edge liegt, als wenn die Verbindung direkt einen Ursprungsserver erreichen muss, und mobile Verbindungen fügen in beiden Fällen tendenziell deutlich mehr Overhead hinzu als ein Festnetz-Breitbandanschluss. Behandeln Sie jede konkrete Millisekundenangabe zur "durchschnittlichen DNS-Abfragezeit", die Sie irgendwo lesen, bestenfalls als grobe Faustregel, nicht als verlässliche Spezifikation.

Jeder zusätzliche Weiterleitungs-Hop kostet einen vollständigen Roundtrip, nicht nur zusätzliche Verarbeitungszeit. Der Browser muss eine Anfrage senden, auf eine Antwort warten und dann den gesamten Verbindungsaufbau für den nächsten Server in der Kette von vorn beginnen, sofern es sich um eine andere Domain handelt. Leitlinien von Suchmaschinen zu Weiterleitungsketten (ursprünglich für SEO-Crawl-Budgets formuliert, aber der zugrunde liegende Mechanismus ist für ein scannendes Smartphone identisch) empfehlen durchgängig, Ketten so kurz wie möglich zu halten, und werten alles jenseits von drei oder vier Hops als Zeichen einer Fehlkonfiguration, nicht als bewusste Design-Entscheidung.

Was das in der Praxis bedeutet: Ein QR-Code, der vom Scan direkt zu einer einzigen Tracking-Weiterleitung und dann zum Ziel führt, ist schnell. Ein QR-Code, der über die Weiterleitung einer QR-Plattform, dann einen separaten URL-Verkürzer, dann ein Marketing-Analytics-Pixel und schließlich erst zur Landingpage läuft, hat bereits drei oder vier sequenzielle Roundtrips angesammelt, bevor der Scanner überhaupt etwas sieht. Jeder dieser Hops ist im Screenshot der fertigen Seite unsichtbar, aber sehr deutlich spürbar in der Wartezeit des Scanners, bis er dort ankommt.

Warum die Wartezeit wichtiger ist, als sie scheint

Es ist verlockend, eine zusätzliche Sekunde Ladezeit als kleine Unannehmlichkeit abzutun. Die Daten zum mobilen Nutzerverhalten sprechen dagegen. In einer der größten Studien dieser Art analysierten Google und DoubleClick rund 900.000 mobile Landingpages und fanden heraus, dass 53 % der Besuche abgebrochen werden, wenn eine mobile Seite länger als drei Sekunden zum Laden braucht. Dieselbe Untersuchung stellte fest, dass die Absprungwahrscheinlichkeit deutlich ansteigt, sie mehr als verdoppelt sich, wenn sich die Ladezeit von einer auf zehn Sekunden ausdehnt.

Ein QR-Scan ist ein noch weniger nachsichtiger Moment als ein typischer Klick auf eine mobile Anzeige. Der Scanner hat bereits die Mühe auf sich genommen, das Smartphone herauszuholen, die Kamera zu öffnen und den Code auszurichten. Er steht vor einem Plakat, einer Speisekarte oder einem Produkt, oft ohne triftigen Grund, lange zu warten, wenn nichts passiert. Jeder zusätzliche Weiterleitungs-Hop zwischen Scan und Seite zehrt an einem Wohlwollen, das sich nicht ohne Weiteres zurückholen lässt, und das noch bevor die eigentliche Ladezeit Ihrer Landingpage überhaupt ins Spiel kommt.

In-App-Browser bringen eine Unbekannte ins Spiel, die Sie nicht kontrollieren

Scannt jemand Ihren QR-Code aus einer App heraus statt über die Kamera des Smartphones oder einen eigenständigen QR-Scanner, etwa einen Code, der in einer Instagram-Story geteilt oder über den in TikTok integrierten QR-Scanner geöffnet wird, öffnet sich das Ziel häufig im integrierten Browser dieser App statt im Standardbrowser des Smartphones. Diese In-App-Browser sind einem normalen mobilen Browser nicht gleichzusetzen. Die vielzitierte Analyse des Sicherheitsforschers Felix Krause aus dem Jahr 2022 ergab, dass mehrere große Apps, darunter Instagram und Facebook, eigenes JavaScript in jede im In-App-Browser geladene Seite einschleusen, und dass der iOS-In-App-Browser von TikTok zum damaligen Zeitpunkt jeden Tastenanschlag und jede Berührung auf externen Websites, die darüber geöffnet wurden, protokollierte.

Belastbare öffentliche Benchmarks dazu, wie viel Latenz dieser eingeschleuste Code tatsächlich hinzufügt, gibt es nicht; begegnen Sie jeder konkreten Zahl zum "Overhead von In-App-Browsern" mit Skepsis. Gut belegt ist hingegen, dass In-App-Browser eine Blackbox sind, die Sie nicht kontrollieren, mit zusätzlichem Code, den Sie nicht geschrieben haben, auf einer Rendering-Engine, die sich anders verhalten kann als Safari oder Chrome. Wenn ein relevanter Teil der Scans Ihrer Kampagne wahrscheinlich aus sozialen Apps stammt, etwa bei einem QR-Code, der primär über einen Instagram-Post beworben wird, lohnt es sich, Ihre Landingpage gezielt in diesen In-App-Browsern zu testen, statt anzunehmen, ein normaler Browsertest decke das ab.

Wie Sie Ihre eigene Weiterleitungskette prüfen

Sie brauchen keine Spezialwerkzeuge, um zu sehen, was zwischen einem Scan und einer geladenen Seite tatsächlich passiert. Ein paar praktische Prüfungen:

• Verfolgen Sie die Kette manuell. Fügen Sie die Tracking-URL Ihres QR-Codes in das Network-Panel eines Browsers ein (den Tab "Network" in Chrome DevTools, mit aktiviertem "Preserve log") und beobachten Sie, wie jede Weiterleitung ausgelöst wird. Zählen Sie die Hops. Alles über die Tracking-Weiterleitung Ihrer QR-Plattform und das eigentliche Ziel hinaus ist einer genaueren Prüfung wert.
• Prüfen Sie die Statuscodes, nicht nur das Ziel. Klicken Sie im selben Network-Panel jede Weiterleitungsanfrage an und bestätigen Sie, ob 301, 302 oder 307 zurückgegeben wurde. Sehen Sie 301er bei einem Link, den Sie später eigentlich noch ändern wollen, ist das ein Cache-Problem, das früher oder später zutage tritt.
• Messen Sie die Zeit mit curl. Der Befehl curl -w "%{time_redirect} %{time_total}\n" -o /dev/null -s -L <Ihre-Tracking-URL> im Terminal liefert die tatsächlich für Weiterleitungen aufgewendete Zeit im Vergleich zur Gesamtzeit der Anfrage, ohne dass Browser-Overhead die Zahlen verzerrt.
• Testen Sie von einem echten Smartphone mit einer echten Verbindung aus. Breitband am Schreibtisch und Büro-WLAN lassen fast jede Weiterleitungskette gut aussehen. Testen Sie über 4G, und falls ein relevanter Teil Ihres Publikums aus sozialen Apps heraus scannt, testen Sie gezielt in den In-App-Browsern dieser Apps.
• Fragen Sie, wofür jeder Hop eigentlich gebraucht wird. Führt die Weiterleitung Ihrer QR-Plattform zu einer separaten Analytics-Weiterleitung, bevor es zum Ziel geht, prüfen Sie, ob diese Analytics-Schicht den Scan nicht in einem einzigen Schritt statt in zwei protokollieren und weiterleiten könnte. Weniger Hops sind nicht nur schneller, sie bedeuten auch weniger Stellen, an denen eine fehlerhafte Integration einen Scan-Datensatz verlieren oder doppelt zählen kann, was für die Genauigkeit Ihres Reportings genauso wichtig ist wie für Scan-Kennzahlen, die Sie gegenüber einem Kunden verteidigen können.

Die Kurzfassung

Die Weiterleitungskette eines dynamischen QR-Codes ist im Screenshot unsichtbar, aber sehr deutlich spürbar in der Wartezeit, bevor beim Scanner überhaupt etwas passiert. Verwenden Sie 302- oder 307-Weiterleitungen, niemals 301, für jeden Code, dessen Ziel sich ändern könnte, denn eine zwischengespeicherte permanente Weiterleitung kann wiederkehrende Scanner unbemerkt auf einem alten Ziel stranden lassen. Halten Sie die Kette wo immer möglich auf einen einzigen Tracking-Hop; jede zusätzliche Weiterleitung zwischen QR-Plattform und Landingpage ist ein vollständiger Roundtrip, den der Scanner aussitzen muss, bevor Ihre Landingpage überhaupt zu rendern beginnt. Begegnen Sie konkreten Millisekundenangaben zu DNS oder In-App-Browser-Overhead mit Skepsis, nehmen Sie den zugrunde liegenden Mechanismus aber ernst: weniger Hops, korrekt typisiert, sind für den Scanner schneller und für Ihr Tracking zuverlässiger. Verfolgen Sie vor Ihrem nächsten Druckauftrag die Weiterleitungskette Ihres eigenen QR-Codes im Network-Panel eines Browsers und zählen Sie die Hops. Sind es mehr als zwei, wissen Sie, was zu tun ist.

Häufig gestellte Fragen

Warum braucht mein QR-Code so lange, bis er weiterleitet?

Die meiste Verzögerung entsteht durch mehrere aufeinanderfolgende Weiterleitungs-Hops und nicht durch einen einzelnen langsamen Schritt. Ein dynamischer QR-Code codiert eine Tracking-URL, die zum Ziel weiterleitet. Sitzt zwischen QR-Plattform und Landingpage ein separater Analytics-Dienst, ein URL-Verkürzer oder eine zusätzliche Tracking-Schicht, kostet jeder davon einen vollständigen Roundtrip, bevor die Seite überhaupt zu laden beginnt. Prüfen Sie die Weiterleitungskette im Network-Panel eines Browsers, um genau zu sehen, durch wie viele Hops Ihr Code läuft.

Wie viele Weiterleitungen sollte ein QR-Code haben?

Ideal ist ein einziger Hop, von der Tracking-URL direkt zum Ziel. Zwei sind in der Regel noch unproblematisch. Alles darüber sollten Sie als Hinweis auf eine Fehlkonfiguration oder Redundanz im Stack werten, ähnlich wie Suchmaschinen lange Weiterleitungsketten als Problem für die Crawl-Effizienz markieren. Jeder zusätzliche Hop ist ein vollständiger Netzwerk-Roundtrip, den der Scanner aussitzen muss.

301 oder 302: Welche Weiterleitung sollte ein QR-Code nutzen?

Verwenden Sie 302 (oder 307) für jeden QR-Code, dessen Ziel sich ändern könnte, was ja die gesamte Grundidee eines dynamischen QR-Codes ist. Eine 301 signalisiert Browsern, dass der Umzug dauerhaft ist, und Browser dürfen das zwischenspeichern und den Server danach nicht mehr kontaktieren, wodurch ein Smartphone, das den Code einmal gescannt hat, auf einem alten Ziel hängen bleiben kann, selbst nachdem Sie die Kampagne aktualisiert haben.

Wirkt sich eine langsame Weiterleitung wirklich auf die Konversionsrate von QR-Codes aus?

Der zugrunde liegende Mechanismus, die Ladegeschwindigkeit mobiler Seiten, wurde direkt untersucht. Die Analyse von Google und DoubleClick über rund 900.000 mobile Landingpages ergab, dass 53 % der Besuche abgebrochen werden, sobald eine Seite länger als drei Sekunden zum Laden braucht, und dass die Absprungwahrscheinlichkeit mit steigender Ladezeit deutlich zunimmt. Ein QR-Scan bringt gegenüber einem gewöhnlichen mobilen Besuch noch eine zusätzliche Schicht Ungeduld mit, da der Scanner den physischen Schritt des Scannens bereits erledigt hat, bevor die Seite überhaupt zu laden beginnt.

Verlangsamen In-App-Browser wie die von Instagram oder TikTok die Weiterleitung von QR-Codes?

Es gibt keinen belastbaren öffentlichen Benchmark, der die genaue Latenz von In-App-Browsern quantifiziert, begegnen Sie konkreten Zahlen also mit Skepsis. Dokumentiert ist hingegen, dass mehrere große Apps eigenes JavaScript in Seiten einschleusen, die in ihrem integrierten Browser geöffnet werden, wodurch sich diese nicht nur in puncto Geschwindigkeit anders verhalten als ein normaler mobiler Browser. Stammt ein relevanter Teil Ihrer Scans aus sozialen Apps, testen Sie Ihre Landingpage gezielt in diesen jeweiligen In-App-Browsern, statt anzunehmen, ein Standard-Mobilbrowsertest sei repräsentativ.

Wie teste ich, wie schnell die Weiterleitungskette meines QR-Codes tatsächlich ist?

Öffnen Sie Ihre Tracking-URL in Chrome DevTools mit aktiviertem Network-Tab und "Preserve log", und zählen Sie jede Weiterleitung, die auslöst, bevor die endgültige Seite lädt. Für eine konkrete Zahl statt einer visuellen Spur führen Sie curl -w "%{time_redirect} %{time_total}\n" -o /dev/null -s -L <url> im Terminal aus, was die für Weiterleitungen aufgewendete Zeit getrennt von der Gesamtzeit der Anfrage ausgibt. Testen Sie über eine echte mobile Verbindung, nicht über Büro-WLAN, da ein Festnetz-Breitbandanschluss fast jede Kette gut aussehen lässt.

Ist ein statischer QR-Code schneller als ein dynamischer?

Ein statischer QR-Code, der ohne Tracking-Schicht direkt auf eine URL zeigt, überspringt den Weiterleitungsschritt komplett und ist damit theoretisch minimal schneller. In der Praxis ist der Unterschied meist zu gering, um ihn gegenüber allen anderen Faktoren, die die Ladezeit einer mobilen Seite beeinflussen, überhaupt wahrzunehmen, und er geht auf Kosten der Möglichkeit, das Ziel nach dem Druck noch zu ändern oder Scans überhaupt zu tracken. Für die meisten Agenturkampagnen ist ein gut konfigurierter dynamischer Code mit einem einzigen sauberen Weiterleitungs-Hop der bessere Kompromiss.

Kann ich einen langsamen QR-Code beheben, ohne ihn neu drucken zu müssen?

Ja, und das ist einer der Vorteile eines dynamischen Codes. Da der gedruckte Code stets nur auf die Tracking-URL zeigt, können Sie unnötige Weiterleitungs-Hops entfernen, eine fehlerhaft konfigurierte 301 auf eine 302 umstellen oder ganz zu einem schnelleren Weiterleitungsdienst wechseln, ohne den physischen Code anzufassen. Zeigen Ihre Tracking-Kennzahlen, dass Scans abbrechen, bevor sie das Ziel erreichen, lohnt es sich, das zusammen mit Ihrer umfassenderen QR-Analytics und Ihrem UTM-Setup zu untersuchen, denn eine langsame Weiterleitung kann sich identisch anfühlen wie ein Scan, der einfach nie konvertiert hat.