HTTPS Migration SEO: Checklist Without Ranking Loss

Most sites switched to HTTPS years ago, so this looks like a solved problem. It isn’t quite. I still run into sites where the https version works but http keeps answering with 200, shops whose canonical tags point at http because a theme hardcoded them in 2016, and migrations where the https redirect goes via www and back. Each of those quietly splits signals. And new projects make the same choices again, because the defaults on cheap hosting still aren’t always right.

What HTTPS does for SEO

Google announced HTTPS as a ranking signal in August 2014, in a post on the Search Central blog. It described the signal as very lightweight, carrying less weight than signals such as high-quality content, and affecting fewer than 1 % of global queries. That’s the full extent of the direct ranking effect Google has confirmed.

The indirect effects are larger. Browsers mark http pages as “Not secure”, and form fields on http pages get explicit warnings. When an https site links to an http page, many browsers strip the referrer, so the http site loses data on where visitors came from. And when Google finds the same content on both protocols, it generally prefers the https URL as canonical, which means an incomplete migration leaves you with two versions competing for the same slot.

HTTPS migration checklist

The table is the order I’d go through. Each line is a known failure point.

Redirect http to https

On nginx, a dedicated server block for port 80 is cleaner than conditionals:

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

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    add_header Strict-Transport-Security "max-age=300" always;
    root /var/www/example;
}

This sends both http hostnames straight to the final https bare domain. If you serve https://www.example.com too, it needs its own 443 block with a redirect; the full pattern is in www vs non-www.

On Apache with .htaccess:

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

One rule, one hop, regardless of which of the three wrong variants a visitor hits. Behind a TLS-terminating proxy, replace the %{HTTPS} condition with %{HTTP:X-Forwarded-Proto} =http, or the server never sees https and redirects forever.

On Cloudflare, “Always Use HTTPS” in the SSL/TLS settings does the protocol part. Set the SSL mode to Full (strict) with a valid certificate on the origin. “Flexible” mode talks plain http to your server, and an origin-side https redirect then loops.

Checking the certificate

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

subject=CN=example.com
X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com
notAfter=Jan 14 09:12:03 2027 GMT

Both names present, expiry in the future. The -ext option needs OpenSSL 1.1.1 or newer; on older systems use -text and look for the Subject Alternative Name block. Google’s 2014 post recommends 2048-bit keys; current Let’s Encrypt clients default to that or to ECDSA.

HSTS without locking yourself out

The Strict-Transport-Security header tells browsers to use https for your domain without even trying http. It removes the first insecure request and the redirect hop for returning visitors. It’s not a ranking factor.

Start small. A max-age of 300 seconds lets you back out if something on a subdomain still needs http. After a few weeks without trouble, raise it to max-age=31536000. Only add includeSubDomains when every subdomain, including the forgotten mail. or intranet., works over https. Preloading into browsers is the last step and hard to undo, so treat it as permanent.

Monitoring the first weeks

If you use a Domain property in Search Console, both protocols already sit in one place, and the Performance report will show the https URLs taking over impressions gradually. With URL-prefix properties, add https://example.com/ and compare it against the old http:// property side by side; the http one should fade towards zero.

Watch the Page indexing report for two categories in particular. “Page with redirect” growing on the http side is expected. “Duplicate, Google chose different canonical than user” on the https side is a warning sign: it usually means some template still declares an http canonical, or the http version still answers with 200 somewhere.

Server logs tell you the rest. Googlebot should request http URLs, get a 301 and then fetch the https version. If you see Googlebot receiving 200s on http after the first week, a rule is missing for some path or hostname.

What you don’t need to do

You don’t need the Change of Address tool. Google says the tool is not intended for http to https changes and that it handles them automatically. The tool is for actual domain changes, covered in the Change of Address guide.

You don’t need to disavow or re-request links. Existing links to http URLs pass through the 301 like any other permanent redirect.

You also shouldn’t combine the HTTPS switch with a domain change and a redesign in one weekend unless you have to. Each change is manageable alone; together they make it impossible to tell which one caused a drop. If a domain change is coming anyway, the domain change guide covers that sequence.

Endings with HTTPS built in

Some newer endings, including .app and .dev, are on the browsers’ HSTS preload list as whole TLDs. A site there only works over https from day one, so this migration never happens. A .dev domain costs €22.99 a year, an .app €22.99. More on whether new endings affect rankings in the new gTLD article.

If you’re starting fresh, look up your preferred name across endings and compare renewal costs in the betadomain price overview before you commit.

Step by step

1. Get a certificate that covers every hostnameIssue a certificate, for example with Let's Encrypt, that includes the bare domain, www and any subdomains you serve, using at least a 2048-bit RSA or an ECDSA key.
2. Make the https version work in fullServe the whole site over https and crawl it with a tool or curl before redirecting anything, checking for errors and mixed content.
3. Update internal URLsChange internal links, canonical tags, hreflang, structured data and the XML sitemap to https URLs.
4. Redirect http to https with a 301Send every http URL to its exact https counterpart in one hop, combined with your www decision so no chain appears.
5. Check robots.txt and Search ConsoleMake sure the https robots.txt doesn't block crawling, add the https property if you use URL-prefix properties, and submit the new sitemap.
6. Add HSTS once everything is stableStart with a short max-age, raise it to a year after a few weeks, and only then consider includeSubDomains and preload.
7. Update external referencesChange the URL in profiles, ad campaigns, email signatures and the links you control on other sites.