Redirect Types & Concepts
What is a masked redirect?
A masked redirect 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 the original URL, instead of being sent to the destination through a standard HTTP redirect, the original page loads a frame, typically an HTML iframe, containing the destination content. The visitor sees the destination content but the address bar never changes. The original URL stays visible throughout the entire visit.
It is also called URL masking, domain masking, or stealth redirect. The terms all describe the same technique: hiding the true destination URL from the visitor by wrapping it in a frame served from the original domain.
Masked redirects were used more frequently in the early web when domain parking services offered masking as a feature: a way to point a secondary domain at a primary site while showing the secondary domain in the address bar. Today they are widely considered a broken, harmful technique that causes significant problems for SEO, security, functionality, and user experience. Understanding what they are and why they should be avoided is important for anyone managing domains and redirects.
How a masked redirect works
A masked redirect works by serving an HTML page at the original URL that contains nothing but a full-screen iframe pointing to the destination URL. The iframe loads the destination site inside it, filling the entire browser window. The visitor sees the content of the destination but the browser address bar continues to show the original URL because the top-level page, the one containing the iframe, is still technically on the original domain.
A basic masked redirect page looks like this:
The original URL returns a 200 OK with this HTML. The iframe loads the destination. The visitor sees destination.com content but originaldomain.com stays in the address bar.
This is fundamentally different from a standard URL redirect where the browser is sent to the destination and the address bar updates to show the destination URL. In a masked redirect the browser never leaves the original URL; it just loads foreign content inside a frame.
Why masked redirects were used
Masked redirects emerged from a specific use case: domain parking with branding preservation. The idea was that a company could register multiple domains and point them all at a primary website while making each domain appear to be its own independent site. A visitor to brand-alternative.com would see the content of primarybrand.com but never know they were on a different domain.
Domain registrars and parking services offered masking as a convenience feature because it required only a simple DNS change and a template HTML page: no server configuration, no SSL certificates on secondary domains, no redirect infrastructure. It was the path of least resistance for pointing multiple domains at one site.
This was always a flawed approach even when it was common. The problems that existed with masked redirects in the early web have become dramatically worse as the web has evolved. Modern websites, browsers, and security standards have made masked redirects dysfunctional in ways that were not fully apparent when the technique was introduced.
Why masked redirects break modern websites
The most fundamental problem with masked redirects is that the modern web has largely broken them, often silently and in ways that are difficult to diagnose.
X-Frame-Options and Content Security Policy: the most decisive reason masked redirects fail on modern sites. Virtually every security-conscious website sets HTTP headers that prevent their content from being loaded inside iframes on other domains. The X-Frame-Options: DENY or X-Frame-Options: SAMEORIGIN header causes the browser to refuse to load the content in the iframe, showing a blank frame or an error instead. The Content Security Policy frame-ancestors directive does the same. Major sites, Google, Facebook, most e-commerce platforms, most SaaS products, most modern marketing sites, implement these headers. Attempting to mask-redirect to any of them results in a blank iframe and a broken experience.
SSL and mixed content: masked redirects create SSL complexity. The original domain serves the iframe wrapper page. If that page is on HTTP and the destination is on HTTPS, or vice versa, browsers flag it as a mixed content issue and may block the iframe content entirely. Even if both are on HTTPS, the SSL certificates are for different domains and the browser is loading content from a domain other than the one shown in the address bar, which is the definition of a misleading connection.
Navigation breaks: when a visitor clicks a link inside a masked redirect iframe, the linked page loads inside the iframe, the address bar still shows the original domain. If the visitor navigates several pages deep within the destination site, the address bar never reflects where they actually are. Sharing a link, bookmarking a page, or copying the URL from the address bar all give the original domain URL rather than the actual page URL. This completely breaks expected browser navigation behaviour.
JavaScript and cookies: web applications use JavaScript and cookies for authentication, personalisation, shopping carts, and countless other functions. Many of these break when loaded inside an iframe on a different domain due to browser security restrictions on cross-origin access. A visitor who is logged into destination.com in a normal tab may not be logged in when the same site loads inside an iframe on originaldomain.com because session cookies cannot be shared across origins in this way.
Mobile and responsive layouts: the iframe wrapper of a masked redirect makes no accommodation for the destination site’s responsive design. Viewport sizing, media queries, and mobile-optimised layouts may not function correctly inside a full-screen iframe, particularly when the iframe wrapper page has different viewport settings than the destination expects.
Masked redirects and SEO
Masked redirects are deeply harmful to SEO and should never be used in any context where search visibility matters.
Duplicate content: a masked redirect causes the same content to appear to exist at two different URLs simultaneously. The destination content is available at destination.com and also appears, from the browser’s perspective, at originaldomain.com. Search engines indexing both URLs find identical content at two addresses, creating a duplicate content problem that splits SEO equity and can trigger ranking penalties.
Wrong URL indexed: search engines may index the masked URL (originaldomain.com) rather than the destination URL. Any link juice, SEO equity, and ranking signals that should be associated with destination.com get attributed to originaldomain.com instead. The destination domain does not benefit from the traffic or links that the masked domain receives.
No SEO equity transfer: unlike a 301 redirect which explicitly transfers link equity from the old URL to the new one, a masked redirect transfers nothing. Backlinks pointing to originaldomain.com build authority for that domain, not for destination.com. If the masking is ever removed and replaced with a proper redirect, all that accumulated equity is on the wrong domain.
Crawl budget waste: Googlebot and other web crawlers encounter the iframe wrapper page, attempt to follow the iframe source, and may or may not successfully crawl the destination content through the frame. This consumes crawl budget on a page structure that provides no indexing benefit.
Canonical URL confusion: a masked redirect creates fundamental ambiguity about which URL is canonical for the content. The destination URL is canonical from the destination server’s perspective. The masked URL appears canonical to anyone visiting through the masked domain. Without explicit canonical tags addressing this, search engines have to guess, and they typically guess in ways that do not benefit either domain.
Masked redirects vs standard redirects
The contrast between a masked redirect and a standard server-side redirect illustrates exactly why masking is the wrong approach for virtually every use case.
A standard 301 redirect sends the browser to the destination URL. The address bar updates to show the destination. The destination site loads normally with all its functionality intact. Search engines follow the redirect, understand the permanent move, transfer SEO equity to the destination, and update their index. The original URL is retired cleanly. Everything works as expected.
A masked redirect loads the destination inside an iframe while keeping the original URL in the address bar. The destination site may or may not load depending on its security headers. Navigation breaks. SSL handling is complex. Search engines find duplicate content at two URLs. SEO equity goes to the wrong domain. The visitor sees a misleading address bar. Nothing works as expected on a modern web.
The only scenario where masking could theoretically serve a purpose that a standard redirect cannot is when there is a genuine requirement to display third-party content under a different domain in the address bar. This is an extremely edge case and one that should prompt serious questions about whether the approach is appropriate at all, both from a technical and an ethical standpoint.
The ethics of masked redirects
Beyond the technical problems, masked redirects raise ethical concerns that are worth acknowledging.
A masked redirect shows visitors one URL in the address bar while serving content from a completely different domain. This is a form of deception: visitors cannot see where the content is actually coming from, cannot share the correct URL for a specific page, and may have no idea they are on a completely different domain than what the address bar shows.
In most everyday use cases this deception is unintentional: it is a configuration choice made for convenience rather than malicious intent. But the technique is structurally identical to phishing attacks, where a malicious site loads a legitimate site inside a frame while collecting credentials entered by a visitor who believes they are on the legitimate domain. This is one of the reasons browsers have progressively tightened restrictions on cross-origin iframe loading: the security implications of arbitrary domain masking are serious.
Using masked redirects, even unintentionally, associates a domain with a technique that browsers and security standards treat as inherently suspicious.
When to use a standard redirect instead
For every scenario where a masked redirect might seem like a solution, a standard server-side redirect is the correct approach.
Domain parking: use a 301 redirect from the parked domain to the primary domain. The visitor reaches the primary domain with the correct URL in the address bar, the destination site loads with full functionality, and SEO equity transfers correctly.
Brand protection domains: use a global redirect with a 301 from each brand protection domain to the primary domain. Clean, simple, and correct.
Domain rebranding: use 301 redirects from all old domain URLs to their equivalents on the new domain. Visitors arrive at the new domain, see the correct URL, and the SEO value of the old domain transfers to the new one.
Wanting to show a secondary domain in the address bar: if the genuine requirement is to serve a site under multiple domain names, the correct solution is either to host the site on all domains with canonical tags pointing to the primary, or to use a CDN or reverse proxy that serves content under multiple domains with proper SSL and navigation handling. Neither approach involves iframe masking.
Identifying and removing masked redirects
Masked redirects are easy to identify. Visit the domain in question and check the address bar as the page loads. If the address bar URL never changes despite the page displaying content that appears to be from a different site, it is likely a masked redirect. Viewing the page source (right-click and View Page Source) and looking for a full-screen iframe pointing to another domain confirms it.
Removing a masked redirect means replacing the iframe wrapper page with a proper server-side 301 redirect from the original domain to the destination. This requires access to the server or hosting configuration for the original domain and optionally a valid SSL certificate on the original domain to handle HTTPS connections before the redirect fires.
Once the masked redirect is replaced with a 301, the original domain begins passing link equity correctly to the destination, the destination site loads with full functionality for all visitors, and search engines can process the redirect correctly.