HTTP to HTTPS Migration

The step-by-step HTTP→HTTPS migration playbook — pre-migration audit, certificate selection, staging tests, redirect mapping at scale, canonical/sitemap/hreflang updates, getting Search Console coverage right, monitoring windows, launch-day regressions, and a rollback plan.

First published: Jul 3, 2026 · Last updated: Jul 26, 2026 · Advanced
AIAuthored byAI v2
1 evidence signal on this page

An HTTP→HTTPS migration is a protocol-only site migration: same host, paths, query strings, content and platform — only the scheme moves from http:// to https://. Because nothing else changes, 301s carry all the weight (301s don't lose PageRank) and you don't need the Change of Address tool. The order that keeps traffic: benchmark the live HTTP site, pick 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 the whole thing on staging, then flip — 301 every URL one-to-one server-side, make HTTPS self-canonical, repoint every internal link/sitemap/hreflang, and fix blockable mixed content before it breaks your scripts on launch day. Afterward, add a Domain property in Search Console (it covers every protocol/host variant automatically) or verify the HTTPS properties individually if you want segmented data, submit the HTTPS sitemap, keep redirects at least a year, and monitor Crawl Stats + indexing for a dip that sticks (broken) versus a dip that recovers (settling). Have a rollback plan — but repair HTTPS first, since caching, cookies and service workers can make a true HTTP rollback unsafe — and treat HSTS preload as slow and risky to reverse, not a one-way door.

TL;DR — An HTTP→HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' move is a protocol-only site migrationA site migration is any significant change to a website's URL structure, domain, platform, protocol, or hosting that can affect how search engines crawl, index, and rank it. The risk scales with how much you change at once.: same host, paths, query stringsThe `?key=value` data tacked onto the end of a URL after a question mark — used for tracking, sessions, filtering, sorting, and search — and one of the biggest sources of duplicate URLs and wasted crawling in SEO., 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 certificateAn SSL/TLS certificate is the file a server presents during the TLS handshake to prove who controls the domain (to a level that depends on the validation type) and to supply the public key that encrypts the connection. It's what makes https:// possible — but Google's ranking signal only checks the URL scheme, not which certificate issued it. (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 PageRankPageRank is Google's original recursive link-graph algorithm: a page's score depends on the scores of the pages linking to it, and in the published model each page's score is split across its outbound links (the simplified version: links are weighted votes). Google says it's evolved since launch but still part of its core ranking systems.), make each page self-canonical to its HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' URL, repoint every internal link, sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. entry, and hreflangHreflang is an annotation (in HTML, HTTP headers, or XML sitemaps) that tells search engines which language and optional region a page targets, and which alternate versions exist. It only works when every page in the cluster references all the others. annotation, and kill blockable mixed contentMixed content is when a page served over HTTPS loads a sub-resource — a script, stylesheet, image, iframe, or similar — over insecure HTTP. Browsers' current taxonomy is upgradable versus blockable; active mixed content (scripts, styles, iframes) is blocked, and passive mixed content (images, audio, video) is warned about or increasingly auto-upgraded, with exceptions like CORS-enabled images and srcset/picture candidates that are blockable, not upgradable. before it breaks your scripts. Add a Domain property in Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. (it covers every scheme/host variant at once) or verify the HTTPS properties individually if you want segmented data, submit the HTTPS sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing., and don’t touch the Change of Address toolA setting in Google Search Console that tells Google you've moved your whole site to a new domain or subdomain. It's a supporting signal for a domain migration — the 301 redirects do the real work of transferring rankings. — it’s for domain moves. Keep redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. at least a year (that’s a floor, not an expiration date). Monitor Crawl Stats and indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.: a dip that recovers is the move settling; a dip that sticks means something broke. Have a rollback plan, but repair HTTPS first — caching, HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open., 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: 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: Google: HTTPS

