Learn How to Mask URL for Subdomain in WordPress Easily
“Mask the subdomain” is a request that comes up a lot when a WordPress site has something like shop.yourbrand.com or app.yourbrand.com and the owner wants visitors to see yourbrand.com in the address bar the whole time. It’s worth being upfront about something most guides on this topic skip: true URL masking, keeping the browser’s address bar showing one URL while actually serving content from a different one, is largely broken on the modern web, and understanding why matters before you spend time implementing something that won’t work reliably.
This covers what masking actually means technically, why the classic method (iframe-based domain forwarding) fails on most sites today, what a 301 redirect does instead (and why it’s not the same thing), and the setup that actually delivers what most people asking for “masking” really want.
Masking for Privacy Reasons Specifically
A smaller share of people asking about subdomain masking aren’t chasing branding at all, they want to obscure the internal structure of their site from casual visitors or scanners for security reasons. It’s worth separating that goal from branding, because the right tools are different. Hiding server structure from automated reconnaissance is better handled through the server-level protections covered in a proper WordPress security hardening pass (disabling directory listings, hiding version strings, restricting sensitive file access) than through URL masking, which does nothing to stop a determined visitor or bot from finding the actual subdomain through DNS records, SSL certificate transparency logs, or a simple search of your site’s own sitemap and internal links. A subdomain used internally for staging or admin purposes is far better protected by IP allowlisting or authentication at the server level than by any front-end masking trick, iframe-based or otherwise.
Why This Comes Up So Often
Subdomains are genuinely useful for separating infrastructure: a store running on WooCommerce or EDD might live on shop.yourbrand.com so it can scale independently of the main site’s hosting, a support portal on help.yourbrand.com might run different software entirely, and a blog on blog.yourbrand.com might sit on a completely different platform than the marketing pages. All of that makes sense on the backend. The friction shows up on the frontend, where a visitor bouncing between yourbrand.com and shop.yourbrand.com can read as two different destinations rather than one cohesive brand, especially if the visual design or navigation doesn’t match closely between them.
That’s the actual problem “mask the URL” is usually trying to solve: not literal address-bar concealment, but brand continuity. Which is exactly why the fix that works reliably is architectural (proxy the content under one domain, or match the design tightly across subdomains) rather than a browser-level trick that search engines and modern security headers are specifically designed to prevent.
Masking vs. Redirecting: Not the Same Thing
These two get conflated constantly, so it’s worth being precise:
- A redirect sends the visitor’s browser to a different URL, and the address bar updates to show that new URL. A 301 redirect from shop.yourbrand.com to yourbrand.com/shop means the visitor ends up looking at yourbrand.com/shop in their browser, not the subdomain.
- True masking keeps the original URL visible in the address bar while the browser is actually displaying content pulled from somewhere else, typically through an iframe or a server-side reverse proxy. The visitor never sees the real source URL at all.
A lot of “how to mask a URL” guides, including older versions of this one, describe adding a 301 redirect rule to .htaccess and calling it masking. It isn’t. A 301 redirect changes what the visitor sees in their address bar; it doesn’t hide anything. If the goal is genuinely “keep one URL visible no matter what page the visitor is actually on,” a redirect is the wrong tool entirely.
A Quick Reference
- 301 redirect: address bar changes to the new URL. Search-engine-safe when used correctly. Easiest to set up.
- iframe domain masking: address bar stays on the original URL while different content loads inside a frame. Breaks on any destination site with X-Frame-Options or CSP set, which is most modern sites. Carries cloaking risk with search engines.
- Reverse proxy: address bar shows one consistent domain because the routing happens server-side before the browser ever sees a different URL. Works reliably and is search-engine-safe, but takes more setup effort than the other two options.
Why Classic iframe Masking Doesn’t Work Reliably Anymore
The traditional method, still offered by some domain registrars as “domain forwarding with masking,” wraps the destination page in an iframe served under the original domain, so the address bar never changes even though the content comes from elsewhere. This worked reasonably well a decade ago. It doesn’t work reliably today, for a specific technical reason: most modern sites send an X-Frame-Options or Content-Security-Policy header specifically to prevent being loaded inside someone else’s iframe, a security measure built to stop clickjacking attacks. If the subdomain or destination site you’re trying to mask has either header set, which is the default on most current hosting and CDN configurations, the iframe simply refuses to load, and the visitor sees a blank frame or a browser error instead of your content.
On top of the technical breakage, iframe-based masking creates real problems even when it does load: mobile browsers handle nested iframes poorly, visitors can’t bookmark or share a link to a specific page since every URL looks identical, back-button behavior breaks, and search engines have long treated aggressive URL masking as a form of cloaking, serving one thing to the crawler’s context and something else to a human, which risks manual action penalties in Google Search Console if it’s flagged as deceptive. This is exactly why most major registrars, GoDaddy included, have quietly deprecated or hidden their domain masking features over the past several years rather than promoting them.
What People Asking for “Masking” Actually Want
In most real cases, the underlying goal isn’t literally hiding the URL, it’s making a secondary section of the site feel like a natural continuation of the primary domain rather than a separate destination. There are two solid ways to get that outcome without relying on broken iframe tricks.
Option 1: Reverse Proxy the Subdomain Under a Path Instead
Rather than running the secondary service on shop.yourbrand.com, configure a reverse proxy (through Nginx, Cloudflare Workers, or your host’s routing layer) so requests to yourbrand.com/shop/ are transparently served by the same backend that used to live on the subdomain. The visitor’s browser only ever sees yourbrand.com/shop/, genuinely, not through an iframe trick, because the proxy is doing real server-side routing before the response ever reaches the browser. This is technically more involved to set up than a DNS record, but it’s the approach that actually holds up: no broken frames, no cloaking risk, and full SEO value since the content now lives under one canonical domain instead of being split across a subdomain and consolidated with redirects after the fact.
Option 2: Use a Clean 301 Redirect and Accept the URL Will Change
If reverse proxying isn’t practical, a standard 301 redirect from the old subdomain to the new path is the honest, SEO-safe alternative, with the understanding that the visitor’s address bar will show the new URL rather than staying hidden. This is what the .htaccess method below actually accomplishes, and it’s worth doing correctly even though it isn’t “masking” in the strict sense:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^subdomain\.yourdomain\.com [NC]
RewriteRule ^(.*)$ https://www.yourdomain.com/$1 [L,R=301]Add this to the .htaccess file in your WordPress root directory (accessible via FTP or your host’s File Manager), after confirming hidden files are visible since .htaccess is a dotfile. This sends anyone hitting the old subdomain straight to the equivalent path on the primary domain, with a permanent redirect status code that tells search engines to transfer the old URL’s ranking signals to the new one instead of treating it as duplicate content.
Where a URL Redirect Plugin Actually Fits
Plugins like Redirection and Simple 301 Redirects manage exactly this kind of URL-to-URL mapping through the WordPress dashboard instead of editing server files directly, which is the more approachable route for anyone not comfortable in .htaccess. Both are genuine 301 redirect managers, useful for consolidating a subdomain into the primary domain’s structure.
One plugin worth a specific correction here: Pretty Links is built for cloaking outbound affiliate links (turning a long, ugly affiliate URL into a clean yourbrand.com/go/product-name link), not for hiding your own subdomain’s browser URL from visitors browsing your own site. It’s a useful tool for its actual purpose, but it doesn’t do what “mask my subdomain” is usually asking for, and reaching for it here would solve the wrong problem.
Setting Up a Reverse Proxy in Practice
The specific setup depends on where the primary domain’s DNS and hosting live, but the general shape is consistent across platforms. Using Cloudflare as an example, since it’s a common, low-cost way to do this without managing your own proxy server:
- Point yourbrand.com through Cloudflare’s DNS if it isn’t already, which gives you access to Cloudflare Workers, the piece that actually performs the proxying.
- Write a Worker script that intercepts requests to yourbrand.com/shop/* and forwards them server-side to whatever backend currently serves shop.yourbrand.com, then returns that response back to the visitor exactly as if it had come from yourbrand.com directly.
- Update internal links and canonical tags on the proxied content to reference the new yourbrand.com/shop/ path, not the old subdomain, so search engines and analytics tools treat it as the real, canonical location going forward.
- Redirect the old subdomain with a 301 to the new path as a fallback, covering any external links, bookmarks, or backlinks still pointing at the old subdomain URL.
This is meaningfully more setup than a DNS forwarding checkbox, and it’s worth being honest that it usually needs either a developer comfortable with edge routing or a hosting platform that offers this as a built-in feature. But it’s the version that actually delivers “one consistent domain, always” without the iframe workaround breaking on half the sites you’d want to mask.
When a Subdomain Is Fine As-Is
Not every situation actually needs masking or proxying at all. Search engines and most users have long been comfortable with subdomains as a normal part of a brand’s web presence, mail.google.com and drive.google.com being the most obvious example nobody finds confusing. If the real concern is looking established and trustworthy rather than literally hiding the subdomain, making sure the subdomain shares the same visual branding, navigation, and SSL certificate as the main site usually solves the trust problem without touching DNS or server routing at all. Reserve the proxy or redirect approach for cases with a specific, concrete reason: consolidating SEO value from a subdomain that’s being retired, or a genuine technical requirement to serve everything under one origin for cookie or authentication reasons.
Common Questions About URL Masking
Will masking or redirecting hurt my current search rankings?
A clean 301 redirect, set up correctly and left in place, transfers the vast majority of a page’s ranking signals to the new URL over time; Google has stated this directly for years. What actually hurts rankings is a redirect chain (subdomain to intermediate URL to final URL), a wrong redirect type (302 instead of 301 for a permanent move), or content that changes meaningfully between the old and new URL, which confuses which page should rank for what.
Can I just use a CNAME record to make the subdomain “invisible”?
A CNAME record controls DNS routing, pointing a subdomain to another hostname, but it has no effect on what shows in a visitor’s address bar. The browser still displays whatever URL the visitor actually navigated to or was redirected to, regardless of what’s happening at the DNS layer behind the scenes. CNAME setup and URL masking are solving different problems entirely.
Is there a WordPress-native way to do reverse proxying without an external service?
Not really, at least not reliably. Reverse proxying happens at the web server or CDN layer, before a request ever reaches WordPress itself, so it has to be configured in Nginx, Apache, or an edge platform like Cloudflare rather than through a WordPress plugin. Plugins that claim to do this from inside WordPress are usually just performing a redirect or an iframe embed under a different name, with the same limitations covered above.
What if the subdomain and the main site run on entirely different platforms?
This is common, a WordPress marketing site with a subdomain running a separate SaaS app or a different CMS entirely, and it’s actually the clearest case for a reverse proxy over a redirect. A redirect would bounce visitors between two visibly different products; a proxy lets the different backend serve its content under the primary domain’s path without the visitor ever needing to know two separate systems are involved. The setup work is the same regardless of what’s running behind the proxy, since the proxy only cares about routing the request, not what technology generates the response.
SEO Considerations Either Way
- Use 301, never 302, for a permanent consolidation. A 302 (temporary redirect) tells search engines not to transfer ranking value, which defeats the purpose if the subdomain is being retired for good.
- Update internal links to point directly at the new URL rather than relying on the redirect to catch every internal reference; a redirect chain (old subdomain to new path to yet another URL) dilutes SEO value and slows page loads.
- Set a canonical tag on the destination page pointing to itself, which reinforces to search engines which version of the URL should actually be indexed.
- Avoid true cloaking entirely. Serving meaningfully different content to search engine crawlers than to human visitors, which is what aggressive iframe masking risks looking like, is against Google’s Webmaster Guidelines and can trigger a manual action that’s far more damaging than whatever branding inconsistency prompted the masking request in the first place.
A Few Practical Notes Before Implementing Either Approach
- Test across devices and browsers after any redirect or proxy change, since behavior can differ between mobile Safari, Chrome, and older browsers still in use by some visitors.
- Monitor site performance after switching. A reverse proxy adds a network hop, which can add latency if the proxy and backend aren’t well positioned relative to each other; a redirect adds a small, usually negligible delay from the extra HTTP round trip.
- Document the change somewhere your team can find it later. URL structure changes made once and forgotten are a common source of confusion during a future site migration or redesign, when nobody remembers why the subdomain routing looks the way it does.
- Check analytics setup after switching. Moving content from a subdomain to a path under the primary domain can affect how Google Analytics or other tracking tools segment traffic, since many setups treat subdomains as a distinct property or view by default. Confirming tracking still fires correctly on the new URL structure avoids a gap in reporting right when you’d want to measure whether the change actually improved anything.
- Give search engines time to recognize the change. Even a correctly configured 301 redirect doesn’t transfer ranking signals instantly; it typically takes several weeks for search engines to fully process the shift and consolidate ranking history onto the new URL.
The Bottom Line
If the actual goal is one consistent domain for visitors from start to finish, a reverse proxy that serves the subdomain’s content under a path on the primary domain is the setup that genuinely works today, with none of the broken-iframe or cloaking risk that comes with old-school masking. If a full proxy setup isn’t practical, a clean 301 redirect consolidates the URLs honestly, even though visitors will see the new address rather than a hidden one. Either beats implementing an iframe masking trick that a growing share of destination sites will simply refuse to display.
Interesting Reads:
Understanding How Do Hackers Mine WordPress for Admin Emails
