Why Bare Vanity Short Links (Like /johnny) Flash a 404 on Mobile — and the Attribution-Routing Trade-Offs

The symptom: a 404 flashes on mobile before redirecting

Let's reconstruct the scene. Each of our consultants has a dedicated, clean promotional URL in the form of a bare single-segment path — for example, truelink-group.com/johnny. It goes on business cards, into quotes, into direct messages, and its whole purpose is to be easy to remember, easy to say, and easy to type. A client receives this URL, opens it on a phone, and expects to see the consultant's personal landing page.

What actually happens is this: the instant the page opens, a full-page "404 Not Found" heading appears first, lingers for a split second, and only then auto-redirects to the correct consultant landing page. The journey does end at the right destination — but that "404 flash" has already planted a question mark in the client's mind.

The most maddening part is how hard it is to reproduce in a development environment. An engineer on a desktop, opening that bare URL in Chrome or Safari over and over, lands almost instantly on the right page nearly every time, with no 404 visible at all. So reports like this are easily dismissed as "the user imagined it" or "a one-off network hiccup" — until more and more mobile users, especially those tapping in from in-app browsers in apps like LINE and Facebook, all describe the very same flash.

First, the distinction: bare vanity URL vs. attribution route

To understand this bug, you first have to separate two URLs that look alike but have completely different jobs:

• The bare vanity URL (bare single-segment path): for example, /johnny. Its value is being human-friendly — short, memorable, perfect for a business card or saying out loud. It has no prefix, no ?ref= tail of parameters; it just looks clean.
• The attribution route: for example, /r/johnny. This is the platform's formal path, handled by the back end: when someone visits it, the back end returns an HTTP 200 with a complete server-side-rendered (SSR) consultant landing page. Because the content is emitted directly as HTML by the server, share previews (Open Graph cards) on social and search resolve correctly, and even crawlers that don't run JavaScript can see the content.

In other words, /r/johnny is "a structurally complete entry point for machines and formal sharing," while /johnny is just "a clean, memorable surface for humans." Ideally, we want a user who types /johnny to also arrive at the consultant landing page smoothly — and that is exactly the seam where the problem occurs.

Key design principle: formal outbound sharing (social posts, messages) should use /r/johnny, because it is friendly to crawlers and share previews; the bare /johnny is for the "a human types it" business-card scenario. To crawlers that don't run JavaScript, the bare URL is still a 404 — and that is a deliberate trade-off, not an oversight.

Root cause: no route means a 404, and the rescue script sat at the very end

Now let's move the camera to the server side and see what actually happens when a client requests /johnny.

