HTTPS Migration: Complete Guide

Moving a site from HTTP to HTTPS is a site move in Google’s terms: every URL changes protocol, so every URL gets a new address. Because the paths, content and structure stay the same, it has fewer moving parts than a move that also changes URLs, templates or domains. Done carelessly, it produces duplicate versions, mixed-content warnings, redirect chains and, in the worst case, a site left blocked by staging rules. Each of those failures is checkable before and right after launch, which is why the order of steps matters as much as installing a valid certificate.

What HTTPS does for Search

Google announced HTTPS as a ranking signal on August 7, 2014, calling it at the time “a very lightweight signal” affecting “fewer than 1% of global queries” (Google’s 2014 announcement). That announcement is old, and Google’s current page experience documentation frames the question differently: it lists “Are your pages served in a secure fashion?” among its self-assessment questions, and states that “Beyond Core Web Vitals, other page experience aspects don’t directly help your website rank higher in search results” (Google’s page experience documentation).

The practical reasons to move are therefore user-facing and technical: browsers mark HTTP pages as not secure, forms and logins need encryption, and modern browser features require a secure context. Treat any ranking effect as a minor consideration, not the goal.

Before the move

Certificates and server

• [ ] Obtain a certificate covering every hostname that serves content (example.com, www.example.com, subdomains such as shop. or cdn.).
• [ ] Configure automatic renewal and a monitoring alert before expiry.
• [ ] Confirm the server supports current TLS versions.

Inventory

• [ ] Export the full list of HTTP URLs (crawl, sitemap, analytics landing pages, Search Console top pages).
• [ ] Record current indexed counts, top queries and top pages as a baseline.
• [ ] Note every external resource the pages load (scripts, fonts, images, iframes, APIs).

Content and code

• [ ] Change internal links, canonical tags, hreflang annotations and structured data URLs to https://.
• [ ] Find hard-coded http:// resource references in templates, CSS and the database.
• [ ] Prepare an HTTPS version of the XML sitemap.
• [ ] List the places outside the site that still use http:// addresses you control (ad final URLs, email templates, social profiles, business listings) and schedule their update for launch day.

Staging

• [ ] Test the full site on HTTPS in staging, including checkout, forms and logins.
• [ ] Make sure staging noindex tags and robots.txt blocks are not part of the release.

During the move

1. Enable HTTPS on the live server for every hostname.
2. Redirect every HTTP URL to its exact HTTPS equivalent with a permanent server-side redirect (301 or 308). Map path to path, not everything to the home page.
3. Combine protocol and host rules into one hop. http://example.com/page should reach https://www.example.com/page in a single redirect, not via https://example.com/page.
4. Update canonical tags to the HTTPS URLs (already prepared in templates).
5. Publish the HTTPS sitemap and reference it in the HTTPS host’s robots.txt.
6. Keep robots.txt on the HTTP host reachable until redirects are confirmed; do not disallow the HTTP site, or Google cannot follow its redirects.

Search Console steps

• Add and verify the HTTPS property if you use URL-prefix properties. A Domain property already covers both protocols.
• Submit the HTTPS sitemap.
• Do not use the Change of Address tool. Google’s site move guide states it is not needed for HTTP to HTTPS moves (moving a site with URL changes).

After the move: verification

Mixed content

A page served over HTTPS that loads scripts, stylesheets or iframes over HTTP is mixed content. Browsers block insecure active content and may warn about or upgrade passive content such as images. The fix is to load every resource over HTTPS, which may mean updating URLs in the database, switching third-party embeds to their HTTPS versions, or replacing providers that do not offer HTTPS. A Content-Security-Policy: upgrade-insecure-requests header can help during the transition, but it does not replace fixing the references.

What to expect in Search

Google’s site move guide says to expect temporary ranking fluctuation “while Google recrawls and reindexes your site”, and that for medium-sized sites it can take “a few weeks or more” for Google to start showing new URLs instead of old ones, longer for larger sites. It also notes Google will temporarily crawl the new site more heavily than usual. Filter the Performance report by page URL (http:// against https://): impressions should shift from HTTP to HTTPS URLs over weeks, not hours.

HTTPS migration mistakes

Google’s site move guide lists mistakes that apply to HTTPS moves, including leaving noindex or robots.txt blocks from staging in place. Others to check:

• redirects that send every HTTP URL to the HTTPS home page;
• redirect chains combining protocol and host changes in two hops;
• canonical tags still pointing to http://;
• an expired or incomplete certificate on one subdomain;
• hreflang annotations mixing HTTP and HTTPS URLs;
• removing redirects too early. Google’s guidance is to keep redirects “generally at least 1 year”, and from a user’s perspective, indefinitely.

HSTS, as a later step

HTTP Strict Transport Security tells browsers to use HTTPS for a host without first requesting HTTP. It is a security feature, not an SEO requirement. Add it after HTTPS is stable everywhere, start with a short max-age, and include subdomains only when every subdomain supports HTTPS, because browsers will refuse HTTP for the policy’s duration.

Migrating a 3,000-page publisher and its image host

Take a hypothetical 3,000-page publisher on http://www.example.com with images on http://img.example.com.

• Before: certificates for www and img; templates updated to absolute https:// URLs; database search and replace for image URLs in old articles, tested in staging.
• Launch: server rule redirects http://www.example.com/* to https://www.example.com/* in one hop; img served on HTTPS, with http://img.example.com/* redirected the same way so old image URLs in external links and caches still resolve; HTTPS sitemap submitted.
• Day 1 checks: a sample of 200 URLs each redirect in one hop; the console shows mixed content on 40 old articles that embedded an HTTP video player; those embeds are updated.
• Weeks 1 to 6: check that impressions in the Performance report move to HTTPS URLs and that URL Inspection on sample pages shows HTTPS canonicals.
• What to expect: temporary fluctuation is possible; the migration does not guarantee identical traffic during reprocessing.

The risk in an HTTPS migration sits in redirects, leftover blocks and forgotten resources as much as in the certificate. Inventory first, map every URL one to one, and verify each layer after launch.