What you are seeing
This fix decides whether the login is intended or a mistake, then repairs the link or the page access. You will test the destination while signed out, check who the page is meant for, and make the public journey work without a login where the code promises a public page. Never paper over a login with a shared password printed beside the code.
Likely causes
1.
Link points at a private or draft page — Quick test: open the URL in a private window while signed out.
2.
Page access settings changed — Quick test: check the page access settings and recent changes.
3.
Redirect sends visitors to a login — Quick test: follow the redirect chain and note where the login appears.
4.
Login is genuinely required — Quick test: confirm with the page owner whether the code is meant for signed-in users only.
5.
Shared or expired session link — Quick test: check whether the URL contains a session or token parameter.
Step-by-step fix
Step 1: Open the destination in a private window while signed out and confirm the login prompt.
Step 2: Decide with the page owner whether the page is meant to be public or restricted.
Step 3: If it should be public, fix the access settings or replace the link with the public address.
Step 4: If a redirect sends visitors to a login, fix the redirect rule so it reaches the intended page.
Step 5: If the link carries a session or token, replace it with a clean public link and regenerate the code.
Step 6: If the login is intended, add a clear note beside the code explaining that a login is required.
Step 7: Retest while signed out on two phones and confirm the journey matches the promise beside the code.
Putting this into practice
In practice, keep public codes and private codes in separate records, and never print a private link on a public poster. A public code that asks for a login wastes every scan it receives. 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
- 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)
