What you are seeing
This fix makes the code open the app where the app is available, and a useful page everywhere else. You will decode the payload, check the app link setup, and test the journey on phones with and without the app. Verify the fallback as well as the app launch, because the fallback is what most visitors will actually see.
Likely causes
1.
Link points at the app, not the content — Quick test: open the link on a phone without the app.
2.
App link association not set up — Quick test: check the app link setup for the domain.
3.
App not installed on the phone — Quick test: check whether the app is installed on the failing phone.
4.
Redirect breaks the app link — Quick test: follow the redirect chain and compare the app behaviour.
5.
Link mistyped or outdated — Quick test: decode the payload and compare the link with the intended app page.
Step-by-step fix
Step 1: Decode the payload and write down the exact link it carries.
Step 2: Test the link on a phone with the app installed and on a phone without it.
Step 3: If the app does not launch on a phone that has it, check the app link association for the domain.
Step 4: If a redirect breaks the handover, point the code at the final link or fix the redirect.
Step 5: If the link is mistyped or outdated, regenerate the code from the correct app page link.
Step 6: Add a web fallback page so visitors without the app still reach the content.
Step 7: Retest on two phones, one with the app and one without, and confirm both journeys work.
Putting this into practice
In practice, test every app code on two phones: one with the app and one without. A code that only passes on the phone with the app is a code that fails for most visitors. 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
- Pointing a public QR code at an app-only link with no web fallback for visitors who lack the app.
- 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 scans but the app will not open will be used.
- Changing the artwork and the placement at the same time, so you cannot tell which change fixed a code that scans but the app will not open.- Skipping the proof test because the change looked small, when small changes cause most repeat failures.
Quick checklist
- The link opens the app where the app is installed
- Visitors without the app reach a useful web page
- The journey passes on two phones, with and without the app
- 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
- [app store QR code generator](/app-store-qr-code-generator)
- [QR payload inspector](/qr-payload-inspector)
- [QR redirect chain viewer](/qr-redirect-chain-viewer)
- [QR expiry checker](/qr-expiry-checker)
- [QR scan log](/qr-scan-log)
- [QR safety checker](/qr-safety-checker)
