How to migrate from HTTP to HTTPS without losing rankings

Load a still-on-HTTP site in a current browser and the first thing you see is not your content. It is the browser’s “Not secure” label next to the address, and on some pages a full interstitial before a form will submit. That warning is the real starting gun for an HTTPS migration. The mechanical core is genuinely simple: install a certificate, redirect HTTP URLs to their HTTPS equivalents, update internal links. The complications live everywhere else (mixed content, third-party integrations that reference old URLs, search engines that take weeks to update their picture of the site), and that is where migrations lose rankings.

Done correctly, an HTTP-to-HTTPS move causes no permanent ranking loss; Google’s own guidance frames temporary fluctuation during recrawl as normal, not as a sign of a botched job. The rest of this guide walks the steps in the order the work actually happens, from the mechanical first rungs to the forensic cleanup that most sites leave half-finished.

Why HTTPS still matters in 2026 #

For most sites today, HTTPS is the default rather than a target, so the playbook exists for the holdouts (legacy systems, internal tools that became public-facing, sites that never updated) and for cleaning up a migration that was rushed the first time. The reasons to be on HTTPS go well past SEO. Browsers warn on HTTP pages and sometimes block form submission. Modern web APIs (geolocation, service workers, payment flows) require a secure context to run at all. HTTP/2, which improves load performance through multiplexing, is served over TLS by every major browser, so HTTP-only sites forgo that too. And Google has used HTTPS as a ranking signal since its August 2014 announcement, which described the signal as lightweight and evaluated at the URL level, noting it might strengthen over time. Treat HTTPS as a user-trust and functionality baseline first; the ranking effect is real but modest.

Certificate, redirect, and HSTS: the mechanical rungs #

Choose and verify the certificate. Three validation levels exist: Domain Validated (DV) confirms control of the domain, Organization Validated (OV) adds business-identity checks, and Extended Validation (EV) adds deeper legal verification. For nearly every site, DV is correct; Chrome dropped the special EV green-bar treatment in 2018, so browsers no longer visually distinguish the two and the extra cost rarely returns anything outside narrow compliance cases. Free DV certificates come from Let’s Encrypt, operational since 2015 and supported by essentially every hosting platform. Managed hosts (WordPress.com, Shopify, Cloudflare, Netlify) provision HTTPS automatically; on a traditional VPS, Certbot automates issuance and renewal. That renewal automation is the decision that bites: Let’s Encrypt certificates are valid for 90 days (and the project has announced plans to shorten that further), so manual renewal eventually fails when someone forgets. After installation, confirm the certificate with SSL Labs (ssllabs.com), the browser padlock’s certificate details, and curl -I against the HTTPS URL. The most common defect is a missing intermediate certificate: some browsers complete the chain on their own and others do not, so the same site looks fine in one and broken in another. SSL Labs flags this immediately.

Redirect HTTP to HTTPS with a 301. Once HTTPS serves correctly, send every HTTP request to its HTTPS counterpart with a server-level permanent redirect. In Apache .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

In Nginx:

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

The status code has to be 301, not 302. The move is permanent, and Google’s redirect guidance states that permanent redirects (301 and 308) pass PageRank while a temporary 302 leaves the original HTTP URLs eligible to stay canonical in the index. A 302 here splits signals between the HTTP and HTTPS versions of the same content. After enabling the rule, test the full set of patterns: apex, www, deep paths, and URLs carrying query strings. A redirect rule that preserves the path but drops ?utm_source=newsletter breaks tracked URLs, so confirm the query string and fragment survive.

Add HSTS, in the right order. The Strict-Transport-Security header tells browsers to convert HTTP requests to HTTPS on their own and to refuse plain HTTP, which also closes downgrade attacks where an attacker on the same network keeps a user on HTTP. A representative header:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

max-age is the retention period in seconds (31536000 is one year). includeSubDomains extends the policy to every subdomain, which is powerful and dangerous since it locks in subdomains that may not yet serve HTTPS. preload opts into the browser preload list submitted at hstspreload.org, which enforces HTTPS even on a first visit; that list requires max-age of at least one year plus includeSubDomains, and removal takes weeks to months to propagate. So sequence matters: enable HTTPS, run it stably, add HSTS with a short max-age, raise the duration as confidence grows, and only add preload after months of reliable HTTPS. A long max-age locked in before HTTPS is solid can make the site unreachable if the certificate lapses.

Update internal links and hunt mixed content #

Even with redirects live, internal links should point straight at HTTPS URLs: redirects add a round trip of latency on every click, the cleanest ranking signal goes directly to the destination rather than through a hop, and hardcoded HTTP links can trigger mixed content warnings inside an HTTPS page. Updating them means a search-and-replace across wherever URLs are stored. For WordPress:

