What you are seeing
This fix stops the code sending visitors to someone else's content and proves the destination is yours. You will decode the payload, check for tampering, and repair the link, the redirect, or the physical code. If you find evidence of tampering, replace the physical code and check any other codes in the same location.
Likely causes
1.
Sticker placed over the original code — Quick test: inspect the physical code for a raised edge or a second layer.
2.
Reused code file from another job — Quick test: check the artwork history and the destination it encodes.
3.
Typo in the domain — Quick test: compare the decoded domain with your real domain letter by letter.
4.
Redirect changed or hijacked — Quick test: follow the redirect chain and check the change history.
5.
Short code or shortener collision — Quick test: open the encoded URL on its own and confirm whose content it serves.
Step-by-step fix
Step 1: Take the physical code down or cover it so no more visitors reach the wrong content.
Step 2: Decode the payload and write down the exact URL it contains.
Step 3: Compare the decoded domain with your real domain letter by letter.
Step 4: Inspect the physical code for an overlay sticker, a second layer, or a mismatch with the printed URL beside it.
Step 5: Check the redirect settings and change history, and secure the account if anything was changed without your knowledge.
Step 6: Generate a fresh code from your own domain, with the printed URL beside it so visitors can verify the destination.
Step 7: Inspect every other code in the same location for tampering, and test the replacement on two phones.
Putting this into practice
In practice, treat any report of someone else's content as an incident, not a glitch. Take the code down, check the other codes in the same spot, and find the cause before you put a replacement up, or the replacement can suffer the same fate. Record the before-and-after behaviour with the job file, so the fix is provable rather than anecdotal. When the same failure appears again, that record tells you whether the old fix held or a new cause appeared.
Common mistakes to avoid
- Leaving a tampered code in place while investigating, so more visitors reach the wrong content.
- Reprinting the full run before a single proof passes, which turns one failure into many.
- Testing on one phone in ideal conditions instead of two phones in the real conditions where a code that shows someone else's content will be used.
- Changing the artwork and the placement at the same time, so you cannot tell which change fixed a code that shows someone else's content.- Skipping the proof test because the change looked small, when small changes cause most repeat failures.
Quick checklist
- The decoded domain is your own domain
- The physical code shows no overlay or second layer
- The replacement destination is verified on two phones
- The corrected proof passes on two phones in the real conditions
- The fix is recorded in the job file so the next reprint starts from a proven setup
- Every printed copy is checked against the approved proof
- The proof is retested after any later change to the link, design, or placement
Related tools and guides
- [QR safety checker](/qr-safety-checker)
- [QR typosquat checker](/qr-typosquat-checker)
- [QR phishing pattern trainer](/qr-phishing-pattern-trainer)
- [QR allowlist builder](/qr-allowlist-builder)
- [QR tamper evidence planner](/qr-tamper-evidence-planner)
- [QR scan log](/qr-scan-log)
