How Do You Migrate From HTTP to HTTPS and Fix Mixed Content Errors?

Four steps take a website from unencrypted HTTP to encrypted HTTPS, and together they’re what people mean by an HTTP to HTTPS migration. Install a TLS certificate, 301-redirect every HTTP URL to its HTTPS version, update links and resources so nothing loads over HTTP (the cause of mixed content errors), and turn on HTTP Strict Transport Security (HSTS) so browsers never fall back to the insecure version.

Today HTTPS is the default, not a nice-to-have. Google reports that about 95% of navigations in Chrome now use HTTPS, and with Chrome 154 in October 2026, Chrome turns on “Always Use Secure Connections” by default, asking users for permission before loading any public site that doesn’t support HTTPS. A site still on HTTP looks outdated, and now it greets new visitors with a warning.

This post first ran in 2017, and we’ve updated it while keeping the original guidance, which still holds. We like to keep our clients at Daylight in the know on trends in web development. In March 2017, Alex wrote about changes coming to Google Chrome that make users more aware of insecure sites through labels. This post is the follow-up deep dive: why more and more sites moved to HTTPS for confidentiality, integrity and authenticity, the basics of how HTTPS works, the issues of cost, complexity, compatibility and confidence, and simple solutions using services like Let’s Encrypt along with Certbot, Content Security Policies and HTTP Strict Transport Security.

How has HTTPS adoption changed since 2017?

When we first wrote this post in 2017, these were the trends pushing sites to HTTPS:

• The average daily volume of encrypted internet traffic had just surpassed the average daily volume of unencrypted traffic (Wired 1/30/17).
• Over 30% of the world’s top 1,000,000 sites were using HTTPS (Scott Helme 8/17).
• Major browsers were demonstrating their commitment to a more secure web through labels and warnings that educate users on a site’s safety.
• Google had begun factoring page load speed into its ranking algorithm. HTTP/2 makes for a faster web but is only served by browsers over an HTTPS connection, which actually makes encrypted sites faster than unencrypted ones.

Every one of those trends has since played out:

• Chrome labels HTTP pages “Not secure.” Starting with Chrome 68 in July 2018, Chrome marks every HTTP page as “Not secure” in the address bar, whether or not the page has a form.
• HTTPS is the norm. Google now reports roughly 95% of Chrome navigations happen over HTTPS, and Chrome 154 warns before loading public HTTP sites by default.
• Free certificates are standard. Let’s Encrypt and automatic certificate renewal are built into most hosting platforms, so cost is rarely a barrier anymore.
• Faster protocols still require encryption. Browsers only use HTTP/2, and its successor HTTP/3, over encrypted connections.

Why migrate to HTTPS?

The simplest reason to move your site to HTTPS is man-in-the-middle attacks.

A man-in-the-middle (MitM) attack occurs when someone intercepts your internet traffic. These attacks can happen at a variety of insertion points and are often malicious. One of the more common places is public wifi, between the router and your browser (think coffee shops, hotel lobbies, airports and Airbnbs). A wifi router isn’t the only insertion point, though. Web traffic can also be intercepted between the router and an internet service provider (ISP), or between an ISP and a web server. There are a lot of ways internet traffic can be intercepted, and that’s a big reason the internet needs to move to a more secure protocol.

Communication served over HTTP is not encrypted. If someone intercepts it through a MitM attack, they can see all the communication between your browser and the site you’re visiting, and can even change the information going to your browser.

The move to HTTPS is about doing more to ensure confidentiality, integrity and authenticity in your web experience.

Confidentiality

When you use the web to access your bank accounts, email and social media, you expect privacy. You assume your communication with the page or app is understandable only to your browser and the server providing the service, especially on sites where you enter a lot of personal details, and that to an outside observer it would look like gobbledygook. A page served over HTTP doesn’t provide this. Anything served over HTTP can be viewed by other people if your connection suffers a MitM attack.

A good example occurred back in 2010, when Facebook wasn’t served over HTTPS and people were intercepting others’ Facebook traffic on Starbucks wifi. A developer made a Firefox extension called Firesheep that let anyone, technical or not, hijack a user’s session cookie and access their Facebook or Twitter account as if they were logged in as that user.

Integrity

Integrity means a user’s interactions on a site do only what they expect and what they’ve approved in the terms of service and cookie policy. When you click an edit button, you expect it to edit something you’ve posted. When you click submit, you expect it to send the data you just entered to that company’s database, and only that.

