HTTP to HTTPS migration is the process of moving a website from serving content over unencrypted HTTP connections to serving it over encrypted HTTPS connections, implementing TLS encryption across the entire site, obtaining and installing SSL certificates, configuring permanent redirects from all HTTP URLs to their HTTPS equivalents, and updating all internal references to use the new HTTPS addresses.

The migration is a technical infrastructure change, the site’s content does not change, its domain does not change, and its URL paths do not change. What changes is the protocol prefix, every URL that was http://example.com/page becomes https://example.com/page. This single-character change, adding the S, requires coordinated changes across server configuration, SSL certificate provisioning, redirect configuration, internal linking, and canonical tag implementation to execute correctly without disrupting rankings or user experience.

HTTP to HTTPS migration has become one of the most universal technical SEO undertakings of the past decade. Google announced HTTPS as a ranking signal in 2014, a modest but real advantage for HTTPS sites over equivalent HTTP sites. More significantly modern browsers have progressively made HTTP less acceptable, Chrome labels all HTTP pages as Not Secure, a warning that significantly affects user trust and conversion rates. Let’s Encrypt made free SSL certificates available in 2016, removing the cost barrier that previously kept many smaller sites on HTTP. The combination of ranking incentives, browser pressure, and free certificate availability has made HTTPS adoption essentially universal for new sites and strongly advisable for any remaining HTTP sites.

Why HTTP to HTTPS migration matters for SEO

HTTP to HTTPS migration has specific SEO implications that make it more complex than a simple infrastructure change. Unlike a standard server configuration update the protocol change affects every URL on the site, and every URL on the web that links to the site.

SEO equity at risk: the most significant SEO challenge of HTTP to HTTPS migration. Every external backlink pointing to the site uses HTTP URLs, http://example.com/page. After migration the canonical URLs are HTTPS, https://example.com/page. The HTTP backlinks must pass their link juice through 301 redirects from the HTTP URLs to the HTTPS canonical URLs, a transfer that preserves most but not all equity. Incorrectly configured redirects, redirect chains, or missing redirects waste the equity accumulated through years of link building.

Duplicate content risk: if both HTTP and HTTPS versions of pages are simultaneously accessible without canonical signals both versions may be indexed, splitting equity between HTTP and HTTPS variants. Forced HTTPS redirects and HTTPS canonical tags must be implemented together to ensure only the HTTPS version is indexed.

Crawl budget impact: search engines must recrawl the entire site after migration to discover the HTTPS URLs and process the redirect signals from HTTP URLs. For large sites this recrawl takes time, during which HTTP URLs remain indexed while HTTPS URLs are being discovered. Monitoring crawl progress after migration confirms the transition is occurring as expected.

Ranking fluctuation: some temporary ranking fluctuation after HTTP to HTTPS migration is normal, Google’s systems process the protocol change and update their index. For well-executed migrations the fluctuation is minimal and short-lived. Significant or prolonged ranking drops indicate migration problems, missing redirects, incorrect canonical tags, or SSL configuration errors.

Pre-migration preparation

Thorough preparation before executing an HTTP to HTTPS migration minimises disruption and maximises equity preservation.

SSL certificate provisioning: obtaining SSL certificates that cover all domains and subdomains that will be migrated to HTTPS. A certificate covering example.com and www.example.com is the minimum. Subdomains that will serve HTTPS, blog.example.com, shop.example.com: need certificate coverage. A wildcard certificate for *.example.com covers all subdomains. Certificate provisioning must be completed before migration, HTTPS connections cannot be established without a valid certificate.

Complete URL inventory: crawling the site to identify every URL that will change from HTTP to HTTPS. The URL inventory serves two purposes, it identifies every URL that needs an HTTP-to-HTTPS redirect and every internal link that needs updating. For large sites this inventory may include tens of thousands or hundreds of thousands of URLs.

