An https migration is a site move in Google's eyes: every http:// URL is replaced by an https:// one, so rankings carry over only if each old address redirects in one 301 hop to the same path on https, and everything on the site names the https URLs. It is the lowest-risk migration there is, because the paths do not change and one site-wide rule does the redirecting, but the order of the steps matters. This guide is for site owners and developers moving an existing site from http to https: what to prepare, the launch steps, the Search Console setup, and why HSTS comes last. For migrations in general, see the website migration guide.
Quick answer
- Get a certificate and test the https site first, before any redirect: every page should load over https without mixed content.
- Update the site to name https: canonicals, hreflang, sitemap, internal links, structured data and Open Graph URLs.
- Redirect every
http://URL to the same path onhttps://with one 301, combined with your www rule so there is never a chain. - Search Console: a Domain property already covers http and https; with URL-prefix properties, add the https one. Do not use Change of Address.
- Turn on HSTS last, with a short
max-agefirst, once https has worked for a while. - Verify with the redirect checker and the full report: one hop, no mixed content, canonical on https.
Why move to https, and does it affect SEO?
Google announced https as a ranking signal in 2014 and describes it as lightweight, so the move will not lift a weak page above a strong one. The bigger reasons are what browsers do:
- Chrome marks every http page "Not secure" in the address bar, and has done since Chrome 68 in 2018.
- Chrome 154, due in October 2026, turns on "Always Use Secure Connections" by default. According to Google's announcement, Chrome then tries https first and warns before loading public sites that only work over http.
- Referral data. Browsers do not send the referring address when a visitor goes from an https page to an http one, so an http site loses referral information from https sites that link to it.
- Features. Many modern browser features, such as service workers and HTTP/2 in browsers, need https.
The SEO risk is not https itself but the move: missing redirects, redirect chains, canonicals that still name http, and pages that break over https because of mixed content. HTTPS vs HTTP explains the difference and the "Not secure" label; this guide is about moving an existing site.
Before the move
1. Pick the final address form
Decide the one form every URL will have: https, with or without www, with or without a trailing slash. The http to https redirect will go straight to that form, so a visitor typing http://example.com/page lands on https://www.example.com/page/ in one hop. Trailing slashes, www and https: pick one covers the choice and the combined rule.
2. Install a certificate
Get a certificate that covers every hostname you serve, such as example.com and www.example.com. Most hosts and CDNs issue free certificates automatically; on your own server, Let's Encrypt does it with automatic renewal. If a CDN such as Cloudflare sits in front, use its Full (strict) mode with a valid certificate on your server, not Flexible, which is a classic cause of redirect loops.
3. Test the https version before redirecting
With the certificate installed and no redirect yet, both versions answer. Open key pages over https and fix whatever breaks:
- Mixed content: images, scripts, stylesheets, fonts, iframes or form actions still loaded over
http://. Browsers block mixed scripts and styles, which can break layouts and features, and flag the page as not fully secure. Mixed content after https shows how to find every leftover and fix it in the database, theme and settings. - Hard-coded http links in content, menus and templates.
- Third-party embeds that do not support https.
4. Record a baseline
Note traffic, rankings and indexed pages for your key pages, so you can compare afterwards. The before-and-after measurement guide shows what to record.
Launch: the steps in order
5. Update everything on the site to https
Before or at the same moment as the redirect, change every place the site names its own URLs:
- Canonical tags:
<link rel="canonical" href="https://www.example.com/page/">. - hreflang annotations, for multilingual sites.
- XML sitemap: https URLs only.
- robots.txt: the
Sitemap:line with the https URL. - Internal links in content, navigation and templates.
- Structured data and Open Graph tags, such as the Organization
url,logoandog:url. - CMS settings, such as WordPress Address and Site Address in Settings → General, followed by a database search-replace of
http://www.example.comwith the https form.
6. Turn on the site-wide 301
Add one rule that sends every http request to the same path on https, keeping the query string, and fold the www rule into it:
# nginx: every http request → https://www.example.com, one hop
server {
listen 80;
server_name example.com www.example.com;
return 301 https://www.example.com$request_uri;
}# Apache .htaccess: http or non-www → https://www.example.com, one hop
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]Behind a CDN or load balancer, the server may see every request as http; use the CDN's own "always use https" setting or check the X-Forwarded-Proto header instead, or you get a loop. In the nginx example, https://example.com still needs a server block on port 443, with the certificate, that returns the same 301 to www. Many hosts have a "force https" switch that does the same; check it does not add a second hop.
Use a 301 or 308, never a 302. And point every older redirect, from previous changes, straight at the final https URL so no chain forms.
7. Set up Search Console
Google treats http to https as a site move with URL changes, but you do not use the Change of Address tool for it; Google's help page says the tool is not for protocol changes.
- Domain property (verified by DNS): it already covers http and https and every subdomain. Nothing to add.
- URL-prefix properties: add and verify
https://www.example.com/. Keep the http property to watch its pages move to "Page with redirect".
Submit the https sitemap. Use URL Inspection on a few key pages to check that Google can fetch the https version and sees the https URL as canonical.
8. Verify every old URL
Enter an http:// URL. The checker follows every hop, lists each status code, and also tests the http and the other www variant, so you see whether all of them reach the final https address permanently in one hop. You want one 301 or 308, then a 200 on a page whose canonical is its own https address.
For a list of URLs, paste your old http sitemap into the bulk URL checker, or pairs of old http and new https URLs into the validator:
The full getReport report checks the https side of the site on every run:
After the move: HSTS, last
Once the https site has run without problems for a while, add the Strict-Transport-Security header. It tells browsers to use https for your domain for a set time, even when someone types http:// or follows an old link, which removes the redirect hop for returning visitors and closes a window for downgrade attacks.
Start with a short max-age, such as one day, check nothing breaks on any subdomain, then raise it to a year. Add includeSubDomains only when every subdomain works over https, and apply for the browser preload list only when you are sure, because leaving it takes months. HSTS safely, and the preload list walks through the stages.
HSTS comes last because it is hard to undo: a browser that saw the header refuses http for your domain until max-age runs out, so a certificate problem during the migration would lock visitors out.
What to expect in search
Because paths stay the same and one rule does the redirecting, an https migration usually settles faster and more quietly than a domain change. Rankings can move a little for a few weeks while Google recrawls http URLs and discovers their redirects; popular pages switch first. Keep the http to https redirect permanently. It costs nothing, and old links and bookmarks will keep arriving over http for years.
If traffic drops and keeps dropping, look for the usual causes: a redirect that goes to the home page, a chain through several hops, canonicals or the sitemap still on http, mixed content breaking pages, or a CDN loop. The site migration checklist has the full launch-day list.
Common mistakes
- Redirecting before the https site works, so visitors land on broken or half-loaded pages.
- Two hops: http → https, then non-www → www. Combine them into one rule.
- Canonicals and the sitemap still on http, telling Google the opposite of the redirects.
- A 302 from a "force https" plugin or host switch. Check the status code.
- Cloudflare Flexible mode with a server that forces https: a redirect loop.
- Using Change of Address for a protocol change. It is not meant for it.
- HSTS with a one-year
max-ageandincludeSubDomainson day one, before every subdomain has a certificate.
Questions people ask
Does moving to https affect SEO?
Yes, slightly for the better in the long run and neutrally during the move if it is done right. https is a lightweight ranking signal, and Google prefers the https version of a page as canonical. The move itself changes every URL, so rankings can fluctuate for a few weeks; one-hop 301s and updated canonicals keep that short.
Do I need to use the Change of Address tool for http to https?
No. Google's help page says the Change of Address tool is not for protocol changes. Redirect every http URL to its https equivalent with a 301, update canonicals and sitemaps, and add the https property in Search Console if you use URL-prefix properties. A Domain property already covers both protocols.
Should the http to https redirect be a 301 or a 302?
A 301, or a 308. The move to https is permanent, and a permanent redirect tells Google to replace the http URL with the https one in its index. A 302 says the move may be undone, so Google may keep the http URLs longer. Some hosting "force https" switches and plugins use 302; check the status code with a redirect checker.
When should I enable HSTS after moving to https?
After the https site has run cleanly for a while, typically a few weeks, and every page and subdomain you cover works over https. Start with a short max-age, such as a day, then raise it step by step to a year. Add includeSubDomains and the preload list only when you are sure, because both are slow to undo.