HTTP to HTTPS Migration

TL;DR — An HTTP→HTTPS migration means moving every page on your site from the insecure http:// address to the secure https:// one. You install a certificate, then redirect every old URL to its new secure version so nothing breaks and no rankings are lost. Done carefully it’s safe — the damage only comes from sloppy execution.

What you’re actually doing

Moving HTTP URLs to HTTPS changes their canonical URLs and should use permanent server-side redirects plus consistent canonical signals. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: Site moves with URL changes HTTPS configuration must also present a valid TLS certificate and avoid mixed resources. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: HTTPS

Right now your pages live at addresses that start with http://. You want them to live at https:// instead — the secure, encrypted version, the one that shows the padlock and doesn’t trip Chrome’s “Not Secure” warning. The content, the hostnames, the paths, and the query strings all stay the same, and you’re not changing CMS or hosting platform at the same time. Only the first few characters of every URL change.

Because the pages themselves aren’t moving, this is the gentlest kind of site migration — but only while all of that stays true. If you’re also merging subdomains, restructuring URLs, rewriting content, or switching platforms at the same time, that’s a different, higher-risk move; see the short version’s note below. Otherwise, it’s still a migration, so it deserves care.

The one rule that matters most

Redirect every old http:// URL to its exact https:// version with a 301 redirect. A 301 is a “permanent” redirect — it tells search engines “this page lives here now, forever, please move everything over.” Google has confirmed 301s don’t cost you any ranking strength, so a clean switch keeps your traffic.

The trouble starts when redirects are missing, or when your pages still try to load an image or a script from the old http:// address. That “mixed content” can make parts of your page break in the browser. So the work isn’t the switch — it’s making sure nothing still points at the old addresses.

The short version of the process

1. Take a snapshot of your site as it is now — a full list of pages and your current rankings — so you can compare afterward.
2. Get a certificate and install it. A free one (like Let’s Encrypt) works perfectly for SEO.
3. Test on a copy first if you can, so launch day has no surprises.
4. Flip it on: redirect every old URL to the secure version, update your internal links and sitemap, and fix anything still loading over http://.
5. Re-check Search Console. The simplest fix is a Domain property, which covers every http/https/www variant automatically — you don’t need to verify each one separately.
6. Keep the redirects (for at least a year, ideally forever) and watch your traffic for a couple of weeks. A little wobble is normal.

If you’re also renaming URLs, merging subdomains, moving to a new CMS, or changing what’s on the pages, stop — that’s a bigger, riskier move than a straight protocol switch. Use the full site migration playbook instead and fold the HTTPS switch into it.

Want the full engineering version — certificate choices, redirect mapping for thousands of URLs, the four Search Console properties, monitoring windows, and a rollback plan? Switch to the Advanced tab. (For where HTTPS fits as a ranking signal in the first place, start with the HTTPS hub.)

TL;DR — An HTTP→HTTPS move is a protocol-only site migration: same host, paths, query strings, content, and platform — only the scheme changes. That makes it the lowest-risk migration there is if all of that holds — but the discipline is identical to any site move. Benchmark the live HTTP site, choose and install a TLS certificate (a free DV cert earns the same lightweight ranking signal as any paid one — Google checks the scheme, not the issuer), rehearse on staging, then flip: 301 every URL one-to-one server-side (301s don’t lose PageRank), make each page self-canonical to its HTTPS URL, repoint every internal link, sitemap entry, and hreflang annotation, and kill blockable mixed content before it breaks your scripts. Add a Domain property in Search Console (it covers every scheme/host variant at once) or verify the HTTPS properties individually if you want segmented data, submit the HTTPS sitemap, and don’t touch the Change of Address tool — it’s for domain moves. Keep redirects at least a year (that’s a floor, not an expiration date). Monitor Crawl Stats and indexing: a dip that recovers is the move settling; a dip that sticks means something broke. Have a rollback plan, but repair HTTPS first — caching, HSTS, cookies, and service workers can make a true HTTP rollback unsafe — and treat HSTS preload as slow and operationally risky to reverse, not a literal one-way door.

The HTTPS hub covers why to be on HTTPS and sketches the migration at a high level. This is the deep, step-by-step companion to that section — the part where a migration actually goes wrong or goes clean.

First, right-size the risk: this is a protocol-only migration

Google treats protocol changes as site moves with URL changes; temporary ranking or reporting fluctuations are possible and no migration timeline is guaranteed. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: Site moves with URL changes Transport security and Search processing are related but separate concerns. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: HTTPS

Site migrations exist on a spectrum of danger. Changing your domain, your URL structure, or your CMS/platform all rewrite the identity of your URLs and carry real risk. A protocol-only switch is the low-risk case only when everything else holds steady. Confirm all of these before treating it as a one-rule redirect:

• Hostnames — no www/non-www consolidation or subdomain changes riding along with the switch.
• Paths and query strings — no URL restructuring, slug renames, or parameter cleanup bundled into the same release.
• Content — pages aren’t being rewritten, merged, or pruned at the same time.
• Platform/rendering behavior — no CMS, framework, or hosting migration happening in parallel.

When all four hold, the domain, the paths, and the content are identical; only the scheme in front of each URL moves. That’s why Google is explicit that you “don’t need to use the Change of Address tool” for it: there’s no address change to declare.

