http to https migration seo
The lowest-risk migration type on this list, and still routinely botched — almost always by leaving more than one host variant reachable and letting Google pick a canonical for you.
Primary riskFour reachable host variants competing as duplicates, with the canonical decided by inference rather than by you.
An HTTPS migration is the simplest migration type by a wide margin. Paths do not change. Content does not change. Templates do not change. The mapping is http://x/path to https://x/path, which requires no judgment at all.
It still goes wrong often enough to be worth its own page, and almost always for the same reason: after the change, more than one version of the site is reachable, and nobody decided which one is canonical.
Every site has four possible host and protocol combinations. After an HTTPS migration, all four frequently remain reachable. Google then has to work out which is canonical, and it will make a decision whether or not you intended one.
The consequence is not dramatic. It is a slow dilution: links split across variants, crawl budget spent recrawling duplicates, and Search Console reporting split across properties so nobody can see the whole picture. It rarely produces a visible drop, which is precisely why it persists for years.
Pick one canonical host. Write it down. Make every other variant reach it in a single 301, and make every canonical tag, sitemap entry and internal link agree.
The most common configuration error is two rules that each do their job correctly and produce a two-hop chain together.
One rule upgrades HTTP to HTTPS. Another rule normalizes www to non-www. Run in sequence, http://www.example.com becomes https://www.example.com becomes https://example.com. Both rules are right. The result is a hop that did not need to exist, on every legacy inbound link to the site.
Googlebot follows up to ten hops, so nothing visibly breaks. But every hop costs crawl budget and adds real latency for users arriving from old links. The fix is to handle protocol and host normalization in one rule at the edge, then test all four variants individually.
Template-level mixed content is easy to find and fix. The awkward part is content.
Editors paste absolute URLs into body copy. Over years, a site accumulates thousands of http:// image and link references inside database fields that no template change touches. They surface as blocked images on individual pages, discovered one at a time by users rather than all at once by a crawler.
Search the content database directly, not just the codebase. A find-and-replace across body fields is the only reliable fix, and it wants a backup taken first.
HTTPS migrations rarely happen alone anymore — they are usually bundled into a replatform or a domain change. When bundled, the protocol change is the least of the risks, but the four-variant check still needs running against the new host.
The technical scope page covers redirect architecture in more depth, and the full checklist puts these steps in sequence with the rest of the launch work.
What you see http://example.com redirects to http://www.example.com, which then redirects to https://www.example.com. Every legacy link takes two hops.
What fixes it Collapse protocol and host normalization into a single rule at the edge, so any variant reaches the canonical in one hop.
What you see Browsers block scripts, stylesheets or images still requested over HTTP. Pages render broken or partially unstyled, and layout scores collapse.
What fixes it Rewrite hardcoded http:// asset references in templates, content and the database. Protocol-relative URLs are a workaround, not a fix.
What you see Pages serve over HTTPS while their canonical tag points at the HTTP version, telling Google the encrypted page is the duplicate.
What fixes it Generate canonicals from the request host and protocol rather than hardcoding them, then verify a sample in production after cutover.
What you see A subdomain that has no valid certificate becomes unreachable, and the browser refuses to let users bypass it.
What fixes it Ship HSTS with a short max-age first, confirm every subdomain serves valid HTTPS, then raise it. Only add includeSubDomains once that is proven.
| Variant | Correct behavior | Hops allowed | Common mistake |
|---|---|---|---|
| http://example.com | 301 straight to the canonical HTTPS host | 1 | Redirects to http://www first, then to HTTPS — two hops |
| http://www.example.com | 301 straight to the canonical HTTPS host | 1 | Chained through the HTTPS non-canonical variant |
| https://www.example.com | 301 to canonical if non-www is canonical, otherwise serve | 1 | Both www and non-www serve 200 and compete as duplicates |
| https://example.com | Serve 200 — this is the canonical in most setups | 0 | Canonical tag still pointing at the http:// version |
Short list, run in order. Most HTTPS problems are configuration rather than strategy.
www or non-www. Either is fine; the decision matters more than the answer. Every rule, canonical tag and sitemap entry afterwards refers back to this choice.
Output Documented canonical host
Test each of the four combinations individually and confirm each reaches the canonical in a single hop with a 301.
Output Four-variant test results
Crawl for http:// references in templates, inline content and database fields. Content editors paste absolute HTTP URLs into body copy, and no template fix catches those.
Output Mixed content exception list
Canonical tags, XML sitemaps, hreflang annotations and structured data URLs all need to reference the HTTPS canonical host.
Output Updated canonicals and sitemaps
Start with a short max-age. Confirm every subdomain serves valid HTTPS before adding includeSubDomains, and only consider preload after that has been stable.
Output HSTS header live with documented max-age
HTTP and HTTPS are separate properties unless you use a domain property. Add the HTTPS version and submit the updated sitemap.
Output Verified HTTPS property
Not if it is done cleanly. Expect a short settling period of one to four weeks while Google recrawls and reassigns signals. Lasting damage comes from configuration errors — redirect chains, competing host variants, canonicals still pointing at HTTP — rather than from the protocol change.
No. Change of Address only applies to moves between different domains. A protocol change is handled entirely through redirects and canonical tags. Add the HTTPS property in Search Console and submit the updated sitemap instead.
Mixed content is an HTTPS page requesting resources over HTTP. Browsers block active mixed content such as scripts and stylesheets outright, so pages render broken. Beyond the security warning, a page missing its stylesheet fails Core Web Vitals and looks broken to users.
Only once every subdomain reliably serves valid HTTPS, because preload is close to irreversible in practice — removal takes months to propagate through browser releases. Run a long max-age with includeSubDomains for a while before submitting.
Send the launch date and what is changing. We will tell you which parts of this page apply to your situation and which do not.