Dynamic QR Routing: Send Scanners to Different URLs Automatically

Dynamic QR codes don't have to send every scanner to the same URL. Conditional routing — also called scan routing or rule-based redirects — lets you point different audiences to different destinations using a single printed code. If you've ever wished your lunchtime flyer could redirect to your menu, your evening crowd to a reservation form, and your international visitors to a localised page, that's exactly what this feature enables.

Here's how the most useful routing scenarios work, what to set up first, and where people commonly go wrong.

What "Routing" Actually Means in a Dynamic QR Context

When a scanner hits a dynamic QR code, the code's destination URL is stored on a server — not baked into the code itself. That server-side redirect is where routing logic lives. Instead of a flat redirect ("all scans → URL A"), you add conditional rules:

• If condition is met → send to URL A
• Else → send to URL B (the fallback)

Most platforms that support this (sometimes called "multi-URL QR codes" or "smart redirect QR codes") let you layer two or three rules. The fallback URL is always required. Understanding the difference between static and dynamic behaviour is foundational here — the complete breakdown of static vs dynamic QR codes explains why the redirect lives on a server and why that matters for routing.

Scenario 1: Time-of-Day Routing

Use case: A café prints one QR code on a table tent. Morning scanners see the breakfast menu; afternoon scanners see the lunch menu; evening scanners see the drinks list.

How to set it up:

1. Create three destination URLs (or page sections) for each menu period.
2. Add time rules in UTC — remember to account for your local timezone offset.
3. Set the most common use case as the fallback in case a scanner hits outside defined hours.

Where it goes wrong: Teams forget that scan time is server-recorded in UTC by default. A rule set for "11:00–14:00" without a timezone setting will fire at the wrong hours for scanners in your city. Always confirm your platform's timezone handling before printing.

Other practical examples:

• Event venues routing to a pre-show programme before 7 pm, then post-show merch after 9 pm
• Retailers showing a flash-sale landing page only during defined promotional windows
• Gyms sending class schedules on weekdays and a weekend timetable on Saturdays/Sundays

Scenario 2: Country or Language Routing

Use case: A product box ships to 12 countries. One QR code routes English-speaking markets to an English support page, French-speaking markets to the French version, and everyone else to a language selector.

How to set it up:

1. The routing engine detects the scanner's country via IP geolocation.
2. Map specific country codes (US, GB, CA → English page; FR, BE, CH → French page; DE → German page).
3. Set the language-selector page as the global fallback.

Caveats to document internally:

• IP geolocation is accurate to country level roughly 95–99% of the time, but VPN users will misroute. This is acceptable for most use cases.
• Don't route by language preference detected from the browser — QR scan requests don't reliably pass Accept-Language headers through all apps.
• If your platform charges per destination URL or per rule, map country groups together rather than listing 40 individual countries.

Scenario 3: Device-Type Routing

Use case: A software company's print ad runs in both a trade magazine and a developer newsletter. iOS users go to the App Store listing; Android users go to Google Play; desktop scanners (someone photographing the ad on their laptop camera) go to the web app.

How to set it up:

1. The platform reads the User-Agent string from the scan request.
2. Route iOS → App Store URL; Android → Play Store URL; Other/Desktop → web app.

Why this matters: App Store redirect pages are notoriously bad at auto-detecting platform. Sending Android users to an App Store link produces an error and kills conversions. Device routing solves this cleanly without requiring a custom smart-banner implementation on your website.

Scenario 4: Combining Rules (Multi-Condition Routing)

Some platforms let you stack rules — for example, country AND device. A common real-world setup:

Rules are evaluated top-to-bottom, so order matters. Put the most specific conditions first, broad geographic rules in the middle, and the fallback last. This is easy to mis-sequence — always test each condition with a real device and, if possible, a VPN set to the relevant country before going to print.

What You Can Track Per Route

Routing is only half the picture. Each destination URL should carry UTM parameters so you can separate performance by audience segment in your analytics platform. A scan routed to the French page should fire ?utm_source=qr&utm_medium=print&utm_content=fr so you can distinguish it from a generic scan.

For a deeper look at which metrics to pull from your QR dashboard, the guide to QR code analytics that actually drive decisions covers scan-to-conversion tracking in detail.

You can also use routing logs to identify unexpected traffic patterns — if 40% of scans on a UK-only print run are triggering the "non-UK fallback," your geolocation setup needs checking before you scale spend.

Platform Checklist Before You Commit to Routing

Not every dynamic QR platform supports conditional routing. Before choosing one, confirm:

• Time-of-day rules with timezone selection (not just UTC)
• Country/region-level geolocation routing
• Device-type detection (iOS / Android / Other minimum)
• Rule stacking or multi-condition support
• Per-rule scan analytics, not just aggregate totals
• Fallback URL is always required and editable

If your current tool lacks these, Super QR Code Generator supports conditional routing across time, country, and device with per-rule analytics included.

Key Takeaways

• Routing sends different scanners to different URLs from a single printed QR code, using server-side redirect logic.
• Time-of-day routing requires correct timezone configuration — UTC defaults will misfire in most markets.
• Country routing uses IP geolocation, which is reliable at the country level but fails for VPN users.
• Device routing is the cleanest fix for app download campaigns that need to separate iOS and Android destinations.
• Always add UTM parameters to each routed URL so downstream analytics remain segmented.
• Test every routing rule with a real device (and ideally a VPN) before printing at scale.