What Is Domain Forwarding, and How Do You Set It Up?

You bought a shorter version of your brand name, a common misspelling, or a .net to go with your .com, and now you want all of them to land on your main website. That is exactly what domain forwarding does: it sends anyone who visits one domain to a URL on another. Almost every registrar offers it as a checkbox, but behind that checkbox are choices that matter for SEO, HTTPS, and user experience, such as permanent versus temporary redirects and "masked" forwarding. This article explains how domain forwarding actually works, which options to pick, and how to set it up at a registrar, on your own Nginx or Apache server, or with Cloudflare rules. If you only want the DNS side of the story, see how to redirect a domain using DNS records.

What Is Domain Forwarding?

Domain forwarding (also called URL forwarding or domain redirection) is the practice of automatically sending visitors from one domain, the source, to a different URL, the destination. Someone types example.net into their browser and ends up on https://www.example.com.

The crucial thing to understand is that DNS cannot redirect a browser by itself. DNS only translates names into IP addresses. A redirect is an HTTP response, so something has to answer the HTTP request for the source domain and reply with a redirect status code and a Location header. That "something" can be:

• Your registrar's forwarding service, which runs web servers whose only job is to send redirects.
• Your own web server (Nginx, Apache, Caddy, IIS) configured to answer for the source domain.
• A CDN or edge platform, such as Cloudflare, which answers at its edge before the request ever reaches an origin.

In all three cases, the source domain's DNS points at whichever server is doing the redirecting. A full redirect exchange looks like this:

GET / HTTP/1.1
Host: example.net

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/

The browser then makes a fresh request to the URL in the Location header.

Common Reasons to Forward a Domain

• Consolidating extensions: send .net, .org, or country-code versions of your brand to your primary domain. See whether you should buy multiple domain extensions before stockpiling them.
• Catching typos: forward misspellings of your brand so customers do not end up somewhere else.
• Rebranding or migration: point an old domain at a new one so existing links and rankings carry over. For the full process, read how to move a website to a new domain.
• Campaign and vanity URLs: a short, memorable domain for print or podcast ads that forwards to a tracked landing page.
• Social or third-party profiles: forward a domain to a profile page, a shop on a marketplace, or a link-in-bio page while you build a real site.

Types of Domain Forwarding

301 Permanent Redirect

A 301 Moved Permanently response tells browsers and search engines that the source has moved for good. Browsers may cache it, and search engines treat it as a strong signal to index the destination instead of the source and to consolidate ranking signals there. This is the right choice for nearly every forwarding setup: extra extensions, typo domains, and migrations.

302 Temporary Redirect

A 302 Found response says the move is temporary. Search engines generally keep the source URL in mind and may keep it indexed. Use it for genuinely temporary situations, such as a seasonal campaign domain that will later host its own site, or a short maintenance redirect.

Two related codes matter if you redirect anything other than simple page loads:

Status	Meaning	Permanent?	Method preserved?
301	Moved Permanently	Yes	No (browsers may turn POST into GET)
302	Found	No	No (browsers may turn POST into GET)
307	Temporary Redirect	No	Yes
308	Permanent Redirect	Yes	Yes

For ordinary website forwarding, 301 and 302 are what registrars offer and what you need. Use 307 or 308 when forms or API clients send POST requests to the old domain, since those codes guarantee the method and body are kept. Google treats 301 and 308 as permanent and 302 and 307 as temporary.

Masked Forwarding (Frame Forwarding)

Masked forwarding, sometimes called stealth or cloaked forwarding, does not redirect at all. Instead, the registrar serves a small HTML page on the source domain that loads the destination inside a full-screen iframe. The address bar keeps showing the source domain.

The page a registrar generates looks roughly like this:

<!doctype html>
<html>
  <head>
    <title>My Site</title>
    <meta name="description" content="My site description" />
  </head>
  <body style="margin:0">
    <iframe
      src="https://www.example.com/"
      style="border:0;width:100%;height:100vh"
    ></iframe>
  </body>
</html>

It sounds appealing, but masked forwarding has serious drawbacks:

