What you are seeing
This fix finds whether the page moved, was deleted, or was mistyped, and repairs the right end of the chain. You will check the encoded URL, the redirect rules, and the live site, then either restore the page, add a redirect, or reprint the code. Verify the final page on two phones before you close the job.
Likely causes
1.
Page moved or renamed without a redirect — Quick test: open the old URL and see whether the site redirects to the new address.
2.
Page unpublished or deleted — Quick test: search the site for the page and check whether it still exists.
3.
Typo in the encoded URL — Quick test: decode the payload and compare it with the real page address.
4.
Redirect rule broken or expired — Quick test: follow the redirect chain and note where it stops.
5.
Case or trailing-slash mismatch — Quick test: try the address with the exact case and slash pattern the site uses.
Step-by-step fix
Step 1: Decode the payload and write down the exact URL the code carries.
Step 2: Open the URL and confirm the 404. Search the site for the intended page and note its current address.
Step 3: If the page moved, add a redirect from the old address to the new address.
Step 4: If the page was deleted, restore it, or set the redirect to the closest live page and note the change.
Step 5: If the encoded URL has a typo, regenerate the code from the correct address.
Step 6: If a redirect rule broke, repair the rule or the shortener entry and test it on its own.
Step 7: Retest the corrected code on two phones, following it to the final page, and confirm the page is the intended one.
Putting this into practice
In practice, before any page is moved or deleted, search for the printed codes that point at it. A redirect added on the day of the move is cheap; a redirect added after visitors start hitting 404s is a repair job. 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
- Deleting a campaign page while printed codes still point at it, with no redirect left behind.
- 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 a 404 error will be used.
- Changing the artwork and the placement at the same time, so you cannot tell which change fixed a code that shows a 404 error.- Skipping the proof test because the change looked small, when small changes cause most repeat failures.
Quick checklist
- The final page loads instead of a 404
- A redirect covers the old address if the page moved
- Printed codes point at stable addresses you control
- 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 redirect chain viewer](/qr-redirect-chain-viewer)
- [QR expiry checker](/qr-expiry-checker)
- [QR batch validator](/qr-batch-validator)
- [QR typosquat checker](/qr-typosquat-checker)
- [QR safety checker](/qr-safety-checker)
- [UTM builder](/utm-builder)
- [blog](/blog)