First thing: the bare single-segment path /johnny has no matching back-end route (rewrite). Our host only has rules for the formal attribution route (/r/** is handed to the back-end redirect function), but "a bare single-segment path" is not in that ruleset. So the host looks for a physical page called /johnny, and doesn't find one.

Second thing: with no page found, the host does exactly what it should — it returns the real 404 page (the HTTP status code is literally 404). This 404 page is a well-designed, multilingual "page not found" error page, and there is nothing wrong with it.

Third thing, and the bug's true home: to avoid stranding the client on a 404, we placed a rescue redirect script inside that 404 page. Its logic is: "If what the user typed is a legitimately formatted single-segment slug (like johnny), send them to the proper attribution route /r/johnny." The idea itself is entirely correct — but that script was originally placed at the very end of the page's <body>.

A browser processes an HTML document top to bottom. With the redirect script at the end of the <body>, the browser parses and paints the entire page first (including that big, attention-grabbing "404" heading), and only afterward reaches the script at the bottom and starts the location.replace('/r/johnny') redirect. So the sequence becomes:

1. Host returns the 404 page.
2. Browser parses and paints the "404" heading (the user sees it).
3. Browser reaches the script at the end of the body, finds a legitimate slug, calls location.replace.
4. Page navigates to /r/johnny, and the correct landing page appears.

The gap between steps 2 and 3 is the truth behind the "404 flash" the user sees. It isn't broken; it is a paint-then-redirect timing gap that the naked eye managed to catch.

Why desktop never sees it and mobile does

This explains the most confusing part: why does the same URL test fine on an engineer's machine but flash on a client's phone?

The answer is that the length of that "gap" stretches and shrinks with device and network conditions. Desktops usually have faster CPUs and steadier networks, so the time between "painting the 404" and "running the bottom script" is so short the eye basically can't tell — it looks like one smooth step.

Mobile is different. Mobile devices generally have weaker processing and connection quality, especially when the link is tapped from a social app's in-app browser, where the environment is more constrained. That once-invisible gap gets stretched, so the 404 heading genuinely gets painted, lingers for an instant, and is then washed away by the redirect. That is also why bugs like this love to surface on "the client's real phone" while hiding nicely in "the developer's clean environment."

There is a universal lesson here: any design that "lets some transitional state paint and then swaps it out with JavaScript" will expose that transitional state on slower devices. The genuinely robust approach is to make sure the state you don't want seen never gets the chance to paint at all.

The fix: move the redirect to head, hide first, then replace

Once you know the root cause, the fix becomes clear. It comes down to one sentence: make the redirect happen before the 404 heading is ever painted. We did two things:

1. Move the rescue redirect script to the very top of <head>

We moved that redirect logic from the end of <body> to the very front of <head> — that is, it runs while CSS and page content have not yet been painted. This way, before the browser draws any 404 visuals, it already has a chance to decide "is this a bare slug that should be redirected?"

2. When a slug matches, hide the whole page first, then replace

Moving it up alone isn't fully safe — in the few milliseconds before the redirect takes effect, a sliver of content could in theory still flash. So we added a safeguard: when the script determines this is a legitimate single-segment slug, it first sets documentElement's visibility to hidden (hiding the entire page before any paint), and then calls location.replace to send the user to /r/johnny. Because the page is hidden, the user can't even see an afterimage of that instant — achieving true zero flicker.

After the fix, the sequence becomes:

1. Host returns the 404 page.
2. Browser begins parsing <head> and immediately runs the redirect script.
3. Script finds a legitimate slug → first visibility:hidden to hide the page → location.replace('/r/johnny').
4. The user never saw the 404 and lands directly on the landing page.

There is also an important safety net: if the redirect fails for any reason, the page falls back to showing the 404 as usual, never stranding the user on a hidden, blank page. In other words, this rescue layer intervenes only when it "can actually help," and bows out gracefully — back to normal 404 behavior — when it can't.

Just as importantly, this fix carries zero routing risk — we did not touch the host's rewrite rules at all, only adjusted the position and behavior of that one script inside the 404 page. The blast radius is minimal: it affects only "requests that were already going to 404," and cannot possibly disturb any normal page.

Loop guard: why nf=1 is not optional

Sending a bare path to the attribution route raises an edge case you must handle: what if the slug doesn't exist at all?

Picture this: a client types /johndoe, but there is no consultant named johndoe on the platform. Our rescue script sees a legitimately formatted single-segment slug and, by the rules, sends them to /r/johndoe. The back-end attribution route looks it up, finds no such person, and bounces the user back to the 404 page — where the rescue script again sees that johndoe is a legitimate slug and again sends them to /r/johndoe… Left unhandled, this becomes an infinite redirect loop with both sides kicking the user back and forth.

The solution is a simple but crucial loop-guard flag: when the attribution route finds no slug and bounces the user back to the 404, it appends an nf=1 parameter to the URL (nf as in "not found"). The rescue script inside the 404 page, before doing any redirect, first checks whether the URL already contains nf=1:

• If it does contain nf=1 → that means "I already tried to redirect to the attribution route, but it had no data and bounced me back" → don't redirect again; just honestly show the 404.
• If it doesn't contain nf=1 → this is a first visit; go ahead and try redirecting to the attribution route.

This one little flag tidies up the awkward "legitimately formatted but non-existent slug" case completely: the user is redirected at most once, and after the route confirms there's no data, they stop at a normal 404 rather than being trapped in endless hopping. Any redirect design where "A sends to B, and B under some condition sends back to A" must have a one-way flag like this to break the potential loop — a lesson you cannot skip when writing redirect logic.

Why not a catch-all rewrite to "solve it once"

By now, many engineers will have an instinct: "Instead of rescuing with a front-end script inside the 404 page, why not just add a catch-all /* rewrite to route every bare path into the back end and let the back end decide whether to redirect? Then it would never return a 404 and never flash, right?"

It's a reasonable idea, but we deliberately chose not to do this, for a cost-and-stability trade-off:

• A catch-all turns every mistyped URL into a back-end invocation. A /* rewrite means: a user typing /jonny (a typo), /abuot (a typo), random paths probed by crawlers, dead links from the past… all of it gets sent into a Cloud Function. Requests the host could have answered with a static 404 page — zero back-end cost, instant response — now each fire up a function invocation. The more traffic and the more mistyped URLs, the more that cost and latency add up.
• It weakens the speed and stability of the host's native static 404. A static 404 is the fastest, least error-prone response path; replacing it with "everything goes through the back end first" only adds another link that can fail or slow down.
• It enlarges the blast radius. Touching rewrite rules affects "the routing behavior of all paths," whereas our fix only touches "the one page that was already going to 404." The former is global surgery; the latter is a local patch — and when "a small-scope fix solves it," there's no reason to operate on global routing.

So our principle is: don't touch rewrites; do the front-end rescue only on requests that were already going to be a 404. A clean catch-all looks like a once-and-for-all solution, but the real price is upgrading every typo into a back-end call. Keeping the change to the smallest possible scope — rescuing only requests that were already going to fail, never touching the routing of normal traffic — is the more robust, more cost-conscious choice.

The attribution-routing trade-off: who referred this client?

At this point it's worth stepping back to ask: why did we design the /r/johnny attribution route in the first place? Why not just make the bare /johnny the formal entry point?

Because "who referred this client" itself has business value. When a consultant brings a client into the platform via their dedicated URL, and the client eventually signs up or converts, the platform needs to know "which consultant this conversion should be credited to." The /r/johnny route is, in essence, a formal entry point that carries attribution: handled by the back end, it can record "this visit came from johnny" right on the server side and carry the correct attribution all the way into the subsequent signup flow.

This brings out a genuine engineering trade-off:

• Bare /johnny: most human-friendly (memorable, easy to type, looks good on a card), but it has no back end, carries no structure, is a 404 to crawlers, and can't do server-side attribution.
• Attribution route /r/johnny: most machine-friendly (200 SSR, good OG previews, indexable by crawlers, can record attribution in the back end), but the URL carries an extra /r/ prefix and isn't quite as "clean."

Our solution isn't to pick one over the other; it's to let both coexist, each doing its own job: reserve the bare URL for the "a human types it" card scenario and use the rescue redirect described above to wire it painlessly into the attribution route; and treat /r/johnny as the standard link for "formal outbound sharing." This way a consultant can print the clean, memorable /johnny on a card, while the platform never loses "who brought them in" at the moment of conversion. This 404-flash bug is, in fact, a crack at the seam of that very design where "human-friendly URL" and "machine-friendly route" coexist — fixing it is what makes the trade-off truly whole.

First-touch attribution cookie trade-offs

Attribution has a finer dimension too: when a client doesn't "click and sign up immediately" but instead "browses, then comes back a few days later to register," how does the platform remember "who originally brought them in"? This is where so-called first-touch attribution comes in, and it is usually implemented with a cookie — on the client's first visit via a consultant link, "the source is johnny" is written into the browser's cookie, so that even if they later open the site directly and register, that source can be read back and the credit correctly given to whoever first brought them.

The mechanism is practical, but it carries a string of trade-offs you must face honestly. Here are several dimensions to weigh when designing a first-touch attribution cookie:

• First-touch vs. last-touch: if a client is first brought in by consultant A, then later clicks consultant B's link before registering, who gets the credit? First-touch (remember the first one) protects "the person who originally developed this client"; last-touch (remember the last one) leans toward "the person who closed it." There is no universally right answer, but you must pick one explicitly and state the rule clearly, or attribution becomes a source of he-said-she-said disputes.
• Cookie lifetime: how long should the attribution cookie last? Too short, and a client who returns to register days later can't be traced back to the source, undervaluing the consultant's contribution; too long, and a click from months ago still influences today's attribution, potentially overvaluing it and not matching the client's real intent. Lifetime is a dial that directly affects whether attribution is fair.
• Privacy and consent: an attribution cookie tracks "where a user came from," which is a category to handle carefully under privacy regulations. It should serve honest commercial attribution, not become cross-site tracking; what you store, for how long, and why should all live up to the promises you've made to users. For a brand whose core value is trust, the legitimacy of attribution is itself a part of that trust.
• Cross-device and cookie-clearing realities: a user might click a link on a phone but register on a computer; they might clear cookies, or use incognito mode. Any purely cookie-based attribution will miss in these cases — so attribution should be designed as "best-effort, reasonable estimation," not "down-to-the-decimal truth." Treating it as a signal with error margins is what keeps you from making bad business decisions in edge cases.

We lay these trade-offs out because attribution is often treated as a "just bolt it on" minor feature; but the moment it involves crediting a person (and, by extension, a commission split), every dial — first or last touch, how long, what you store — becomes a real fairness-and-trust question. Facing attribution's error margins and choices honestly is more trustworthy than pretending it is perfectly precise.

Why a 404 that flashes for an instant is still worth fixing

You might think: "It only flashes for a moment, and it still ends up on the right page — is all this fuss necessary?" The answer is: yes, because in the business of trust, first impressions are expensive.

Picture the scene clearly: a consultant prints the clean URL on a card, writes it into a quote, drops it into a direct message, and shares it earnestly with a prospect who is still deciding whether to trust this company. The client opens this link for the first time — their first digital contact with the brand — and the screen greets them with a big, bold "404." Even if the redirect then succeeds, the subtext that instant delivers is: "this link looks off," "this company's stuff seems shaky." For a brand that sells "digital trust," this first-touch blemish is especially ironic, and especially damaging.

And its most dangerous quality, like many mobile-side conversion problems, is that it's silent. The client won't go out of their way to report "I saw your site flash a 404"; they'll just quietly dock a point in their head, or simply close the tab. On your side, the logs may just show one fewer completed visit, with no error signal telling you "someone just grew a doubt about you at the very first mile." We only discovered it because a consultant who was willing to speak up asked on his client's behalf — how many who don't speak up have already docked their point?

Seen the other way, this also means: patching this crack is one of those rare "small investment, direct return" experience optimizations. We didn't rewrite routing, didn't touch global rewrites, didn't take on any back-end cost — we just moved a script, added a hide-the-page step and a loop guard. The right person, the very first time they open the link, sees a smooth, clean, trustworthy landing page — and a smooth entrance is itself one of the most concrete cornerstones of digital trust.

Pre-launch checklist

Finally, let's condense the whole approach into a checklist you can take and compare against directly:

• Redirect script position: put the bare-slug rescue redirect script at the very top of <head>, not at the end of <body> — so it runs before CSS/content are painted.
• Hide before redirect: when a legitimate single-segment slug matches, set documentElement.style.visibility = 'hidden' first to hide the page, then location.replace to the attribution route, achieving zero flicker.
• Graceful fallback: if the redirect fails for any reason, show the 404 as usual — never strand the user on a hidden, blank page.
• Loop guard: when the attribution route finds no slug and bounces back, append nf=1; the rescue script, on detecting nf=1, stops redirecting and shows the 404, breaking the potential infinite loop.
• Slug-format gatekeeping: redirect only for "legitimately formatted single-segment slugs"; anything with path separators, a file extension (like .html), or multiple segments shows the 404 as usual — don't misdirect genuine 404s.
• Don't touch global routing: rescue on the front end; do not add a catch-all /* rewrite for bare slugs, to avoid turning every typo into a back-end call.
• Share via the attribution route: for formal outbound sharing (social, messages, OG previews) always use /r/slug; reserve the bare URL for the "a human types it" card scenario.
• Test on a real device: always test the bare URL on a real phone, ideally from a social app's in-app browser — desktops are too fast and often can't reproduce that flashing 404.

The essence of this problem was never "the link is broken," but "a transitional state you didn't want seen got painted on a slower device." The real fix isn't to wash it away after the fact, but to make sure it never gets the chance to paint. Patch this seam, and what you protect is not just a short link, but the still-fragile trust of a client's very first encounter with your brand.