URL Forwarding Explained: Domain, Path, and Masked Forwards

URL forwarding sends visitors from one URL to another automatically. You type in one address, and you end up somewhere else. It is one of the most common operations on the web, and it is also one of the most commonly misconfigured.

The confusion starts because "URL forwarding" is an umbrella term. Domain registrars, hosting providers, and CDNs all offer forwarding features, but they implement them differently. The type of forwarding you choose affects whether search engines transfer your rankings, whether visitors see the original URL or the new one, and whether your site works correctly at all.

This guide breaks down the three main types of URL forwarding, explains how each works at the protocol level, and helps you pick the right one. For the full technical background on HTTP redirects, see the HTTP Redirect Guide.

What URL Forwarding Actually Does

At its simplest, URL forwarding maps one URL to another. A visitor requests URL A, and the server sends them to URL B. The mechanism behind that send determines everything.

There are three distinct approaches:

1. Domain forwarding redirects an entire domain to another domain using HTTP status codes.
2. Path forwarding redirects specific URL paths to different destinations.
3. Masked (frame) forwarding loads the destination content inside a frame while keeping the original URL in the browser's address bar.

Each one uses a fundamentally different technique, and each has different consequences for SEO, user experience, and security.

Domain Forwarding

Domain forwarding redirects all traffic from one domain to another. If you own oldbrand.com and your site now lives at newbrand.com, domain forwarding sends every request for oldbrand.com to newbrand.com.

How It Works

When you set up domain forwarding at your registrar, the registrar configures DNS for the source domain to point to their own forwarding servers. When a request arrives, the server responds with an HTTP redirect, either a 301 or 302, pointing the browser to the destination domain.

Browser: GET http://oldbrand.com/about
Server:  HTTP/1.1 301 Moved Permanently
         Location: https://newbrand.com/about
Browser: GET https://newbrand.com/about

The browser follows the redirect transparently. The visitor sees the new URL in their address bar.

Path Preservation

Good domain forwarding preserves the path. A request to oldbrand.com/blog/my-post should forward to newbrand.com/blog/my-post, not just to newbrand.com. Most registrars offer path forwarding as an option, but some default to forwarding everything to the root of the destination domain. Always check this setting.

Losing path information during a forward means every page on your old domain sends visitors to the homepage of your new domain. That is a terrible user experience and wastes the link equity that pointed to specific pages.

SEO Implications

Domain forwarding with a 301 redirect is the gold standard for domain migrations. Google and other search engines treat a 301 as a signal to transfer ranking signals from the old URL to the new one. Over time, the old URLs drop out of the index and the new URLs take their place.

Using a 302 for domain forwarding is a common mistake. A 302 tells search engines the move is temporary, which means they may keep the old URL in their index indefinitely. For permanent moves, always use 301. For more on how redirects affect rankings, see redirect SEO impact.

Path Forwarding

Path forwarding redirects specific URL paths rather than entire domains. You keep the same domain but send certain paths to different destinations.

How It Works

Path forwarding is configured at the web server or CDN level rather than at the registrar. You define rules that match incoming request paths and redirect them to new locations.

example.com/old-page    --> example.com/new-page       (internal redirect)
example.com/shop        --> store.example.com           (cross-subdomain)
example.com/partner     --> partnersite.com/landing     (cross-domain)

The server evaluates each incoming request against the redirect rules and responds with the appropriate HTTP redirect status code.

Common Uses

Path forwarding handles URL restructuring, which is one of the most frequent redirect scenarios. When you reorganize your site's URL structure, rename categories, or consolidate pages, path-level redirects ensure old links still work.

Other common uses include:

• Redirecting removed pages to relevant replacements
• Sending vanity URLs (like example.com/webinar) to third-party platforms
• Handling trailing slash inconsistencies
• Routing old campaign URLs to updated landing pages

Configuration Methods

Path forwarding can be set up in several places:

Web server configuration. Apache uses .htaccess or httpd.conf with Redirect or RewriteRule directives. Nginx uses rewrite or return directives in the server block.

CDN or edge rules. Cloudflare Page Rules, AWS CloudFront functions, and Vercel redirects all handle path-level forwarding at the edge, before the request reaches your origin server.

Application-level redirects. Your CMS or application framework can issue redirects programmatically. WordPress plugins, Next.js redirects in next.config.js, and Rails route redirects all handle this.

Registrar path forwarding. Some registrars allow path-specific forwards, but the control is limited compared to server-level configuration.

SEO Implications

Path forwarding with 301 status codes preserves link equity for individual pages. This is critical during URL restructuring. Each old URL should map to the single most relevant new URL.

Avoid redirect chains where one path forward leads to another forward. Each hop in a chain delays the page load and risks search engines dropping the chain before reaching the final destination. For more on this, see redirect chains explained.

Masked (Frame) Forwarding

Masked forwarding, sometimes called frame forwarding or URL masking, loads the destination site's content inside an HTML frame while keeping the source URL visible in the browser's address bar.

