Domain Forwarding and SEO: Redirects That Keep Your Rankings

A 301 redirect from an old domain to a new one passes ranking signals to the destination, and search engines will eventually treat the new domain as the canonical one. A 302 does not, because it says the move is temporary. The mistake that costs the most traffic is not the status code — it is redirecting every old URL to the new homepage instead of to its equivalent page.

Domain migrations are routine and they still go wrong often, usually in the same two ways. This covers what actually transfers, the URL mapping that most of the value depends on, and the mistakes that turn a rebrand into a traffic loss you spend a year recovering from.

Table of contents

• The status codes, and what each signals
• Map URLs, do not dump them on the homepage
• Redirect chains, and why they compound
• The migration checklist
• What forwarding does not fix
• Defensive domains: forward, do not park
• How this fits the rest of the stack
• FAQ

The status codes, and what each signals

• 301 Moved Permanently — the resource has permanently moved. Ranking signals transfer. This is the one for domain migrations.
• 308 Permanent Redirect — like 301 but preserves the HTTP method. Treated equivalently for ranking purposes.
• 302 Found — temporary. Signals stay with the original URL. Correct for A/B tests and maintenance pages, wrong for a move.
• 307 Temporary Redirect — like 302, preserving method.
• Meta refresh and JavaScript redirects — work eventually and are much weaker signals. Avoid for anything that matters.

Google has stated that 301s pass ranking signals, and the earlier folklore about a fixed percentage of loss is not something they have confirmed. In practice a well-executed migration recovers within weeks; a badly executed one may not fully recover.

Some registrar domain forwarding features use a meta refresh or a frame rather than a real 301. That is materially worse and easy to miss — check what is actually returned:

# Follow the chain and show every hop
curl -sIL https://old-domain.com/some/page | grep -E '^HTTP|^[Ll]ocation'

# Expected: a single 301 straight to the final URL
# HTTP/1.1 301 Moved Permanently
# location: https://new-domain.com/some/page
# HTTP/1.1 200 OK

Map URLs, do not dump them on the homepage

This is where most of the damage happens. Redirecting every old URL to the new homepage feels tidy and destroys page-level signals.

Search engines treat a redirect to an irrelevant page as a soft 404 — they recognise the destination is not an equivalent of the source, and the accumulated signals for that page are discarded rather than transferred.

# Wrong: everything to the homepage
old.com/blog/scaling-postgres  ->  new.com/
old.com/pricing                ->  new.com/

# Right: page to equivalent page
old.com/blog/scaling-postgres  ->  new.com/blog/scaling-postgres
old.com/pricing                ->  new.com/pricing

When the URL structure also changes, build a mapping file rather than guessing:

# nginx: exact mappings, with a sensible pattern fallback
map $request_uri $new_uri {
    /blog/scaling-postgres   /articles/scaling-postgres;
    /pricing                 /plans;
    /about-us                /about;
    default                  "";
}

server {
    listen 443 ssl;
    server_name old-domain.com www.old-domain.com;

    location / {
        return 301 https://new-domain.com$uri$is_args$args;
    }
}

Pages with no equivalent should return 410 Gone, not redirect to the homepage. A 410 tells search engines the page is deliberately removed, which is honest and gets it de-indexed cleanly. A homepage redirect is a lie that gets treated as a soft 404 anyway.

Redirect chains, and why they compound

Every successive migration adds a hop, and hops accumulate quietly across the years.

# Three hops, from three separate migrations
http://old.com/page
  -> https://old.com/page          (HTTP to HTTPS)
  -> https://www.new.com/page      (domain change)
  -> https://new.com/page          (www to apex)

# One hop, which is what you want
http://old.com/page  ->  https://new.com/page

Chains cost crawl budget, add latency for every visitor, and Google stops following after several hops. Each new redirect rule should be written against the final destination, not against whatever the previous rule pointed at.

# Audit chains across your important URLs
while read -r url; do
  hops=$(curl -sIL -o /dev/null -w '%{num_redirects}' "$url")
  [ "$hops" -gt 1 ] && echo "$hops hops: $url"
done < important-urls.txt

Redirect loops are the failure mode to test for first. Two domains each redirecting to the other produces ERR_TOO_MANY_REDIRECTS and total unavailability, and it is easy to create when one rule is added without reading the other.

The migration checklist

