What Is HTTPS? Secure Website Communication Explained
HTTPS is HTTP sent over an encrypted connection. The browser and the server agree on keys through Transport Layer Security (TLS), and from then on the data between them cannot be read by anyone on the network path, such as a public Wi-Fi operator or an attacker on the same network, and any change to it in transit is detected. The certificate behind the connection also lets the browser confirm that it is talking to the real site and not an impostor.
What TLS Protects, and What It Does Not
The TLS 1.3 specification, RFC 8446, describes the protocol as a way for client and server applications to communicate over the internet in a manner “designed to prevent eavesdropping, tampering, and message forgery.” That gives three protections: the data is unreadable in transit, changes to it are detected, and the server proves its identity with a certificate issued by a certificate authority that checked who controls the domain.
HTTPS protects data while it moves. It does not encrypt data stored in your database or files, and it does not replace application security, access control, or input validation. Nor does it vouch for the business: a valid certificate shows that the connection is encrypted and that control of the domain was checked, not that the site’s owner or claims can be trusted.
HTTPS and Rankings
Google announced HTTPS as a ranking signal in an August 2014 post, describing it as “only a very lightweight signal” that was “affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content.” It added that “over time, we may decide to strengthen it.”
Google’s current page experience documentation lists being “secure (HTTPS)” among the aspects of page experience and says that, apart from Core Web Vitals, these aspects do not directly help a site rank higher. Read together, the two sources point the same way: HTTPS is a baseline for a trustworthy site, not a lever that moves rankings by itself. The reasons to use it are the visitors’ data and their trust.
Migrating From HTTP to HTTPS
- Install a valid certificate for every hostname you serve, including subdomains.
- Redirect each HTTP URL to its own HTTPS equivalent with a permanent (301) redirect, path for path, not everything to the homepage.
- Update internal links, canonical tags, hreflang annotations, sitemap entries, and hard-coded resource URLs to HTTPS so they do not depend on a redirect.
- Fix mixed content: every image, script, stylesheet, font, and frame on an HTTPS page must also load over HTTPS.
- Check the HTTPS version in Search Console. With URL-prefix properties, HTTP and HTTPS are separate properties with separate data; a Domain property covers both protocols.
- Make sure robots.txt and
noindexrules do not block the HTTPS version.
Web.dev’s explanation of mixed content separates two types. Passive mixed content, such as images, “is less of a risk than active mixed content, but that risk is still there.” With active mixed content, such as scripts, attackers “can take complete control over the page, not just of the insecure resources.” It also notes: “Most browsers now block mixed content for security reasons.”
After the move, the Search Console HTTPS report “shows how many indexed URLs on your site are HTTP vs HTTPS” and names the reasons a page’s HTTPS version is not indexed, among them “HTTPS has invalid certificate” and “HTTPS has redirect,” where the HTTPS URL redirects back to HTTP.
| Mistake | What goes wrong |
|---|---|
| Redirecting every HTTP URL to the homepage | Visitors and crawlers land on a page that is not the one they asked for |
| Leaving mixed content | Browsers block insecure resources and parts of the page break |
| Keeping HTTP URLs in the sitemap | The sitemap contradicts the redirects and canonical tags |
| Skipping the HTTPS property in Search Console | Indexing problems on the new version go unseen |
| Letting the certificate expire | Visitors get a security warning instead of the page |
Certificates and Renewal
Certificates differ by how much the certificate authority checks before issuing them: domain validation (DV) confirms control of the domain, organization validation (OV) also checks the organization, and extended validation (EV) adds a stricter identity review. All three encrypt the connection the same way. Browsers have stopped showing EV details in the address bar; the Chromium project’s note on moving EV UI to Page Info explains that from Chrome 77 the EV badge moved behind the lock icon. Choose OV or EV when the identity check itself matters to your business, not for search.
Let’s Encrypt, a free certificate authority, is shortening its certificate lifetimes. Its FAQ states: “Our default certificates are valid for 90 days,” recommends “renewing 90 day certificates every 60 days,” and describes six-day certificates as an opt-in. In an October 7, 2026 post, it set the next step: “On February 10, 2027, all Let’s Encrypt subscribers will move to certificates with 64 day lifetimes by default unless they select an even shorter lifetime (45 or 6 days, as previously announced).” Default lifetimes of 45 days follow in 2028. The post advises that renewals hard-coded to a date before expiration should be changed “to renew at approximately ⅔ of the lifetime instead.” Six-day certificates have been generally available since January 2026 as an opt-in. Automated renewal is the only workable way to keep up.
TLS Versions
TLS 1.3, defined in RFC 8446, is the current version. Its full handshake takes one round trip, which the specification calls the 1-RTT handshake, so secure connections start faster. It also added a zero round-trip mode for resumed connections, “saving a round trip at connection setup for some application data, at the cost of certain security properties.” TLS 1.0 and 1.1 are obsolete: in a 2020 post, Mozilla wrote that “Mozilla, Google, Apple and Microsoft have committed to disabling” them, a deprecation announced in October 2018. A server should offer TLS 1.2 and 1.3.
HTTPS also matters for HTTP/2. The HTTP/2 FAQ notes that “currently no browser supports HTTP/2 unencrypted,” so a site without HTTPS cannot use it in browsers.
HSTS
HTTP Strict Transport Security is a response header that, as MDN describes it, “informs browsers that the host should only be accessed using HTTPS, and that any future attempts to access it using HTTP should automatically be upgraded to HTTPS.” It closes a gap that redirects leave open: “If the browser loads an insecure http URL prior to knowing that the host is an HSTS host, the initial request is vulnerable to network attacks.” Once the header has been seen, the browser goes straight to HTTPS for the period set by max-age.
The HSTS preload list removes even that first insecure request by building the domain into browsers. To be accepted, a site must serve a valid certificate, redirect HTTP to HTTPS on the same host, serve all subdomains over HTTPS, and send an HSTS header with a max-age of at least 31536000 seconds (one year) and the includeSubDomains and preload directives. The site warns that “inclusion in the preload list cannot easily be undone,” and that new entries “can take several months” to reach the stable version of Chrome. Submit only when every subdomain is ready for HTTPS permanently.