Chrome HTTP warning is now default: 2027 HTTPS audit for site owners

Summary. Chrome now asks for permission by default before it opens a public page over plain HTTP. The change, listed as Ask before HTTP on by default, shipped in Chrome 154 (stable on 22 September 2026), and Google said on 21 October 2026 that the protection had been extended to all users by default. Chrome tries HTTPS first, warns only if HTTPS fails, and remembers the visitor's answer for 15 days, renewed on each visit. It does not warn on localhost, local IP addresses or single-label hosts. The catch is redirects: a hop through a host without HTTPS triggers the warning even when the final page is HTTPS. Google's early rollout data says nearly 95% of desktop users see no HTTP warning in a given week, so a site that triggers it looks unusual. For SEO, Google says page experience aspects beyond Core Web Vitals do not directly lift rankings, but it prefers HTTPS canonicals, and bad certificates push it strongly towards HTTP. Test every hop, subdomain and http:// link, add HSTS, and automate renewals before Let's Encrypt moves to 64-day certificates on 10 February 2027.

About this article. For people who run public websites. On 1 November 2026 we checked Chrome's behaviour against Google's posts, release notes and Chromium documentation; search claims against Google Search Central; and certificate facts against the CA/Browser Forum, Let's Encrypt, Google and eMudhra. Legal points come from the DPDP Act, 2023 with the DPDP Rules, 2025 and commencement notification (Gazette of 13 November 2025), GDPR Article 32 as published in 2016, and a PCI SSC FAQ of July 2025. This is not legal advice, browser behaviour changes often, and no vendor paid for inclusion. Researched with AI assistance and reviewed by our editorial team.

What Chrome changed, and when

Google announced the plan on 28 October 2025, naming Chrome 154 as the release that would flip the default and expecting it in October 2026. Chrome 154 in fact reached stable on 22 September 2026, and its release notes list the change. On 21 October 2026 Chrome's Secure Web and Networking team confirmed it had rolled out to all users by default.

Platforms differ. Chrome Status lists desktop in Chrome 154 and Android in Chrome 155, with no iOS milestone, so test each platform your visitors use. Milestones also pass quickly now that Chrome ships every two weeks: Chrome 157 is due on 3 November 2026.

The timeline draws on Google's two posts, the Chromium schedules and Chrome Status. Chrome 147's release notes do not mention the Enhanced Safe Browsing step; Google says only that it happened earlier in 2026.

Why now? Google's 2025 post says HTTPS plateaued at roughly 95% to 99% of Chrome page loads around 2020. On public sites alone even Linux, the lowest, reaches nearly 97%, and redirects through HTTP never give a Not Secure badge a chance to appear.

What the warning covers, and what it does not

The rules come from Chromium's adoption guide for site owners and IT teams.

It fires when:

• Chrome cannot connect over HTTPS but thinks HTTP might work. Chrome tries HTTPS first, so a host that supports HTTPS is upgraded without a prompt, even from an old http:// link, QR code or bookmark.

• Any step in a redirect chain does not support HTTPS. Several such steps can produce several warnings in one navigation.

It does not fire when:

• The host is localhost, a local IP address, a single-label name or a non-unique name such as staging.local.

• The browser holds an HSTS policy for the host. Chrome then does not fall back to HTTP, and HSTS takes precedence over the warning.

• A link or typed URL explicitly uses https:// and fails. The user sees a normal network error, with no HTTP fallback.

• The user has turned the setting off at chrome://settings/security, or set it before the rollout. Chrome respects earlier choices.

Certificate errors are unchanged. An expired or misconfigured certificate still produces Chrome's existing certificate warning, and the guide says no additional warnings of that type will appear.

Google's early rollout data puts mobile warning rates below desktop, and Google says Chrome is the first browser to make this change.

Does an HTTP page hurt SEO in 2027?

The direct ranking answer is smaller than many SEO checklists claim. Google's page experience documentation (updated 22 September 2026) lists secure serving as a self-assessment question, then says Core Web Vitals are used by ranking systems and other page experience aspects do not directly help a site rank higher.

The indirect effects are real, and they come from canonical choice and from users. Google's canonical guide (updated 10 July 2026) is the source for the first six rows below.

A failed renewal hurts canonical choice and shows visitors an error, so read this audit with our Let's Encrypt 64-day certificates guide. Search Console's HTTPS report shows whether you serve secure HTTPS pages and what to fix.

The 2027 HTTPS audit: 14 checks

Chromium's guide recommends a simple first step: enable Always Use Secure Connections for public sites in your own Chrome, then use your site, campaigns and checkout as a customer would. Each warning shows a host that needs HTTPS, and the DevTools Network panel shows every redirect hop.

            # 1. Can each host serve HTTPS? Chrome tries this first. 000 means no working HTTPS, so expect a warning.
for h in example.com www.example.com shop.example.com; do
  printf '%s: ' "$h"
  curl -s -o /dev/null --max-time 10 -w '%{http_code}\n' "https://$h/"
done