If a connection to a site communicating over HTTP is compromised by a MitM attack, the site can lose its integrity. The submit button may still post your order to the company database, but it may also install malware on your system or add malicious cookies that track the sites you visit and your personal details.

Authenticity

Authenticity is different from confidentiality. It means your browser is in fact communicating with the website you think it is, not a spoof. When you fill out a form and click submit, you expect the information to go to the company whose page you’re on. If your communication is compromised, attackers can intercept it and route it elsewhere.

Here’s how that could work. Say a bank’s login page is served over HTTP before routing you to an HTTPS site once you’re logged in. Someone who hijacks your connection could prompt you to re-enter personal details on a page that looks very similar to the bank’s, then use those details to access your account on their own.

How does HTTPS work?

“By HTTPS we mean HTTP over SSL, and by SSL we mean TLS” – Etsy

When a browser (the client) visits a site (the server) over HTTPS, the first thing that happens is a TLS handshake. TLS stands for Transport Layer Security, which improved on Secure Sockets Layer (SSL), developed in the 1990s. Both are cryptographic protocols, and when people say “SSL” today they almost always mean TLS. SSL itself is long retired, and current sites should support TLS 1.2 and TLS 1.3.

Back to the handshake. First, the client and server agree on how they’ll communicate securely (the highest TLS version both support, cipher suites and so on). The server responds to the client’s initial request with its preferences and its certificate, including its public key, which the browser checks against its list of trusted certificate authorities to confirm the server really is who it claims to be. Once that checks out, the client and server perform a key exchange and start communicating with encrypted traffic.

What are the common issues when upgrading to HTTPS?

The dangers of MitM attacks make it seem like everything should be served over HTTPS. The risks are too great. So why did companies hesitate to adopt the standard? In 2017, it came down to four issues: cost, complexity, compatibility and confidence.

Cost

A perceived limitation was the cost of acquiring certificates from a certificate authority (CA) and renewing them. That could get expensive for large sites that need many certificates, which is why early on it was mostly companies in the financial sector, who needed the security and could afford it, that used HTTPS. As more of the web moved to HTTPS, the cost of certificates dropped substantially, and free options for acquiring and renewing certificates, like Let’s Encrypt, sprang up. Today, free certificates are the default on most hosts.

Complexity

Closely related to cost was complexity. Enabling HTTPS meant figuring out how to obtain the certificate, making sure it was in the right format for your server, converting it if necessary and configuring the server. All of that had to be repeated with each renewal, and time equals money. Automation has since removed most of this work, as long as someone confirms the automation keeps running.

Compatibility

When you move a site originally written for HTTP to HTTPS, the way you reference resources such as images, CDNs, scripts, embedded videos and advertisements will often trigger a mixed content warning, because the content is still referenced over HTTP and the browser knows that’s insecure. This is still the most common migration problem today.

Confidence

Finally, there’s confidence. Will your efforts actually prevent man-in-the-middle attacks? Are there still weaknesses that give someone with intent the opportunity to spoof, snoop or inject malware?

How do you solve cost and complexity? Let’s Encrypt and Certbot

If cost and complexity are what’s holding you back, a few services make the move much less painful.

The first question to ask is, “Do you have shell access to the hosting environment you need the certificate on?” If so, Let’s Encrypt and Certbot are for you.

Let’s Encrypt is a free, automated and open certificate authority run for the public’s benefit by the Internet Security Research Group and sponsored by many major tech companies. It offers a way to get digital certificates for free. By 2017, Let’s Encrypt had issued over 100 million certificates and was on its way to passing Comodo as the top provider of digital certificates. It has since become one of the most widely used certificate authorities on the web.

Free is great. Automation is even better.

Certbot is an Automated Certificate Management Environment (ACME) client from the Electronic Frontier Foundation (EFF). It runs on your server and communicates with Let’s Encrypt to validate that you control the domain, then automates acquiring, installing and renewing certificates. That matters because Let’s Encrypt certificates are short-lived. In 2017 they were valid for three months, and Let’s Encrypt is now cutting certificate lifetimes to 45 days. An opt-in 45-day profile arrived in May 2026, the default drops to 64 days in February 2027 and to 45 days in February 2028. With automatic renewal, the duration of the certificate isn’t as relevant, but hard-coded renewal schedules (such as every 60 days) will need updating.

But what if you don’t have shell access?

