HTTP to HTTPS Migration: Move Your Site to HTTPS in the Right Order

HTTPS is HTTP carried over an encrypted connection. It protects what passes between your visitors and your server from being read or changed on the way. The web.dev article "Why HTTPS matters" recommends protecting all websites with HTTPS, even those that do not handle sensitive information, because attackers and intrusive networks can tamper with unprotected traffic, including images, scripts and HTML, and because unprotected browsing reveals what people read.

An HTTP to HTTPS migration changes every address on your site from http:// to https://. For search engines these are different URLs, so the move needs care: a certificate, working pages, redirects, matching canonical tags and a few updates in Search Console. Do the steps in the wrong order and visitors see certificate warnings or loops. This guide is for site owners and developers who still serve pages over HTTP or serve a mix. By the end you will have a site that answers on HTTPS only, redirects the old addresses to it and protects returning visitors with HSTS.

A correct migration makes the secure version the one that gets used. It does not promise a change in rankings or traffic.

Before you begin

You will need:

Control of the site's server, hosting panel or CDN, where certificates and redirects are configured.
Access to DNS, to confirm the host names you will secure.
A list of every host name in use: the bare domain, www, and any other subdomains that serve pages.
A Search Console property for the site. Google advises verifying both the HTTP and HTTPS variants (a Domain property covers all protocols).
A staging copy if you can, plus a backup of the site, its database and its server configuration.
Time: a few hours for a small site, plus a monitoring period.

Risk is moderate. A bad redirect rule can lock visitors out, and HSTS, if set wrongly, is remembered by browsers. The order below keeps those risks small. Google's site move guidance says HTTP to HTTPS is a site move that changes URLs, and that you should not use the Change of Address tool for it, since the domain is unchanged.

Step-by-step instructions

Step 1: Get and install a certificate

A TLS certificate proves your site's identity and enables encryption. Your host or CDN may issue one for you. If you create your own, web.dev advises a 2,048-bit RSA key, since a shorter key can be broken by brute-force guessing, and it says one certificate can cover several names, such as the bare domain and www. A wildcard such as *.example.com matches one label only, so it covers blog.example.com but not a.blog.example.com.

Make sure the certificate covers every host name that will serve pages, including both the bare domain and www. Store the private key somewhere that is not served by the website. Then test the setup in a browser and with a TLS testing tool, and treat anything weak as a bug to fix. Set up automatic renewal, because an expired certificate makes the site show a browser warning. See SSL Certificate Errors.

What success looks like: opening https://example.com/ and https://www.example.com/ shows a padlock with no certificate warning, even if the pages still look wrong.

Step 2: Make sure the site works on HTTPS before redirecting

web.dev's order is to enable HTTPS first and redirect later. Open the HTTPS version of several pages and check that they load and function: forms, login, search, checkout, scripts and images.

The usual fault is mixed content: a page loaded over HTTPS that still requests a resource over HTTP. MDN explains that browsers upgrade some of these requests automatically, such as images, audio and video, and block others, such as scripts, stylesheets, iframes and fetch() calls. Blocked resources can break the page.

Fix it in the source:

Use HTTPS addresses, or host-relative addresses such as /css/site.css, for your own resources, in templates, stylesheets, scripts, menus and the content stored in your database.
Switch third-party resources to their HTTPS versions where available.
Use the browser console to find warnings, or crawl the site with a tool that reports mixed content.

If you cannot edit every reference at once, MDN notes the upgrade-insecure-requests Content Security Policy directive can upgrade requests to HTTPS while you work through the cleanup:

Content-Security-Policy: upgrade-insecure-requests

Treat that as a stopgap and not a substitute for fixing the links. See Fix Mixed Content for a longer walk-through.

What success looks like: key pages on HTTPS load with no mixed content warnings in the browser console.

Step 3: Update canonical tags, internal links and the sitemap

Tell search engines that the HTTPS version is the main one. Google's canonicalization guidance says it generally prefers HTTPS pages as canonical unless there are problems such as an invalid certificate, insecure non-image dependencies or a canonical tag that points to HTTP. To support that:

Add or update a rel="canonical" link on each page, using an absolute https:// URL.
Update internal links, hreflang annotations and structured data to HTTPS. Do not list HTTP URLs in a sitemap or in hreflang.
Update the XML sitemap so it holds only HTTPS URLs. See How to Create a Valid XML Sitemap.
Update the sitemap line in robots.txt, and check robots.txt is reachable on HTTPS.

<link rel="canonical" href="https://example.com/page/">

Do not point any canonical from HTTPS back to HTTP, and avoid HTTPS-to-HTTP redirects, which push Google strongly towards HTTP.

What success looks like: the source of an HTTPS page shows an HTTPS canonical, and the sitemap has no HTTP addresses.

Step 4: Redirect HTTP to HTTPS

Now send HTTP requests to HTTPS with a permanent redirect. Google's site move guidance says to redirect HTTP URLs to HTTPS with permanent redirects. Use 301 or 308, keep the path and query string, and go to the final address in one hop. If you also need to pick between www and the bare domain, combine both decisions in one redirect, as covered in WWW vs Non-WWW.

Nginx:

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

Apache:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]