# 2. Walk a redirect chain, then run test 1 on every new host named in a Location line
curl -sIL --max-redirs 10 "http://example.com/" | grep -iE '^(HTTP/|location:)'

# 3. HTTP URLs still listed in the sitemap (skips the sitemaps.org namespace)
curl -s https://www.example.com/sitemap.xml | grep -oE '(<loc>|href=")http://[^<"]+' | sort -u | head

# 4. Is HSTS sent, and who issued the certificate?
curl -sI https://www.example.com/ | grep -i strict-transport-security
echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null \
  | openssl x509 -noout -issuer -dates
          

An http:// value in a Location line is not always a trigger: Chrome tries HTTPS on that host first, so only a host that fails test 1 warns.

The apex-to-www trap. Chromium's guide gives this example: a site at https://www.example.com that redirects http://example.com to http://www.example.com, with no HTTPS on the apex, warns everyone who goes to example.com. The fix is HTTPS on the apex itself.

Your logs need a baseline. A visitor who turns back at the warning never loads your page, so JavaScript analytics never sees them. Google says Chrome asks before the connection occurs, so that visitor is missing from port 80 logs too. Use server, CDN or load-balancer logs from before the rollout as a baseline for HTTP traffic by host and path, then compare with today. A drop on a host without HTTPS is the closest signal available.

Mixed content: what Chrome upgrades and what it blocks

Mixed content is an HTTPS page that loads resources over HTTP. The new prompt is about navigations, but mixed content still breaks pages and can stop the HTTPS version being chosen as canonical. The table follows MDN's reference.

Test CSS background images rather than assume: MDN lists background-image under both the upgradable and the blockable groups. Fix blockable items first because they fail outright. The Content-Security-Policy: upgrade-insecure-requests header upgrades all requests, including blockable ones, so it is a useful stopgap, but it only works if every third-party host supports HTTPS.

Device setup portals that stayed on HTTP to reach local routers or printers can now move: Chrome's local network access permission lets an HTTPS page reach local devices once the user agrees.

HSTS: turn it on, ramp it, and think twice about preload

HTTP Strict Transport Security tells the browser to use HTTPS for your domain for a set period. Chromium's guide says HSTS takes precedence over Chrome's automatic upgrades and the new warning, and that Chrome will not fall back to HTTP for an HSTS host.

The browser learns the policy only after a first HTTPS visit, so HSTS helps return visitors, not newcomers. It also removes the escape hatch: RFC 6797 tells browsers to end the connection on any certificate error for a known HSTS host, with no option to proceed. Automate renewals before you raise max-age.

hstspreload.org, the Chromium project's preload site, recommends ramping max-age in stages with includeSubDomains and waiting the full period at each stage while you watch for breakage: 300 seconds (5 minutes), then 604,800 (1 week), then 2,592,000 (1 month). That adds up to 3,197,100 seconds, about 37 days. Check every subdomain first, including internal ones.

            server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;   # same host first, then to the canonical host
}

server {
    listen 443 ssl;
    server_name example.com www.example.com;
    # ssl_certificate lines go here, covering both names
    # Stage 1. Raise to 604800, then 2592000, then 31536000 once each stage is clean.
    add_header Strict-Transport-Security "max-age=300; includeSubDomains" always;
}
          

The site's own ramp stops at one month. One year (31,536,000 seconds) is its minimum for preload, and we suggest it as the end point for a plain header too.

Preloading is now discouraged. The preload list is built into Chrome, so HTTPS applies even on a first visit. But the site now says HSTS is recommended and preloading is not, because Chrome and Safari already upgrade HTTP navigations. Removal takes months to reach users, and a forgotten HTTP-only subdomain becomes unreachable. For most businesses, a ramped header without preload is the right end state.

Managed Chrome fleets: policies and test flags

If you run Chrome for employees, two enterprise policies matter:

• HttpAllowlist takes hostnames or patterns such as [*.]example.com that will not be upgraded and will not warn. Use it for legacy internal apps on public hostnames. Blanket wildcards are not allowed, and the policy does not apply to HSTS upgrades, so an includeSubDomains header on a parent domain still wins.

• HttpsOnlyMode controls the setting. force_balanced_enabled locks users into the new default, force_enabled turns on strict mode, which also warns on private sites, and disallowed turns it off.

For automated tests with ChromeDriver or Selenium, the guide documents the --unsafely-treat-insecure-origin-as-secure flag, which takes a comma-separated list of origins or hostname wildcards. Keep it to test environments.

Worked example: what one HTTP entry point can cost

We found no Google figure for how many users turn back, so treat this as a template with invented inputs.

Take a hypothetical Indian direct-to-consumer brand with 150,000 monthly sessions. Port 80 logs from before the rollout show that old backlinks, packaging QR codes and an email click-tracking link deliver 4% of sessions to hosts with no working HTTPS.

The fix is cheap by comparison: many certificate authorities offer free certificates, and Apache, Nginx and Caddy support ACME. Discovery is usually the larger cost, so the logs and host inventory come first.

India, EU and US notes

