Chrome now stops and asks permission before it connects to a public website over plain HTTP, and the prompt is on by default for every user, Google’s Chrome security team announced on Wednesday, Oct. 21. A site that still serves pages without encryption now greets visitors with an interstitial instead of a small label in the address bar. For site owners, that raises the price of leaving legacy URLs unencrypted.
According to the Google Chrome security blog, the feature first reached users in Enhanced Protection mode of Safe Browsing earlier this year. The default rollout extends it to everyone. The team says the old “Not Secure” badge fell short in three ways: passive warnings can go unnoticed, redirects and other short-lived requests never get a badge, and the badge appears only after data has been exposed.
The redirect gap deserves attention from SEO teams. An old backlink, a printed URL, or an ad destination that begins with http:// is an HTTP request, even if the server immediately forwards it to HTTPS. Google’s post lists redirects as a blind spot of the badge, which suggests the prompt is meant to catch them. The post does not spell out how the prompt treats a redirect hop, so teams should test their own legacy URLs in a current Chrome build rather than assume.
The prompt has limits. Chrome asks on the first visit to a site, then stays quiet until the user has been away for at least two weeks. Warnings are off by default for hosts that cannot obtain a publicly trusted certificate, such as single-label names like intranet/ and local addresses like 192.168.0.1. A public staging or microsite hostname does not fall into that group, so it can trigger the prompt (this is an inference from Google’s description, not a stated example).
Google’s own rollout figures point to a small affected population. Early data shows nearly 95 percent of desktop Chrome users see no HTTP warning in a given week, and fewer than 1 percent see three or more. Mobile rates are lower still. The team credits that low rate to high HTTPS adoption, which is why it now considers warnings safe from fatigue.
That also means the remaining HTTP sites stand out. When almost nobody sees a warning in a normal week, a prompt on your domain is an anomaly that visitors may read as a sign of a neglected or compromised site. Google has published no click-through, bounce, or traffic data for sites that trigger the prompt, and this article does not estimate any.
Two practitioner checks follow from this. First, mixed content, where an HTTPS page pulls images, scripts, or embeds over HTTP, is a separate problem. Google’s post concerns the connection to the site itself and says nothing about subresources, so do not treat a clean prompt test as proof that a page is fully secure. Second, canonical tags, sitemaps, hreflang annotations, and internal links that still name http:// URLs force extra redirect hops, which is wasteful whether or not a prompt appears.
The announcement also carries a competitive note. Google claims that no other browser has shipped this protection yet, and says it hopes rivals will adopt it. No other browser vendor has committed to it in the source material, so the behavior applies to Chrome users for now.
A practical audit takes an afternoon. Crawl for any internal or external reference that resolves through an http:// address, check that every legacy host has a valid certificate and a direct redirect to its HTTPS equivalent, and fix the highest-traffic inbound links first. Teams with public subdomains that were never migrated should treat them as the most likely place for visitors to hit the new prompt.
Based on “Chrome Now Warns Before Insecure HTTP Connections,” published Oct. 21, 2026, on the Google Chrome security blog (blog.google) by Chrome’s Secure Web and Networking Team.
