How to Mask URL for Subdomain in WordPress

“Masking” a subdomain in WordPress means the visitor sees one address in the browser while the content is served from somewhere else. Most people asking this question want one of two things: either shop.example.com should show up as example.com/shop, or a WordPress site living on app.example.com should answer on a completely different branded domain. The short answer is that an iframe “mask” is the wrong tool for both jobs, and a reverse proxy, a redirect, or WordPress Multisite domain mapping is the right one depending on what you actually need.

This guide walks through each option, with the server config and WordPress settings we use on client sites, and is honest about the trade-offs. Pick the method that matches your goal rather than the one that looks easiest.

First, decide what you actually want

The word “mask” covers four different outcomes, and they need four different solutions. Write down which one you mean before touching DNS or the wp-config file.

What you want	Right approach	SEO impact
Visitors type blog.example.com and land on example.com/blog	301 redirect	Good: link equity moves to the target
Content lives on blog.example.com but should appear at example.com/blog in the address bar	Reverse proxy (server or Cloudflare Worker)	Good if canonicals point at the proxied URL
One WordPress install serves several brands on their own domains	Multisite with domain mapping	Good: each domain is a first-class site
Hide the real host entirely, including for bookmarks and search	Not really possible; the closest safe option is a proxy	Iframe masking is actively harmful

If your case is the first row, stop reading after the redirect section. A surprising share of “how do I mask my subdomain” requests are solved by a one-line redirect.

Why the iframe trick is the wrong answer

The classic masking method is an HTML page on the subdomain containing a full-screen iframe that loads the real site. Some domain registrars still call this “URL forwarding with masking” in their DNS panels. It works in the sense that the address bar does not change, and that is where the good news ends.

• Search engines index the iframe shell (an empty page) rather than your content. Google treats framed content as belonging to the framed URL, so the masked domain gets nothing.
• Every internal click stays inside the frame, so the address bar never updates. Visitors cannot bookmark or share a specific page.
• Browsers block third-party cookies inside cross-site iframes by default, which breaks WordPress login, WooCommerce carts and BuddyPress sessions.
• Your own site may refuse to load: WordPress sends X-Frame-Options: SAMEORIGIN on login and admin pages, and many security plugins add it everywhere.
• Screen readers and mobile browsers handle nested full-page frames poorly.

We have removed iframe masks from at least a dozen client sites over the years, usually after someone noticed the domain had no rankings at all. Skip it unless you are building a throwaway landing page that nobody needs to find.

Option 1: a 301 redirect (when masking is not what you need)

If the content already lives at example.com/shop and you want shop.example.com to be a memorable shortcut, redirect it. Visitors see the final URL, which is fine because it is the canonical one anyway.

On Apache, put this in the .htaccess file at the document root that answers for the subdomain, above the WordPress rules:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^shop\.example\.com$ [NC]
RewriteRule ^(.*)$ https://example.com/shop/$1 [R=301,L]

On Nginx, a dedicated server block is cleaner:

server {
    listen 443 ssl;
    server_name shop.example.com;
    return 301 https://example.com/shop$request_uri;
}

If you do not have server access, the free Redirection plugin (Tools → Redirection) can handle path-level redirects, but it only runs once WordPress has loaded on the subdomain, so the subdomain still needs to point at a WordPress install. For a bare hostname, a DNS-level or hosting-panel redirect is faster and avoids PHP entirely.

Option 2: a reverse proxy (true masking done properly)

A reverse proxy sits in front of the real site, fetches the page, and returns it under the address the visitor typed. The browser never knows the content came from elsewhere. This is how large companies serve a WordPress blog at company.com/blog while the blog itself runs on a separate host.

Apache with mod_proxy

Your host needs mod_proxy and mod_proxy_http enabled. Shared hosting usually does not allow this; VPS and dedicated servers do.

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^blog/(.*)$ https://blog.example.com/$1 [P,L]
ProxyPassReverse /blog/ https://blog.example.com/

The [P] flag is what makes this a proxy rather than a redirect. ProxyPassReverse rewrites Location headers coming back from the subdomain so that redirects issued by WordPress (after login, after a form post) stay on the masked path.

Nginx

location /blog/ {
    proxy_pass https://blog.example.com/;
    proxy_set_header Host blog.example.com;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Proto https;
    proxy_redirect https://blog.example.com/ https://www.example.com/blog/;
}

Cloudflare Workers (no server access needed)

If both hostnames are behind Cloudflare, a Worker routed to www.example.com/blog* can rewrite the request to the subdomain and hand back the response. This is our preferred approach when the two sites are on different hosts or when the main site is not even WordPress. A minimal Worker looks like this:

export default {
  async fetch(request) {
    const url = new URL(request.url);
    if (url.pathname.startsWith('/blog')) {
      url.hostname = 'blog.example.com';
      url.pathname = url.pathname.replace(/^\/blog/, '') || '/';
      return fetch(new Request(url, request));
    }
    return fetch(request);
  }
};

Workers run on Cloudflare’s free plan up to 100,000 requests a day, which covers most blogs.

The WordPress side of a proxy