India: check the issuer, not just the padlock. On 20 October 2026 Google disclosed that private keys for eight eMudhra subordinate CA certificates had been generated with insufficient randomness. It scheduled removal of the emSign ECC Root CA - G3 from the Chrome Root Store for 27 October 2026, warning that some legitimate certificates would stop working, and said it was reviewing eMudhra's remaining certificates. Chromium's root store list, read on 1 November 2026, no longer shows that root and still shows emSign Root CA - G1.

eMudhra says about 30,800 certificates under the affected hierarchies belong to a client ecosystem in the United States, that it is winding down publicly trusted TLS, and that most other TLS customers have moved to alternate providers. It says its digital signature and eSign services are unaffected. So add an issuer check (item 13) for every property, and replace any certificate whose issuer names emSign or eMudhra.

India: DPDP. Section 8(5) of the Digital Personal Data Protection Act, 2023 requires data fiduciaries to take reasonable security safeguards to prevent a personal data breach, and the Schedule sets a penalty of up to ₹250 crore. Rule 6 of the DPDP Rules, 2025 gives encryption as an example in its minimum measures. Both start eighteen months after Gazette publication on 13 November 2025, which computes to 13 May 2027. Collecting personal data through an HTTP form, or an HTTPS page that posts to HTTP, will be hard to defend as reasonable. Our DPDP Act engineering playbook covers the wider controls.

EU. GDPR Article 32 names encryption of personal data as an example of an appropriate security measure.

US and card payments. We have not surveyed US sector rules. If you take cards, PCI DSS says cardholder data crossing an open or public network must be secured with strong cryptography and security protocols (Requirement 4.2). It is an industry standard with global reach, not a US statute.

Certificate lifetimes are shrinking everywhere. The CA/Browser Forum's Baseline Requirements (version 2.3.1) cap public certificates at 100 days from 15 March 2027 and 47 days from 15 March 2029, following Ballot SC-081v3. Let's Encrypt moves its default to 64 days on 10 February 2027. See our guide on the 100-day certificate cap.

Implementation checklist

1. Turn on the setting yourself and walk the site, checkout, campaigns and support pages.

1. Pull port 80 logs from before the rollout and from today, and list every hostname from DNS and Certificate Transparency.

1. Fix the apex and www first, then every redirect hop, legacy subdomains and vendor tracking domains.

1. Regenerate sitemaps, canonicals and hreflang, and clear blockable mixed content on top templates.

1. Check every certificate's issuer and expiry, then automate renewals with ACME and ARI and alert on renewal failure.

1. Ramp HSTS through the three stages (about 37 days), then raise to one year; skip preload unless you have a clear reason.

1. Set Chrome policies for managed fleets, and re-run the host test monthly.

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. Our cybersecurity services team can run this audit across your domains, redirects and certificate chains, then fix what it finds. Talk to us at /contact-us/.

Last updated: 1 November 2026.

References

1. Chrome 154 release notes — Chrome for Developers

1. Chrome Now Warns Before Insecure HTTP Connections, 21 October 2026 — Google

1. Adapting your website for Chrome's Ask-before-HTTP warning — Chromium Docs

1. Understanding Google page experience, updated 22 September 2026 — Google Search Central

1. How to specify a canonical with rel=canonical and other methods, updated 10 July 2026 — Google Search Central

1. 64-Day Certificate Lifetimes Coming Feb 2027, 7 October 2026 — Let's Encrypt

1. HTTPS by default, 28 October 2025 — Google

1. Chrome 154 milestone schedule — Chromium Dash

1. Ask-before-HTTP warning on by default — Chrome Platform Status

1. Chrome 157 milestone schedule — Chromium Dash

1. Chrome 147 milestone schedule — Chromium Dash

1. Chrome 155 milestone schedule — Chromium Dash

1. Mixed content, last modified 15 August 2026 — MDN Web Docs

1. HSTS Preload List Submission — Chromium project

1. RFC 6797: HTTP Strict Transport Security (HSTS), sections 8.4 and 12.1 — IETF

1. Chrome policy templates, HttpAllowlist and HttpsOnlyMode — Google

1. Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates, 20 October 2026 — Google

1. Chrome Root Store list, main branch — Chromium

1. eMudhra Statement on Recent Certificate Security Incident, updated 30 October 2026 — eMudhra

1. Digital Personal Data Protection Act, 2023 — Ministry of Electronics and Information Technology

1. Digital Personal Data Protection Rules, 2025, G.S.R. 846(E), 13 November 2025 — Ministry of Electronics and Information Technology

1. Commencement notification, G.S.R. 843(E), 13 November 2025 — Ministry of Electronics and Information Technology

1. Regulation (EU) 2016/679, Article 32 — EUR-Lex

1. FAQ 1075, July 2025 — PCI Security Standards Council

1. PCI Data Security Standard (PCI DSS) — PCI Security Standards Council

1. Baseline Requirements for TLS Server Certificates, version 2.3.1, 4 October 2026 — CA/Browser Forum

1. Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods — CA/Browser Forum