QR code wrong destination

A QR code wrong destination means the camera decoded something, just not the page you meant. Two tent cards in frame, a static URL left in modules, a 301 cache, or a preview path encoded in ink explain almost every case. Type the URL first, then confirm with a test scan on a fresh phone.

Why a QR code wrong destination is rarely the ink quality

If modules are sharp enough to decode, contrast and size already worked. The payload in the symbol, a second symbol in the same photo, or a cached hop is next. Menu tents fail this way when a lunch card and a dinner card sit together.

Open the intended page in a browser without scanning. If that page is already wrong, fix the site. If that page is right, the print or the redirect cache is lying.

Hosted website and landing-page types can change the hop without reprinting because the pattern encodes a SmartQRCode URL. A static file cannot. Pause is not the same as a wrong URL: pause stops the hop; archive keeps scanning. A dashboard edit versus 301 cache is the other fork: the row looks updated and one phone still opens last week.

A Canva one-off is the right tool when the URL will never move. It is the wrong tool when you are about to reprice a PDF weekly.

Two tent cards in one camera frame

Cause: the reader returns one symbol, not an average. A guest frames both the wine list code and the Wi-Fi code. Staff report "it goes to the network join" as if the menu file were corrupt.

Fix: separate the codes in space. Do not pair a hosted menu hop with a static Wi-Fi payload on the same small tent unless you accept mixed behaviour. Put Wi-Fi on the table edge and the menu on the stand, or use one camera-width of empty cloth between them.

Confirm: cover one code with your hand and scan the other. If the "wrong" destination vanishes, the camera was choosing a neighbour. Brief staff. Reprint only if both payloads are genuinely wrong.

A static payload that still encodes last week's URL

Cause: the modules store the destination. Changing the website does not change last month's flyers. Wi-Fi is the same class: not editable after printing, not a redirect. People still talk about "updating the QR" as if it were a hosted short link.

Fix: if you need edits after ink, recreate as a dynamic URL. Point the old static run at a notice on the site if you still control that old URL. You cannot patch the paper.

Confirm: scan a leftover flyer and a new hosted card. If only the leftover opens the retired page, the static payload was the cause. Stop printing the old file. Test-scan the new file on a second phone.

Dashboard edit that never reached scanners on a 301 cache

Cause: HTTP 301 lets browsers and some apps cache the destination, so later edits never reach those scanners. This product uses 302 on scan redirects so edits stay live. A previous vendor, a CDN rule, or an in-app webview that stored a 301 will still show last week's site on that device.

Fix: change the hosted target again and test on a device that never scanned the old hop. If that device is correct and a regular guest phone is not, you are in cache, not in the dashboard. A new short URL is the clean break when you do not control the old 301.

Confirm: private Safari on a fresh iPhone should follow the current 302. If it does, document that some staff phones need site data cleared. Do not reprint yet.

Preview screenshots that encode /qr-preview not the live hop

Cause: the layout used a capture of the on-screen preview. That pattern encodes /qr-preview, so a "successful" scan opens a mock, not your campaign URL.

Fix: delete the screenshot. Download PNG, JPG, SVG, or PDF from the generator and plate that. Pay before you treat the preview as live; the preview is not the live payload.

Confirm: scan the new press proof. If the phone now opens the real destination, the mock was the cause. Keep the old screenshot out of the brand library.

A WhatsApp hop that still opens last week's pre-filled message is the same class as a static URL: you are reading whatever the modules or the cached hop still hold. Change the hosted message if the type is WhatsApp and the print is hosted. Reprint if someone generated a static wa.me string into the modules with another tool.

Location types open whatever maps app the phone has set. There is no guarantee of Google Maps on iPhone. A "wrong destination" report that is Apple Maps versus Google is OS behaviour, not a corrupt file. Confirm by opening the same maps URL in Safari without scanning. If both go to the same pin, the code worked. Change the guest caption if you needed a named app.

If the press file still encodes /qr-preview, every "wrong destination" ticket is the mock. Replace the art, keep the old screenshot out of the brand library, and test-scan the new proof on two phones.

When you should reprint versus retarget the hosted URL

Reprint when the modules encode a static URL, a Wi-Fi string, or /qr-preview. Retarget when the modules encode your hosted short URL and a fresh phone already gets the right page.

If a throwaway poster has a wrong URL and you will never count scans, generate a corrected one-off in Canva or Google and print that. Do not open a hosted account to fix one poster. If the run is 5,000 menus, hosted retargeting is the point of the encoding.

User-archived codes still hop. If "wrong destination" is actually a paused page, resume or pick a new target; do not blame the printer.