HTTPS migration is a redirect job with hidden complexity:
Migrating a site from HTTP to HTTPS sounds straightforward. Install an SSL certificate, redirect HTTP URLs to their HTTPS equivalents, update internal links, done. The mechanical work is genuinely simple. The complications come from everywhere else: mixed content errors, broken third-party integrations, search engines that take weeks to update their understanding of the site, and the dozens of places URLs are referenced beyond the obvious ones.
For most sites in 2026, HTTPS is the default rather than a migration target. New sites launch on HTTPS from day one. Older sites mostly migrated years ago. The migration playbook still matters because remaining HTTP sites exist (legacy systems, internal tools that became public-facing, sites that never updated), and the same playbook applies to mid-migration cleanups where the original work was rushed or incomplete.
HTTPS is necessary for several reasons that go beyond SEO. Modern browsers display warnings on HTTP pages, sometimes blocking access to forms or sensitive features. Many modern web APIs (geolocation, service workers, payment processing) require HTTPS to function. Google has used HTTPS as a lightweight ranking signal since 2014, and the signal has grown stronger over time as Chrome and other browsers tightened their treatment of HTTP. A site still on HTTP in 2026 faces user-trust problems before SEO ever enters the picture.
The migration process breaks into discrete steps with ascending difficulty. The first steps are mechanical and low-risk. The middle steps require more attention to detail. The final steps reveal edge cases that only become visible after the main migration appears complete. Going through them in order matches the actual work.
Step 1: choose the right certificate type:
The SSL/TLS certificate is the foundation. Three certificate types exist, with different validation levels and use cases.
| Type | Validation | Use case |
|---|---|---|
| Domain Validated (DV) | Email or DNS confirmation of domain control | Standard sites, blogs, content sites, most use cases |
| Organization Validated (OV) | DV plus business identity verification | Corporate sites where the company name shown in the cert matters |
| Extended Validation (EV) | OV plus deeper business and legal verification | Financial institutions, government, sites where users specifically check for the green bar (mostly historical) |
For most sites in 2026, DV is the right choice. Browsers no longer visually differentiate EV from DV certificates (Chrome dropped the green address bar treatment in 2019), so the higher cost and longer setup of OV or EV rarely produces real benefit. EV remains relevant in narrow contexts where the verified company name needs to appear in certificate details for compliance reasons.
Free DV certificates are available through Let’s Encrypt, which has been operational since 2015 and is supported by virtually every modern hosting platform. Most managed hosting services (WordPress.com, Shopify, Cloudflare, Netlify) provide HTTPS automatically with no certificate procurement step. For sites running on traditional VPS hosting, Certbot automates Let’s Encrypt installation and renewal.
The single biggest practical decision is renewal automation. Let’s Encrypt certificates expire every 90 days. Manual renewal works but eventually fails when someone forgets. Automated renewal through Certbot’s systemd timer or ACME clients on managed platforms prevents the certificate expiration that takes the site down.
Step 2: install and verify the certificate:
Installing the certificate depends on the hosting platform. Three patterns cover most cases.
Managed hosting with built-in HTTPS. WordPress.com, Shopify, Squarespace, Wix, and similar platforms handle certificate installation through their interface. The user enables HTTPS in the admin panel, and the platform provisions and installs the certificate. No file manipulation involved.
Cloud platforms with one-click HTTPS. Cloudflare offers free HTTPS through its proxy, which terminates SSL at Cloudflare’s edge and passes traffic to the origin. Netlify, Vercel, AWS Amplify, and similar platforms include automatic HTTPS as part of the deployment pipeline. The user configures the domain, and HTTPS works.
Self-managed servers with Certbot. For sites running on traditional VPS hosting (DigitalOcean, Linode, AWS EC2, dedicated servers), Certbot automates Let’s Encrypt certificate acquisition and configures Apache or Nginx to use it. The setup involves running a few commands once, then trusting the renewal automation.
After installation, verify the certificate is working correctly using three checks. SSL Labs (ssllabs.com/ssltest) provides a comprehensive grade for the certificate setup, flagging weak cipher suites, protocol version issues, and certificate chain problems. The browser address bar shows the padlock icon and certificate details when clicked. The curl -I https://example.com command returns the HTTPS response and certificate chain information.
A common installation issue is the certificate chain. The intermediate certificates that link the site’s certificate to a trusted root authority need to be installed alongside the site certificate itself. Missing intermediates produce errors in some browsers while working in others, since browsers handle chain completion differently. SSL Labs flags missing intermediates as a major warning.
Step 3: redirect HTTP URLs to HTTPS:
Once HTTPS works, the next step is sending HTTP traffic to the HTTPS version. The standard tool is a 301 redirect at the server level, configured to send every HTTP request to the corresponding HTTPS URL.
In Apache via .htaccess:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]In Nginx via the server configuration:
server {
listen 80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}The redirect is permanent (301, not 302), since the move from HTTP to HTTPS is permanent. The status code matters because 302 leaves the original HTTP URLs in Google’s index, while 301 transfers signals to the HTTPS versions. The when-to-use-302 piece covers the redirect-type decision in more detail; for HTTPS migration, the answer is always 301.
After enabling the redirect, test that every HTTP URL on the site successfully redirects to its HTTPS equivalent. The test patterns:
http://example.comshould redirect tohttps://example.comhttp://example.com/pageshould redirect tohttps://example.com/pagehttp://www.example.com/pageshould redirect tohttps://www.example.com/page(or tohttps://example.com/pageif the site canonicalizes www)- Deep URLs with query parameters should redirect with parameters preserved
Each path that doesn’t redirect correctly is a potential SEO leak. Crawlers reaching HTTP URLs that don’t redirect properly may continue indexing the HTTP versions, splitting signals between HTTP and HTTPS for the same content.
Step 4: implement HSTS (HTTP Strict Transport Security):
HSTS is an HTTP response header that tells browsers to remember that the site uses HTTPS and to refuse HTTP connections in the future. Once a browser receives the HSTS header, it converts HTTP requests to HTTPS automatically before making the request.
The header:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadThree parameters:
max-age=31536000 specifies how long the browser remembers the HSTS policy (in seconds; 31536000 seconds is one year). Longer durations provide more protection but harder rollback if HTTPS breaks. Starting with shorter durations and increasing them as confidence builds is the safer pattern.
includeSubDomains applies the HSTS policy to all subdomains of the site. Use cautiously, since it locks every subdomain into HTTPS, including subdomains that may not yet support it.
preload opts the site into Chrome’s HSTS preload list, which ships with the browser and applies HSTS even before the user has visited the site. Submission goes through hstspreload.org and is hard to reverse (removal takes weeks to months to propagate through browser updates).
The order of operations matters. Enable HTTPS, verify everything works, run the site on HTTPS for some time without HSTS, then add HSTS with a short max-age, then increase the duration once stability is confirmed. HSTS with a long max-age locked in before HTTPS is fully reliable can break access to the site if the certificate expires or the HTTPS setup breaks.
HSTS also protects against downgrade attacks where an attacker intercepts the initial HTTP request and prevents the user from reaching the HTTPS redirect. Without HSTS, an attacker on the same network could keep the user on HTTP indefinitely. With HSTS in place, the browser refuses the HTTP connection regardless.
Step 5: update internal links to HTTPS:
Even with HTTP-to-HTTPS redirects in place, internal links should point directly to HTTPS URLs rather than relying on redirects. Three reasons matter.
Redirects add latency. Each HTTP-to-HTTPS redirect costs a round trip. For users clicking internal links, that’s a noticeable delay multiplied across every page transition.
Redirect chains create signal dilution. Although Google handles 301 redirects well, the cleanest signal goes directly to the destination URL. Internal links pointing at the canonical HTTPS URL provide that cleanest signal.
Mixed content errors. Internal links that hardcode HTTP URLs may produce mixed content warnings in browsers when rendered inside an HTTPS page, depending on how the link is constructed.
Updating internal links involves search-and-replace across the database (for CMS-driven sites), the codebase (for static sites or applications), and any link tables or metadata that store URLs. The pattern:
For WordPress, the wp-cli command:
wp search-replace 'http://example.com' 'https://example.com' --all-tables --skip-columns=guidThe --skip-columns=guid flag is important. The GUID column in WordPress stores feed identifiers that should not be updated even when URLs change.
For other databases, a similar SQL search-and-replace covers content stored as text:
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');Database backups before running any search-and-replace are non-negotiable. A typo in the replacement string can corrupt thousands of rows simultaneously, and rolling back without a backup is harder than running the replace correctly in the first place.
After the database update, the public site should serve HTTPS URLs in all internal links. Spot-checking pages with browser DevTools confirms no HTTP URLs remain in href attributes, src attributes, or inline scripts.
Step 6: hunt down mixed content:
Mixed content is the failure mode where an HTTPS page loads resources (images, scripts, stylesheets, iframes) over HTTP. Browsers handle mixed content with increasing strictness over time, blocking many types of mixed content outright and warning users about others.
Three types of mixed content:
Passive mixed content (images, audio, video). The browser may display these but mark the page as not fully secure, showing a broken-padlock indicator instead of the regular HTTPS lock. Visible warning, partial functionality.
Active mixed content (scripts, stylesheets, iframes). The browser blocks these entirely. Pages that depend on blocked active mixed content fail to render correctly. The console shows specific errors for each blocked resource.
Auto-upgraded mixed content. Some browsers auto-upgrade passive mixed content from HTTP to HTTPS, which works if the resource is available over HTTPS but fails silently if it isn’t.
The hunt for mixed content involves browser DevTools and a crawler.
Open DevTools on a representative page, switch to the Console tab, and look for mixed content warnings. Each warning identifies a specific resource and where it’s loaded from. The Issues tab in newer browsers consolidates these into a structured list.
Run a site crawler with mixed content detection enabled. Screaming Frog’s “Insecure Content” report lists every page where mixed content was detected, along with the specific resources causing the issue. Crawler-based detection scales to entire sites rather than checking pages individually.
The fixes are case-by-case. For images, scripts, or stylesheets hosted on the same domain, update the URLs from http:// to https:// (or to protocol-relative //, which lets the browser use whatever protocol the page is loaded over). For third-party resources, switch to HTTPS versions where available, or replace third-party resources that don’t support HTTPS with alternatives.
Hard-coded HTTP URLs in CMS post bodies, template files, and CSS files are the most common sources of mixed content after the database search-and-replace. Each one needs to be found and updated manually.
Step 7: update third-party integrations and external systems:
Beyond the site itself, several external systems reference the site’s URLs and need to be updated.
Google Search Console requires a new property for the HTTPS version. The HTTP version remains active in Search Console after the migration, showing the historical data. The HTTPS version becomes the new property where ongoing data lives. Both should be verified.
Google Analytics tracking continues to work after the migration if the tracking code was implemented through a tag manager or the standard GA4 snippet. Some older direct tracking code implementations (especially Universal Analytics carried over from before its July 2023 retirement) may need URL updates or full replacement. Verify after migration that pageviews are still being tracked correctly.
Sitemap files need updating. The XML sitemap should list HTTPS URLs, not HTTP URLs. After updating the sitemap, resubmit it through Search Console to ensure Google sees the new version.
robots.txt may reference the sitemap URL with HTTP. Update it:
Sitemap: https://example.com/sitemap.xmlSocial media profiles, business directories, and other places the site URL appears externally should be updated when feasible. The 301 redirect handles automatic transition, but the cleaner long-term state has external references pointing at the HTTPS URL directly.
Backlinks from other sites continue to work through the 301 redirect, which transfers link equity. No external action required from third parties, but it’s worth reaching out to high-value referrers to suggest they update their links directly.
Third-party scripts and integrations may need URL updates in their configurations. Analytics platforms, marketing automation tools, email service providers, and similar services often have URL fields that reference the site. Each one needs to be updated to the HTTPS version.
Step 8: monitor and recover during the transition:
After the migration, ranking position may fluctuate for several weeks as Google re-crawls and re-indexes the site at its HTTPS URLs. The pattern is normal but unnerving.
Search Console’s Page indexing report (formerly Coverage report) shows the indexing status of both HTTP and HTTPS URLs during the transition. Healthy migration produces a gradual shift: HTTP URLs decrease in indexed count while HTTPS URLs increase, eventually stabilizing with all valuable URLs indexed at HTTPS.
Crawl statistics show Googlebot’s activity. After migration, expect increased crawl activity as Google reads both HTTP redirects and HTTPS pages. The increase is temporary, lasting weeks to a couple of months, depending on site size and Google’s recrawl schedule.
Ranking positions often dip briefly during the first week or two after migration, then recover as the new URLs accumulate ranking signals. The dip isn’t universal and isn’t a sign of a botched migration; it’s the normal recalibration of an index update.
Specific recovery actions if rankings don’t return within a month:
Check the redirects. Every HTTP URL should still redirect cleanly to its HTTPS counterpart. Audit redirect chains for broken hops.
Check HSTS deployment. Premature HSTS with a long max-age can prevent recovery if any HTTPS configuration issue arose during migration.
Check Search Console for crawl errors. New HTTPS URLs producing 404s or other crawl failures indicate redirect issues or content gaps.
Check the sitemap. Confirm Google has processed the new HTTPS sitemap. Resubmit if necessary.
Most migrations recover fully within several weeks. Migrations that don’t recover usually have a specific issue (broken redirects, persistent mixed content, indexing exclusions) that diagnostic work surfaces.
Seven HTTPS migration anti-patterns:
Migrations that lose rankings usually lose them to the same set of mistakes. Each one is preventable with attention at the right step.
- 302 instead of 301 for HTTP-to-HTTPS redirect. The migration is permanent but the redirect signals temporary. Link signals don’t transfer cleanly. Fix: change to 301 immediately. The redirect type matters more for migration than almost any other context.
- Mixed content from hardcoded HTTP URLs. Images, scripts, or iframes load over HTTP even though the page is HTTPS. Browsers show warnings or block resources entirely. Fix: systematic database search-and-replace, plus manual cleanup of theme files and CSS.
- HSTS too aggressive before HTTPS stable. Long max-age locks the site into HTTPS before the implementation is reliable, breaking access if anything goes wrong. Fix: start with short max-age (300 seconds or less), increase gradually, only add preload after months of stable HTTPS.
- No Search Console property for HTTPS. The HTTPS version of the site isn’t registered, so post-migration data isn’t visible. Fix: add a new property for the HTTPS URL. Both HTTP and HTTPS should be verified during the transition period.
- Old sitemap with HTTP URLs. The submitted sitemap still references HTTP URLs even though the site is HTTPS. Fix: regenerate the sitemap with HTTPS URLs and resubmit through Search Console.
- Certificate without proper chain. Intermediate certificates are missing, causing some browsers to show errors. Fix: install the full certificate chain. SSL Labs flags this issue immediately.
- External resources still on HTTP. Third-party scripts, fonts, or APIs the site uses haven’t been updated to HTTPS sources. Fix: find HTTPS versions of every external resource. If no HTTPS version exists, replace the resource with an alternative.
An eighth pattern worth flagging: incomplete redirects for query parameters. The redirect rule preserves the path but drops query parameters, breaking URLs like ?utm_source=newsletter. Fix: redirect rules need to preserve the full original URL including query string and fragment.
The migration ladder, from mechanical to forensic:
The work of moving a site from HTTP to HTTPS climbs a ladder of difficulty. The first rungs are mechanical (the certificate, the redirect, the HSTS header). These are technical tasks with straightforward right answers. A site administrator with moderate experience can handle them in an afternoon.
The middle rungs require attention. Updating internal links across thousands of database rows. Hunting mixed content across hundreds of pages. Verifying every URL pattern still redirects correctly. This work isn’t difficult conceptually, but the volume of detail means small mistakes accumulate into noticeable problems. A migration that gets these rungs right looks clean from the outside. A migration that gets them wrong has visible cracks for weeks afterward.
The top rungs require persistence. Third-party integrations that need URL updates one platform at a time. Backlinks that should be refreshed where possible. Search Console properties that need to be set up correctly and monitored through the transition. Ranking dips that need to be diagnosed against the specific patterns of post-migration recovery. This work spreads over weeks and months, and many migrations stop short of finishing it. The site is technically on HTTPS, the migration is technically complete, but the long tail of cleanup never quite happens.
What distinguishes a clean migration from a typical one isn’t usually the technical steps. The certificate gets installed. The redirects work. HSTS gets enabled. The differentiator is the persistence to finish the cleanup work (mixed content all hunted down, every internal link updated, every third-party integration refreshed, every external system pointing at the HTTPS URLs directly). The work isn’t difficult. It’s just easy to leave half-done.
The sites that fully complete the migration end up at the cleanest possible HTTPS state: every URL canonical, every link direct, every signal pointing where it should. The sites that stop earlier end up at a working-but-imperfect state: the site loads on HTTPS, but accumulated cruft from the migration generates ongoing minor friction. Most sites in 2026 are in the imperfect state, and most never finish climbing the ladder. The technical part is done. The forensic part is still pending. That distinction is the difference between a migration that’s complete and a migration that’s just live.