HTTP to HTTPS redirects: the right way to move

October 10, 2026·4 min read

An HTTP to HTTPS redirect sends every http:// URL on your site to the same path on https:// with one permanent 301 or 308. That alone is not the migration. You also need canonicals, internal links, the sitemap and hreflang pointing at HTTPS, an HSTS header so browsers stop asking for HTTP, and no insecure resources left on your pages. Get those right and Google treats the move as routine.

Is HTTPS a Google ranking signal?

Yes, but a small one. When Google announced it in 2014, it called HTTPS a very lightweight signal that affected fewer than 1% of global queries and carried less weight than content quality. Google's page experience guide still asks whether your pages are served securely.

So don't expect a jump after you switch. The real HTTPS SEO risk is a careless move that leaves two copies of the site, chains on every old link and pages that break.

The HTTPS migration checklist

Google files HTTP to HTTPS under site moves with URL changes, and the steps come straight from that guide.

Install a valid certificate on every host you serve. That includes www if it redirects, because the browser checks the certificate before it reads your 301.
Redirect every URL in one hop. http://example.com/pricing?plan=pro should land on https://example.com/pricing?plan=pro, path and query intact. Fix the protocol and the host in the same rule, as the www vs non-www guide shows, or every old link pays for a redirect chain.
Use a permanent status. Google asks for 301 or 308. A 302 tells it the move is temporary.
Point canonical tags at HTTPS. Each page's rel="canonical" should name its own https:// URL. A canonical still on http:// contradicts your redirect.
Update internal links. Menus, footers, body links and image src values with hardcoded http:// either cost a redirect or cause mixed content.
Rebuild the sitemap with HTTPS URLs and submit it in Search Console. Google says warnings about redirects in the old sitemap are normal.
Update hreflang annotations so every alternate uses the new URLs.
Set up Search Console. A Domain property covers both protocols. With URL-prefix properties, verify the HTTPS one alongside HTTP. You don't need the Change of Address tool, which Google says is not for HTTP to HTTPS moves.
Keep the redirects. Google says at least one year. I'd keep them forever, because old backlinks never expire.

For the server rules themselves, the .htaccess redirect examples cover Apache, and the www post has an nginx version.

HSTS and the preload list

HSTS is a response header that tells browsers to use HTTPS for your host without asking HTTP first. After one visit, a typed example.com goes straight to https://, skipping the redirect.

Strict-Transport-Security: max-age=31536000; includeSubDomains

Send it on HTTPS responses only. MDN notes that browsers ignore it over HTTP. Start with a short max-age such as a day, check that nothing breaks, then raise it to a year. Add includeSubDomains only when every subdomain works on HTTPS, internal tools included, because the browser will refuse plain HTTP on all of them.

Preloading puts your domain in a list built into browsers, so even the first visit uses HTTPS. hstspreload.org requires a valid certificate, an HTTP to HTTPS redirect on the same host, HTTPS on every subdomain, and a header on the base domain with max-age of at least 31536000, includeSubDomains and preload. It warns that inclusion cannot easily be undone and removal can take months to reach users. Skip preload until HSTS has run for a while without complaints.

Fix mixed content before you flip the switch

Mixed content is an HTTPS page that loads resources over HTTP. Per MDN's mixed content guide, browsers upgrade images, audio and video to HTTPS on their own, and block the rest. Scripts, stylesheets, iframes, fonts, fetch() calls and images loaded through srcset or <picture> all fail.

A page can look fine while its checkout iframe never loads. Search your templates and database for http:// and replace them.

As a safety net while you clean up, this header makes the browser try HTTPS for blockable requests too:

Content-Security-Policy: upgrade-insecure-requests

It only helps when the resource exists on HTTPS. A third-party host with no certificate still breaks.

How to verify the move

Test the redirect from outside your browser, which caches 301s and HSTS:

curl -sIL http://example.com/pricing | grep -iE "^(HTTP|location|strict-transport)"

You want one 301 or 308 with a Location on https://, then a 200 carrying Strict-Transport-Security. Run it on the home page, a deep page with a query string, and the www and bare versions of both. If the redirect loops, your CDN and origin disagree about the protocol. The ERR_TOO_MANY_REDIRECTS post walks through that fix.

Then check a few templates in the browser console for mixed content warnings, and watch Search Console's page indexing report. The HTTP URLs should drop out as "Page with redirect" while the HTTPS ones take their place.

Check your HTTP to HTTPS redirect

The Redirect Chain & HTTP Header Checker requests the http and https versions of both your bare domain and www. It flags any that end on HTTP, versions that land on different origins, and apex and www both serving pages. It also follows the URL you enter hop by hop, up to 10 redirects, and flags chains of two or more, HTTPS sent back to HTTP, a final URL still on HTTP, and a final HTTPS page with no Strict-Transport-Security header.

A run costs 10 credits. It reads HTTP redirects and response headers only. It does not scan pages for mixed content, read your canonical tags or sitemap, or follow JavaScript and meta refresh redirects past the first document.