wp search-replace 'http://example.com' 'https://example.com' --all-tables --skip-columns=guid

The --skip-columns=guid flag matters because WordPress uses the GUID column as a feed identifier that should stay fixed even after URLs change. For other databases, a scoped SQL replace covers text content:

UPDATE posts SET post_content = REPLACE(post_content, 'http://example.com', 'https://example.com');
UPDATE postmeta SET meta_value = REPLACE(meta_value, 'http://example.com', 'https://example.com');

Back up the database before any replace; a typo in the replacement string can corrupt thousands of rows at once, and recovery without a backup is far worse than getting the replace right.

Mixed content is the next hunt. It comes in three forms. Passive mixed content (images, audio, video) may still display but marks the page as not fully secure. Active mixed content (scripts, stylesheets, iframes) is blocked outright, so pages depending on it fail to render. Some browsers auto-upgrade passive resources to HTTPS, which works when an HTTPS version exists and fails silently when it does not. Find it two ways: open DevTools on representative pages and read the Console and Issues tabs, which name each offending resource, then run a crawler with insecure-content detection (Screaming Frog’s report lists every affected page and resource) to scale past manual spot checks. Fixes are case by case: rewrite same-domain URLs to HTTPS, switch third-party resources to their HTTPS versions, or replace resources with no HTTPS option. Hardcoded HTTP URLs in post bodies, theme templates, and CSS files are the usual survivors after the database replace, and each needs a manual edit.

Update external systems and monitor the transition #

Several systems outside the site reference its URLs. Google Search Console needs a new property for the HTTPS version; verify both, since the HTTP property retains historical data while HTTPS becomes the live one. Google’s site-move guidance is to verify each property separately. The XML sitemap should list HTTPS URLs and be resubmitted, and robots.txt should point at the HTTPS sitemap:

Sitemap: https://example.com/sitemap.xml

Confirm analytics still records pageviews (most GA4 and tag-manager setups carry over untouched), and update URL fields in third-party tools (marketing automation, email platforms, embedded scripts) one at a time. Backlinks keep working through the 301, which forwards link equity, so no third-party action is strictly required, though refreshing high-value referrers to the direct HTTPS URL is worth the effort.

Then monitor. Ranking positions often dip for a week or two and recover as HTTPS URLs accumulate signals; Google describes this fluctuation during recrawl and reindex as expected, with a medium site typically taking a few weeks to settle. In Search Console, the Page indexing report should show HTTP URLs falling as HTTPS URLs rise, and crawl stats a temporary spike as Googlebot reads both redirects and new pages. If rankings have not returned within a month, work the checklist: audit that every HTTP URL still redirects cleanly with no broken chains, check that a premature long-max-age HSTS is not masking an HTTPS fault, look for new HTTPS URLs returning 404s, and confirm Google has processed the new sitemap. Migrations that fail to recover almost always have a specific fault (broken redirects, persistent mixed content, indexing exclusions) that diagnostics surface.

Frequently asked questions #

Will I lose rankings by moving to HTTPS? Not permanently, if the migration is done correctly. A brief dip during recrawl is normal, and a 301 forwards ranking signals. Lasting loss traces to a specific error, most often a 302 instead of a 301 or unresolved mixed content.

Do I have to use the Change of Address tool? No. That Search Console tool is for domain changes. An HTTP-to-HTTPS move on the same domain does not use it; you add and verify the HTTPS property and let the 301s do the work.

How long until rankings stabilize? Google indicates a medium-sized site usually takes a few weeks for most pages to settle in the index, and larger sites can take longer. If nothing has recovered after roughly a month, treat it as a fault to diagnose rather than more waiting.

Is HSTS required for the SEO benefit? No. The ranking signal attaches to serving HTTPS and redirecting correctly. HSTS is a security hardening layer; add it after HTTPS is stable, not as a prerequisite for rankings.

The migration climbs a ladder from mechanical to forensic. The bottom rungs (certificate, redirect, HSTS) have clear right answers a moderately experienced administrator can finish in an afternoon. The middle rungs (thousands of internal links, hundreds of pages checked for mixed content, every URL pattern verified) are not hard conceptually, but the volume of detail is where small mistakes accumulate into visible cracks. The top rungs (third-party integrations updated one platform at a time, Search Console monitored through the transition) spread over weeks, and this is where most migrations stop short. What separates a clean migration from a typical one is rarely the technical steps, which almost always get done; it is the persistence to finish the cleanup so that every URL is canonical, every link is direct, and every signal points where it should. The practical priority, then, is to schedule that forensic pass rather than call the migration complete the moment the site loads on HTTPS.