Dev.to WebDev 🛠 Dev 👁 0 📖 8 min read

How to keep shared short links and QR codes working when a campaign destination changes

Disclosure: I work with JE4NDEV, the remote studio that built URLPivot. This article explains a durable pattern for campaign links and QR codes. URLPivot is one product that implements that pattern; every product claim b

Disclosure: I work with JE4NDEV, the remote studio that built URLPivot. This article explains a durable pattern for campaign links and QR codes. URLPivot is one product that implements that pattern; every product claim below is taken from its public pages, and every general HTTP, UTM or QR claim links to official docs at the end. Self-serve links only: no call or meeting pitch.

You ship a SaaS waitlist. The short link goes into the launch newsletter. The QR goes on conference badges and a one-pager at the booth. Two weeks later the waitlist should become the public docs, or the beta signup should move to a new subdomain. The destination changed. The shared and printed addresses did not.

That is when campaigns quietly break. People still open the old URL. The page 404s, lands on an unrelated homepage, or shows a stale offer. The QR did not fail. It still encodes the same string. The string still points at a place that is no longer useful.

The problem: the destination moves after the share

A campaign URL has two lives:

  1. The public address people click, copy or scan: the short link in email, the QR on a badge, the link in a launch thread.
  2. The destination: the waitlist, docs section, pricing page or changelog that you want them to land on today.

Those lives diverge as soon as something gets printed or forwarded. A PDF in an inbox, a laminated badge, a newsletter that already went out: none of them update when the product moves.

Minting a new short link and asking everyone to switch splits click history and leaves the old QR opening the wrong flow.

How redirects and short links work (high level)

At HTTP level, a redirect is simple. The browser requests a URL. The server answers with a 3xx status and a Location header. The browser follows it. MDN's guide on HTTP redirections states that redirect responses have status codes that start with 3, and a Location header holding the URL to redirect to.

Two shapes matter for campaigns:

  • A temporary redirect (for example 302 or 307) says the destination may change again; crawlers should not treat it as the permanent home.
  • A permanent redirect (for example 301 or 308) says the public URL has moved for good.

A managed short link is a stable public URL your tool resolves with a redirect to the destination you configured. The visitor barely notices the hop. You care, because that hop is where you change the destination without changing the public address.

QR codes sit one layer below. ISO/IEC 18004 defines how a QR symbol encodes data. It does not define what the payload means. If the payload is a URL, the phone opens that URL and normal HTTP rules apply. Change the bytes inside the QR and you need a new print. Keep the same URL string and you can change what that URL does on the server.

Why hardcoding the destination fails

Hardcoding means the public address is the destination: the newsletter links straight to /waitlist-oct, the badge QR encodes a full docs path with UTM query params, the one-pager prints a changelog URL. That works until the path, host, offer or tracking changes. Then every channel that already carried the old string is wrong.

UTM parameters make the trap sharper. Google's Analytics help on custom campaign URLs says you add utm_source, utm_medium, utm_campaign (and related fields) to the destination URLs used in referral links. If those parameters are baked into a printed QR, you cannot retag without reprinting. If they live on the destination behind a stable public URL, you can adjust tagging when the offer moves.

The design pattern: stable public URL → editable destination

Treat the thing you share and print as infrastructure, not as the offer:

  1. Create one stable public URL for each durable entry point (newsletter CTA, badge, packaging insert).
  2. Point that URL at the current destination through a redirect you control.
  3. When the campaign evolves, edit the destination. Do not mint a new public URL unless the campaign itself is new.
  4. Keep the QR image generated from the stable public URL. Archive that PNG or SVG with the campaign so reprints stay identical.

Examples that fit product and SaaS work:

  • SaaS launch: …/go/launch → waitlist today, docs tomorrow, pricing after GA.
  • Product docs: …/go/docs-start → the current "start here" guide after a docs reorg.
  • Conference badge: …/go/conf-2026 → live demo signup during the event, then the on-demand recording.
  • Email newsletter: …/go/issue-47-cta → the feature post; later a follow-up survey, without editing archived HTML.
  • Print for a product campaign: packaging insert or booth poster → the current campaign landing page while creative iterates.

