How to Redirect a Domain (URL Forwarding) Without Losing SEO

You bought a second domain, or you're retiring an old one, and now you just want it to land visitors on your main site. Sounds simple. Then someone tells you to "just forward it," you do that in five minutes through the registrar panel, and three weeks later your search rankings are gone and half your email has stopped arriving. Here's how to actually do it without either of those things happening.

What "Domain Forwarding" Really Means

Domain forwarding isn't one thing — it's three different mechanisms that all get called the same name, and mixing them up is where most of the damage happens:

• DNS-level pointing — you change the domain's A record or nameservers so it resolves straight to your server, and your server serves the actual site. No redirect involved.
• HTTP redirect (301/302) — the domain still resolves somewhere (usually a lightweight host or your registrar's parking server), and that server sends the browser an HTTP redirect to the real URL.
• Masked/frame forwarding — the registrar loads the destination site inside an invisible frame while the address bar keeps showing the old domain. It looks convenient. It's almost never the right call — more on that below.

Which one you want depends entirely on the use case, and picking the wrong one is the actual root cause behind most of the "my rankings tanked" and "my email vanished" tickets we see.

Symptom: What Goes Wrong When It's Done Carelessly

Three complaints show up over and over after a rushed domain forward:

1. Rankings and backlinks disappear. Google indexed the old domain for years, and a masked forward or a 302 redirect tells search engines "this might be temporary, don't transfer the ranking signals." The link equity just sits there, unused.
2. Email stops working. Someone points the whole domain — nameservers and all — at a forwarding service, wiping out the MX records that were quietly delivering mail. Nobody notices until a client says an invoice never arrived.
3. Browsers throw a certificate warning. The destination gets an HTTPS redirect, but the forwarding server itself has no valid SSL certificate for the old domain, so the browser blocks the page before the redirect can even fire.

Cause: Why This Keeps Happening

It's almost always the same root cause: someone used a one-click "forward this domain" button in the registrar's dashboard without checking what it actually does under the hood. Most registrar forwarding tools default to masked forwarding with a 302 (temporary) status code, because that's the setting that "just works" in a demo — not because it's SEO-safe. And because that tool controls the whole domain, it silently overwrites whatever MX and TXT records were already there.

Fix: Set It Up the Right Way

Step 1 — Decide what you actually need

If you're not sure, default to a 301. It's permanent, it passes ranking signals to the new URL, and every browser and crawler understands it correctly.

Step 2 — Keep DNS and mail separate from the redirect

Before touching forwarding, check what's currently on the domain's DNS zone:

dig MX olddomain.com +short
dig TXT olddomain.com +short

If there's an MX record or an SPF/DKIM TXT record in there, do not let a forwarding wizard overwrite the zone. Keep those records exactly as they are — a redirect only needs the A record (or the registrar's forwarding target) to change, nothing else.

Step 3 — Redirect at the server, not at the registrar, when you control hosting

If both domains point to hosting you manage, an unmasked 301 done in .htaccess (Apache/cPanel) is cleaner and easier to audit than registrar-side forwarding:

# Redirect entire domain, preserving the path (best for SEO)
RewriteEngine On
RewriteCond %{HTTP_HOST} ^olddomain\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.olddomain\.com$
RewriteRule ^(.*)$ https://newdomain.com/$1 [R=301,L]

Notice the $1 — it carries the URL path across, so olddomain.com/blog/hosting-tips lands on newdomain.com/blog/hosting-tips, not just the new homepage. Dumping every old URL onto the new homepage is the single biggest SEO mistake in a domain migration; it tells Google every page lost its content.

For Nginx, the equivalent block:

server {
    listen 80;
    listen 443 ssl;
    server_name olddomain.com www.olddomain.com;
    ssl_certificate     /etc/letsencrypt/live/olddomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/olddomain.com/privkey.pem;
    return 301 https://newdomain.com$request_uri;
}

Step 4 — If you're using registrar-level forwarding instead

Fine for a domain with no hosting behind it at all. In cPanel-adjacent registrar panels this is usually under Domain > Forwarding. Two settings matter:

• Pick 301/Permanent, not 302/Temporary.
• Turn masking off. Leave "Forward with masking" unchecked so the address bar actually updates to the real URL.

Step 5 — Don't skip SSL on the source domain

A redirect from HTTP to HTTPS still has to pass through the old domain first. If the old domain has no valid certificate, Chrome and Firefox block the connection before your redirect rule ever runs — the visitor sees a security warning, not your new site. Keep AutoSSL (or a free Let's Encrypt cert) active on the old domain for as long as it's still pointed anywhere, even if the only thing it does is redirect.

Step 6 — Verify it properly

curl -IL https://olddomain.com/some-page

You want to see a single 301 hop straight to the final HTTPS URL on the new domain — not a 302, not two or three chained redirects, and not a mixed-content warning in the browser console.

Prevention: Keep It From Breaking Again

• Add the old domain as a property in Google Search Console and watch the Page Indexing report for a few weeks — a spike in "Page with redirect" is expected; a spike in "Not found" isn't.
• Never chain redirects. old.com → temp.com → new.com loses more ranking signal at every hop and adds latency. Point straight to the final URL.
• Leave the old domain renewed for at least 12 months after the switch — losing it to expiry cancels the redirect and the domain often gets snapped up by a squatter within days.
• Set a canonical tag on the new pages pointing to themselves, so even during the transition period there's no ambiguity about which URL is the "real" one.
• Re-check MX/SPF/DKIM/DMARC after any forwarding change — a quick dig MX olddomain.com takes ten seconds and catches the mistake before a client's invoice bounces.

Quick Reference