Many hosting services support Let’s Encrypt, including WordPress.com, Squarespace, Wix and DreamHost, and many managed hosts now issue and renew certificates automatically. Let’s Encrypt’s community keeps a list of hosting providers that support Let’s Encrypt. With these providers, adding a certificate is usually a setting in the hosting dashboard.

What are mixed content errors, and how do you fix them?

Mixed content happens when a page loaded over HTTPS pulls in images, scripts, stylesheets, fonts, iframes or videos over HTTP. Browsers treat it in two ways:

• Active mixed content (scripts, stylesheets, iframes, fetch requests) can change the whole page, so modern browsers block it. The result is broken layouts, forms or features.
• Passive mixed content (images, audio, video) is now usually upgraded to HTTPS automatically. If the resource isn’t available over HTTPS, it fails to load and leaves a gap on the page.

To find mixed content, open your browser’s developer tools and check the Console for “Mixed Content” messages, or use the Security panel in Chrome DevTools. On larger sites, a crawler that flags HTTP resources on HTTPS pages saves time. MDN’s guide to mixed content explains exactly what each browser blocks.

Step 1: Change resource paths

We recommend a layered approach for fixing mixed content, such as images or videos referenced in the HTML over HTTP when you’re trying to serve the site securely.

First, go through all of your URLs and change them to relative paths if they’re internal links, or to HTTPS paths if they point to outside resources like a YouTube video or an Amazon S3 bucket. This is the safest approach, but it can take the most time to double-check, especially on a large site. In a CMS, many of these URLs live in the database rather than in templates, so a careful database search and replace (WordPress users can run wp search-replace with WP-CLI, after a backup) is often the fastest fix. Don’t forget hard-coded URLs in CSS and JavaScript files, theme settings and the CMS’s own site address.

The common wisdom used to be moving cross-origin resources (resources not on your domain) to protocol-relative paths like //www.youtube.com, to avoid pulling content in over HTTP on an HTTPS site. There are a few reasons this is no longer recommended.

The first is speed. If you haven’t locked down all your redirects and someone visits your site over HTTP in an old browser that doesn’t support Content Security Policies, protocol-relative resources load over the protocol of the page they’re on, which in this case is HTTP. Since HTTP/2 (the faster protocol that allows for concurrency) only works over HTTPS, the site will load more slowly for that user. If you’re curious how much of a difference HTTP/2 can make, check out httpvshttps.

The other reason is security. Every time we can load a resource over HTTPS, we should, because it reinforces the confidentiality, integrity and authenticity of users’ web experience. Mixed content warnings are a one-way street: they only appear on HTTPS pages, not the other way around.

Step 2: Add a Content Security Policy

Next, add a Content Security Policy as a meta tag in your headers like this:

<meta http-equiv=”Content-Security-Policy” content=”upgrade-insecure-requests”>

If you copy the tag, use straight quotes. Here’s the same line ready to paste, along with the equivalent HTTP response header, which you can set on the server instead:

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

Content-Security-Policy: upgrade-insecure-requests

This instructs the browser to fetch resources securely if you still have insecure (HTTP) links to outside resources on your site. In practice, links you haven’t updated won’t cost you the secure padlock (Chrome has since replaced the padlock with a neutral icon, but the secure status is the same), and you won’t have empty areas on your site, as long as those resources are available over HTTPS.

In 2017, you still needed step one because Content Security Policies were only supported in newer browsers, and anyone on an older or non-compliant browser would see a broken padlock and lots of security warnings. Every current browser now supports upgrade-insecure-requests, but step one still matters: the policy can’t fix a resource that isn’t available over HTTPS, and clean source URLs are easier to maintain.

How do you build confidence? HSTS and HSTS preload

When you migrate a site from HTTP to HTTPS, the first thing you’ll do is set a permanent (301) redirect from http://www.yourcompany.com to https://www.yourcompany.com. In 2017, every browser defaulted to the insecure protocol when someone typed www.yourcompany.com into the address bar. Chrome now tries HTTPS first in many cases, but not every browser or link does, so the redirect is still essential. On Nginx, for example, it looks like this:

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

Unfortunately, a redirect alone still leaves your site open to a MitM attack. The response header of a 301 redirect contains the location it points to, and someone could intercept the redirect and send a visitor to a spoofed site. The protection is HTTP Strict Transport Security (HSTS). Once a browser sees the HSTS response header, it won’t make an insecure request to that domain for the length of the header’s max-age. A typical header looks like this:

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