Proxying the HTML is only half the job. WordPress generates absolute URLs everywhere (stylesheets, images, REST calls, pagination links), and those still point at blog.example.com. You have three ways to fix that:

1. Change the WordPress address. In Settings → General, set both WordPress Address and Site Address to https://www.example.com/blog. WordPress now believes it lives there and emits correct links. This is the cleanest option when the subdomain is only ever reached through the proxy.
2. Rewrite on the way out. Apache’s mod_substitute or Nginx’s sub_filter can replace the hostname in HTML responses. It works but is fragile with compressed responses and JSON.
3. Filter inside WordPress. Hook home_url and site_url when the request carries your X-Forwarded-Host header. Useful if you need the subdomain to keep working directly as well.

Whichever you choose, add a canonical tag that points at the masked URL. Yoast and Rank Math both read the home URL, so option 1 handles this for you. With options 2 and 3, check the <link rel="canonical"> in page source before calling it done, otherwise Google may index the subdomain and the masked path as duplicates.

Also tell WordPress it is behind HTTPS. When the proxy terminates SSL and talks to the origin over plain HTTP, WordPress sees an insecure request and redirects in a loop. Put this near the top of the wp-config file:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
    $_SERVER['HTTPS'] = 'on';
}

Option 3: Multisite domain mapping

If the real goal is “several brands, one WordPress install, each on its own domain”, do not proxy anything. WordPress Multisite has had domain mapping built in since version 4.5 (2016), so the old WordPress MU Domain Mapping plugin is no longer needed.

1. Enable Multisite by adding define( 'WP_ALLOW_MULTISITE', true ); to the wp-config file, then follow Tools → Network Setup. Subdomain installs are the more flexible choice for mapping.
2. Create the sub-site, for example brand.network.com.
3. Point the custom domain’s DNS (an A record, or a CNAME if your host supports it) at the same server as the network.
4. In Network Admin → Sites → Edit, change the Site Address to https://brandname.com.
5. Make sure the server answers for the new hostname and has an SSL certificate for it. Hosts like Kinsta, WP Engine and Cloudways handle this in their panel; on your own server, Let’s Encrypt with a wildcard or per-domain cert works.

Each mapped site is a full WordPress site with its own canonical domain, so there is nothing to mask and nothing to rewrite. This is the right architecture for agency client networks and for community sites that run separate branded sub-communities. If you are building something like that on BuddyPress, our BuddyPress development team has set up mapped multisite networks several times and can save you a week of DNS head-scratching.

Option 4: plugins, and what they can and cannot do

People often ask for “a plugin that masks the URL”. Be clear about what each one does:

• Pretty Links creates short links such as example.com/go/offer that redirect elsewhere. It cloaks affiliate links, not whole subdomains.
• Redirection manages 301 and 302 rules from inside WordPress. Good for path redirects, not for proxying.
• WP Hide & Security Enhancer rewrites /wp-content/ and /wp-admin/ paths to custom names. It hides that you run WordPress, not which hostname you are on.
• Domain Mapping System (commercial) maps extra domains to specific pages or post types on a single, non-multisite install. Worth a look if you want landing.com to show one landing page from your main site without setting up Multisite.

None of them turn a subdomain into a subdirectory on their own. For that you need the proxy or the redirect.

Troubleshooting the usual breakages

Redirect loop after setting up the proxy

Almost always the HTTPS detection issue above. Add the X-Forwarded-Proto check to the wp-config file, and make sure the proxy actually sends that header.

CSS and images load from the wrong host

The WordPress Address still points at the subdomain. Update Settings → General, then clear any page cache and object cache. If you use a CDN plugin that rewrites asset URLs, update its origin setting too.

Logging in kicks you back to the subdomain

Cookies are scoped to the domain that set them. When the login form posts to blog.example.com but the visitor is on www.example.com, the auth cookie is set on the wrong host. Define COOKIE_DOMAIN in the wp-config file to match the public hostname, and confirm ProxyPassReverse or proxy_redirect is rewriting the post-login redirect.

Google still shows the subdomain

Check canonicals, submit the new sitemap in Search Console, and either redirect direct hits on the subdomain to the masked path or block them with a noindex header. Leaving both reachable without a canonical is the most common cause of duplicate-content trouble we see after a proxy migration.

REST API and AJAX calls fail

The block editor, WooCommerce checkout and BuddyPress activity feeds all call /wp-json/ and admin-ajax.php using the home URL. If that still points at the subdomain, the browser blocks the request as cross-origin. Fixing the home URL resolves it; otherwise add CORS headers at the proxy.

What we’d do

For a single subdomain that should appear as a folder: use a reverse proxy (Cloudflare Worker if you can, server config if not), change the WordPress Address to the masked path, and verify canonicals. For a subdomain that is only a shortcut: 301 it and move on. For multiple brands: Multisite with core domain mapping. Do not use an iframe.

If the site that needs moving is a busy community or store and you would rather not experiment on it live, our WordPress migration service handles proxy setups, domain changes and the search-and-replace that follows. For the underlying server documentation, Apache’s mod_proxy reference and Cloudflare’s Workers documentation are the two sources worth bookmarking.