Dynamic QR Redirects: 301 vs 302 and What It Does to Your Data

A print run of 40,000 flyers ships on a Monday. Week one brings 3,100 scans. Week two brings 400. Week three, almost nothing. Nobody changed the artwork, the placement, or the offer.

Sometimes that curve is honest campaign decay. Sometimes it is an HTTP status code quietly removing rows from your report.

The Five Steps Hiding Behind One Scan

A dynamic QR code does not carry your landing page address in its modules. It carries a short URL belonging to the service that issued the code. From there:

1. The camera decodes the short URL out of the black and white grid.
2. The phone requests that URL.
3. The redirect service writes a row: timestamp, coarse location inferred from the IP address, device and browser strings, campaign tag if one is attached.
4. The service answers with a redirect pointing at the real destination.
5. The phone follows the redirect and loads your page.

Every number in an analytics panel comes from step 3. A scan that skips step 3 is not a low-quality data point, it is not a data point at all. The mechanics of step 1 are covered in how QR codes work. This piece is about step 4, where the reporting is won or lost.

Permanent Versus Temporary

HTTP gives a server several ways to say "go somewhere else," and they do not mean the same thing to the client that receives them.

301 Moved Permanently states that the resource has a new home and that future requests should go straight there. Clients are allowed to remember that. Browsers cache it, and so can proxies and other intermediaries sitting between the phone and your server.

302 Found states that the detour is temporary. The client should keep using the original URL next time.

307 Temporary Redirect carries the same temporary meaning with stricter rules about preserving the request method, which matters for form submissions more than for a camera opening a link.

A scan is always a plain GET, so the interesting split is not 302 against 307. It is permanent against temporary.

What a Cached Redirect Does to Week Two

Suppose the service returns 301. The first scan on a given phone behaves normally: request, log, redirect, load. On the second scan, the browser may consult its own cache, find the permanent answer it stored earlier, and jump directly to the destination. The redirect service is never contacted. Nothing is logged.

The visible symptom is a scan curve that falls off faster than the campaign does, with repeat visitors vanishing from the QR data while the destination's own web analytics keep showing arrivals. Two systems, two stories, and the QR side is the one that is wrong.

How long a cached permanent redirect survives depends on the browser, its version, and any cache headers that came with the response. Behavior is not consistent across devices, and it is not something you can inspect from your side. The reliable fix is to never create the situation.

The Failure Mode That Costs More Than Data

Undercounting is annoying. The second consequence is worse.

The reason to pay for a dynamic code is that the destination can change after printing. A conference badge points at this year's schedule. A packaging insert points at the current manual. A poster points at whichever promotion is live this month.

If a phone cached a permanent redirect to the old target, editing the destination in your dashboard does not reach that phone. It keeps going where it was told to go the first time. There is no way to push a correction into a cache you do not control, and the person holding the phone has no reason to suspect anything, because the code still "works." It just works incorrectly. That is a nastier variant of the problems in why a QR code stops working, because nothing is visibly wrong with the printed symbol.

Four Questions Worth Asking Before the Print Run

Redirect behavior is an implementation choice, and it is fair to ask about it rather than assume:

• Which status code does the redirect return, and which cache headers accompany it?
• After I change a destination, how quickly does that change take effect for a device that already scanned the code?
• Are repeat scans from the same device counted, deduplicated, or dropped?
• What happens to the code and its history if the subscription lapses?

You can answer the first one yourself in under a minute. Generate a test code, copy the short URL out of it, run curl -I against that URL from a terminal, and read the status line and the Location header. A browser network panel with caching disabled shows the same thing. If the answer is 301 and you need editable destinations, raise it before 40,000 sheets go through a press. A dynamic QR code is only as editable as the weakest cache between the phone and your server.

When the Redirect Is Not Worth It

Not every code needs one. A static code encodes the destination directly. There is no lookup, no logging, no monthly dependency, and nothing to break if a vendor disappears.

What you give up is measurement and the ability to change the target. That trade is reasonable for a Wi-Fi credential on a hotel card, a phone number on a service vehicle, or an asset tag on equipment. It is a poor trade for anything where you plan to compare placements, cities, or time windows, which is the case made in dynamic codes and analytics.

Reading Your Numbers With the Cache in Mind

Even with correct temporary redirects, treat scan counts as an approximate floor rather than an exact figure. Some messaging apps prefetch links before a human taps anything. Some security tools open URLs to inspect them, which inflates counts. Some phones are offline at the moment of the scan, and the request never lands at all.

The useful discipline is comparative. One code per placement, one per city, one per print date, then read the differences between them instead of the absolute totals. Differences survive the noise. Absolute numbers rarely do.