The single most important consequence: because URLs map one-to-one and deterministically (http://example.com/x → https://example.com/x), your redirect logic can usually be a single server rule, and your redirect map writes itself. Compare that to a domain or platform move, where every old URL needs a hand-checked destination. Keep that framing — it tells you where to spend effort (certificate, mixed content, Search Console) and where not to (agonizing over redirect targets).

If you’re also changing domain or platform at the same time, stop: that’s a stacked migration, the risks multiply, and the protocol switch is the least of your worries. Do the harder move using the full site migration playbook and fold HTTPS into it.

Step 1 — Benchmark the live HTTP site before you touch anything

You can’t tell whether a migration went well without a “before” picture to diff against. Capture, while the site is still on HTTP:

• A full crawl of the live site — save every 200 URL and, critically, every existing redirect and its target. You’ll re-run this crawl after launch and diff the two; anything that was a 200 and is now a 404 is a regression.
• A rankings snapshot for your tracked keywords, so a post-launch dip has a baseline.
• A Search Console export — Performance (queries, pages, clicks, impressions), the Page Indexing report, and Crawl Stats. GSC data does not transfer from the HTTP property to the HTTPS one, so this export is your only record of the “before.”
• Your backlink profile, so you know which URLs carry the most external equity and therefore most need clean, single-hop redirects.
• Your robots.txt and any noindex directives as they stand — you’ll want to make sure none of them silently carry over to block the HTTPS site.

Step 2 — Choose and install the TLS certificate

Here’s the SEO-relevant truth that saves people money: the ranking signal checks the URL scheme, not the certificate. Gary Illyes described it as “basically looking at the first five characters in front of the URL, and if it’s HTTPS … it will get a minimal boost.” So for SEO, a free Domain Validation (DV) certificate — Let’s Encrypt is the default — earns exactly the same signal as a paid OV or EV certificate. OV/EV buy organizational identity, not rankings. Don’t promise yourself (or a client) a ranking boost, or a special benefit for a particular certificate type or key algorithm — Google’s own description calls this a lightweight, minimal signal, not a lever worth paying for.

What you do need to get right technically:

• Scope. A single-domain cert covers one hostname; a wildcard (*.example.com) covers one label deep — it works for foo.example.com but not foo.bar.example.com. If you run deep subdomains, plan a multi-domain (SAN) or additional certs.
• Key strength. Google’s guidance is to “generate a 2,048-bit RSA key pair” — shorter is brute-forceable, longer wastes resources.
• Auto-renewal. The most common post-migration incident is an expired cert. Automate renewal (Let’s Encrypt is built for it) and monitor expiry. Note the nuance: Google generally prefers HTTPS as the canonical version of a page, but that preference is conditional, not automatic — an invalid certificate, insecure dependencies, an HTTPS-to-HTTP redirect, or an HTTP canonical tag can flip Google’s canonical choice back to the HTTP URL, and HSTS cannot override that preference. Evidence for this claim Google generally prefers HTTPS as the canonical version of a page, but that preference is conditional: an invalid certificate, insecure dependencies, an HTTPS-to-HTTP redirect, or an HTTP canonical tag can flip Google's choice back to the HTTP URL. HSTS is a browser-only mechanism and cannot override Google's canonical selection. Scope: Describes Google's conditional HTTPS canonical preference, not a guarantee that certificate problems are search-invisible. Confidence: high · Verified: 2026-07-17 Google: Consolidate duplicate URLs So an expired cert is not a harmless non-event for Search — it’s simultaneously a UX/security emergency (a full-screen browser warning that destroys user trust) and a real risk to your HTTPS canonical preference the longer it persists. Fix it fast either way. (For the full certificate-failure taxonomy — expired, self-signed, hostname mismatch, incomplete chain — see the TLS/SSL certificates deep dive.)

Step 3 — Rehearse on staging

Do the whole flip on a staging/pre-production copy first. What you’re validating:

• The redirect rule fires for every path shape, including query strings, trailing-slash variants, and www/non-www.
• No redirect loop (a misconfigured rule that bounces HTTPS back to HTTP and around again locks everyone out — including you).
• Pages render clean with no blockable mixed content in the DevTools console.
• Your canonical tags already emit https:// on staging.

Guard the staging copy from indexing (auth or a noindex you remember to remove — a stray migration-only noindex that survives to production is a classic self-inflicted wound). Google’s own guidance calls this out: don’t forget to remove noindex or robots.txt blocks that were only needed for the migration.

Step 4 — Redirect mapping at scale

For a protocol switch, the mapping is deterministic, so you drive it with one rule, not a giant lookup table:

• Server-side, one-to-one, and permanent (301). Every http:// URL → the same path on https://. Do it in the server/edge config (Apache, Nginx, or your CDN), not in application code and not with client-side JavaScript, so bots see a clean server 301.
• No redirect chains. If you already had HTTP redirects (say http://a → http://b), don’t let the HTTPS switch turn that into http://a → http://b → https://b. Update the original rules so old URLs land on the final HTTPS destination in one hop. Google will follow up to 10 hops, but it “advise[s] redirecting to the final destination directly.” Every extra hop is wasted crawl budget and a little lost speed.
• Never mass-redirect to the homepage. Unmatched URLs should still resolve to their own HTTPS twin. Dumping everything on / is the migration mistake that actually loses rankings.
• Verify the map with a crawl. Re-crawl the HTTP URL list after launch and confirm each returns a single 301 to the right HTTPS URL — not a 302, not a chain, not a 404.

Step 5 — Repoint every canonical, sitemap, and hreflang signal

Redirects do the heavy lifting, but don’t make Google lean on them to fix sloppy internals. Update the actual signals:

• Canonicals. Every page should carry a self-referencing rel="canonical" pointing at its own https:// URL — Google’s site-move guidance states “Each new URL should have a self-referencing rel=“canonical” <link> tag.” A canonical still pointing at http:// fights your migration. (This is exactly the kind of conflicting signal the canonicalization topic warns about — align every signal on the HTTPS URL.)
• Internal links. Change them in the templates and content to https:// (or protocol-relative/root-relative) — don’t leave thousands of internal links pointing at http:// and relying on the redirect to clean up. Every internal http:// link is an unnecessary redirect hop for both users and bots.
• XML sitemaps. Regenerate them with the HTTPS URLs only, listing canonical, indexable pages, and update lastmod. Submit the new sitemap in GSC after launch.
• Hreflang. If you run an international setup, every hreflang annotation must reference the HTTPS version of each alternate. Half-migrated hreflang (some http, some https) is a silent, hard-to-diagnose international SEO bug.
• Structured data and Open Graph URLs. og:url, canonical references inside JSON-LD, and any hardcoded absolute URLs should all be HTTPS.

Step 6 — Kill mixed content before launch, not after

Mixed content is an HTTPS page loading a sub-resource over HTTP. It’s the most common launch-day regression. The current terminology (the older “active/passive” split is historical, but you’ll still see it in older docs and tooling) splits it by what the browser does about it:

• Blockable mixed content — scripts, stylesheets, iframes, XMLHttpRequest/ fetch (the old “active” bucket). Browsers block these outright because a tampered script can rewrite the whole page. This is what actually breaks the site after the flip: a blocked stylesheet or JS bundle can leave a page unstyled or non-functional. Fix these first.
• Upgradable (optionally-blockable) mixed content — images, audio, video (the old “passive” bucket). Modern browsers increasingly auto-upgrade these requests to HTTPS transparently and block them if the upgrade fails, rather than just warning and displaying them over HTTP; treat “it still loads” as a browser-version-dependent behavior, not a guarantee. Fix next regardless.
• Exceptions exist — some browser/embed contexts (certain plugin-loaded resources, some legacy <applet>/<embed> cases) don’t follow either rule cleanly, which is one more reason to verify behavior in the browsers your audience actually uses rather than assuming the general rule.

Find it by crawling the HTTPS site (Ahrefs Site Audit, Screaming Frog), watching the Chrome DevTools console, or collecting CSP reports. As a transitional proactive net, the Content-Security-Policy: upgrade-insecure-requests header tells the browser to silently upgrade http:// sub-resource requests to https:// before it makes them — but a CSP header doesn’t prove the HTTPS version of every endpoint actually exists or behaves the same as the HTTP one, and it doesn’t replace fixing the source URLs or testing in real browsers. One clarification that saves confusion: an ordinary anchor link to an HTTP page isn’t mixed content — it just navigates.

Step 7 — Get Search Console coverage right

This is the step people underestimate — but it’s a decision, not a universal checklist. Search Console’s URL-prefix properties track http://example.com, http://www.example.com, https://example.com, and https://www.example.com as four separate properties that don’t share data. You are not required to verify all four:

• A Domain property aggregates every protocol and subdomain variant automatically — add one and it absorbs the switch without you touching anything else. This is the simplest default for most sites.
• URL-prefix properties segment data by exact protocol and host. Keep or add them only if you deliberately want that segmentation — for example, comparing how much HTTP straggler traffic is still arriving against the live HTTPS site. That’s a reporting choice, not a requirement.

Either way:

• Submit the new HTTPS sitemap wherever you’re tracking the site (the Domain property or the HTTPS URL-prefix property).
• Do not use the Change of Address tool. Google is explicit: “If you’re moving your site from HTTP to HTTPS, you don’t need to use the Change of Address tool.” That tool is only for domain-level moves, and using it here is a well-meaning mistake.
• Keep any HTTP properties you already had verified — they’ll show the redirects being processed and the old URLs dropping out of the index, which is useful monitoring signal, not clutter.
• Revisit your disavow file, if you have one — its entries reference HTTP URLs, and it lives per-property.

For diagnosing individual URLs rather than tracking the whole site, GSC’s HTTPS report flags certificate, redirect, canonical, robots, and sitemap-evaluation reasons a URL didn’t move to HTTPS. Treat it as a sampled diagnostic tool, not a full inventory — it’s sampled and it ignores query parameters when matching URLs, so it won’t catch everything your own crawl would. See the GSC HTTPS report deep dive for how to read it.

Step 8 — Monitoring windows: settling vs. broken

Expect “temporary fluctuation in site ranking during the move” — that’s normal and not a reason to panic or revert. The discipline is telling a settling dip from a broken one:

• A dip that recovers over days to a few weeks is the index swapping HTTP URLs for HTTPS ones. Google notes a small-to-medium site takes a few weeks for most pages to move; larger sites take longer.
• A dip that sticks means something broke — a stray robots.txt block, a noindex that survived from staging, canonicals still pointing at http://, internal links en masse still on HTTP, or redirect chains bleeding equity.

There’s no fixed recovery window — track these independently rather than waiting for one number to say “done”:

• TLS/browser behavior — certificate validity and chain, and the actual DevTools console on representative pages (no mixed-content errors, no certificate warnings). This is the one Search metrics won’t tell you about.
• GSC Crawl Stats on wherever you’re tracking the site — you want to see Googlebot fetching the HTTPS URLs and the response-code mix staying healthy (mostly 200 + the 301s on old URLs). A spike in 5xx means your server is struggling under the new load.
• Page Indexing report — HTTPS URLs moving to “Indexed,” HTTP URLs moving to “Page with redirect.” That crossover is exactly what you want to see.
• URL Inspection on a few key pages — confirm the reported canonical is the HTTPS URL and the page renders without mixed content.
• Server logs — the ground truth for which URLs bots actually hit and what status they got. Watch for bots still hammering HTTP URLs (fine, briefly) or hitting chains/loops (not fine).
• Analytics and business outcomes — a chunk of “direct” traffic can appear because HTTPS→HTTP referral data gets stripped, so make sure your own outbound links go to HTTPS destinations; also track conversions/revenue independently — a ranking metric recovering doesn’t guarantee the business metrics did too.

Monitor actively for 2–4 weeks as a rule of thumb, then keep a lighter eye on it until indexing fully crosses over — larger or slower-crawled sites can take longer, and there’s no guaranteed end date.

Step 9 — Keep the redirects, and add HSTS deliberately

• Keep the 301s for the long haul. Google’s guidance is “as long as possible, generally at least 1 year” — that’s a floor Google recommends, not an expiration date after which it’s safe to remove them. In practice, keep them for the life of the site — external links and bookmarks on the old http:// URLs never fully disappear.
• HSTS is a second layer, not a replacement. The Strict-Transport-Security header tells browsers to always use HTTPS for your domain, closing the “first-request problem” (that very first request from a new visitor still goes out over HTTP before the 301 fires — the window an SSL-stripping attacker wants). But when a browser honors HSTS it performs a browser-only 307 internal redirect that crawlers never see — search engines still need your server-side 301. You need both.
• Treat HSTS preload as slow and risky to reverse — not a literal one-way door. Submitting to the browser-baked preload list (which requires max-age of at least a year, includeSubDomains — meaning the policy applies to every subdomain, not just the one you submitted, so any subdomain that isn’t fully HTTPS-ready breaks under it — and preload) closes the gap even for first-time visitors. Removal is genuinely possible via hstspreload.org, but it’s slow (the change has to propagate through browser release cycles) and every browser already on the old list keeps enforcing HTTPS-only until it updates — operationally risky, not literally irreversible. Google’s warning is blunt: “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.”

Step 10 — Have a rollback plan (and know its limits)

Even a low-risk migration deserves an exit — but the default move when something breaks is to repair HTTPS, not revert to HTTP. A “rollback” is a limited safety net, not a guaranteed reversal: cached 301s in browsers and CDNs, Secure-flagged cookies, service workers registered under the HTTPS origin, and HSTS/preload policy can all make serving HTTP again unsafe or simply ineffective for a chunk of your visitors, even if you did everything right on launch.

Before you flip:

• Time the launch for low traffic — Google explicitly suggests you “time your move to coincide with lower traffic, if possible.” A quiet window means fewer users hit any launch-day bug and you have room to react.
• Keep HTTP serving underneath the redirect. Don’t tear down the HTTP listener; keep it alive so the 301s have something to fire from, and so a redirect-rule revert is available as an option if the HTTPS site is badly broken.
• Do not enable HSTS on day one. HSTS (and especially preload) makes an HTTP rollback far less viable — once a browser has cached the policy, it won’t talk HTTP to your domain regardless of what your server does. Add HSTS only after the HTTPS site has proven stable for a while.
• Define your abort criteria in advance — e.g., site-wide 5xx, a redirect loop, or mass mixed-content blocking. When you hit them, work the problem in this order: (1) can you fix the HTTPS bug directly (bad cert, missing resource, broken canonical)? Usually yes, and that’s faster and safer than reverting. (2) Only if HTTPS itself is unusable, revert the redirect rule as a stopgap — and expect it to be incomplete: previously cached redirects, cookies, and service workers won’t un-cache themselves just because your server changed its mind.

Diagnose calmly rather than debugging live, and treat “revert to HTTP” as a break-glass option you hope never to need — not a routine, clean undo.

AI summary

A condensed take on the Advanced version:

• It’s a protocol-only migration — conditionally. Same host, paths, query strings, content, and platform; only the scheme changes. Lowest-risk migration there is if all five hold, so URLs map one-to-one and the redirect logic is usually a single rule. No Change of Address tool (that’s for domain moves). If anything else is also changing, treat it as a stacked migration instead.
• Benchmark first: full crawl (save every 200 + existing redirect), rankings snapshot, GSC export (data doesn’t transfer to the HTTPS property), backlink profile, current robots/noindex.
• Certificate: the ranking signal is scheme-based, so a free DV cert (Let’s Encrypt) earns the same lightweight signal as any paid cert; OV/EV buy identity, not rankings — don’t promise a ranking boost for any cert type or key algorithm. 2,048-bit key; watch wildcard scope (one label deep); automate renewal. Google generally prefers HTTPS as canonical, but that preference is conditional — a bad cert, insecure dependencies, an HTTPS→HTTP redirect, or an HTTP canonical tag can flip it back to HTTP, and HSTS can’t override that.
• Rehearse on staging — every path shape redirects, no loops, no blockable mixed content, canonicals already emit HTTPS; remove any migration-only noindex before it reaches production.
• The flip: 301 every URL one-to-one, server-side (301s don’t lose PageRank); no chains (redirect to the final HTTPS destination in one hop); never mass-redirect to the homepage; then repoint canonicals (self-referencing HTTPS), internal links, sitemaps, hreflang, and OG/JSON-LD URLs.
• Mixed content: current terms are blockable (scripts/styles/iframes/XHR — browsers block outright, fix first) and upgradable (images/audio/video — modern browsers auto-upgrade to HTTPS or block on failure, not just warn); the old active/passive split is historical. upgrade-insecure-requests CSP is a transitional net, not proof the HTTPS endpoint exists. Anchor links to HTTP pages aren’t mixed content.
• Search Console is a decision, not a universal count. Add one Domain property (aggregates every scheme/host variant automatically) — URL-prefix properties (http, https, http-www, https-www) are optional segmentation, not a requirement. Submit the HTTPS sitemap; review the disavow file. The GSC HTTPS report is a sampled diagnostic tool (ignores query parameters), not a full inventory.
• Monitor independently, no fixed window: TLS/browser behavior, Crawl Stats, Page Indexing, URL Inspection, logs, and analytics/business outcomes each tell a different part of the story. A dip that recovers over days to weeks is settling; a dip that sticks means something broke (stray block, lost canonical, HTTP internal links, chains).
• Keep redirects ≥ 1 year as a floor, not an expiration date (most sites keep them indefinitely). HSTS is a browser-only 307 crawlers never see — on top of, not instead of, the 301. Preload is slow and risky to reverse — genuinely possible via hstspreload.org, but not something to rush into.
• Rollback plan, with limits: repair HTTPS first — that’s usually faster and safer than reverting. Launch at low traffic, keep HTTP serving, don’t enable HSTS on day one, define abort criteria — but cached redirects, cookies, and service workers can make a true HTTP rollback incomplete even then.

Official documentation

Primary-source documentation for planning and executing the migration.

Google

• Site moves with URL changes — the migration playbook: server-side 301s, one-hop redirects, self-referencing canonicals, “keep redirects at least 1 year,” “no Change of Address tool for HTTP→HTTPS,” and “time your move to coincide with lower traffic.”
• Consolidate duplicate URLs — Google’s conditional HTTPS canonical-preference guidance: HTTPS is generally preferred, but a bad certificate, insecure dependencies, an HTTPS→HTTP redirect, or an HTTP canonical tag can flip that preference back to HTTP.
• Enable HTTPS on your servers (web.dev) — certificates, 2,048-bit keys, 301-to-HTTPS-canonical, HSTS, and cookies.
• Why HTTPS matters (web.dev) — the security and browser-feature case for switching.
• Fixing mixed content (web.dev) — blockable vs. upgradable (optionally-blockable) mixed content — the current terms for what’s historically called active/passive — and upgrade-insecure-requests.
• HTTPS as a ranking signal (2014) — the original “very lightweight signal” post, plus Google’s implementation notes (cert type, relative URLs, don’t block HTTPS in robots.txt).
• Understanding page experience — where HTTPS and the GSC HTTPS report sit.

Certificates & configuration

• Let’s Encrypt — free, automated DV certificates with built-in renewal.
• SSL Labs Server Test — grade your TLS configuration after install.
• hstspreload.org — HSTS preload eligibility and the removal warnings.

Chrome / Chromium

• A secure web is here to stay (2018) — Chrome 68 marking all HTTP “not secure,” the deadline that pushed most sites to migrate.

Quotes from the source

On-the-record statements that govern how a migration should be run. Each deep link jumps to the quoted passage on the source page.

Google — redirects and PageRank

• “301 and other permanent redirects don’t cause a loss in PageRank.” — Google Search Central. Jump to quote
• “Keep the redirects for as long as possible, generally at least 1 year.” — Google Search Central. Jump to quote
• “Each new URL should have a self-referencing rel=“canonical” <link> tag.” — Google Search Central. Jump to quote

Google — the HTTP→HTTPS specifics

• “If you’re moving your site from HTTP to HTTPS, you don’t need to use the Change of Address tool.” — Google Search Central. Jump to quote
• “Expect temporary fluctuation in site ranking during the move.” — Google Search Central. Jump to quote

Google — HSTS and certificates (web.dev)

• “Use HTTP Strict Transport Security (HSTS) to avoid the cost of the 301 redirect.” — web.dev (Google). Jump to quote
• “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” — web.dev (Google). Jump to quote

Gary Illyes — the signal is scheme-based

• “Basically looking at the first five characters in front of the URL, and if it’s HTTPS … it will get a minimal boost.” — Gary Illyes, Google, 2016 (via Search Engine Land). Read the coverage

Which path should I take?

“Am I changing anything besides the scheme?”

• Only http:// → https:// — same host, paths, query strings, content, and platform → this article’s protocol-only playbook. One redirect rule, no Change of Address tool.
• Also changing domain, hostnames/subdomains, URL structure, content, or CMS/platform → stop. That’s a higher-risk stacked migration — run the full site migration playbook and fold HTTPS into it.

“Which certificate do I need?”

• Just need the HTTPS scheme + the ranking signal → a free DV cert (Let’s Encrypt). Same lightweight signal as anything paid — don’t pay more expecting a ranking boost.
• Want a visible organization name / regulated industry → OV/EV — but understand it buys identity, not SEO.
• Multiple subdomains → wildcard covers one label deep only; deep subdomains need a SAN/multi-domain cert.

“A ranking dip appeared after launch — panic or wait?”

• It’s within the first couple of weeks and slowly recovering → wait. That’s the index swapping HTTP for HTTPS. Normal.
• It’s not recovering after several weeks → something broke. Check, in order: stray robots.txt block → surviving noindex → canonicals still on http:// → internal links still on http:// → redirect chains → mixed content blocking pages.

“Should I turn on HSTS now?”

• It’s launch day / the migration isn’t proven stable yet → no. HSTS makes an HTTP rollback far less viable if you need one.
• HTTPS has run cleanly for a while and renewal is automated → add the header.
• Considering the preload list? → only when you’re certain you won’t need to revert; removal is genuinely possible but slow and operationally risky, not a literal one-way door.

“Do I need to verify all four Search Console properties?”

• Just want continuity, no interest in segmented data → no. Add one Domain property; it covers every scheme/host variant automatically.
• Want to compare HTTP straggler traffic against the live HTTPS site → keep or add the individual URL-prefix properties for that segment — optional, not required.

“Do I need the Change of Address tool?”

• HTTP → HTTPS, same domain → no. Google says so explicitly.
• Changing the actual domain → yes — but that’s a different migration.

“An old URL doesn’t have an obvious HTTPS twin — where does it redirect?”

• For a protocol switch there’s always a twin → same path on https://, one hop.
• The page is genuinely gone → that’s a content decision (404/410 or redirect to the closest relevant page) — don’t mass-dump it on the homepage.

HTTP → HTTPS migration checklist

Before (benchmark + prep)

• Full crawl of the live HTTP site saved (every 200 + every existing redirect + target).
• Rankings snapshot, GSC export (Performance, Page Indexing, Crawl Stats), and backlink profile archived.
• Current robots.txt and noindex directives recorded.
• TLS certificate obtained (free DV is fine), 2,048-bit key, auto-renewal configured.
• Wildcard scope checked against your subdomain depth.
• Whole flip rehearsed on staging: every path shape redirects, no loops, no blockable mixed content, canonicals emit HTTPS.
• Launch timed for a lower-traffic window.
• Confirmed this is truly protocol-only: host, paths, query strings, content, and platform are all unchanged.

The flip

• Every HTTP URL 301-redirects, server-side and one-to-one, to its HTTPS twin.
• No redirect chains — old URLs land on the final HTTPS destination in one hop.
• No bulk redirects to the homepage for unmatched URLs.
• Each page self-references rel="canonical" to its HTTPS URL.
• Internal links, XML sitemaps, and hreflang updated to HTTPS (not left to redirects).
• og:url / JSON-LD / hardcoded absolute URLs updated to HTTPS.
• Blockable mixed content (scripts, styles, iframes, XHR) fixed — these get blocked outright.
• Upgradable mixed content (images, media) fixed — don’t rely on browser auto-upgrade alone; upgrade-insecure-requests CSP set as a transitional net, not a fix.
• Any migration-only noindex or robots.txt block removed.

Search Console & after

• Domain property added in GSC (recommended default) — or HTTPS URL-prefix properties verified individually if you specifically want segmented data.
• New HTTPS sitemap submitted; old HTTP properties kept verified for monitoring, if you had them.
• Change of Address tool not used (domain moves only).
• Disavow file (if any) reviewed for HTTP URLs.
• Redirects kept at least 1 year as a floor, not a removal date — ideally for the life of the site.
• HTTP listener kept alive underneath the redirect (limited rollback safety net, not a guaranteed undo).
• HSTS not enabled on launch day; added only after HTTPS proves stable.
• TLS/browser behavior, Crawl Stats, Page Indexing, URL Inspection, logs, and analytics/business outcomes monitored for 2–4 weeks (no fixed end date); a dip that doesn’t recover = something broke.

Standard operating procedure: run the migration

A repeatable runbook. Assign an owner to each phase; don’t skip the staging rehearsal.

T-minus (a week out) — benchmark & build

1. Crawl the live HTTP site; export the full URL list with status codes and existing redirects.
2. Export GSC (Performance, Page Indexing, Crawl Stats) and snapshot rankings + backlinks.
3. Obtain and install the DV certificate on staging; confirm the chain validates (SSL Labs).
4. Build the single server-side 301 rule (http → https, preserve path + query).
5. Update templates so canonicals, internal links, sitemaps, hreflang, and OG/JSON-LD emit HTTPS.
6. Run the mixed-content sweep on staging; fix all blockable, then upgradable.

T-zero (launch, low-traffic window) 7. Deploy the cert to production; confirm HTTPS serves with a valid chain. 8. Enable the 301 rule. Immediately spot-check: a handful of URLs each return a single 301 to the correct HTTPS URL. 9. Confirm the homepage and top templates render with no console mixed-content errors. 10. Remove any migration-only noindex/robots.txt block.

T-plus (first hour → first day) 11. Re-crawl the old HTTP URL list; confirm one-hop 301s, no chains, no 404s, no loops. 12. Add a Domain property in GSC (recommended default), or verify the HTTPS URL-prefix properties individually only if you want segmented data; submit the HTTPS sitemap. 13. Watch server logs and error rates for 5xx spikes under the new load.

T-plus (first 2–4 weeks) 14. Monitor GSC Crawl Stats + Page Indexing daily: HTTPS URLs → “Indexed,” HTTP URLs → “Page with redirect.” 15. Spot-check URL Inspection on key pages: reported canonical = HTTPS, renders clean. 16. Compare against your benchmark; distinguish a recovering dip (settling) from a stuck dip (broken) and fix the latter. 17. Review the disavow file for HTTP URLs.

T-plus (stable → ongoing) 18. Once HTTPS is proven stable and renewal is automated, add the HSTS header. 19. Consider preload only if you’re confident you won’t need to revert — removal is possible but slow and operationally risky. 20. Keep the 301s and the HTTP listener for at least a year (a floor, not a removal date) — ideally permanently. If an incident ever hits, repair HTTPS before considering an HTTP rollback; caching, cookies, and service workers can make that rollback incomplete.

Playbooks by situation

Small site (a few hundred URLs) on shared hosting Get a free Let’s Encrypt cert (most hosts one-click it), add the single 301 rule, update internal links and the sitemap, run one mixed-content pass in DevTools, verify the HTTPS Domain property in GSC. You can do the whole thing in an afternoon. The main risk is a forgotten hardcoded http:// asset — sweep for it.

Large site (100k+ URLs) behind a CDN Put the 301 at the edge (CDN/reverse proxy) so it’s one rule at scale, not per-app logic. Benchmark hard first — the “before” crawl and GSC export are your only safety net. Expect the index crossover to take longer than a small site; monitor Crawl Stats for 5xx under load and watch for redirect chains where legacy HTTP redirects now stack. Re-crawl in batches to confirm one-hop 301s.

Site with an existing redirect layer (past migrations, vanity URLs) The trap is stacking: http://old → http://new → https://new. Rewrite the source rules so every old URL reaches the final HTTPS destination in one hop. Audit for chains explicitly after launch — this is where equity leaks.

International site with hreflang Every hreflang annotation and its return links must reference HTTPS alternates. A half-migrated hreflang cluster (some http, some https) silently breaks targeting. Regenerate all annotations from a single source of truth on HTTPS.

You already flipped and rankings dropped and haven’t recovered Work the diagnosis in order: (1) is anything blocked in robots.txt or carrying a leftover noindex? (2) do canonicals point at https://? (3) are internal links on HTTP? (4) are there redirect chains or loops? (5) is blockable mixed content breaking pages, or a bad certificate flipping Google’s canonical preference back to HTTP? Most “HTTPS killed my rankings” stories are one of these five — not the protocol switch itself. Fix the underlying HTTPS problem directly; don’t jump to an HTTP rollback as the first move.

What not to do

• Redirecting everything to the homepage. The single most damaging migration mistake. Every old URL must reach its own HTTPS twin. Google explicitly warns against redirecting many old URLs to one irrelevant destination like the home page.
• Using 302 instead of 301. A 302 is “temporary” and signals the move isn’t permanent. Use 301 so engines fully transfer the URL and its equity.
• Building redirect chains. http://a → http://b → https://b wastes crawl budget and speed. Redirect to the final HTTPS destination directly.
• Leaving internal links on http://. Relying on the 301 to “clean up” internal links means every internal click and every crawl hits a redirect. Fix the links.
• Canonicals still pointing at http://. A self-canonical that references the old scheme fights the migration and confuses canonical selection.
• Ignoring blockable mixed content until after launch. A blocked stylesheet or JS bundle can leave pages broken for real users on day one. Fix blockable mixed content before the flip.
• Using the Change of Address tool for a protocol switch. It’s for domain moves. Google says you don’t need it here.
• Assuming you must verify all four GSC properties. You don’t — a single Domain property aggregates every scheme/host variant automatically. (Verifying only the old HTTP property and nothing HTTPS-aware is still the real mistake to avoid.)
• Enabling HSTS (or preload) on launch day. It makes an HTTP rollback far less viable if the HTTPS site turns out to be broken. Add it only after HTTPS is proven stable.
• Leaving a migration-only noindex in production. A noindex or robots.txt block you added to protect staging, forgotten and shipped, quietly deindexes the new site.
• Tearing down the HTTP listener immediately. Keep it alive so the 301s have something to fire from and so a redirect-rule revert is at least an option.
• Treating “keep HTTP alive” as a guaranteed rollback. Cached redirects, cookies, and service workers can make serving HTTP again unsafe or incomplete — repair HTTPS first, and treat reverting as a last resort, not a routine undo.

HTTP → HTTPS migration — cheat sheet

Redirect & mapping facts

Certificate facts

Signals to repoint

Mixed content & HSTS

GSC properties A Domain property aggregates every scheme/host variant automatically — recommended default. URL-prefix properties (http://example.com · http://www.example.com · https://example.com · https://www.example.com) are optional segmentation, not a universal requirement.

Force the 301 (server-side)

Do the protocol redirect in server/edge config, not app code. Test on staging first — a botched rule can create a redirect loop that locks everyone out.

Apache (.htaccess)

# 301 every HTTP request to the same path on HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Nginx

# Dedicated port-80 server block that 301s to HTTPS, preserving host + path
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Verify a URL returns a clean single-hop 301

Confirm each old URL 301s straight to its HTTPS twin — not a 302, not a chain.

macOS / Linux

# Show every hop and status code for one URL
curl -sIL http://example.com/some/page \
  | grep -Ei '^(HTTP/|location):'
# Want a single 301 -> https://example.com/some/page -> 200, no extra hops

Windows (PowerShell)

# Follow redirects and print each status + Location
$r = Invoke-WebRequest -Uri "http://example.com/some/page" -MaximumRedirection 10
$r.BaseResponse.ResponseUri.AbsoluteUri   # final URL should be https://

Find mixed content left in the HTML

Grep a rendered page for insecure sub-resources (scripts/styles/images/iframes).

macOS / Linux

curl -s https://example.com/ \
  | grep -Eo '(src|href)="http://[^"]+"' \
  | sort -u

Chrome DevTools Console — flag insecure sub-resources on the live page

Paste into the Console on any HTTPS page to list every element still pointing at http:// (skips ordinary anchor links, which aren’t mixed content):

[...document.querySelectorAll('[src],link[href],iframe[src]')]
  .map(el => el.src || el.href)
  .filter(u => u && u.startsWith('http://'))
  .forEach(u => console.warn('Insecure sub-resource:', u));

Batch-check a URL list after launch (single-hop 301s)

Feed your saved HTTP URL list in and flag anything that isn’t a clean one-hop 301.

macOS / Linux

# urls.txt = one http:// URL per line (from your pre-migration crawl)
while read -r u; do
  code=$(curl -s -o /dev/null -w '%{http_code}' -I "$u")
  loc=$(curl -sI "$u" | awk -F': ' 'tolower($1)=="location"{print $2}' | tr -d '\r')
  echo "$code  $u  ->  $loc"
done < urls.txt

For a whole-site sweep, a crawler (Ahrefs Site Audit, Screaming Frog) is faster than scripting URL by URL — but these snippets are handy for spot-checks and CI.

Audit the migration mapping before launch

Act as a technical SEO reviewing an HTTP-to-HTTPS migration. I will provide a crawl
of live HTTP URLs, the current redirect export, the proposed HTTPS URL list, and a
staging crawl.

For every old URL, determine whether it maps one-to-one to the same host, path, and
query on HTTPS. Flag redirect chains, loops, 302s, homepage dumps, missing targets,
HTTP canonicals, HTTP internal links, HTTP sitemap or hreflang entries, blockable
mixed content, and staging noindex/robots blocks.

Return a table with old URL, observed status, first target, final target, expected
target, issue, severity, owner, and retest. Separate launch blockers from normal
post-launch index settling. Do not recommend the Change of Address tool for this
protocol-only move.

Diagnose a post-launch decline

Compare the pre-launch crawl and Search Console exports with the post-launch crawl,
logs, Page Indexing, Crawl Stats, and URL Inspection samples. Test for blocked
crawling, surviving noindex, HTTP canonicals or internal links, redirect chains or
loops, 5xx responses, and mixed-content rendering failures. Explain which evidence
shows normal HTTP-to-HTTPS canonical crossover and which evidence shows a broken
migration. Give the smallest reversible fix and a validation query for each finding.

A protocol-only migration framework

Treat HTTP→HTTPS as four linked systems rather than a certificate installation:

1. Transport: HTTPS serves a valid certificate and complete chain on every required hostname.
2. Routing: Each HTTP URL returns one permanent, server-side redirect to its exact HTTPS twin. The 301 is the bridge that preserves URL meaning; Google says permanent redirects do not lose PageRank.
3. Signals: Canonicals, internal links, sitemaps, hreflang, and structured URL references all agree on HTTPS instead of making crawlers rediscover the move through redirects.
4. Observation: A saved baseline, post-launch crawl, logs, and Search Console distinguish an expected index crossover from a technical failure.

The protocol-only scope keeps risk low only when host, path, query behavior, content, and rendering stay equivalent. If those change at the same time, split the work into separate migrations so each failure has a diagnosable cause.

Migration verification tools

• Redirect Checker — inspect an individual HTTP URL’s full path and confirm it reaches the matching HTTPS URL in one hop.
• Bulk HTTP Status Code Checker — retest the saved pre-launch URL set for permanent redirects, broken targets, loops, and unexpected statuses.
• Canonicalization Checker — verify the final HTTPS page declares the intended HTTPS canonical rather than pointing back to HTTP.

Export results before and after launch. A tool result is most useful when it can be compared with the approved URL mapping instead of judged in isolation.

Migration release tests

Test 1: staging rehearsal

• Purpose: Prove content and signals are HTTPS-ready before redirects affect users or crawlers.
• Method: Crawl representative paths and templates on staging; inspect canonicals, internal links, hreflang, sitemaps, robots directives, and rendered resource URLs.
• Expected result: Pages render equivalently, emit HTTPS signals, contain no blockable mixed content, and carry no migration-only crawl or index block.
• Failure trigger: HTTP signals, blocked resources, certificate errors, or a surviving noindex/robots restriction.
• Next action: Hold the launch and correct the source template or configuration.

Test 2: one-to-one redirect replay

• Purpose: Confirm the production routing preserves every old URL’s destination.
• Method: Replay the saved HTTP URL crawl through the bulk status checker and compare first and final destinations with the approved mapping.
• Expected result: Each old URL returns one permanent redirect to its exact HTTPS twin, whose final response is healthy.
• Failure trigger: A chain, loop, 302, homepage dump, changed path/query, 4xx, or 5xx destination.
• Next action: Correct the source redirect rule; keep the HTTP listener available for rollback until the replay passes.

Test 3: post-launch search-signal check

• Purpose: Verify crawlers receive a consistent migration story.
• Method: Inspect key HTTPS URLs and monitor logs, Crawl Stats, and Page Indexing against the saved baseline.
• Expected result: HTTPS URLs are crawled and selected as canonical while HTTP URLs increasingly appear as redirected; response errors remain within the site’s established baseline.
• Failure trigger: Persistent HTTP canonicals, widespread blocked crawling, redirect loops, or a material 5xx increase.
• Next action: Apply the predefined reversible fix; do not enable HSTS until the HTTPS release is stable.

Resources worth your time

My speaking

• Better Safe Than Sorry with HTTPS — SMX East 2016 (SlideShare) — my deep-dive on TLS, the common HTTPS implementation failures, and the migration gotchas: 302-instead-of-301 mistakes, missing HTTPS canonicals, TLS SNI misconfigurations that can get you de-indexed by Bing/Baidu, and the referral-data (“dark traffic”) loss on HTTPS→HTTP links. (Standing disclaimer applies: it’s my understanding of these systems, and the adoption stats in it are from 2016.)

My related writing

• The Beginner’s Guide to Technical SEO — where migrations and HTTPS fit in the bigger picture.

From around the industry

• Google’s Site moves with URL changes — the canonical migration playbook (server-side 301s, one-hop redirects, keep redirects ≥1 year, no Change of Address tool for HTTP→HTTPS).
• Google’s Enable HTTPS on your servers and Fixing mixed content — the most useful concentrated implementation docs.
• Let’s Encrypt — free, automated DV certificates with built-in renewal; all you need for the ranking signal.
• SSL Labs Server Test — grade your TLS configuration once the cert is installed.
• hstspreload.org — check eligibility (and read the removal warnings) before you commit to preload.
• HSTS — What It Is and How to Use It (Kinsta) — practical HSTS guide covering the preload lock-in risk.
• HTTPS Is Easy (Troy Hunt) — short video series demystifying TLS setup from scratch.

Stats worth citing

• 301 redirects don’t lose PageRank. Google’s flat statement — the number that kills the “switching to HTTPS costs link equity” myth and defines the whole migration approach. Source
• Keep redirects at least 1 year. Google’s own recommended minimum — not a cutoff after which removal is safe; most sites keep them indefinitely. Source
• All HTTP pages marked “Not Secure” since Chrome 68 (July 2018). The deadline that turned HTTPS migration from optional to table stakes. Source
• ~89% of websites now use HTTPS. The migration is about not being the holdout, not about a ranking gain (W3Techs, 2026; confirm the current figure).
• Googlebot follows up to 10 hops in a redirect chain, but Google advises redirecting to the final destination directly — the ceiling behind the “no chains” rule. Source

Test yourself: HTTP to HTTPS Migration

Five quick questions on running an HTTP→HTTPS migration. Pick an answer for each, then check.

HTTP to HTTPS Migration

An HTTP to HTTPS migration is the process of moving every URL on a site from the insecure http:// scheme to the encrypted https:// scheme — installing a TLS certificate and 301-redirecting each old URL to its secure equivalent. Done correctly, it doesn't lose rankings or PageRank.

Related: HTTPS

HTTP to HTTPS Migration

An HTTP to HTTPS migration is a protocol-only site migration: the content, the paths, and the domain stay the same, but every URL switches from http:// to https://. You install a TLS certificate, redirect each old URL to its secure twin, and repoint every signal (canonicals, internal links, sitemaps, hreflang) at the HTTPS versions.

The reassuring part is that a clean protocol switch keeps your rankings. Google is explicit that “301 and other permanent redirects don’t cause a loss in PageRank,” and because you’re not changing the domain, you don’t need the Change of Address tool — that tool is only for domain-level moves.

The risk isn’t the switch itself; it’s the mistakes around it. The usual failures: missing or chained redirects, internal links left pointing at http://, mixed content (an HTTPS page loading an HTTP script or image) breaking pages on launch day, forgetting that Google Search Console treats http://, https://, http://www, and https://www as four separate properties, or removing the redirects too early — Google says keep them “as long as possible, generally at least 1 year.” A migration is carried by the 301s; canonicals, sitemaps, and re-verification just help the engines process it faster.

Related: HTTPS

Changelog