QR code redirect not working

A QR code redirect not working when the camera already decoded the pattern and the server hop failed. A paused hop to qr-paused, a destination URL down, a landing page not a 302, or a Wi-Fi payload is not a redirect are the usual causes. Confirm the target in a browser, then test-scan on a phone without an old cache.

Why a QR code redirect not working is a server hop

Only four types redirect through the tracker: website URL, WhatsApp, Google review, and location. They hop through the track path for that short code. Landing-page types (menu, PDF, vCard, and the rest of that class) serve a page. Wi-Fi never leaves the phone.

If the iOS Camera banner never appears, this is not a redirect article. Fix the print first.

Scan redirects are 302. A 301 would cache the destination and freeze edits. Hosted codes last as long as the provider resolves them. That is the trade for changing a URL after ink.

A free static generator is the right one-off when you do not need a hop, counts, or edits. Do not buy a redirect you will never look at.

Pause sending scanners to a paused page

Cause: pause is a separate boolean from archive. A paused hosted code can resolve to a paused page while the vinyl still looks perfect. User-archived codes keep scanning, so "I archived it, why do people still land?" is expected.

Fix: resume the code if the campaign is live. If you meant to kill the hop, pause is the lever, not archive. Deleted or expired states are different again; do not assume names from another vendor.

Confirm: scan after resume. You should leave the paused page and land on the current target. A second phone should match. If resume does nothing, the destination URL itself is next.

A destination URL that never loads

Cause: the 302 fired and the target 404s, times out, or blocks the phone. Staff report "QR broken." The symbol worked.

Fix: open the target in Safari and Chrome without scanning. Repair HTTPS, the path, or the WhatsApp number format. Then save the hosted destination.

Confirm: type, then scan. If type works and scan still fails, look at pause, cache, or a preview file. If both fail, stop blaming the generator.

A 301 from another host freezing the old target

Cause: an older short-link host or CDN issued 301. That iPhone still has last month's URL. Your dashboard shows the new one. Fresh Android is correct. This product's hops are 302 so that split should not start here; it still appears when the print came from mixed vendors.

Fix: test on a device that never scanned the 301. If needed, issue a new hosted short URL and print that run. Clearing site data on one staff phone does not fix the field.

Confirm: private browsing on a never-used handset follows the live 302. Document mixed-vendor prints in retail so the next campaign does not reuse the poisoned short link.

Landing-page types that are not F10-F13 redirects

Cause: someone built a menu, PDF, or video page and expected a 302 to an external checkout. Those types serve a landing page. Analytics still record scans; the hop semantics are different. Wi-Fi is the other mismatch: static, not trackable, not a redirect.

Fix: pick website URL when you need a 302 to an external site. Keep landing types when the phone should stay on the page you designed. Do not describe Wi-Fi as a redirect.

Confirm: scan and read the address bar. If you stay on a SmartQRCode landing path, you chose a landing type. If you wanted Google, you wanted a URL or review type. Recreate the code; the printed modules encode the type's URL.

A landing page not a 302 is the type mismatch that burns a day of support. Menu, PDF, video, and vCard serve pages. They record scans. They do not 302 to an external checkout unless you built a website URL type instead. Read the address bar after a test scan. If you remain on a hosted landing path, recreate as website URL when the brief was an external hop.

A Wi-Fi payload is not a redirect, and no amount of dashboard pausing will make it one. If the "redirect" ticket is a guest network join, move to the Wi-Fi troubleshooting path. Confirm by reading the prompt on the phone: join network versus open link. Those are different objects that happen to share a visual language of nested squares.

Deleted or expired hosted states are not pause and not archive. Do not collapse them in the runbook. Test-scan after each dashboard change in isolation. One change, one scan, one note. That is how you stop swapping 302 advice onto a static file.

HTTPS failures look like a broken QR when the destination certificate expired. Type the URL. If the browser warns, fix the certificate, then test-scan. The 302 did its job. The site did not.

When a static URL file is the honest replacement

If the print must work with no provider, no invoice, and no pause state, the payload has to live in the modules. Canva, Google, or in-app iOS static files do that. You lose edits and scan totals.

If you need those, keep the hosted 302 and treat provider resolution as part of the campaign, like keeping DNS paid. A physically perfect print can still stop when resolution stops.

Test-scan after each change: resume, target repair, new short URL, or a true static reprint. One change per test so you know which cause you closed.