• Many sites refuse to be framed. Sites that send X-Frame-Options: DENY or a Content-Security-Policy with frame-ancestors restrictions will show a blank or error page inside the frame. Most large platforms do this.
• SEO suffers. Search engines see a nearly empty page on the source domain and index the destination separately, so the masked domain earns nothing.
• Deep links break. The address bar never changes as users click around, so they cannot bookmark or share specific pages.
• HTTPS and mixed-content problems appear if the frame wrapper and destination use different schemes.
• Mobile and accessibility issues are common with full-page frames.

If you want a different domain to show in the address bar, the correct solution is to actually host the site on that domain, or make it the primary domain and redirect the others to it.

Path Forwarding vs. Homepage-Only Forwarding

Registrars usually offer a choice between forwarding everything to the homepage and preserving the path. With path preservation, example.net/pricing?ref=ad goes to https://www.example.com/pricing?ref=ad. Without it, every URL lands on the homepage. For migrations and alternate extensions, always preserve the path; sending every old URL to the homepage is treated much like a soft 404 by search engines and frustrates visitors.

How to Set Up Forwarding at Your Registrar

The exact menus differ, but the process is nearly identical everywhere:

1. Sign in to your registrar and open the domain you want to forward.
2. Find the Forwarding, Redirect, or URL forwarding section. It is sometimes under DNS settings.
3. Enter the destination URL including the scheme, for example https://www.example.com.
4. Choose Permanent (301) unless you have a specific reason for temporary.
5. Choose Forward only rather than Forward with masking.
6. Enable path forwarding if it is offered.
7. Save. The registrar usually adds or changes A (and sometimes CNAME) records to point at its forwarding servers.

Two important caveats:

• Forwarding only works if the registrar's DNS is authoritative for the domain, or if you manually create the records the registrar asks for. If your domain uses Cloudflare or another DNS host, the registrar's forwarding toggle may do nothing.
• HTTPS support varies. Some registrars issue certificates for forwarded domains automatically; others only forward plain HTTP, so https://example.net produces a certificate error. Test both schemes after setup.

Do not touch existing MX records when enabling forwarding. Web forwarding only affects HTTP traffic, and email for the source domain will keep working as long as its mail records stay in place.

How to Set Up Forwarding on Your Own Server

If you already run a web server, handling forwarding yourself gives full control over status codes, paths, and HTTPS. Point the source domain's A and AAAA records at your server first.

Nginx

This configuration redirects every request for example.net and www.example.net, on HTTP and HTTPS, to the same path on https://www.example.com:

server {
    listen 80;
    listen [::]:80;
    server_name example.net www.example.net;
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name example.net www.example.net;

    ssl_certificate     /etc/letsencrypt/live/example.net/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.net/privkey.pem;

    return 301 https://www.example.com$request_uri;
}

$request_uri contains the original path and query string, so deep links are preserved. Note that the HTTPS block needs a valid certificate for the source domain, because the TLS handshake happens before any redirect is sent. You can get one with Certbot:

sudo certbot certonly --nginx -d example.net -d www.example.net
sudo nginx -t && sudo systemctl reload nginx

On Nginx versions older than 1.25.1, replace http2 on; with listen 443 ssl http2;.

Apache (.htaccess or Virtual Host)

With mod_rewrite enabled, place this in the document root's .htaccess for the source domain, or inside its VirtualHost:

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

If you control the virtual host configuration, the simpler mod_alias form is faster and needs no rewrite engine:

<VirtualHost *:80>
    ServerName example.net
    ServerAlias www.example.net
    Redirect permanent / https://www.example.com/
</VirtualHost>

Redirect automatically appends the rest of the path, so /blog/post goes to https://www.example.com/blog/post.

Cloudflare Redirect Rules

If the source domain uses Cloudflare DNS, you do not need a server at all. Create a proxied (orange-cloud) DNS record so Cloudflare receives the traffic. A common pattern is an A record pointing to a reserved placeholder address such as 192.0.2.1, which is never actually contacted because the redirect happens at Cloudflare's edge.

