URL masking means showing visitors one address while the content actually loads from somewhere else. Type example.com/blog into a browser and the page that appears is really being served from blog.example.com, but the address bar never changes. For site owners running WordPress alongside a subdomain (a help desk, a shop, a members area, a separate app), masking keeps the whole experience feeling like one property instead of three or four disconnected ones.
It sounds simple. It isn’t always. Masking a URL is really proxying a request, and proxying comes with tradeoffs that a lot of tutorials skip past. This guide covers the three practical ways to do it in WordPress, what each one actually does under the hood, and where people get burned.
What’s Really Happening When You Mask a URL
There are two different things people mean when they say “URL masking,” and mixing them up causes most of the confusion.
The first is a straightforward redirect. Someone visits example.com/blog, the server sends back a 301 or 302 response, and the browser follows it to blog.example.com. The address bar updates. This is not masking. It’s a redirect, and search engines and visitors both see it happen.
The second is a reverse proxy, sometimes called a transparent proxy or cloaked redirect. The server at example.com/blog quietly fetches the content from blog.example.com and hands it to the visitor as if it originated locally. The address bar stays put. This is what most people actually mean when they ask about masking a subdomain, and it’s the harder one to set up correctly.
Confusing these two is the single biggest mistake in this whole topic. A plugin that promises “URL masking” but only does 301 redirects will not give you the result you’re picturing.
Why Bother Masking a Subdomain at All
A few recurring reasons come up. A support subdomain like help.example.com gets served at example.com/help so the brand feels continuous. A checkout flow built on a separate app lives at shop.example.com but appears as example.com/shop so customers never leave the perceived main site. A staging or partner-facing tool needs to sit behind the primary domain for cookie or authentication reasons that only work within a single origin.
Cleaner navigation and consistent branding are the obvious wins. Less obvious: some third-party scripts and cookies behave differently across origins, and keeping everything under one visible domain sidesteps a category of cross-origin headaches before they start.
Method 1: Reverse Proxy Through .htaccess (Apache)
If your host runs Apache, mod_proxy is the tool that actually performs true masking. This is server-level, not a WordPress feature, so it works regardless of what plugins you have installed.
First, back up your existing .htaccess file. If this rule is wrong, your site can go down, so you want a fast way back.
Then confirm mod_proxy and mod_proxy_http are enabled on your server. Shared hosting often disables these for security reasons. If they’re off, this method won’t work no matter how the rule is written, and you’ll need to ask your host or move to Method 2.
Add this above your existing WordPress rewrite block:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?example\.com$
RewriteRule ^blog/(.*)$ http://blog.example.com/$1 [P,L]
The [P] flag is what makes this a proxy pass rather than a redirect. Without it, this rule just becomes a very confusing redirect that leaks the real subdomain into the address bar, which defeats the purpose.
Save the file and upload it back to the server. Then visit example.com/blog directly and watch the address bar. If it changes to blog.example.com, the [P] flag isn’t being honored, which almost always means mod_proxy isn’t actually active on your server.
Method 2: A Redirection or Proxy Plugin
Not everyone has server access or wants to touch .htaccess directly. Plugins like Redirection or Pretty Links are excellent for standard 301/302 redirects, link shortening, and tracking click-throughs, but be clear about what they’re doing before you rely on one for masking.
Most WordPress redirect plugins operate at the PHP level, inside WordPress itself, after the request has already reached your server. They can rewrite where a link points to. They generally cannot proxy an entire separate subdomain’s content back through your main domain the way a server-level rule can, because WordPress doesn’t have direct access to fetch and stream another server’s response efficiently at scale.
Install one of these plugins from Plugins > Add New if you haven’t already, then look for its redirect or rule builder, usually under Tools or a dedicated menu item. Set the source path (example.com/blog) and destination (blog.example.com). Test it. If the address bar changes when you visit, you’ve set up a redirect, which is useful for consolidating old URLs or tracking clicks, but it is not masking.
If your specific goal is invisible masking and your host doesn’t support mod_proxy, the more reliable route is a lightweight reverse proxy server (Nginx, Cloudflare Workers, or a small PHP proxy script) sitting in front of both origins, rather than expecting a WordPress plugin to do server-level proxying it wasn’t built for.
Method 3: Hosting Control Panel Redirect Tools
cPanel and Plesk, along with most similar panels, usually include a “Redirects” section under Domains. These almost always create standard HTTP redirects, identical in behavior to Method 2’s plugin approach: functional for pointing traffic somewhere else, visible in the address bar, not true masking.
Some managed hosts (Kinsta, WP Engine, Cloudways) offer reverse proxy or “domain mapping” features at the infrastructure level that do perform real masking, but the terminology varies by provider. If you’re on managed hosting, check their documentation for “reverse proxy,” “domain masking,” or “path-based routing” specifically rather than the general redirects tool, since those are usually two separate features with different capabilities.
If You’re on Nginx Instead of Apache
A meaningful share of WordPress hosting runs Nginx, where .htaccess doesn’t apply at all. Reverse proxying there happens in the server block configuration, usually something only your host or a developer with SSH access can edit.
A minimal proxy block looks like this:
location /blog/ {
proxy_pass http://blog.example.com/;
proxy_set_header Host blog.example.com;
proxy_set_header X-Real-IP $remote_addr;
}
The proxy_set_header lines matter more than they look. Without passing the correct Host header, the subdomain’s server may not know which site it’s actually serving and can return the wrong content, a certificate mismatch, or a flat error. This is the step people forget when copying a proxy_pass example from a tutorial written for a completely different setup.
If you’re on shared or managed Nginx hosting without config access, ask support directly whether they offer reverse proxy or subdomain masking as a supported feature. Many managed WordPress hosts do, under names like “domain mapping” or “path routing,” even when they don’t expose raw Nginx config to customers.
Where Masking Quietly Breaks Things
A proxy pass forwards the HTML, but it doesn’t automatically rewrite every hardcoded link or cookie reference inside that HTML to match the masked address. This is where a lot of setups look fine on the homepage and then fall apart two clicks in.
Relative links inside the proxied content usually survive fine, since they resolve against whatever URL is in the address bar. Absolute links hardcoded to the real subdomain (a common pattern in themes and page builders that store full URLs in the database) will still point visitors back to blog.example.com, quietly breaking the illusion the moment someone clicks one.
Session cookies set by the subdomain application are scoped to that subdomain by default. If the masked app relies on a login session, and the cookie was issued for blog.example.com while the visitor is browsing under example.com/blog, the browser may refuse to send it back on subsequent requests, and the user gets logged out or stuck in a redirect loop. This shows up constantly with masked membership areas, help desks with their own login, or e-commerce checkouts running on a separate subdomain platform. Fixing it usually means reconfiguring the cookie domain on the subdomain app itself, not something the proxy rule can patch on its own.
Mixed content warnings appear when the masking domain is HTTPS but any asset pulled through the proxy, whether that’s an image or a script, loads over plain HTTP from the source subdomain. Browsers will block or flag those resources, and the page can look broken in ways that have nothing to do with your rewrite rule.
None of this means masking is a bad idea. It means test past the homepage: log in if there’s a login, click an internal link, check the browser console for mixed content warnings, before calling the setup finished.
The SEO Question Nobody Answers Clearly
Masking a URL doesn’t hide it from search engines the way it hides it from the address bar. Googlebot reads the actual response content and, in the case of proxying, will index whatever appears at example.com/blog as that URL’s content, even though it’s sourced from blog.example.com behind the scenes. That’s usually the intended outcome: you want the masked URL indexed, not the real one.
The risk shows up when both URLs are independently crawlable and return the same content. Google can flag that as duplicate content and choose which version to rank, which might not be the one you wanted. Fix this by setting a canonical tag on the masked page pointing to itself, and either blocking the true subdomain from indexing with a noindex tag or robots.txt rule, or 301 redirecting it outright if nothing needs to live there independently.
Skipping this step is the second most common mistake after confusing redirects with proxying. People set up a proxy, see it working visually, and never check whether Search Console is indexing two competing URLs six weeks later.
Common Mistakes Worth Naming Directly
Forgetting the [P] flag in an .htaccess proxy rule turns masking into a plain redirect, silently. The rule looks identical at a glance, which is why so many people are convinced they’ve set up masking correctly when they’ve actually just redirected traffic.
Testing only in a browser tab you’re already logged into. Cached DNS, cached pages, and browser extensions can hide a broken rule. Test in an incognito window or a different browser entirely, and clear any page caching plugin’s cache before checking.
Assuming a plugin does proxying because its description says “URL masking” in the marketing copy. Read what the plugin actually configures (redirects, rewrite rules, or genuine proxy passthrough) before building a workflow around an assumption.
Leaving both the masked and the real subdomain fully crawlable with no canonical tag, which invites the duplicate content problem described above.
When Masking Isn’t the Right Call
Sometimes the honest answer is to skip masking entirely and just use a clean redirect or, better, restructure the site so the content lives where it should in the first place.
If the subdomain is a genuinely separate product with its own team, its own release cycle, and its own branding decisions, masking it under the main domain can create more coordination overhead than it’s worth. Every deploy on the subdomain risks breaking the proxy relationship if paths change. A visible subdomain with consistent design and a shared header is often more maintainable long term than an invisible seam that has to be re-verified after every update on either side.
If SEO is the primary motivation, meaning you want the masked path to rank instead of the subdomain, a straightforward alternative is publishing that content natively on the main domain rather than proxying it from elsewhere. Proxying adds a layer of technical risk (mixed content, cookie scoping, canonical management) that a native page simply doesn’t have.
Masking earns its complexity when the technical reason is real: a third-party platform that must live on its own subdomain for infrastructure reasons, but where brand continuity in the address bar genuinely matters to the business. Outside that, weigh the setup and maintenance cost against what you’re actually gaining.
Verifying the Setup Properly
A masking rule that “looks like it’s working” on a first glance is not the same as one that’s actually solid. Before considering the job done, run through a short verification pass.
Open the masked URL in a fully private browser window, not a tab where you’re already authenticated or where a caching plugin has served you a stale page. Check the address bar stays on the masked path through at least two internal navigation clicks, not just the landing page.
Open the browser’s developer console and look at the Network tab while the page loads. Any request returning a 404, any mixed-content warning, or any request going out to the real subdomain’s URL where it shouldn’t, will show up there immediately and is worth chasing down before moving on.
Run the masked URL through Google’s Rich Results Test or a simple site: search once it’s live, to confirm which version search engines are actually picking up weeks later. A canonical tag that looks correct in the page source can still be overridden if the real subdomain is stronger in Google’s eyes, so checking after the fact matters more than assuming the tag alone settles it.
If the masked page includes a login, a form submission, or any interactive element, test that specific flow start to finish rather than just the static page load. Cookie scoping issues, in particular, almost never show up on a first look and only surface once someone tries to actually use the thing.
FAQ
Does URL masking hurt my SEO?
Not inherently, but leaving both URLs indexable without a canonical tag can create duplicate content issues. Set the canonical correctly and it’s a non-issue.
Can I mask a subdomain that isn’t on the same server?
Yes, through a reverse proxy rule, but performance depends on network latency between the two servers. A proxy pass to a subdomain hosted somewhere else will always be a bit slower than one hosted on the same box.
Will SSL certificates cause problems?
Both the masking domain and the masked subdomain need valid SSL. Mixed content or certificate mismatches between the two will throw browser warnings even if the proxy rule itself is correct.
Is there a simpler option if I just want traffic to end up at the subdomain?
Yes. A standard 301 redirect via a plugin or your host’s redirect tool is simpler and faster to set up, and it’s perfectly fine when you don’t need the address bar to stay hidden.
What happens if my host doesn’t support mod_proxy and I’m not on Nginx with config access?
Ask support whether they offer a managed reverse proxy or domain mapping feature. If they don’t and won’t enable mod_proxy, a small edge-layer service such as Cloudflare Workers can sit in front of both domains and perform the proxy pass without needing anything changed on the origin server itself. It’s more setup than an .htaccess rule but works on hosts that lock down server modules.
Do I need to redo this after every WordPress update?
No. The rule lives outside WordPress core, in your server config or your host’s panel, so core and plugin updates don’t touch it. What can break it is a theme or page builder update that changes how internal links are generated, which is one more reason to spot-check the masked page after major updates rather than assuming it’s permanently fine.
Where This Leaves You
Pick the method that matches what you actually need. If the goal is truly invisible masking, that’s a server-level reverse proxy, either through .htaccess with mod_proxy or your host’s dedicated masking feature, not a WordPress plugin. If the goal is just clean, trackable redirects, a plugin like Redirection handles that well and is the right tool for the job. Confusing the two is where most implementations go wrong, and it’s worth five minutes of clarity before you touch a config file.
