# HTTPS migration SEO: move from http to https without losing rankings

> Moving from http to https changes every URL on your site. The SEO steps in the right order: certificate, one-hop redirects, canonicals, sitemaps, mixed content, Search Console and HSTS last.

Updated 2026-09-26 · Technical SEO · HTML version: https://getreport.app/guides/https-migration-seo

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](https://getreport.app/guides/website-migration-seo).

## 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 on `https://`** 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-age` first, once https has worked for a while.
- **Verify** with the [redirect checker](https://getreport.app/tools/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](https://getreport.app/guides/http-vs-https-and-not-secure-warning) 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](https://getreport.app/guides/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](https://getreport.app/guides/free-ssl-certificate-lets-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](https://getreport.app/guides/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](https://getreport.app/guides/measuring-before-and-after-a-redesign) 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`, `logo` and `og:url`.
- **CMS settings,** such as WordPress Address and Site Address in Settings → General, followed by a database search-replace of `http://www.example.com` with 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
# 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
# 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

> **Free tool:** [Redirect checker: 301, 302 and redirect chains](https://getreport.app/tools/redirect-checker): Free redirect checker: follow every hop from your URL to the final page, with status codes, HTTP to HTTPS and www redirects, and the canonical at the end.

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](https://getreport.app/tools/bulk-url-checker), or pairs of old http and new https URLs into the validator:

> **Free tool:** [301 redirect map validator for site migrations](https://getreport.app/tools/migration-validator): Check your 301 redirect map after a migration. Paste up to 1,000 old and new URL pairs and see which land right, chain, go temporary or are lost. Free.

The full getReport report checks the https side of the site on every run:

> **Check: http:// redirects to https://.** Visitors who type your address without https, or follow an old link, land on the unencrypted page. Every one of those visits can be read or altered on the network.
>
> 1. Redirect every http:// URL to the same path on https:// with a 301.
> 2. nginx: return 301 https://$host$request_uri; Apache: RewriteRule in .htaccess; most hosts and Cloudflare have a "Always use HTTPS" switch.

> **Check: No resources load over http://.** Browsers block http:// scripts and stylesheets on an HTTPS page, which breaks layout or features, and upgrade http:// images and media to https, showing them broken when that fails. It usually appears after a move to HTTPS while old absolute URLs stay in the content.
>
> 1. Search and replace http:// with https:// in content, theme and configuration (WordPress: a search-replace plugin covers the database).
> 2. Add Content-Security-Policy: upgrade-insecure-requests as a safety net.

> **Check: www and non-www redirect.** When www and non-www both answer, visitors and tools see two sites with separate cookies, caches and analytics sessions. One should redirect to the other.
>
> 1. Pick one host and 301-redirect the other to it, keeping the path; most hosts and CDNs have a one-click setting for this.
> 2. Use the chosen host everywhere (links, sitemap, analytics property, social profiles).

> **Check: Canonical tag is present.** Without a canonical URL, search engines may index duplicate versions of this page (with and without trailing slash, with UTM parameters) and split its ranking signals.
>
> 1. Add <link rel="canonical" href="https://your-site.com/page/"> in <head>.
> 2. In WordPress, Yoast or Rank Math add this automatically — check it is not disabled for this page.

## 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](https://getreport.app/guides/hsts-safely-and-the-preload-list) walks through the stages.

> **Check: Strict-Transport-Security header is set.** HSTS tells browsers to always use HTTPS for your site, so after the first visit a typed address or an old http:// link never starts on an unencrypted connection. Only the preload list covers the very first visit.
>
> 1. Send the header: Strict-Transport-Security: max-age=31536000; includeSubDomains.
> 2. Start with a shorter max-age (e.g. 86400) if you are not sure every subdomain supports HTTPS.

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](https://getreport.app/guides/site-migration-checklist-domain-https-cms) 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-age` and `includeSubDomains` on 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.