Adapt the host name to your canonical host. If a CDN or load balancer terminates TLS in front of your server, the server may see plain HTTP for every request, and a rule like the Apache example above could loop. In that case, redirect at the CDN, or read the forwarded protocol header that your provider documents. Check where the redirect belongs before you add it. For background, see 301 vs 302 Redirects and Redirect Chains and Loops.

What success looks like: curl -I http://example.com/page/ returns a 301 with an HTTPS Location, and the HTTPS page returns 200.

Step 5: Update Search Console

Make sure the HTTPS property is verified. If you use a Domain property it already includes all protocols and subdomains, and it needs DNS verification. If you use URL-prefix properties, add and verify the HTTPS version separately from the HTTP one, since a URL-prefix property includes only URLs with the exact protocol. Submit the HTTPS sitemap. Do not use the Change of Address tool, because the domain has not changed.

Watch the reports over the following weeks. Google's site move advice is to check the sitemaps report, the page indexing report, the performance report and server logs for old URLs falling away, new URLs appearing and unexpected errors. It also notes that medium-sized sites can take a few weeks or more to show new URLs. See Set Up Google Search Console.

What success looks like: the HTTPS sitemap is accepted and the HTTPS property starts to show data.

Step 6: Update everything outside the site

Change the links you control to HTTPS: social profiles, business listings, ad destinations, email templates, payment and analytics settings, and any API callbacks. Mark cookies with the Secure flag, as web.dev advises. Referrer information is not sent from HTTPS pages to HTTP pages, so analytics from links you place on other sites may change. External links that still use HTTP will pass through the redirect, which is why it stays.

What success looks like: the integrations you rely on work with the HTTPS addresses.

Step 7: Add HSTS when everything is stable

HSTS (HTTP Strict Transport Security) is a response header that tells browsers to use HTTPS for your site for a set time, so they skip the HTTP request and its redirect. RFC 6797 defines it. The header is Strict-Transport-Security, with a required max-age in seconds and an optional includeSubDomains. Browsers only honour it when it arrives over a secure connection, and they ignore it on plain HTTP.

Strict-Transport-Security: max-age=300

Start with a short max-age, as web.dev advises, and raise it over time once nothing breaks. Browsers may refuse to connect at all if a certificate problem appears while HSTS is active, so only enable it when certificate renewal is reliable. Add includeSubDomains only when every subdomain works on HTTPS. Setting max-age=0 tells browsers to forget the policy. Read HSTS Setup Guide and Add HTTP Security Headers before choosing long values.

What success looks like: the HTTPS response carries the Strict-Transport-Security header, with a value you chose deliberately.

Step 8: Re-crawl and keep the redirects

Crawl the site on HTTPS. Look for HTTP links, redirect chains, mixed content, canonical tags that point to HTTP and pages that now return errors. Keep the HTTP-to-HTTPS redirects in place long term. Google's site move advice is to keep redirects at least a year and to consider keeping them indefinitely.

What success looks like: the crawl reports no HTTP internal links, no mixed content and no chains.

Final verification checklist

The certificate covers every host name, is valid and renews automatically.
HTTPS pages load without mixed content warnings.
Canonical tags, internal links, hreflang and structured data use HTTPS.
The sitemap and the robots.txt sitemap line list only HTTPS URLs.
Every HTTP URL redirects to its HTTPS equivalent with a single 301 or 308.
The Search Console HTTPS property is verified and the HTTPS sitemap is submitted.
Change of Address was not used.
Cookies that should be secure carry the Secure flag.
If HSTS is on, its max-age is a value you chose on purpose.
A re-crawl finds no HTTP links, loops or chains.

Common mistakes to avoid

Redirecting before HTTPS works. Visitors hit errors. Enable and test HTTPS first.
A certificate that misses a host. Visitors to the uncovered name see a warning before any redirect. Cover the bare domain and www.
Mixed content left behind. Browsers block scripts and stylesheets loaded over HTTP, which can break the page. Fix the references.
Canonical tags still pointing to HTTP. This pushes Google towards HTTP. Update them.
Redirect loops behind a CDN or proxy. If TLS ends before your server, an HTTPS check on the server can loop. Redirect at the right layer.
HTTP URLs in the sitemap. Replace them with HTTPS.
A long HSTS value on day one. A mistake is remembered by browsers. Start with a short max-age.
Using Change of Address. The domain did not change, so Google says not to.

Frequently asked questions

Will HTTPS improve my rankings?

web.dev's migration article calls HTTPS a positive search ranking signal, but no source promises a measurable gain from it. Treat the move first as a security and trust measure, and do not expect a visible change in rankings.

Do I need to redirect every page?

Yes. Each HTTP URL should redirect to its HTTPS equivalent, keeping the path and query. A catch-all redirect to the home page loses the page-to-page mapping.

Is a free certificate acceptable?

What matters is that the certificate is valid, covers all your host names, is issued by an authority browsers trust and renews automatically. Check your host's documentation for the options it supports.

Should I add the HTTP site as a separate property?

If you use URL-prefix properties, verify both so you can watch the old URLs fall away. A Domain property already includes both protocols.

Can I remove the redirect after a few months?

Google recommends keeping redirects for at least a year and considering keeping them indefinitely. Old links and bookmarks will keep arriving over HTTP.

Official references

Next step: See how Crawvix checks a website and capture a baseline once scanning opens. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.