1. Crawl the old site first. Export every indexed URL with its traffic and inbound links. You cannot map what you have not listed.
2. Build the mapping — old URL to new URL, one line each. Spend the time here; it is where the value is.
3. Set up 301s before announcing anything. Test a sample of URLs across every content type before the change is public.
4. Update canonical tags on the new site to point at new URLs. A leftover canonical pointing at the old domain undoes the redirect.
5. Update the sitemap and submit it. Temporarily keep the old sitemap accessible so crawlers rediscover the old URLs and follow the redirects.
6. Use the change of address tool in Google Search Console. It exists specifically for this and is routinely skipped.
7. Verify both domains in Search Console so you can watch traffic move from one to the other.
8. Update inbound links at the source where you can. The high-value ones are worth an email.
9. Keep the redirects for years. There is no meaningful cost, and links from 2019 still send traffic.

Do not let the old domain expire. Expired domains with residual traffic are bought within minutes of dropping, and the buyer inherits your redirects, your remaining traffic, and the ability to receive email at your old addresses.

Keep the redirects at the edge rather than in application code — they need to work whether or not the application is running, and they are configuration rather than logic. The redirects documentation covers defining them per path.

What forwarding does not fix

Redirects transfer signals; they do not transfer everything, and expecting them to causes disappointment.

• Email does not follow. MX records are separate. Forwarding a domain’s web traffic does nothing for mail, and the old addresses stop working unless you configure them.
• Analytics history splits. The new domain starts a new property unless you plan for continuity.
• Brand recognition does not transfer. People typing the old name into a search box still search for the old name for years.
• Bad content stays bad. A migration does not improve pages that were not ranking anyway.
• Penalties follow you. A manual action or algorithmic suppression transfers with the redirect. Migrating away from a penalty does not work and is a well-known dead end.

Expect a dip. Even a clean migration typically shows a temporary drop while search engines reprocess the site. Two to eight weeks is normal depending on size and crawl frequency. The mistake at this point is panicking and changing things, which resets the clock.

Plan the migration for a low-traffic period, change one thing at a time, and resist the temptation to redesign the site in the same week. If traffic drops after a combined migration and redesign, you have no way to tell which caused it.

Defensive domains: forward, do not park

Most organisations own domains they do not serve — misspellings, other TLDs, retired brands. Parking them wastes them; forwarding them costs nothing.

• 301 them to the canonical domain. Any accumulated links pass along, and people who typed the wrong thing arrive where you wanted.
• Never serve identical content on both without canonical tags. That is duplicate content and you lose control of which one gets indexed.
• Publish null SPF and DMARC records on domains you do not send mail from, so nobody can spoof your brand from them.
• Keep auto-renew on. A lapsed defensive domain is worse than never having registered it.

; A domain you own but never send mail from
example.net.          TXT  "v=spf1 -all"
_dmarc.example.net.   TXT  "v=DMARC1; p=reject;"
example.net.          MX   0 .

The www versus apex question belongs here too. Pick one, 301 the other to it, and be consistent in every internal link, sitemap entry, and canonical tag. Serving both without a redirect splits your signals for no benefit — which one you pick genuinely does not matter.

How this fits the rest of the stack

Use 301s, map old URLs to their real equivalents rather than to the homepage, and collapse chains so every redirect points at the final destination. Keep the old domain registered and the redirects in place indefinitely. Expect a temporary dip and do not react to it by changing more things. If you are consolidating domains and want to see what custom domains and bandwidth cost, the RunxBuild hosting calculator shows the line items.

Useful related references:

• SSH Tunnel: Local and Remote Port Forwarding, and SOCKS Proxy
• Port Forwarding vs Port Triggering: The Real Difference, the Security Trade-Off, and Why Cloud Apps Need Neither
• Domain Migration: DNS Plan, 301 Redirects, and SEO Preservation
• Custom domains and certificates on RunxBuild

FAQ

Does domain forwarding hurt SEO?

Not when done as a 301 with URLs mapped page to page. Ranking signals transfer to the destination. Harm comes from using a 302, from meta-refresh forwarding offered by some registrars, or from redirecting everything to the homepage.

Should I use a 301 or 302 redirect for a domain move?

301, or 308 if you need to preserve the HTTP method. A 302 signals a temporary move, so search engines keep the original URL as canonical and the new domain does not inherit the signals.

Why should I not redirect everything to the new homepage?

Search engines treat a redirect to an unrelated page as a soft 404 and discard that page’s accumulated signals rather than transferring them. Map each URL to its real equivalent, and return 410 for pages with none.

How long should I keep domain redirects in place?

Indefinitely. Links from years ago still send traffic and there is no meaningful cost to leaving the rules running. Letting the old domain expire also risks someone else registering it and inheriting your traffic and email.

How long does it take for rankings to recover after a domain migration?

Typically two to eight weeks depending on site size and crawl frequency, with a temporary dip being normal. Changing things during the dip resets the clock, so avoid combining a migration with a redesign.