Then add a Redirect Rule (Rules, then Redirect Rules, or a Single Redirect) with a custom filter expression and a dynamic target:

When incoming requests match:
  (http.host eq "example.net" or http.host eq "www.example.net")

Then:
  Type: Dynamic
  Expression: concat("https://www.example.com", http.request.uri.path)
  Status code: 301
  Preserve query string: enabled

For forwarding many domains or thousands of specific URLs, Cloudflare's Bulk Redirects feature uses lists of source and target URLs instead. Cloudflare has deprecated the older Page Rules product in favour of these rules, so new setups should use Redirect Rules. Setting up the zone itself is covered in how to set up Cloudflare DNS for your website.

Forwarding the Apex Domain

Forwarding a bare domain like example.net (as opposed to www.example.net) has an extra wrinkle: the apex cannot hold a CNAME record, so you cannot simply CNAME it to a forwarding service. You need an A record to the forwarder's IP, an ALIAS/ANAME record, or a provider that does flattening. The background is in what an apex domain is and can you use a CNAME record on the root domain.

How to Test Your Forwarding

Use curl with -I (headers only) to see exactly what the server returns, without following the redirect:

curl -sI http://example.net/pricing?ref=test
curl -sI https://www.example.net/pricing?ref=test

You want to see a 301 and a Location header with the full destination path:

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/pricing?ref=test

To see the whole chain and catch extra hops, follow redirects and print each step:

curl -sIL https://example.net/pricing | grep -iE "^(HTTP|location)"

A clean setup has a single hop from any source URL to the final destination. Chains like http://example.net to https://example.net to https://example.com to https://www.example.com work, but they waste time and dilute signals. Fix them by making each source rule point straight to the final URL.

To check many domains at once, this Bash loop prints the status code and destination for each:

#!/usr/bin/env bash
for d in example.net example.org exmaple.com; do
  for scheme in http https; do
    out=$(curl -s -o /dev/null -w "%{http_code} %{redirect_url}" "$scheme://$d/")
    echo "$scheme://$d -> $out"
  done
done

Domain Forwarding and SEO

Search engines handle forwarding well when it is done properly:

• Use 301 (or 308) for permanent moves. Google's documentation states that permanent server-side redirects are the best way to signal a move and that they pass signals to the target.
• Preserve paths and map old URLs to their closest equivalents.
• Avoid masked forwarding for anything you want to rank.
• Keep redirects in place for the long term. Google recommends keeping redirects for at least a year after a site move, and keeping them indefinitely is safer, since old links on other sites never expire.
• Renew the forwarded domain. If a forwarding domain lapses, someone else can register it and capture your traffic. Turn on auto-renewal for every domain that forwards traffic.

Forwarded domains that never hosted content do not pass any special ranking benefit. Buying keyword domains and forwarding them to your site is not an SEO strategy.

Domain Forwarding FAQ

Conclusion

Domain forwarding is simple in concept: point a domain at a server that answers every request with a redirect. The choices around it are where quality comes from. A permanent 301 that preserves the path, works on both HTTP and HTTPS, and reaches the final URL in a single hop gives visitors a seamless experience and gives search engines a clear signal. Masked forwarding, homepage-only forwarding, and long redirect chains do the opposite.

Registrar forwarding is fine for a handful of spare domains as long as it supports HTTPS. If you run your own server or use Cloudflare, configuring the redirect there gives you more control and easier testing. Whichever route you choose, verify it with curl, keep the forwarded domains renewed, and leave the redirects in place long after the switch.

Here are some useful references for going deeper on domain forwarding and redirects:

1. Google Search Central: Redirects and Google Search — how Google interprets each redirect type and which to use.
2. MDN Web Docs: Redirections in HTTP — a clear explanation of 3xx status codes and redirect mechanisms.
3. RFC 9110: HTTP Semantics, Redirection 3xx — the standard defining 301, 302, 307, and 308.
4. Nginx: ngx_http_rewrite_module — official documentation for the return and rewrite directives.
5. Cloudflare Docs: Single Redirects — how to build redirect rules at Cloudflare's edge.