What you are seeing
This fix restores the review page behind the code. You will test the review link on its own, check the platform and the page, and repair whichever step blocks it. Verify the fix by scanning and reaching a working review form on two phones.
Likely causes
1.
Review link expired or changed — Quick test: open the review link directly.
2.
Review platform blocking the visit — Quick test: open the link in a second browser and while signed in.
3.
Redirect dropping the review target — Quick test: follow the redirect chain and watch the review identifier.
4.
Page script or pop-up blocking the form — Quick test: check whether the page loads without the form.
5.
Link mistyped in the payload — Quick test: decode the payload and compare the link with the intended review link.
Step-by-step fix
Step 1: Decode the payload and write down the exact review link it carries.
Step 2: Open the review link directly in a phone browser. If it fails there, the destination is the problem.
Step 3: Follow the redirect chain and check that it preserves the review identifier all the way to the final page.
Step 4: If the link changed or expired, get the current review link from the platform and regenerate the code.
Step 5: If the page loads without the form, fix the page or link to the review form directly.
Step 6: Test the destination in a second browser and while signed in, to separate a platform block from a link fault.
Step 7: Retest by scanning the code on two phones and reaching a working review form.
Putting this into practice
In practice, keep the review link under regular check, because review platforms change their links and rules. A review code that worked at launch can fail months later when the platform changes, and the first person to notice is a visitor whose feedback is lost. 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
- Assuming a review QR code still works months after launch without ever retesting the destination.
- 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 review page will not load 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 review page will not load.- Skipping the proof test because the change looked small, when small changes cause most repeat failures.
Quick checklist
- The review link loads directly in a phone browser
- Redirects preserve the review target
- Scanning reaches a working review form on two phones
- 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
- [survey QR code generator](/survey-qr-code-generator)
- [feedback QR code generator](/feedback-qr-code-generator)
- [QR payload inspector](/qr-payload-inspector)
- [QR redirect chain viewer](/qr-redirect-chain-viewer)
- [QR expiry checker](/qr-expiry-checker)
- [UTM builder](/utm-builder)
