Dynamische QR-Codes müssen nicht jeden Scanner zur gleichen URL leiten. Bedingte Weiterleitung – auch Scan-Routing oder regelbasierte Umleitung genannt – ermöglicht es dir, verschiedene Zielgruppen mit einem einzigen gedruckten Code zu unterschiedlichen Zielen zu lenken. Wenn du dir schon immer gewünscht hast, dass dein Mittags-Flyer zum Menü weiterleitet, deine Abend-Besucher zu einem Reservierungsformular und internationale Gäste zu einer lokalisierten Seite, dann ist genau das die richtige Funktion für dich.
Hier erfährst du, wie die nützlichsten Routing-Szenarien funktionieren, was du zuerst einrichten musst und wo häufig Fehler entstehen.
Was „Routing" im Kontext dynamischer QR-Codes bedeutet
Wenn ein Scanner einen dynamischen QR-Code erfasst, ist die Ziel-URL auf einem Server gespeichert – nicht im Code selbst eingebrannt. Diese serverseitige Umleitung ist der Ort, an dem die Routing-Logik lebt. Statt einer einfachen Umleitung („alle Scans → URL A") fügst du bedingte Regeln hinzu:
- Wenn Bedingung erfüllt ist → sende zu URL A
- Sonst → sende zu URL B (Fallback)
Die meisten Plattformen, die diese Funktion unterstützen (manchmal „Multi-URL-QR-Codes" oder „Smart-Redirect-QR-Codes" genannt), erlauben dir, zwei oder drei Regeln zu schichten. Die Fallback-URL ist immer erforderlich. Um zu verstehen, warum die Umleitung auf einem Server lebt und warum das für Routing wichtig ist, schaue dir den umfassenden Vergleich von statischen und dynamischen QR-Codes an.
Szenario 1: Tageszeit-Weiterleitung
Anwendungsfall: Ein Café druckt einen QR-Code auf ein Tischzelt. Morgendliche Scanner sehen die Frühstückskarte; Nachmittags-Scanner sehen die Mittagskarte; abends Scanner sehen die Getränkeliste.
So richtest du es ein:
- Erstelle drei Ziel-URLs (oder Seitenbereiche) für jeden Menü-Zeitraum.
- Füge Zeitregeln in UTC hinzu – bedenke deine lokale Zeitzone.
- Lege den häufigsten Anwendungsfall als Fallback fest, falls Scanner außerhalb der definierten Zeiten eintreff.
Wo es schiefgeht: Teams vergessen, dass die Scan-Zeit standardmäßig in UTC vom Server erfasst wird. Eine Regel für „11:00–14:00" ohne Zeitzone-Einstellung wird zu den falschen Uhrzeiten für Scanner in deiner Stadt auslösen. Bestätige immer, wie deine Plattform mit Zeitzonen umgeht, bevor du druckst.
Weitere praktische Beispiele:
- Veranstaltungsorte leiten vor 19 Uhr zum Pre-Show-Programm, danach nach 21 Uhr zum Merchandise weiter
- Einzelhandelsketten zeigen eine Flash-Sale-Landingpage nur während definierter Promotionsfenster
- Fitnessstudios senden Stundenpläne an Wochentagen und einen Wochenend-Zeitplan am Samstag/Sonntag
Szenario 2: Land- oder Sprach-Weiterleitung
Anwendungsfall: Eine Produktbox wird in 12 Länder versendet. Ein QR-Code leitet englischsprachige Märkte zu einer englischen Support-Seite, französischsprachige Märkte zur französischen Version und alle anderen zu einem Sprachwahlseite.
So richtest du es ein:
- Die Routing-Engine erkennt das Land des Scanners via IP-Geolokalisierung.
- Ordne spezifische Ländercodes zu (US, GB, CA → Englische Seite; FR, BE, CH → Französische Seite; DE → Deutsche Seite).
- Stelle die Sprachwahlseite als globales Fallback ein.
Intern zu dokumentierende Einschränkungen:
- IP-Geolokalisierung ist auf Länderebene zu etwa 95–99 % genau, aber VPN-Nutzer werden falsch geroutet. Das ist für die meisten Anwendungsfälle akzeptabel.
- Routiere nicht nach Sprachpräferenz aus dem Browser – QR-Scan-Anfragen übergeben Accept-Language-Header nicht zuverlässig durch alle Apps.
- Wenn deine Plattform pro Ziel-URL oder pro Regel berechnet, ordne Ländergruppen zusammen, statt 40 einzelne Länder aufzulisten.
Szenario 3: Gerätetyp-Weiterleitung
Anwendungsfall: Eine Software-Firma schaltet Anzeigen in Fachmaga und Entwickler-Newslettern. iOS-Nutzer gehen zum App-Store-Listing; Android-Nutzer zu Google Play; Desktop-Scanner (jemand fotografiert die Anzeige mit der Laptop-Kamera) gehen zur Web-App.
So richtest du es ein:
- Die Plattform liest den User-Agent-String aus der Scan-Anfrage.
- Route
iOS→ App-Store-URL;Android→ Play-Store-URL;Sonstiges/Desktop→ Web-App.
Warum das wichtig ist: App-Store-Weiterleitungsseiten sind berüchtigt darin, Plattformen nicht automatisch zu erkennen. Android-Nutzer zu einem App-Store-Link zu senden, erzeugt einen Fehler und tötet Conversions. Geräte-Routing löst das sauber, ohne dass du eine benutzerdefinierte Smart-Banner-Implementierung auf deiner Website brauchst.
Szenario 4: Regeln kombinieren (Multi-Condition Routing)
Manche Plattformen lassen dich Regeln stapeln – zum Beispiel Land UND Gerät. Ein häufiges Setup in der Praxis:
| Priorität | Bedingung | Ziel |
|---|---|---|
| 1 | Land = US + Gerät = iOS | US App Store |
| 2 | Land = US + Gerät = Android | US Play Store |
| 3 | Land = DE | Deutsche Landingpage |
| 4 | Fallback | Globale Landingpage |
Regeln werden von oben nach unten ausgewertet, daher ist die Reihenfolge wichtig. Setze die spezifischsten Bedingungen zuerst, breite geografische Regeln in der Mitte und das Fallback zuletzt. Das ist leicht falsch zu sequenzieren – teste immer jede Bedingung mit einem echten Gerät und, wenn möglich, mit einem VPN im relevanten Land, bevor du zum Druck gehst.
Was du pro Route verfolgen kannst
Routing ist nur die halbe Miete. Jede Ziel-URL sollte UTM-Parameter tragen, damit du die Leistung nach Zielgruppensegment in deiner Analytics-Plattform trennen kannst. Ein Scan, der zur französischen Seite geroutet wird, sollte ?utm_source=qr&utm_medium=print&utm_content=fr auslösen, damit du ihn von einem generischen Scan unterscheiden kannst.
Für einen tieferen Blick auf die Metriken, die du aus deinem QR-Dashboard herausholst, behandelt der Guide zu QR-Code-Analytics, die wirklich Entscheidungen treffen, Scan-zu-Conversion-Tracking im Detail.
Du kannst auch Routing-Logs verwenden, um unerwartete Traffic-Muster zu identifizieren – wenn 40 % der Scans bei einem nur für UK gedachten Print-Run das „Non-UK-Fallback" auslösen, muss deine Geolokalisierungs-Konfiguration überprüft werden, bevor du Ausgaben skalierst.
Plattform-Checkliste vor der Festlegung auf Routing
Nicht jede dynamische QR-Plattform unterstützt bedingtes Routing. Bevor du dich für eine entscheidest, bestätige:
- Tageszeit-Regeln mit Zeitzone-Auswahl (nicht nur UTC)
- Land-/Regions-Geolokalisierungs-Routing
- Gerätetyp-Erkennung (iOS / Android / Sonstiges Minimum)
- Regel-Stapelung oder Multi-Condition-Support
- Pro-Regel-Scan-Analytics, nicht nur Gesamtsummen
- Fallback-URL ist immer erforderlich und bearbeitbar
Wenn dein aktuelles Tool diese Funktionen fehlen, unterstützt Super QR Code Generator bedingtes Routing über Zeit, Land und Gerät mit Per-Regel-Analytics inklusive.
Wichtigste Erkenntnisse
- Routing sendet verschiedene Scanner zu verschiedenen URLs von einem einzigen gedruckten QR-Code aus, indem serverseitige Redirect-Logik verwendet wird.
- Tageszeit-Routing erfordert korrekte Zeitzone-Konfiguration – UTC-Standards werden in den meisten Märkten fehlschlagen.
- Land-Routing nutzt IP-Geolokalisierung, die auf Länderebene zuverlässig ist, aber bei VPN-Nutzern fehlschlägt.
- Geräte-Routing ist die sauberste Lösung für App-Download-Kampagnen, die iOS- und Android-Ziele trennen müssen.
- Füge immer UTM-Parameter zu jeder gerouteten URL hinzu, damit die Downstream-Analytics segmentiert bleiben.
- Teste jede Routing-Regel mit einem echten Gerät (und idealerweise einem VPN) vor dem Drucken in großem Maßstab.