What Is SSL/HTTPS? Difference from TLS

Google confirmed in August 2014, on its official Search Central blog, that HTTPS would count as a ranking signal. At the time it described this as a "lightweight" signal, carrying less weight than content relevance or link quality, but with the stated goal of pushing the whole industry toward encryption. More than a decade later, that push worked: HTTPS is now the de facto standard, and finding a relevant page still served over plain HTTP is the exception, not the rule.

The real turning point didn't come from the search algorithm, though, it came from the browser. In February 2018, the Chromium team announced that starting with Chrome 68, released that July, any page loaded over HTTP would show a "Not secure" label next to the URL, without needing a password or credit card field on the page as had been the trigger before. That warning shows up before a visitor has read a single line of content. Later Chrome versions pushed the warning further still, briefly turning the label red instead of grey on pages with input fields, to make it harder to miss.

That's the practical distinction worth keeping straight: the ranking bonus from HTTPS is small and mostly acts as a tiebreaker between equally relevant pages. The "Not secure" warning, on the other hand, is an explicit, visible flag that a visitor reads instantly as "I shouldn't trust this site," with no algorithm involved at all. That trust damage, immediate bounces, abandoned carts, forms nobody bothers finishing, tends to outweigh the extra ranking point in practice, and it's usually the argument that convinces a hesitant client when SEO alone doesn't land. What a business feels first isn't a ranking drop, it's whether a visitor is even willing to type personal details into a form after seeing that warning.

Migrating from HTTP to HTTPS looks like a minor technical tweak, but it's one of the moves that tanks the most traffic when it's rushed. The first point, and the one most often skipped, is that every HTTP URL needs its own 301 redirect to the exact matching HTTPS version, not just the homepage. A blanket redirect from the whole domain to the new homepage breaks every indexed URL and throws away the link equity each page had already built.

The second problem, nearly unavoidable without an audit beforehand, is mixed content: images, stylesheets, scripts, or iframes that the new page still loads from an http:// address instead of https://. The browser can block those resources outright, or at minimum drop the padlock from the address bar, which visually undoes the point of migrating in the first place. Resources need checking one by one, not just the HTML of the main pages.

The third point covers the signals Google uses to figure out which version is canonical: canonical tags and internal links need to point to https already, not keep referencing the old version. Leaving canonicals pointing at http after the migration sends a contradictory signal at exactly the moment Google needs to trust the new version. The same applies to sitemap entries, structured data, and hardcoded resource references such as Open Graph images: those tend to keep the old http address too, because they were baked into a template or config file instead of following the current protocol dynamically.

Finally, Search Console treats http and https as separate properties, so the https property needs verifying as a new entity, and the updated sitemap with the correct URLs needs resubmitting. Google's change-of-address tool isn't required for a migration that only changes the protocol, but both properties should still stay verified and monitored in parallel while the transition plays out, and the redirects should stay live for at least a year to give the index time to fully catch up. During that window, it's worth checking the coverage report on both properties regularly: a sudden spike in crawl errors or excluded pages on the new https property usually shows up there before it's visible in organic traffic.

Not every certificate verifies the same thing, even though the browser's padlock looks identical either way. A Domain Validated (DV) certificate only confirms that whoever requested it controls that domain; it's issued in minutes, often for free through Let's Encrypt, and it's the level the vast majority of blogs, company sites, and landing pages need.

An Organization Validated (OV) certificate adds a check that a real company actually sits behind the domain, with paperwork and manual verification involved. An Extended Validation (EV) certificate goes a step further and verifies the organization's legal identity with the strictest scrutiny the industry offers.

For years, EV was sold on the promise that it displayed the company name in green next to the URL. Chrome removed that visual indicator in version 77, back in 2019, after its own usability research found that almost no one noticed it or understood what it meant. Firefox followed shortly after. That information now only shows up if someone clicks the padlock and digs into the connection details, so an EV certificate no longer buys a visible trust badge: it buys stricter legal verification, relevant mainly for compliance or liability reasons in sectors like banking or high-volume e-commerce, not for standing out in the address bar.

Coverage matters too, regardless of validation level: a single-domain certificate covers exactly one domain, a wildcard certificate also covers every subdomain (shop.example.com, blog.example.com, and so on), and a multi-domain (SAN) certificate bundles several unrelated domains into one. Which of those fits depends on how a site's domains and subdomains are structured, not on how much validation the project needs.

• Redirect every HTTP URL with a 301 to its exact HTTPS equivalent, not just the root domain, and avoid multi-hop redirect chains.
• Audit every resource on the page (images, CSS, JavaScript, iframes) before calling the migration done, to strip out any lingering http:// reference.
• Update canonical tags, hreflang, and internal links to point straight at the https version, instead of relying on an intermediate redirect.
• Verify the https property as a new property in Search Console and upload the updated sitemap as soon as the change goes live.
• Set up automatic certificate renewal; an expired certificate doesn't just drop the padlock, in many browsers it replaces the whole page with a full-screen warning.
• Add the HSTS header once everything's confirmed working over https, so the browser doesn't even try loading the http version on future visits.

• Migrating only the homepage to https and leaving the rest of the site on http, or redirecting every old URL to the new homepage instead of its exact equivalent.
• Leaving mixed-content resources uncorrected, which blocks individual elements or drops the padlock even though the main URL is already https.
• Forgetting to update canonical tags and internal links, so they keep pointing at http after the migration.
• Not verifying the https property in Search Console, leaving Google without performance data on the new version for weeks.
• Letting the certificate expire because renewal wasn't automated, which brings the "Not secure" warning back on a site that had already migrated.
• Overpaying for an EV certificate assuming it still shows the company name in green, a feature Chrome and Firefox both retired back in 2019.