Redirect Types & Concepts
What is URL masking?
URL masking is a technique that displays content from one URL while keeping a different URL visible in the browser address bar. When a visitor navigates to a masked URL, the page loads content from a completely different destination, but the address bar never changes. The original URL remains visible throughout the entire visit regardless of what content is actually being displayed.
URL masking is also called domain masking, website masking, or stealth redirect. It is most commonly encountered as a feature offered by domain registrars alongside their domain forwarding services: a checkbox option labelled “mask URL” or “enable stealth forwarding” that hides the destination domain from visitors.
The technique is technically distinct from a standard URL redirect. A standard redirect sends visitors to the destination URL and the address bar updates to show the destination. URL masking keeps the original URL in the address bar while loading destination content in a hidden frame; the visitor sees content from one place but the browser reports being somewhere else entirely.
URL masking is covered separately from masked redirects, a closely related topic, because the term “URL masking” is specifically associated with the registrar forwarding context and the broader conceptual practice of hiding destination URLs, while “masked redirect” refers more specifically to the iframe-based technical implementation. In practice they describe the same technique from different angles. This article focuses on URL masking as a concept and a registrar feature, including its implications and alternatives.
How URL masking works
URL masking is implemented through an HTML iframe, a page element that embeds one web page inside another. The masking works like this:
The masked URL, olddomain.com, points via DNS to the registrar’s or masking service’s servers. When a visitor requests olddomain.com, those servers return an HTML page that contains nothing but a full-screen iframe loading the actual destination: realdestination.com.
The browser renders the iframe content, filling the entire visible window with the destination site, but the top-level page remains at olddomain.com. The address bar shows olddomain.com because that is the URL of the top-level page. The destination content is embedded inside it, not navigated to directly.
The HTML served by the masking server typically looks something like:
The visitor sees realdestination.com content. The address bar shows olddomain.com. Every page they visit within the destination site, clicking links, navigating deeper, still shows olddomain.com in the address bar because all navigation happens within the iframe rather than at the top-level browser context.
URL masking vs URL forwarding vs URL redirect
These three terms are closely related but describe different techniques with importantly different behaviours. Understanding the distinctions clarifies when each is appropriate, and why masking almost never is.
URL forwarding is the general term for sending visitors from one URL to another. It encompasses both redirects and masking. Registrar forwarding services use this term for their basic redirect feature: the visitor is forwarded from the old domain to the new one with the address bar updating to show the destination.
URL redirect is a server-side HTTP redirect, a 3xx status code and Location header that tells the browser to navigate to a new URL. The address bar updates to show the destination. This is the standard, correct way to send visitors from one URL to another.
URL masking loads the destination in an iframe while keeping the original URL in the address bar. The address bar never updates. The browser is technically still at the original URL throughout the entire visit.
The practical difference for visitors is significant. With a redirect, visitors know where they are: the address bar shows the real URL of the content they are viewing. With masking, visitors are deceived: the address bar shows a URL that has nothing to do with the content they are seeing. Every link they copy from the address bar is the wrong URL. Every bookmark they save goes to the masked URL rather than the specific page. Every time they share a link, it shares the wrong address.
Why registrars offer URL masking
Registrar URL masking exists because of a specific historical use case: domain owners who wanted to serve a website under multiple domain names without the visitor seeing the primary domain in the address bar.
The classic scenario: a business registers both brandname.com and brandname.net. The website actually lives at brandname.com. The owner wants visitors who type brandname.net to see the website content but continue to see brandname.net in the address bar, preserving the illusion that the website lives at both addresses equally.
Before responsive web design and modern hosting infrastructure, this seemed like a reasonable feature. It required no hosting changes, no SSL certificates on the secondary domain, and no server configuration: just a DNS change and a checkbox in the registrar control panel.
The problem is that the web has evolved dramatically since URL masking became a common registrar feature. The modern web actively prevents the kind of cross-origin iframe loading that URL masking relies on. What was a marginal solution in 2005 is a broken solution in 2024.
Why URL masking breaks modern websites
The modern web has made URL masking largely non-functional for any website worth visiting. Several technical developments have collectively broken the iframe-based approach that URL masking relies on.
X-Frame-Options and Content Security Policy: the most decisive reason URL masking fails on modern sites. The vast majority of security-conscious websites set HTTP response headers that prevent their content from being loaded inside iframes on other domains. The X-Frame-Options: DENY header refuses all iframe loading. X-Frame-Options: SAMEORIGIN allows iframe loading only from the same domain. The Content Security Policy frame-ancestors directive provides fine-grained control over which domains can embed the site in a frame.
Every major website: Google, Facebook, Twitter, virtually every e-commerce platform, every SaaS product, every modern marketing site, implements one or more of these headers. Attempting to load any of them inside a URL masking iframe produces a blank frame or a browser error. The masking fails silently and the visitor sees nothing.
SSL and mixed content: URL masking creates SSL complexity that modern browsers handle poorly. If the masked domain does not have a valid SSL certificate — which is common with registrar masking, then HTTPS visitors receive a certificate error before the masked page can load. If the masked domain is HTTP and the destination is HTTPS, mixed content warnings appear. Even when both are HTTPS, browsers are increasingly strict about cross-origin content loading.
Navigation breaks completely: when a visitor navigates within the destination site by clicking links, all navigation happens inside the iframe. The address bar always shows the masked URL; it never changes to reflect which page within the destination the visitor is on. Every page within the destination appears to be at the same URL from the address bar’s perspective. Copying the URL, bookmarking a page, sharing a link, or using the browser back button all behave incorrectly because the browser’s notion of the current URL is completely disconnected from the actual page being viewed.
JavaScript and cross-origin restrictions: web applications use JavaScript extensively for authentication, personalisation, dynamic content loading, and interactive features. Browser security prevents JavaScript in an iframe from accessing properties of the parent page when they are on different origins, and vice versa. Many JavaScript-dependent features break when the site is loaded inside a cross-origin iframe. Session management, authentication flows, and third-party integrations commonly fail in masked contexts.
Mobile and responsive layouts: mobile-optimised sites that rely on viewport meta tags and CSS media queries may render incorrectly when loaded inside an iframe with different viewport dimensions than the destination site expects.
URL masking and SEO
URL masking is deeply harmful to SEO and represents one of the worst possible approaches to managing multiple domain names for the same content.
Duplicate content: URL masking causes the same content to appear at two different URLs simultaneously: the masked URL and the destination URL. Googlebot and other web crawlers may index the masked URL as a separate page containing the same content as the destination. This creates a duplicate content problem that splits SEO equity between two URLs rather than consolidating it on one.
SEO equity attributed to the wrong domain: any backlinks pointing to the masked domain build authority for the masked domain, not for the destination domain. If the masked domain is retired, all that equity disappears rather than having been transferred to the destination through a proper 301 redirect.
No link juice transfer: a 301 redirect from a masked domain to a destination transfers link equity. URL masking with its iframe approach transfers nothing; it does not issue an HTTP redirect at all from the destination’s perspective. The destination server just receives iframe requests. All accumulated authority on the masked domain is wasted.
Incorrect canonical URL signals: with URL masking there is no clear canonical signal. The masked URL returns a 200 OK with iframe content. The destination URL also returns a 200 with real content. Search engines have no clear signal about which URL is the canonical version. Without explicit canonical tags addressing this, which most registrar masking setups do not include, search engines must guess.
Crawl budget waste: Googlebot encounters the masked URL, loads the iframe wrapper page, and may attempt to crawl the iframe source. This consumes crawl budget on a URL structure that provides no indexing benefit.
The correct alternative to URL masking
For every use case where URL masking might seem like a solution, a standard server-side redirect is the correct approach. The choice of redirect type depends on the intent.
Multiple domains pointing to one site: use 301 permanent redirects from all secondary domains to the primary domain. Visitors are sent to the primary domain, the address bar shows the primary domain, and all SEO equity from secondary domain backlinks transfers to the primary. This is clean, correct, and the approach Google recommends.
Domain parking: use a 301 redirect from the parked domain to the primary domain. The visitor reaches the primary domain with the correct URL visible, and any backlinks to the parked domain transfer their equity through the redirect.
Wanting to serve a site under multiple domain names simultaneously: the correct approach is to host the site on all domains with a single canonical domain declared through canonical tags, or to use a CDN or reverse proxy that serves the same content under multiple domains with proper SSL and navigation handling. Neither involves iframe masking.
Brand protection domains: a company that registers brandname.net, brandname.co, and brandname.io to protect its brand should configure 301 redirects from all of them to brandname.com. Clean, SEO-positive, and technically correct.
Identifying URL masking
URL masking is easy to identify by observing the address bar as pages load and navigate.
Visit the masked URL and observe whether the address bar URL changes after the page loads. If the URL stays the same while the page appears to show content from a different site, different branding, different page structure than expected for that domain, URL masking is in use.
Viewing the page source, right-click and View Page Source in most browsers, reveals whether the page contains nothing but an iframe pointing to a different domain. A full-screen iframe with no other meaningful content is the signature of URL masking.
curl -I https://maskeddomain.com returns the server response headers. A masked URL typically returns a 200 OK with HTML content rather than a 3xx redirect status code, because the masking server is serving the iframe wrapper page, not issuing a redirect.
Removing URL masking and replacing it with a proper 301 redirect is straightforward once identified: update the domain’s forwarding configuration in the registrar control panel to use standard forwarding rather than masked forwarding, or configure a server-side redirect directly.