What you are seeing
The code scans, the browser starts loading, then stops with a too-many-redirects error. The browser followed a chain of redirects that looped back on itself or ran on far longer than it should, and gave up. Redirect loops usually come from conflicting rules: one rule sends visitors from A to B while another sends them from B to A, or a secure-page rule fights a trailing-slash rule. The code itself is innocent; the redirect configuration is the fault.
Likely causes
1.
Two rules that point at each other — One rule sends address A to address B while another sends B back to A, so the browser circles forever. Test: follow the chain and look for an address that repeats.
2.
HTTP to HTTPS rule fighting a www rule — A rule that adds HTTPS and a rule that adds or removes www can bounce visitors between variants that never settle. Test: follow the chain and check whether the scheme and host keep changing.
3.
Trailing-slash rule looping — A rule that adds a slash and another that removes it can bounce the same address back and forth. Test: watch for the same path alternating with and without a trailing slash.
4.
Shortener or campaign tool loop — A short link that points at another short link that points back, or a campaign redirect that targets itself, creates a loop outside the main site. Test: follow the chain from the encoded URL and note where it enters the loop.
5.
Login redirect looping — A page that redirects unsigned visitors to a login, while the login redirects them back to the same page, loops for anyone not signed in. Test: open the destination in a private window while signed out.
Step-by-step fix
1. Decode the payload and write down the encoded URL.
2. Follow the redirect chain hop by hop and write down every address until the loop appears.
3. Find the repeating pair of addresses and the rules that produce them.
4. Remove or correct one of the conflicting rules so the chain ends at the final page.
5. Shorten the chain: point the code at the final address or at one clean redirect.
6. Retest the destination on its own, then the full QR journey, on two phones.
Putting this into practice
In practice, redirect loops are configuration drift: two rules written at different times that nobody noticed were fighting. Keep a list of your redirect rules in one place, and check a rule's full effect before you add it, not after visitors start looping. 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
- Adding another redirect on top of a loop instead of finding and removing the rule that causes it.
- 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 redirects too many times will be used.
- Changing the artwork and the placement at the same time, so you cannot tell which change fixed a code that redirects too many times.- Skipping the proof test because the change looked small, when small changes cause most repeat failures.
Quick checklist
- The redirect chain ends at the final page with no repeated address
- The destination loads on its own without a loop error
- The QR journey reaches the final page 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
- [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)
