Dispatch
What Is HTTPS? Secure Website Communication Explained
HTTPS is the secure version of HTTP, the protocol that browsers and servers use to exchange data on the web. The "S" stands for "Secure," and it means the connection...
On this page
HTTPS is the secure version of HTTP, the protocol that browsers and servers use to exchange data on the web. The “S” stands for “Secure,” and it means the connection between a visitor’s browser and your server is encrypted using Transport Layer Security (TLS). Without HTTPS, data travels between browser and server as plain text that anyone positioned on the network path, a public Wi-Fi operator, an ISP, an attacker on the same network, can read or alter. With HTTPS, that data is encrypted in transit, so even if it’s intercepted, it can’t be read or tampered with without the right keys.
It’s worth being precise about what HTTPS protects: it secures data while it moves between browser and server (encryption in transit). It does not, by itself, encrypt data sitting in your database or files on disk (encryption at rest), and it doesn’t replace the need for proper application security, access controls, or input validation. HTTPS is one layer of a broader security posture, not a complete one.
How HTTPS actually works
When a browser connects to an HTTPS site, it performs a TLS handshake with the server before any page content is exchanged. According to Google’s own documentation, HTTPS via TLS provides three distinct protections: encryption (keeping the exchanged data unreadable to eavesdroppers), data integrity (detecting if data was modified or corrupted in transit, intentionally or not), and authentication (proving the browser is actually talking to the website it intends to, not an impostor) (Google Search Central, Secure your site with HTTPS).
That authentication piece relies on a TLS certificate, issued by a certificate authority (CA) that verifies you actually control the domain (or, for higher validation levels, the organization) before issuing it. The browser uses that certificate to confirm it’s connecting to the legitimate server, not one impersonating it.
HTTPS as a Google ranking signal
Google has been explicit that HTTPS is a ranking factor, but it’s a narrow one. In its 2014 announcement, Google’s webmaster team stated that the signal was “very lightweight” at the time, affecting fewer than 1% of global search queries, and weighted less than other major signals like content quality, while also noting that the company intended to make the signal stronger as encrypted browsing became more standard (Google Search Central Blog, HTTPS as a ranking signal).
Practically, this means moving to HTTPS is not going to single-handedly transform your rankings if you’re starting from a well-performing HTTP site, but running HTTP today carries real downsides that go well beyond search rankings: modern browsers actively mark HTTP pages as “Not Secure” in the address bar, particularly on pages with input fields, which affects user trust and conversion regardless of where you rank. Treat HTTPS as a baseline requirement for a modern, trustworthy website, not as a ranking hack.
Migrating from HTTP to HTTPS
A migration touches more of your site than people expect. The core mechanics, per Google’s documentation and standard practice, are:
- Obtain and install a valid TLS certificate from a certificate authority for your domain (and subdomains, if applicable).
- Set up 301 (permanent) redirects from every HTTP URL to its corresponding HTTPS URL. Redirect at the URL level (matching paths one-to-one) rather than blanket-redirecting everything to your homepage.
- Update internal references so they point to HTTPS URLs directly rather than relying on a redirect hop: internal links, canonical tags, hreflang annotations, sitemap entries, and any hardcoded resource URLs.
- Fix mixed content. Once your page itself loads over HTTPS, every resource it pulls in, images, scripts, stylesheets, fonts, iframes, also needs to load over HTTPS. A page with mixed content is one whose HTML loads securely but pulls in some resources over plain HTTP, which weakens the security of the whole page (web.dev, What is mixed content?). Mixed content comes in two flavors: passive (images, audio, video) which browsers may still load but flag, and active (scripts, stylesheets, iframes) which browsers commonly block outright because it can manipulate the page.
- Add the HTTPS property in Search Console. Google treats HTTP and HTTPS as separate properties with separate data, so you need to verify and monitor the new HTTPS property explicitly rather than assuming your existing HTTP property will carry over automatically.
- Don’t block the HTTPS version with robots.txt or noindex tags, an easy mistake during migration that can quietly deindex an entire site.
Search Console’s HTTPS report is built specifically to help verify the migration went cleanly: it samples indexed URLs to show the proportion still being indexed under HTTP versus HTTPS, and flags specific obstacles, like invalid certificates or broken redirects, that are preventing a page’s HTTPS version from being indexed (Search Console Help, HTTPS report).
Common migration mistakes
| Mistake | Why it causes problems |
|---|---|
| Redirecting all old URLs to the new homepage | Loses page-specific relevance and link equity; users and crawlers land somewhere irrelevant |
| Leaving mixed content unresolved | Browsers may block active mixed content outright, breaking page functionality, and it undermines the security benefit of HTTPS |
| Forgetting to update the XML sitemap | Sitemap still references HTTP URLs, sending mixed signals about canonical versions |
| Not adding the HTTPS property in Search Console | You lose visibility into how the new HTTPS version is actually performing and indexing |
| Letting the certificate lapse | An expired certificate breaks the secure connection entirely and triggers browser security warnings for every visitor |
| Blocking HTTPS pages via robots.txt or noindex during cutover | Can cause significant, sometimes site-wide, deindexing |
Certificate types and Let’s Encrypt’s renewal cycle
Certificates differ mainly by validation level: domain validation (DV) confirms you control the domain, organization validation (OV) additionally verifies the requesting organization, and extended validation (EV) involves a more rigorous identity check. Worth knowing before paying extra for EV: Chrome and Firefox stopped showing the distinctive green address bar and company name for EV certificates back in 2019, moving that identity detail into the page info panel behind the padlock instead (Bleeping Computer, Chrome and Firefox changes spark the end of EV certificates). All three validation levels encrypt the connection identically and carry the same SEO weight, so DV is the practical default for most sites; OV or EV mainly matter where the underlying identity vetting itself has value to a business, not because of how the browser displays it. Prices and exact validation processes vary by certificate authority, so it’s worth comparing current offerings directly with providers rather than relying on fixed numbers, since CA pricing and structures change.
Let’s Encrypt, a widely used free certificate authority, issues certificates valid for 90 days by default and explicitly recommends renewing them every 60 days, building in a buffer before expiration; its FAQ states this is a fixed lifetime with no exceptions or adjustments available (Let’s Encrypt FAQ). Because manual renewal every 60-90 days isn’t practical at scale, most sites using Let’s Encrypt automate renewal with client tools like Certbot. Subscribers can already opt into six-day, short-lived certificates today, renewed roughly every three days, and Let’s Encrypt has published a staged plan to shorten its default certificates from 90 days to 64 days in February 2027 and then to 45 days in February 2028, part of a broader industry move toward shorter certificate lifespans (Let’s Encrypt, Decreasing Certificate Lifetimes). If you manage certificates at scale, build your renewal automation around those dates rather than assuming the 90-day default will remain the standard indefinitely.
TLS 1.3 vs TLS 1.2
TLS comes in versions, and the version your server supports affects both security and connection speed. TLS 1.3 is the current version and improves on TLS 1.2 primarily by reducing the handshake to fewer round trips between client and server. Where TLS 1.2 typically requires two round trips to complete its handshake, TLS 1.3 condenses this to a single round trip in most cases, and supports zero-round-trip (0-RTT) resumption for clients reconnecting to a server they’ve already connected to, which removes additional latency on repeat connections (Sectigo, TLS 1.2 Handshake vs TLS 1.3 Handshake). Fewer round trips mean a faster initial secure connection, which matters for both user experience and page-load performance metrics. Most modern servers and browsers support TLS 1.3 today, and TLS 1.2 is still an acceptable baseline, but TLS 1.0 and TLS 1.1 are more than just outdated: Chrome, Firefox, Safari, and Edge disabled them by default back in 2020, so a server offering only those older protocols will fail to connect for most visitors rather than just looking dated (Mozilla Hacks, It’s the Boot for TLS 1.0 and TLS 1.1). HTTPS is also a hard prerequisite for HTTP/2 and HTTP/3: no major browser supports HTTP/2 over a cleartext connection, and HTTP/3 has no unencrypted mode at all since it builds TLS 1.3 directly into its handshake (HTTP/2 FAQ), so skipping HTTPS also means giving up those protocols’ performance gains.
HSTS: enforcing HTTPS at the browser level
HTTP Strict Transport Security (HSTS) is a response header that tells browsers to only ever connect to your domain over HTTPS, even if a user types “http://” or clicks an old HTTP link. This closes a specific vulnerability: without HSTS, a user’s very first request to your domain might still go out over HTTP before being redirected, leaving a brief window an attacker could exploit to intercept or downgrade the connection. Once a browser has received your HSTS header, it enforces HTTPS automatically for the duration you specify, without needing a redirect at all (MDN, Strict-Transport-Security header).
For sites that want the strongest version of this protection, Chrome, Firefox, and Safari maintain a shared HSTS preload list: domains on it are hardcoded into the browser to always use HTTPS, even before the very first visit. Submission is done through the official preload list site, and requires your domain to already redirect HTTP to HTTPS, serve a valid certificate, and serve an HSTS header with a long max-age and the includeSubDomains and preload directives set (HSTS Preload List Submission). Preload list inclusion is difficult to reverse quickly, since it ships inside browser releases, so it’s worth confirming your HTTPS setup is fully stable across all subdomains before submitting.
The bottom line
HTTPS is no longer optional infrastructure, it’s the baseline expectation for any site handling real visitors. The migration itself is mechanical: get a valid certificate, redirect cleanly, fix mixed content, update your canonical and sitemap references, and verify the new property in Search Console. The ranking benefit is real but modest; the user trust, security, and performance benefits (especially once you’re running TLS 1.3 with HSTS in place) are the bigger reasons to get it right.