The shared artifact stays put. Only the redirect target moves.

Practical checklist before you share or print

  1. Decide the durable entry points. One public URL per channel that will outlive a single destination. Do not reuse one public URL for unrelated campaigns if you need clean history.
  2. Put UTMs on the destination, not inside the printed code. Build the tagged destination with Google's Campaign URL Builder or by hand (utm_source, utm_medium, utm_campaign at minimum). Set the managed link's destination to that tagged URL. The QR encodes only the stable public URL.
  3. Test the redirect the way a stranger will. Open the public URL in a private window on phone and desktop. Confirm the final page matches today's offer.
  4. Export and archive the QR of the stable URL. Future reprints must regenerate from the same public URL, not from whatever destination is current that day.
  5. Group related entry points. Badge + newsletter + docs CTA can be separate managed links under one campaign Page or workspace so destinations move together.
  6. Prefer temporary semantics while the offer is still moving. Switch to permanent only when the public URL itself is retiring.
  7. Know the fixed-content caveat. Some QR payloads are not ordinary URLs. URLPivot's public site notes that Pix has fixed QR content: changing a managed link destination does not rewrite a Pix QR the way it rewrites a URL QR.
  8. If agents help operate links, scope their permissions. Prefer workspace-scoped tokens that can list links and change destinations without billing or admin powers. Revoke when the campaign ends.

One product that implements the pattern (URLPivot)

Disclosure (product): URLPivot is built by JE4NDEV. I am writing about it because we built it for this failure mode. Try it yourself; do not take marketing copy as proof of your results.

From the public product pages, URLPivot offers links, QR codes and Pages for what comes after sharing: change destinations without replacing the link or QR you already shared. That maps to:

  • a managed link with a stable public address and an editable destination
  • a reusable QR for that public address
  • Pages that gather managed links into one focused public destination, with button destinations you can update without rebuilding the Page
  • views and clicks, plus campaign signals the site describes as including referrer and approximate country; the JE4NDEV project page also notes human/bot traffic signals without retaining raw IP addresses
  • workspaces to separate client or brand work, with an option on paid plans to connect an eligible domain
  • workspace-scoped MCP access: connect an MCP client with a revocable workspace token; operate links and Pages within token permissions; no billing or administration access (the project page adds that agents can list and create links and change destinations, without billing, deletion, admin or DNS permissions)

Self-serve entry points:

The public site does not establish customer volume, revenue or campaign performance. Use the demo or Free plan to verify the pattern on your own links.

Wrap-up

Shared links and printed QR codes fail less often when you stop treating the destination as the thing you publish. Publish a stable public URL. Point it at today's destination with a redirect you control. Put UTMs on that destination. Archive the QR of the stable URL. When the campaign moves (waitlist to docs, live demo to recording, launch page to pricing), edit the destination and leave the badges, newsletter archive and packaging insert alone.

To try a product that already wires the pattern together, start at urlpivot.app or create a Free account at urlpivot.app/signup. If you only needed the checklist, you can implement the same idea with any redirect you fully control.

Fact sources

Unverified / out of scope (flagged)

  • No public /docs page was found at urlpivot.app/docs (HTTP 404 at research time); do not invent doc URLs.
  • Exact redirect status code URLPivot returns per hop (301 vs 302 vs 307 vs 308) is not stated on the public pages reviewed; the article therefore speaks in general MDN terms only.
  • "Human/bot traffic signals" and "without retaining raw IP addresses" are taken from the JE4NDEV project page wording; raw implementation detail beyond that page is unverified.
  • Catalogue examples on the URLPivot homepage (fictional Pages) are illustrative only and are not used as customer proof here.
  • No customer counts, open rates, scan rates or revenue figures are claimed; none are published as verified metrics on the pages above.
📰 Read the original article on Dev.to WebDev

Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.

Share 𝕏 Twitter ✈ Telegram ↗ Reddit 🟧 HN
← News 🛠 Dev 🏠 Home