Internal link audit: identifying all internal links that use absolute HTTP URLs, links that explicitly specify http:// rather than using relative URLs or protocol-relative URLs. These links need updating to HTTPS after migration, internal HTTP links add unnecessary redirect hops to internal navigation. Tools like Screaming Frog export all internal link URLs, filtering for those starting with http:// identifies the update candidates.

Third-party resource audit: identifying all third-party resources loaded by the site, analytics scripts, advertising tags, embedded widgets, CDN-hosted assets, and verifying that each supports HTTPS. Third-party resources that are HTTP-only create mixed content warnings after migration, these must be replaced with HTTPS equivalents or removed before migration.

Database content audit: for sites with content management systems content stored in the database may contain absolute HTTP URLs, links to internal pages, image src attributes, embedded media URLs. Identifying database-stored HTTP URLs before migration enables bulk updates rather than post-migration discovery of mixed content issues.

Backlink profile documentation: documenting the current backlink profile through Ahrefs, Moz, or Semrush before migration establishes a baseline for monitoring equity transfer after migration. Post-migration comparisons against the baseline reveal whether backlink equity is transferring correctly.

Migration execution

With preparation complete the migration itself involves several coordinated changes that should be executed in a specific sequence.

Step 1, install SSL certificate and enable HTTPS: configure the web server with the SSL certificate and enable HTTPS access. At this stage the site should be accessible at both HTTP and HTTPS, both versions serving content. Test HTTPS access thoroughly, verifying the certificate is valid for all required domains, that no browser certificate warnings appear, and that all pages load correctly over HTTPS.

Step 2, fix mixed content issues: before implementing redirects resolve all mixed content issues, HTTP resources loaded on HTTPS pages. Browser developer tools identify mixed content warnings on any page. Fix by updating resource URLs to HTTPS equivalents, switching to CDN-hosted HTTPS versions, or removing HTTP-only resources. A clean HTTPS version with no mixed content warnings is the prerequisite for the next steps.

Step 3, update canonical tags to HTTPS: update all canonical tags throughout the site to reference HTTPS URLs. If canonical tags are generated dynamically by the CMS update the canonical generation logic to always output HTTPS URLs. If canonical tags are hardcoded in templates update each template. HTTPS canonical tags signal to search engines that the HTTPS version is the preferred canonical before the HTTP-to-HTTPS redirects are in place.

Step 4, implement HTTP to HTTPS redirects: configure 301 permanent redirects from all HTTP URLs to their HTTPS equivalents. The redirect rule should preserve the full URL path, http://example.com/path/page redirects to https://example.com/path/page: not just the homepage. Nginx configuration:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https

Apache.htaccess:

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

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

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

Step 5, update XML sitemaps: regenerate XML sitemaps to contain HTTPS URLs rather than HTTP URLs. Submit the updated HTTPS sitemaps through Google Search Console. Updated sitemaps guide Googlebot to crawl HTTPS URLs directly rather than discovering them through redirects from HTTP.

Step 6, verify redirect configuration: test HTTP-to-HTTPS redirects for all URL variants, root domain, www subdomain, deep page URLs, URLs with query parameters. Verify each redirects to the correct HTTPS equivalent in a single hop, no chains, no redirecting to the homepage instead of the specific page.

Post-migration tasks

Several important tasks must be completed after the migration to ensure complete transition and monitor for issues.

Update Google Search Console: add the HTTPS versions of all site properties to Google Search Console, both https://example.com and https://www.example.com. Google Search Console treats HTTP and HTTPS as separate properties, HTTPS properties provide separate crawl data, coverage reports, and performance data for the migrated HTTPS site.

Submit HTTPS sitemaps: submit HTTPS sitemaps to both Google Search Console and Bing Webmaster Tools. Sitemap submission signals the migrated URLs for crawl consideration, accelerating indexation of HTTPS URLs.