How It Works

Instead of issuing an HTTP redirect, the forwarding server returns an HTML page containing a full-page <iframe> that loads the destination URL.

<!-- What the forwarding server returns for oldbrand.com -->
<html>
<head><title>Old Brand</title></head>
<body style="margin:0">
  <iframe src="https://newbrand.com" 
          style="width:100%;height:100%;border:none;">
  </iframe>
</body>
</html>

The visitor sees oldbrand.com in their address bar, but the content comes from newbrand.com. As they navigate within the framed site, the address bar never changes.

Why People Use It

Masked forwarding appeals to people who want visitors to see their custom domain while the actual site is hosted elsewhere. Common scenarios include:

• A custom domain pointing to a site builder (Wix, Squarespace, etc.) that does not support custom domains on a particular plan
• Multiple domains all showing the same content while appearing to be different sites
• Vanity domains for landing pages hosted on third-party platforms

Why You Should Avoid It

Masked forwarding is problematic for almost every use case.

SEO disaster. Search engines see the framing page, not the framed content. The source domain has almost no indexable content, just an iframe tag. The destination domain gets no link equity from the source domain. Google has been clear that iframed content is not treated the same as directly hosted content. For background on SEO-friendly alternatives, see domain forwarding SEO.

Broken functionality. Many modern websites break inside iframes. Content Security Policy headers, frame-busting scripts, authentication flows, and JavaScript that references window.location can all fail or behave unexpectedly.

Security concerns. Masked forwarding can be exploited for phishing. A legitimate-looking domain frames a malicious site. Browsers have added restrictions on iframe behavior specifically to combat this.

No deep linking. Because the address bar never changes, visitors cannot bookmark or share specific pages within the framed site. Every shared link goes to the homepage.

Mobile issues. Full-page iframes often behave poorly on mobile devices, with scrolling problems, viewport issues, and touch event conflicts.

Forwarding vs Hosting

Sometimes the right answer is not forwarding at all. If you want a domain to serve content, hosting the content directly on that domain is almost always better than forwarding.

When Forwarding Makes Sense

• You changed your domain name and need old links to work
• You own defensive domain registrations (common misspellings, alternate TLDs) and want them to reach your main site
• You are consolidating multiple properties into one
• You need a temporary redirect during maintenance or A/B testing

When Hosting Makes Sense

• You want the domain to have its own identity in search results
• You need full control over the user experience on that domain
• You want to build link equity specifically for that domain
• You need functionality that breaks inside frames (forms, auth, SPAs)

If you are using masked forwarding because your hosting setup does not support custom domains, the better solution is to find hosting that does, or to use a reverse proxy that serves the content directly under your domain without frames.

Setting Up URL Forwarding

At a Domain Registrar

Most registrars (GoDaddy, Namecheap, Cloudflare, Google Domains) offer forwarding directly in their DNS management panel. Look for "URL forwarding," "domain forwarding," or "redirect" in the domain settings. You will typically choose between:

• Permanent (301) or Temporary (302) redirect type
• With or without path forwarding (path preservation)
• Standard or Masked forwarding

Always choose permanent (301), enable path forwarding, and avoid masked forwarding unless you have a very specific reason.

At a Web Server

For path-level forwarding, configure your web server directly.

Nginx:

server {
    listen 80;
    server_name example.com;
    return 301 https://newsite.com$request_uri;
}

Apache (.htaccess):

RewriteEngine On
RewriteRule ^(.*)$ https://newsite.com/$1 [R=301,L]

At a CDN

Cloudflare, AWS CloudFront, and other CDNs let you define redirect rules at the edge. This is often the fastest approach because the redirect happens before the request reaches your origin server, reducing latency.

Verifying Your Forwarding Setup

After configuring any type of forwarding, verify that it works correctly. Check:

1. The status code. Confirm the redirect returns 301 (not 302 or something else).
2. Path preservation. Request a deep path on the source domain and verify it lands on the equivalent path at the destination.
3. HTTPS. Verify that both HTTP and HTTPS versions of the source domain forward correctly.
4. Chain length. Ensure there is no chain of multiple redirects between the source and the final destination.

A redirect tracing tool shows you each hop in the chain, the status code at each step, and where the browser ultimately lands. This is the fastest way to confirm your setup.

Quick Reference

| Type | Mechanism | URL Changes? | SEO Safe? | Use When | |------|-----------|-------------|-----------|----------| | Domain forwarding (301) | HTTP redirect | Yes | Yes | Permanent domain moves | | Domain forwarding (302) | HTTP redirect | Yes | Risky | Temporary domain moves | | Path forwarding | HTTP redirect | Yes | Yes | URL restructuring | | Masked forwarding | iframe | No | No | Almost never |

The short version: use 301 domain forwarding for permanent domain changes, path forwarding for URL restructuring, and avoid masked forwarding entirely. If you need the source URL to appear in the address bar, host the content there instead of masking it.