What you are seeing
This fix makes the map code point at the right place. You will decode the location, check it against the real address, and rebuild the code with verified coordinates. Verify the fix by scanning and comparing the pin with the real location on two phones.
Likely causes
1.
Coordinates mistyped in the payload — Quick test: decode the payload and read the coordinates.
2.
Address ambiguous or misread — Quick test: search the address in the map service and compare the pin.
3.
Map link points at the wrong place — Quick test: open the link and compare the pin with the intended place.
4.
Pin placed on the building, not the entrance — Quick test: compare the pin with the entrance visitors should use.
5.
Outdated map data — Quick test: compare the map with the real location on the ground.
Step-by-step fix
Step 1: Decode the payload and write down the exact location it carries.
Step 2: Open the location in the map service and compare the pin with the real place.
Step 3: Find the correct coordinates for the entrance visitors should use, and write them down.
Step 4: Rebuild the code with the verified coordinates, using the map generator or a verified map link.
Step 5: Scan the rebuilt code on two phones and compare the pin with the real location.
Step 6: If the pin still lands wrong, check for swapped coordinates, a missing minus sign, or an ambiguous address.
Step 7: Retest the final code on two phones and confirm the pin lands on the entrance visitors should use.
Putting this into practice
In practice, keep the verified coordinates in the job file alongside the address. When the code is reprinted, the coordinates are checked against the record instead of being copied from memory. 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
- Copying a map link from the wrong pin and sending visitors to the wrong end of the site.
- 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 map shows the wrong place 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 map shows the wrong place.- Skipping the proof test because the change looked small, when small changes cause most repeat failures.
Quick checklist
- The decoded coordinates match the intended entrance
- The pin lands on the right place on two phones
- The coordinates are recorded in the job file
- 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 payload inspector](/qr-payload-inspector)
- [QR redirect chain viewer](/qr-redirect-chain-viewer)
- [QR expiry checker](/qr-expiry-checker)
- [QR placement guide](/qr-placement-guide)
- [QR safety checker](/qr-safety-checker)
- [blog](/blog)
