How to 301 Redirect a Domain to Another Domain, Including HTTPS

What a domain-wide 301 redirect does

A 301 redirect is an HTTP response that says a resource has moved permanently. When you redirect a whole domain, every request to the old hostname gets a 301 response with a Location header pointing at the matching address on the new domain. Browsers follow it automatically, and search engines treat it as a strong signal that the new URL should replace the old one in their index.

The important word is matching. A good domain redirect keeps the path and the query string, so https://old-example.com/menu/cakes?size=large goes to https://example.com/menu/cakes?size=large, not to the new home page. Sending everything to the home page throws away the relevance of each old page, and Google tends to treat mass redirects to an unrelated page as soft 404s, so the old pages simply drop out rather than passing their signals on.

Google treats 301 and 308 the same way for indexing. What matters more is that the redirect is permanent, happens in one hop, and answers correctly on every version of the old hostname: http and https, with and without www.

Why domain redirects break, and why SSL errors appear

Most failed domain moves come down to one of a handful of causes:

Why the certificate matters before the redirect

This is the part that catches most people out. When a visitor types or clicks https://old-example.com, the browser first opens a TLS connection to that hostname and checks the certificate. Only after the handshake succeeds does it send the HTTP request and receive your 301. If the certificate is missing, expired, or issued for another name, the browser stops at a warning page and never sees the redirect. So a domain you are moving away from still needs a valid certificate for as long as you keep the redirect running, which should be at least a year.

Registrar forwarding services differ here. Some issue a certificate for the forwarded domain automatically, some take a while to do so, and some only forward plain http. If you test the https version of the old domain and get a warning, that is the reason. The fix is to point the old domain at a server or service that holds a valid certificate for it, as covered below. Our SSL hostname mismatch guide explains the certificate side in more depth.

How to test what the old domain returns

Do not trust the browser alone: it caches 301 responses aggressively, so you may be looking at an old result. Use curl from a terminal, which shows every hop and status code:

curl -sI http://old-example.com/menu/cakes
curl -sI https://old-example.com/menu/cakes
curl -sI https://www.old-example.com/menu/cakes?size=large

# follow the whole chain and print each status and location
curl -sIL https://old-example.com/menu/cakes | grep -iE '^(HTTP|location)'

For each variant you want to see a single HTTP/1.1 301 or HTTP/2 301 line, a location: header with the full new address including the path, and then a 200 from the new domain. If curl reports an SSL error such as SSL: no alternative certificate subject name matches, the certificate problem is confirmed.

To see which names the certificate actually covers, run:

openssl s_client -connect old-example.com:443 -servername old-example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName -dates

Both old-example.com and www.old-example.com should appear in the subject alternative names, and the notAfter date should be in the future. The redirect checker demo shows the same hop-by-hop view without a terminal.

Server rules that keep the path

The most reliable setup is to keep the old domain pointed at a web server you control, with a certificate for it, and a single rule that sends everything to the new domain.

Apache (.htaccess in the old domain's document root)

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

The query string is carried over automatically. Put this above any other rewrite rules, such as those from WordPress, so it runs first.

nginx

server {
    listen 80;
    listen 443 ssl;
    http2 on;
    server_name old-example.com www.old-example.com;

    ssl_certificate     /etc/letsencrypt/live/old-example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/old-example.com/privkey.pem;

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

$request_uri holds the original path and query string, so nothing is lost. On older nginx versions, write listen 443 ssl http2; instead of the separate http2 on; line. Get the certificate first, for example with sudo certbot certonly --nginx -d old-example.com -d www.old-example.com, then run sudo nginx -t and sudo systemctl reload nginx.

One hop, not three

Send every variant of the old domain straight to the final https address on the new domain. Avoid a chain such as http old, then https old, then https new, then https www new. The redirect chains guide shows how to collapse chains that build up this way.

Registrars, Cloudflare and Plesk

• Registrar forwarding (GoDaddy, Network Solutions and similar). These panels offer domain or web forwarding. Choose a permanent (301) forward, not temporary, and choose a plain forward rather than masked or framed forwarding. Check whether the option to forward the path is available and switched on; if it is not, every old URL will land on one address. Then test the https version of the old domain with curl. If it gives a certificate error, the forwarding service is not covering https for your domain, and you are better off using one of the options below.
• Cloudflare. Add the old domain to Cloudflare, create proxied DNS records for the root and www (any placeholder address works, because Cloudflare answers before reaching it), and Cloudflare issues an edge certificate. Then add a Redirect Rule or a Single Redirect matching the old hostname, with a dynamic target such as concat("https://example.com", http.request.uri.path), status 301 and preserve query string ticked. See redirects in Cloudflare.
• Plesk. Add the old domain as a domain alias of the new site, or as its own domain with hosting. Issue a Let's Encrypt certificate covering the root and www under SSL/TLS Certificates, then add the redirect in Apache and nginx Settings or in .htaccess. Our Plesk redirects guide walks through the panel.
• WordPress. A redirect plugin on the new site cannot redirect the old domain unless the old domain points at that same installation. Usually it is cleaner to do it at the server or at Cloudflare.

A worked example

Example Bakery is moving from old-example.com to example.com. The old domain is registered at one registrar with web forwarding set to the new home page. Testing gives this:

$ curl -sI http://old-example.com/menu/cakes
HTTP/1.1 302 Found
Location: https://example.com/

$ curl -sI https://old-example.com/menu/cakes
curl: (60) SSL: no alternative certificate subject name matches target host name 'old-example.com'

Three problems show up at once: a temporary status, a lost path, and no certificate on https. The bakery switches the old domain's nameservers to its own server, issues a certificate for both names, and adds the nginx block from above. The retest:

$ curl -sI https://old-example.com/menu/cakes
HTTP/2 301
location: https://example.com/menu/cakes

Then it uses the Change of Address tool in Search Console, under the old property's settings, to tell Google about the move, and updates its own internal links and sitemap so they point directly at example.com.

The fix, step by step

Edge cases worth knowing

• Restructured URLs. If the new site uses different paths, a single domain rule is not enough. Put a map of old path to new path above the catch-all rule, and only let unmatched paths fall through.
• HSTS on the old domain. If the old domain sent a Strict-Transport-Security header, browsers will insist on https for it. That makes a valid certificate even more essential.
• Email. Redirecting the website does not move email. Keep the MX and mail authentication records on the old domain if addresses there are still in use.
• Change of Address requirements. The tool needs both properties verified in the same Search Console account and works on the root domain level, so verify the old and new domains first.
• Browser cache. Browsers cache 301 responses, so if you set the wrong target, visitors who already saw it may keep going there until their cache clears. Test with curl before announcing the move.

Keeping the redirect healthy

Keep the redirect and the old domain's registration and certificate in place for at least a year, and longer if the old domain has many backlinks. Set renewal reminders for both. Re-run the curl tests after any server, DNS or hosting change, and check the Page with redirect report in Search Console for the old property, which should fill with old URLs as Google processes the move. If you see a redirect error there, the redirect error guide explains what each message means. For a site move that also changes structure, follow the migration redirects guide.