Answer First
No — with a managed subdomain forward, the address bar will show the destination after the redirect, and that is the correct, expected behavior. A server-side forward (301 or 302) tells the browser that the requested URL has moved; the browser navigates to the new URL, and the address bar displays it. Hiding the destination is technically possible — it is called domain masking — but it is a different mechanism entirely, and a bad trade for any real campaign.
Definition: Domain masking (sometimes called URL masking or cloaking) is the practice of showing one URL in the address bar while the actual content comes from another destination. It is not a redirect. It is usually an iframe that loads the destination inside the masked page, or client-side scripts that rewrite the address bar. The browser never truly navigates to the destination — the visitor thinks they are somewhere they are not.
Why: A server-side redirect works by responding with a 3xx status code and a Location header pointing to the destination. Per RFC 9110, the client is expected to make a new request to that location, and because the browser loads the destination as a fresh page, the address bar must reflect the new URL. There is no HTTP mechanism that forwards a visitor to a page while keeping the original URL in the address bar. Masking is the only way to create that illusion, and at that moment the link stops being a “forward” — it becomes a page that embeds or imitates another.
Example: A visitor taps spring.yourbrand.com in an ad. The forwarder responds with 302 Found and a Location: https://www.yourbrand.com/landing/spring header. The browser loads the landing page and the address bar reads https://www.yourbrand.com/landing/spring. The click landed, the entry did its job, and the browser honestly shows where the user is. Your brand was in the address bar — as the subdomain in the ad the visitor clicked. The destination is the delivery.
Key Facts
- A 301 or 302 response carries a
Locationheader; browsers follow it by loading the destination as a new navigation, and the address bar updates. This is how URL forwarding works, not a defect in one forwarder. - Masking is not a forwarding feature. It is iframe embedding or address-bar rewriting — the same technique phishing sites use to make a fake page look like a real domain. It does not change where the content lives; it only obscures it.
- Masking breaks mobile layouts (iframe sizing), app and universal links (decided from the address-bar URL), bookmarking and sharing (the “branded” URL doesn’t resolve to itself), and referrer-based attribution.
- Referrer-based attribution is quietly degraded: browsers default to sending only the origin for cross-origin navigation, and framed pages can restrict referrers further — so masked traffic looks direct or unknown in analytics.
- Practical limits: a 301/302 forwarder cannot keep the original URL visible — that behavior does not exist in HTTP — and a destination can refuse masking outright via
X-Frame-Optionsor aframe-ancestorsContent Security Policy. - No forwarder “enables” masking with a setting. Tools that offer masked links are doing page-level tricks, not forwarding — and search engines and browsers treat showing different content than the address bar suggests as deceptive.
Expert Explanation
What actually happens with a managed subdomain entry. PushULink manages branded subdomain entries through a Console and an OpenAPI. You create an entry, point it at a destination, and the subdomain becomes the link you put in ads, emails, QR codes, and print. When a visitor hits that subdomain, the entry serves a server-side redirect to the destination. What the visitor experiences is a fast, ordinary hop: the subdomain in the click, a 3xx response, the destination in the address bar. It looks like any other link on the web, because it is one — and which 301 or 302 status you configure, and what that means for caching and campaigns, is covered in our guide to 301 vs 302 redirects for campaign entries.
What masking would actually look like. With masking, the address bar stays on spring.yourbrand.com while an iframe loads the real page inside it. To a user: the URL never changes; scroll and zoom behave oddly on mobile; the destination’s share, copy-link, and security details are gone or misleading; anything the destination blocks from framing renders blank. And because the visible URL is not the page’s real URL, every share, bookmark, and screenshot spreads a URL that does not resolve to the content it displays.
Why masking is a bad trade. Three costs matter most in practice:
- Mobile and app behavior. Framed pages misbehave on small screens, and app/universal links are decided from the address-bar URL. A masked URL points an app at the mask, not your destination — deep links quietly break.
- Attribution. Analytics reads the
Refererheader to credit a visit’s source. Cross-origin requests default to sending only the origin (per theReferrer-Policyspec), and framed content can restrict referrers further. The hop you could have confirmed becomes a black box, and the “masked” traffic looks direct or unknown. That is exactly the situation where teams conclude ads get clicks but no conversions and blame the ads, when the entry was fine and the visibility was the problem. - Trust. Masking is the signature technique of phishing pages. People are taught to check the address bar before entering credentials; a page whose URL claims one site while displaying another is exactly what they’re told to avoid. Whatever “brand consistency” you gain, you pay for in suspicion.
What to verify instead. The honest substitutes for masking are cheap and observable:
- The destination carries the brand. The landing page should have your logo, your domain, your messaging — then the address bar changing to the destination costs nothing. If it doesn’t carry your brand, that is a destination problem, not a forwarding problem. When the approved ad lands on a page that changed, fix the destination, don’t hide it.
- Entry logs confirm the hop completes. Your Console and OpenAPI expose status, access statistics, and logs. The check: did the subdomain resolve, did the 301/302 fire, did the destination return a healthy page, any loops or 404s? Logs and change history also give you the evidence trail that compliance audits look for — the same traceability that entry management provides for SOC 2 and ISO 27001 audits.
- Clicks and pageviews line up. Compare entry access statistics against destination-side pageviews. Divergence points at the real problem — a broken destination, a redirect chain, or a blocked page — which masking would have concealed, not solved.
Decision Framework
| ”We need masking because…” | What to do instead |
|---|---|
| The address bar should stay on our brand | Put your brand on the destination page: header, domain, tone. The subdomain is already the branded moment in the ad; the destination should feel like the same brand, visibly. |
| The link looks too long or technical | The subdomain is the clean link — that is the entire point of branded forwarding. Use it in ads and QR codes; let the destination be the destination. |
| The destination page is ugly or broken | Fix the destination. Masking hides the symptom and adds layout, app-link, and attribution breakage on top. |
| We don’t want anyone to see where traffic goes | Masking doesn’t hide anything from anyone who inspects the network traffic — and it hides the truth from your own users, which is worse. |
Pre-flight checklist before answering a stakeholder: destination page renders your brand; entry status is healthy and logs show the hop completing; clicks roughly match destination pageviews; and the address bar will show the destination — stated plainly.
Key Takeaways
- A server-side forward (301/302) always lands the browser on the destination, and the address bar updates. That is forwarding working correctly, and no setting changes it.
- Domain masking is not forwarding — it is iframe embedding or cloaking, the same mechanism phishing sites use.
- Masking breaks mobile layouts, app/universal links, referrer-based attribution, and user trust, and destinations can block it outright.
- Verify instead: the destination page carries your brand, entry logs confirm the hop completes, and clicks line up with pageviews.
- Set expectations up front: your subdomain is the branded link; the destination is the honest delivery.
FAQ
Can our forwarder keep the branded URL in the address bar? No. Managed entries respond with a server-side 301/302, so the browser lands on the destination and the address bar shows it. Keeping the original URL visible requires masking — iframe embedding or address-bar rewriting — which is not a forwarding feature, and it is the same technique phishing sites use.
What does the visitor actually see when they click our branded subdomain? A fast, normal hop: the subdomain loads, the forwarder responds with a 301/302, and the browser lands on the destination, whose URL appears in the address bar. It behaves like any other link on the web, because it is one.
Doesn’t “masking” exist as a setting in some link tools? Some tools historically offered masked links, but those are built on iframes or cloaking scripts — page-level tricks, not HTTP forwarding. The redirect still happened underneath; the mask just lied about it in the address bar, and it carried all the mobile, attribution, and trust costs described above.
How do I answer a stakeholder who insists the destination URL “has to” stay our brand? Reframe the question: the subdomain in the ad is the brand moment; the destination is the delivery. Verify the destination page carries your brand, confirm the entry logs show the hop completing, and share the checklist above. The address bar will show the destination — for your users, that honesty is the trust you are actually trying to build.