What you are seeing
The code scans, but instead of the expected page the visitor meets a login screen. A login prompt usually means the destination requires authentication, or the link points at a private version of the page rather than the public one. Sometimes the link is correct and the page genuinely needs a login, in which case the code is working and the expectation is wrong. The fix starts by deciding which of those is true, because a private page and a wrong link need opposite repairs.
Likely causes
1.
Link points at a private or draft page — A link copied from an editing view, a preview, or a members-only area carries its access requirement with it. Test: open the URL in a private window while signed out.
2.
Page access settings changed — A page that was public can become restricted when permissions change, a membership rule is added, or a document is moved to a private folder. Test: check the page access settings and recent changes.
3.
Redirect sends visitors to a login — A redirect rule can send public visitors to a login page when the target page is restricted or the rule is misconfigured. Test: follow the redirect chain and note where the login appears.
4.
Login is genuinely required — Some destinations, such as an account page or a members area, legitimately require a login. Test: confirm with the page owner whether the code is meant for signed-in users only.
5.
Shared or expired session link — A link that carries a session, a token, or a one-time view can demand a fresh login from anyone else. Test: check whether the URL contains a session or token parameter.
Step-by-step fix
1. Open the destination in a private window while signed out and confirm the login appears.
2. Decide whether the page is meant to be public or restricted.
3. If it should be public, fix the page access settings or point the code at the public version.
4. If a redirect causes the login, fix the redirect rule.
5. If the login is intended, add a clear note beside the code so visitors know before they scan.
6. Retest the journey while signed out on two phones.
Putting this into practice
In practice, the login surprise comes from copying a link while signed in. The link works for the person who copied it and demands a login from everyone else. Always test a new code in a private window while signed out, because that is the state your visitors are in. 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
- Printing a shared password beside the code to work around a login that should not be there.
- 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 asks for a login will be used.
- Changing the artwork and the placement at the same time, so you cannot tell which change fixed a code that asks for a login.- Skipping the proof test because the change looked small, when small changes cause most repeat failures.
Quick checklist
- The destination behaves correctly while signed out
- The code points at the public version where the page is public
- Any required login is explained beside the code
- 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)
