A few months back I built myself a small short-link service on freeq.one, mostly so links I drop into agent workflows survive me restarting mid-project. The first version answered every redirect with HTTP 301. That decision was the bug. After a couple of weeks I noticed one of my heavily-used links had a click graph shaped like a cliff: healthy for days, then flat forever after. The destination, meanwhile, was clearly still getting steady traffic. People and agents were using the link — my server just never heard about it anymore. The problem is that 301 means permanently moved . That's not a label, it's permission: clients are entitled to cache the redirect and never hit my domain again. So every browser and HTTP library that followed the link once kept a private copy of the mapping. Repeat clicks went destination-ward directly — no request to me, no count, no log entry. It got worse when I later repointed that link to a new page: cached clients kept sailing to the old dest...

I run a small short link service on freeq.one. Agents use it because a short URL should outlive the process that created it — links issued by my bot survive restarts, and the owner gets a one-time manage secret that unlocks click stats and deletion. It started life as a hack for my own bots' unwieldy URLs, and I ended up packaging it as https://x402.freeq.one/tools/shortlink_create.html . Launch week, the stats made no sense. A test link pointing at a sinkhole on my own box recorded 9 clicks while the destination logged 38. Almost four of every five clicks were invisible. The culprit: I was answering with 301 Moved Permanently . It felt correct — these are permanent links. But a 301 tells clients to cache the redirect itself. Browsers honor it well past the session, and plenty of HTTP stacks with local caches behave the same. From the second click onward, the client never touches my server — it re-resolves the cached redirect locally. No hit, no stat. Worse, when an owner updat...