Rescue a code that is already printed

Check this first

A rescue works by putting one redirect at the address the printed code already opens. So the question that decides everything is whether that address is yours:

• It points at a domain you control · this guide applies. Carry on.
• It points at somebody else's domain · not fixable, by anyone. Everything after the scan happens on a machine you cannot reach.
• It is not a web address at all · WiFi credentials, a contact card or plain text carry their content directly, with no server in the loop. They cannot be changed remotely.

If you are not sure which of those you have, or the code is a dynamic one from another vendor that has stopped working, why did my QR code stop working walks the diagnosis case by case before you spend anything here.

Make the destination first

A rescue needs somewhere to send the traffic, and that has to exist before you set it up · the rescue form deliberately does not offer to create one mid-flow. If you have no dynamic code yet, make one in Links, pointed wherever the printed code should have gone. That code is what you will edit from now on, for the life of the print run.

Claim the printed code

1. Open Rescued printed codes. You can also get there from Static codes with the Printed rescues button.
2. Under Rescue a printed code, fill in The address the printed code opens. Type the address exactly as it is on the print, including the path.
3. Pick Which dynamic code it should reach from the list. If it is empty, the form tells you so and offers Make one first.
4. Choose How you will hand over the hop. We read the printed address and work out which methods are available to you, so you may be offered one option or several. Each comes with its own recipe, written for the platform you are actually on.
5. Press Claim this printed code · 50 credits, once. The charge is on the button, before the click.
6. Install the redirect using the recipe, then press Check now. The row turns to Reaching your code once it works. Until then it reads Waiting for the redirect.

The four handover methods, best first

• Point the hostname at us (DNS) · the strongest, with nothing to install and nothing to maintain. You change the DNS for that hostname and we serve it. The one caution matters: this moves the whole hostname to us, so only use it for a hostname that exists to serve codes. Never point the hostname your website lives on at us.
• A redirect at your origin · the usual answer. One rule on your own server or platform sends that address to your code. The app gives you the exact configuration for your stack rather than a generic instruction.
• Change the destination where it lives · when the printed address is a short link from another service and you still have that account. You point their link at your code and the print run comes with you.
• A script on the page (weakest) · only worth using when your platform has no redirect setting at all. It shows the old page for a moment before moving, does nothing with JavaScript turned off, and search engines treat it as a page rather than a redirect. Do not let this be what backs a large print run.

What it costs, and what the money is for

The charge prices the watching, not the database row. The redirect lives on your server, and that is the real risk in this whole arrangement: a site rebuild, a platform migration or a tidied config file can remove it silently, and a printed code goes dark with nobody watching. So from the moment you claim it we check that address every day, and email you the first time it stops reaching us. That email is careful to say the part people panic about · the printed code is fine, and only the rule at your origin needs fixing.

Things worth knowing

• Five hops is the limit · the checker follows redirects up to five deep. If your address goes through a chain longer than that it reports the chain did not reach your code, which usually means an old redirect is still in the way.
• You are told once, not daily · the breakage email fires when a working rescue first stops working, not every day it stays broken. One alert per failure.
• Set it up promptly · a claim you never finish installing is dropped after a month rather than sitting in the list forever.
• Nothing about the print changes · the symbol, the address and the paper are all untouched. This is the difference between a rescue and a reprint, and it is the only reason the exercise is worth doing.
• You now edit the destination in one place · change the dynamic code and every scan of the printed run follows immediately. That is the position you should have been in before the print, and this is how you get there afterwards.

Questions

Can I change where a QR code goes after it has been printed?

If the printed code points at a web address you control, yes. You install one redirect at that address and point it at a dynamic code, and from then on you change the destination in taproute without touching the print. If the printed code points at a domain somebody else controls, or does not encode a web address at all, then nobody can change it and a reprint is the only path.

Do I need to reprint anything?

No. That is the entire point. The printed symbol keeps encoding exactly what it always did. All that changes is what your server does when someone arrives at that address.

What does the rescue actually buy me?

It costs 50 credits, once, and what that pays for is the watching rather than the row. We check that the printed address still reaches your code every day from then on, and email you the moment it stops. A site rebuild is the usual way a redirect quietly disappears, and without a watcher nobody finds out until the scans have already been lost.

Which handover method should I choose?

Point the hostname at us if the hostname exists only to serve codes · there is nothing to install and nothing to maintain. Otherwise a redirect at your origin is the normal answer. A script on the page is the weakest option and is only worth using when your platform offers no redirect setting at all.

What does a scan cost after the rescue?

The normal 1 credit per scan, like any dynamic code. The rescue charge itself is one-time.

Can I stop a rescue and start it again later?

You can stop watching at any time, and nothing physical changes when you do · the redirect stays on your server and the printed code keeps working. But claiming the same address again later is charged again, and the confirmation says so before you stop.