There’s still a weakness on the very first visit, though. The first time a browser goes to the domain, it hasn’t seen the header yet. You can close that gap by registering your domain for HSTS preloading at Hstspreload.org. Once accepted, your site is added to the HSTS preload list that’s hard-coded into the major browsers, and no one will be able to load it insecurely. Preloading requires a max-age of at least one year, includeSubDomains and the preload directive. Make sure you’re committed to serving your site, and every subdomain, over HTTPS before you apply, because this is not a small step and removal takes time. MDN’s Strict-Transport-Security reference covers the details.

Does switching to HTTPS affect SEO?

Yes, mostly in a good way. Google announced HTTPS as a lightweight ranking signal in 2014, and the speed gains from HTTP/2 help too. The risk comes from the migration itself. Google treats a move from HTTP to HTTPS as a site move with URL changes, because every URL changes. Done well, rankings usually settle within weeks. Done poorly, with redirect chains, missing redirects, mixed content or old sitemaps, a migration can cost traffic.

To protect your search visibility:

• Use one-hop 301 redirects from every HTTP URL to its exact HTTPS equivalent, not to the home page.
• Update canonical tags, hreflang tags, internal links and structured data to HTTPS.
• Submit an HTTPS XML sitemap and make sure robots.txt is reachable over HTTPS.
• Verify the HTTPS version in Google Search Console (a Domain property covers both protocols) and watch indexing and traffic reports after launch.
• Update the site URL in analytics, ad platforms, email templates and social profiles.

HTTP to HTTPS migration checklist

Put together, a typical migration follows these steps:

1. Back up the site, files and database.
2. Install a TLS certificate that covers every hostname you use (with and without www, plus subdomains), and set up automatic renewal.
3. Test on a staging site before switching production.
4. Update internal URLs in templates, the CMS database, CSS and JavaScript to relative or HTTPS paths, and change the CMS site address.
5. Update third-party resources (embeds, fonts, CDNs, ad and analytics scripts) to HTTPS, and replace any that don’t support it.
6. Add a Content Security Policy with upgrade-insecure-requests as a safety net.
7. Set 301 redirects from every HTTP URL to its HTTPS equivalent, in one hop.
8. Check for mixed content in the browser console and with a crawler, page template by page template.
9. Update SEO signals: canonicals, sitemaps, Search Console, analytics and key backlinks you control.
10. Test your TLS setup with a tool like Qualys SSL Labs.
11. Enable HSTS with a short max-age first, increase it once everything works, then consider preloading.
12. Monitor certificate renewals, crawl errors and traffic for several weeks.

HTTPS is also one piece of a broader security routine. For WordPress sites, our guide to WordPress security for non-developers covers the other basics.

Frequently asked questions about HTTPS migration

Why does my site say “Not secure”?

Chrome and other browsers label any page loaded over HTTP as “Not secure.” It can also appear on an HTTPS site if the certificate has expired, doesn’t match the domain or the page loads insecure form actions. Installing a valid certificate and redirecting to HTTPS fixes most cases.

How long does an HTTP to HTTPS migration take?

For a small site on a host that supports Let’s Encrypt, the technical switch can take an afternoon. Larger sites with lots of hard-coded URLs, third-party embeds or custom code can take days of cleanup and testing. Search rankings typically settle within a few weeks if redirects are done right.

Is a free Let’s Encrypt certificate good enough for a business site?

For most sites, yes. Let’s Encrypt certificates provide the same encryption as paid domain-validated certificates and are trusted by all major browsers. Paid certificates mainly add organization validation, warranties or support, which some regulated industries or procurement teams require.

Conclusion

Moving your site to HTTPS requires a bit of work. It’s not as easy as clicking a button, and it takes some thought as developers work on your site, but it’s nothing to shy away from. Certificates are now free and easy to acquire, install and renew automatically. A knowledgeable development team can handle compatibility with outside content using Content Security Policies and correct URL paths. With everyday users reaching the internet mostly through phones and laptops on a wide range of wifi networks, it’s imperative that we keep moving the web to HTTPS by default.

Daylight’s strategists and developers help clients answer questions like these as part of ongoing website management, from certificate renewals to making sure every site is part of the trend toward a more secure user experience.

An HTTP to HTTPS migration is table stakes now. Get a free certificate, redirect every URL, clean up mixed content and lock it in with HSTS, and your visitors will never see a “Not secure” warning on your site.