What you are seeing
The code scans, but the page shows old content: a past event, an expired offer, last season's prices, or a superseded notice. The scan worked and the link may be exactly the one you printed, which is what makes this failure sneaky: nothing looks broken until someone reads the content. Outdated pages come from codes that point at content nobody updates, or at pages whose updates never reach the printed copies. The fix is to point printed codes at content you maintain, and to refresh the destination before the old content embarrasses you.
Likely causes
1.
Code points at a frozen campaign page — A campaign page that is never updated keeps showing its original content long after the campaign ends. Test: compare the page content with the current offer or notice.
2.
Redirect still points at an old page — A redirect that was never updated after a content refresh keeps sending visitors to the superseded version. Test: follow the redirect chain to the final page and check its content.
3.
Cached page served to visitors — A cached copy of the page can keep showing old content even after the live page is updated. Test: open the page in a private window and compare it with the edited version.
4.
Code reused from an old campaign — An old code file reused for a new campaign carries its old destination with it. Test: check the artwork history and the destination it encodes.
5.
Content updated in one place but not the other — A business can update a page in one language, channel, or system while the QR destination still serves the old version. Test: compare the QR destination with the current source of truth.
Step-by-step fix
1. Decode the payload and open the destination to confirm the outdated content.
2. Find the current content and its correct address.
3. Update the page if it is meant to be live, or redirect the code to the current page.
4. Clear or check the cache so visitors get the updated version.
5. If the code was reused from an old campaign, regenerate it from the current destination.
6. Retest on two phones and confirm the final page shows current content.
Putting this into practice
In practice, printed codes need a content owner and a review date. A code with no owner keeps pointing at content nobody checks, and the first person to notice the stale page is a visitor. Give every printed code a review date and a named owner, and check the destination when the date arrives. Keep a short note of what you tested, what failed, and what you changed, so the next person starts from evidence rather than guesswork. A fix that is written down survives staff changes and reprints; a fix that lives only in memory gets repeated.
Common mistakes to avoid
- Reprinting a code that points at a campaign page nobody owns, so the content goes stale again within weeks.
- 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 an outdated page will be used.
- Changing the artwork and the placement at the same time, so you cannot tell which change fixed a code that shows an outdated page.- Skipping the proof test because the change looked small, when small changes cause most repeat failures.
Quick checklist
- The final page shows current content on two phones
- Redirects point at the current page
- The destination has an owner and a review date
- 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)