Site migrationsA site migration is any significant change to a website's URL structure, domain, platform, protocol, or hosting that can affect how search engines crawl, index, and rank it. The risk scales with how much you change at once. exist on a spectrum of danger. Changing your domain, your URL structureURL structure is how the parts of a web address — scheme, domain, path, query string, and fragment — are organized and formatted. It mostly affects crawling, usability, and how engines understand a page, not rankings directly., or your CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms./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/renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. 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 ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance.) 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 migrationA site migration is any significant change to a website's URL structure, domain, platform, protocol, or hosting that can affect how search engines crawl, index, and rank it. The risk scales with how much you change at once. 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 reportThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason., 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 tagA rel=\"canonical\" annotation — in the HTML <head> or an HTTP Link header — that tells search engines which URL is the preferred version of duplicate or near-duplicate content. 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: 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 certificatesAn SSL/TLS certificate is the file a server presents during the TLS handshake to prove who controls the domain (to a level that depends on the validation type) and to supply the public key that encrypts the connection. It's what makes https:// possible — but Google's ranking signal only checks the URL scheme, not which certificate issued it. 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 loopA redirect loop is a chain of redirects that circles back on itself instead of ever reaching a live page — URL A redirects to B and B redirects back to A (or a longer cycle). No page ever returns a 200, so browsers show ERR_TOO_MANY_REDIRECTS and crawlers can't index anything. (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

TIP Reject any redirect that falls back from HTTPS to HTTP

This trace exposes a secure URL whose chain ends on HTTP. It verifies the observed route, not whether every URL in the migration is mapped.

Run representative old URLs through my Redirect Checker to confirm a single permanent hop to the matching HTTPS destination. Redirect Checker Free

  1. Test old HTTP URLs from every major template and path pattern.
  2. Require a direct 301 or 308 to the corresponding HTTPS URL, never an HTTP final destination.
  3. Crawl the complete old-URL inventory after launch rather than extrapolating from spot checks.
A redirect can exist and still point in the wrong protocol direction.

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 chainsA → B → C instead of A → C. Each hop loses link equity and adds latency.. 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 canonicalizationHow search engines pick one canonical URL among duplicates and consolidate signals onto it. topic warns about — align every signal on the HTTPS URL.)
  • Internal linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them.. 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 sitemapsAn XML sitemap is a UTF-8 file listing the canonical URLs on your site (with optional lastmod) so search engines can discover and prioritize them. It's a discovery and diagnostic aid, not a guarantee of indexing — and Google ignores its priority and changefreq tags.. Regenerate them with the HTTPS URLs only, listing canonical, indexable pages, and update lastmod. Submit the new sitemap in GSC after launch.
  • HreflangHreflang is an annotation (in HTML, HTTP headers, or XML sitemaps) that tells search engines which language and optional region a page targets, and which alternate versions exist. It only works when every page in the cluster references all the others.. 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 SEOInternational SEO is the practice of optimizing a site so search engines understand which countries and/or languages it targets, and serve the right version to each user. It spans URL structure, hreflang, and on-page localization. bug.
  • Structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. and Open GraphOpen Graph (OG) tags are `<meta>` elements in a page's head, defined by the Open Graph protocol (ogp.me, created by Facebook), that describe a page as a shareable object — its title, description, image, URL, and type. They control how a link preview card looks when the page is shared on Facebook, LinkedIn, Slack, Discord, WhatsApp, and iMessage. They are not a direct Google ranking factor, though Google reads og:title, og:image, and og:site_name as inputs to how a result appears. URLs. og:url, canonical references inside JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal., and any hardcoded absolute URLs should all be HTTPS.

Step 6 — Kill mixed content before launch, not after

TIP Find insecure subresources on the new HTTPS pages

The result confirms an HTTP subresource in fetched source. It does not prove that one sampled page represents the whole migrated site.

Use my Website Safety Checker for launch spot checks, then crawl the full HTTPS inventory for mixed resources at scale. Website Safety Checker Free

  1. Check representative pages for insecure scripts, styles, iframes, images, and media.
  2. Fix source URLs and confirm the HTTPS resource exists instead of relying only on browser upgrades.
  3. Repeat the crawl after launch and monitor CSP reports for conditional third-party resources.
Mixed-content spot checks need a full-site crawl behind them.

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, iframesHTML element that displays one webpage inside another — how embeds work., 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 crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. 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 reportA Google Search Console report showing how many of your indexed URLs are served over HTTPS vs HTTP — and, for the HTTP ones, why the secure version isn't being used. It's a diagnostic sample, not a full crawl inventory. 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 diveA Google Search Console report showing how many of your indexed URLs are served over HTTPS vs HTTP — and, for the HTTP ones, why the secure version isn't being used. It's a diagnostic sample, not a full crawl inventory. 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 GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. 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 redirectA Google Search Console Page Indexing status for a URL that redirects elsewhere. It's not indexed by design because it's a redirect — the destination is a separate question, and Google says the target may or may not end up indexed — usually expected, not an error (unlike the separate \"Redirect error\")..” 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 crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. 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.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.