Update internal links: update all internal links throughout the site to use HTTPS URLs directly rather than HTTP URLs that redirect to HTTPS. Internal HTTP links that redirect to HTTPS create unnecessary redirect hops in internal navigation, wasting crawl budget and mildly diluting internal link juice flow. This update is lower priority than redirect configuration but important for long-term site health.

Update database content URLs: run database find-and-replace to update absolute HTTP URLs stored in the CMS database, post content, image URLs, embedded media, to HTTPS equivalents. This eliminates mixed content issues in stored content and removes redirect hops from internal content links.

Implement HSTS: after confirming the HTTPS migration is stable implement HSTS, starting with a short max-age and progressively increasing. HSTS eliminates the HTTP-to-HTTPS redirect cost for returning visitors and protects against SSL stripping attacks.

Notify external link sources: for the highest-value backlinks reaching out to the linking sites to update their links to HTTPS eliminates reliance on redirects for equity transfer from those specific links. Not all backlinks can be updated, most never will be, but high-value links from partners and frequently updated publications are worth the outreach effort.

Monitoring after migration

Intensive monitoring in the weeks following migration identifies problems before they cause lasting damage.

Index transition monitoring: tracking the proportion of HTTP versus HTTPS URLs in Google’s index through Search Console Coverage reports. A healthy migration shows HTTP URL indexation decreasing and HTTPS URL indexation increasing over weeks. Stalled transition, HTTP URLs persisting in the index long after migration, indicates redirect or canonical signal problems.

Ranking monitoring: tracking rankings for key queries through ranking tracking tools. Minor fluctuations during the first few weeks are normal. Significant drops that persist beyond two to four weeks indicate migration problems requiring investigation.

Traffic monitoring: monitoring organic traffic through Google Analytics or equivalent. Traffic should be attributed to HTTPS URLs in analytics after migration, HTTP traffic persisting in analytics data may indicate incomplete redirect coverage or analytics configuration issues.

Mixed content monitoring: crawling the HTTPS site after migration to identify remaining mixed content issues, HTTP resources loaded on HTTPS pages that were missed in the pre-migration audit. Browser developer tools and automated scanning tools identify mixed content across all pages.

Backlink equity transfer monitoring: comparing post-migration domain authority scores and backlink metrics against pre-migration baselines. Significant equity loss may indicate redirect problems, backlinks pointing to HTTP URLs not being transferred to HTTPS through correct 301 redirects.

Common HTTP to HTTPS migration mistakes

Redirecting only the homepage: configuring an HTTP-to-HTTPS redirect for the homepage but not for all other pages. Visitors who access deep pages over HTTP receive no redirect, they see HTTP pages while the homepage redirects. Every URL on the site must redirect from HTTP to HTTPS, not just the homepage.

Redirect chains: chaining HTTP-to-HTTPS redirects with other existing redirects, creating two-hop or three-hop chains. A URL that previously redirected from non-www to www and now also redirects from HTTP to HTTPS may create a chain, http://example.com redirects to http://www.example.com then redirects to https://www.example.com. Combine all redirect conditions into single-hop rules, http://example.com redirects directly to https://www.example.com in one hop.

Mixed content errors: failing to resolve all mixed content issues before or immediately after migration. Mixed content warnings in browsers signal to visitors that the HTTPS implementation is incomplete, damaging trust and potentially blocking active mixed content.

Not updating sitemaps: leaving XML sitemaps containing HTTP URLs after migration. Sitemaps should contain only canonical HTTPS URLs. HTTP URLs in sitemaps conflict with the HTTPS canonical signals and waste crawl budget.

Not updating Search Console: failing to add HTTPS properties to Google Search Console. Without HTTPS properties in Search Console there is no visibility into HTTPS crawl coverage, HTTPS indexation status, or HTTPS-specific performance data.

Premature HSTS with high max-age: implementing HSTS with a very long max-age immediately after migration. If HTTPS problems are discovered after HSTS is deployed browsers that received the HSTS header cannot access HTTP fallbacks. Start with short HSTS max-age and increase progressively.