Dynamic QR Codes

Short links

Every QR code encodes an address on your store. By default that’s yourstore.com/?qrcw=k7m2xa — already short. Turn on short links and new codes use yourstore.com/q/k7m2xa instead. It’s off by default, it lives in QR Codes → Settings → Links & tracking, and it’s in the free plugin.

Why use short links

A shorter address makes a less dense code: fewer, bigger squares. That matters when you print small — a hangtag, a jar label, a sticker on a box — or when the code will be scanned from a distance or in poor light. A less dense code scans faster and more reliably.

Turn them on

  1. Go to QR Codes → Settings → Links & tracking. The Short links card is the first one on the tab.
  2. Switch on Use short links (/q/…) for new QR codes. It saves straight away.
  3. Create your next code as usual. Its address now starts with /q/.

New codes only — printed codes keep working

The setting only decides the address of codes you create from now on. A code’s address never changes once it exists, so codes you already printed keep their ?qrcw= address. Both kinds keep working, whichever way the setting is.

Turning short links off later is safe too: new codes go back to the standard address, and every /q/ code you already made keeps opening. Once a short-link code exists, the plugin keeps answering at /q/ for good.

Want an existing code on a short link? Create a new code — the old address can’t be switched, because it’s what’s printed.

Why the address may show in capitals

When your store sits at the root of its domain (yourstore.com, not yourstore.com/shop), a short-link code stores its address in capitals: YOURSTORE.COM/Q/K7M2XA. QR codes pack capital letters more tightly than lowercase, so the same address fits into fewer squares.

Some phone cameras show the address that way before opening it. That’s expected: it opens the same page. Everywhere you read the address in the admin — and the link you copy — it’s shown in lowercase. On a store in a sub-folder the code stays lowercase.

A /q/ address only reaches WordPress when your permalinks use any setting other than Plain (Settings → Permalinks). The ?qrcw= addresses don’t care about permalinks; short links do. The plugin guards this in four places:

  • You can’t turn short links on with Plain permalinks. The card says: Short links don’t work with Plain permalinks. Choose any other setting under Settings → Permalinks.
  • If permalinks are switched to Plain later, the card warns Permalinks are set to Plain, so printed short links don’t open and new QR codes use the standard address until you choose any setting other than Plain. New codes quietly fall back to the standard address in the meantime.
  • An admin notice appears on every admin screen while printed short-link codes can’t open — for example 3 printed QR codes use short links and will stop working — set Permalinks to any setting other than Plain. It disappears as soon as permalinks are fixed.
  • A status row on Settings → Permalinks, so nobody breaks printed codes by accident (see below).

Plain permalinks break printed short links. The codes themselves aren’t touched — switch permalinks back to any other setting and every one of them opens again.

Settings → Permalinks gets a read-only row, QR code short links. It says whether short links are on (On: new QR codes use short links like yourstore.com/q/k7m2xa.) or off, how many printed codes use /q/, and what would break them: They stop working if you choose Plain. Its link, Change in QR Codes → Settings → Links & tracking, takes you to the setting.

When /q/ is already taken

Short links need the /q/ path to themselves. If a page, a post, a category or tag archive, or another plugin’s rewrite rule already answers at /q/, the plugin won’t turn short links on and names what’s in the way — e.g. The path /q/ is already used by the page “Q” on this site, so short links can’t be turned on. Rename or move that page (change its slug), or keep the standard addresses.

Once short-link codes exist, a page created at /q/ later doesn’t break them: the plugin answers /q/… addresses before WordPress looks for a page. Only the Plain permalink setting stops them.

Exclude /q/ from page caches

Every scan response tells caches not to store it (Cache-Control: no-store, plus WordPress’s own “don’t cache this page” flag), so caching plugins leave scans alone. A cache that serves pages before WordPress runs — a host’s server cache, a CDN, Varnish or LiteSpeed rules — can still answer a /q/ request from its copy. Then the scan isn’t counted and nothing goes into the cart.

The page a scan lands on is covered too: when it’s a store page other than the cart or checkout, the plugin adds a one-off qrcw_n=… parameter, so caching plugins and CDNs serve a fresh copy and the scan’s message and qr_scan event survive. A small script removes it from the address bar; exclude qrcw_n as a query parameter in your analytics if it still appears.

If your host or CDN caches pages, add these to its exclusion list (often called “never cache” or “bypass”):

  • paths starting with /q/
  • URLs containing ?qrcw= (the standard addresses — most caches already skip query strings, but check)

Quick test: scan a code twice from a phone, then check its Visits on All QR Codes. If the count doesn’t move or the cart stays empty, a cache in front of WordPress is answering. See Troubleshooting.

Next: Tracking tags →