Chrome now requests user permission before opening an unsecured HTTP connection. The "Always use secure connections" protection, previously enabled more widely for some enhanced browsing profiles, is now extended by default to all users. For a creator, coach, consultant or small business, an old HTTP link can therefore display a warning page even before the visitor reaches the offer, form or reservation.
Google announced this change on 21 October 2026 and presents it as already deployed to all Chrome users. This is not a country-limited test. The measurement is global, although its effect naturally depends on the links visited and the settings administered on certain devices. The right reflex is not to panic, but to audit the entire public journey: domain, subdomains, redirections, bio links, QR codes, old campaigns, forms, files and payment pages.
What Chrome has officially changed
HTTP and HTTPS are two ways to transport a page between a site and the browser. With HTTPS, the connection is encrypted and the certificate allows the browser to verify the technical identity of the site. With HTTP, information flows without this protection. A person placed on the network route may potentially observe or modify what is transmitted.
Until now, Chrome could report an HTTP page as "unsecure" in the address bar. The problem is that this indication appeared once the connection was started. Google also explains that it could go unnoticed and did not adequately protect very brief connections, such as an old HTTP URL that immediately redirects to HTTPS.
The new logic comes before the connection. Chrome first tries to use HTTPS. If the site does not support a secure connection, the browser asks the user if he or she agrees to continue. According tochrome Security Team Announcement, this protection was first activated for users of the Enhanced Safe Browser Protection mode, then extended to all by default on 21 October 2026.
When a user allows a first visit to HTTP, Chrome does not alert him immediately again for this site. The warning may return if the site has not been visited for at least two weeks. Google also provides default exceptions for addresses that generally cannot obtain a public certificate, such as some simple internal names or local IP addresses used to administer a router.
Deployment is possible because the Web already uses very much HTTPS. Google indicates that during the early phases, near 95 % Chrome users on computer did not encounter any HTTP warnings in a given week and that less than 1 % saw at least three. In other words, if your link now triggers an alert, it will appear as an anomaly in an environment where visitors expect a secure connection.
Why an old HTTP link can break a conversion path
For the owner of the site, a redirect from http:// to https:// may seem sufficient: the final destination is secure, so the problem seems to be solved. But the browser must sometimes contact the HTTP address before receiving the redirection order. It is precisely this short passage that Chrome wants to avoid without consent.
The commercial consequence is not measured directly in Google's ad, but it is easy to understand: a warning page adds an unexpected decision between the click and the destination. Some visitors will continue. Others will think the site is hacked, abandoned or unreliable. On mobile, in a journey started from Instagram, TikTok, LinkedIn, newsletter or QR code, this friction can be enough to interrupt the action.
This is particularly expensive when the click has been purchased. Article VIFLY on ads that generate clicks without producing customers already recalls that a campaign does not repair a fragile destination. An old HTTP URL in an ad, button or email can now create a break even before the destination page has the possibility to explain the offer.
The same logic applies to organic confidence. A profile can be professional, useful content and a clear offer; If the main link triggers an alert, the experience contradicts the message. Among the errors that weaken a professional profile, an old or poorly maintained link appears secondary until the day the browser places it in the center of the screen.
What to really audit
Check that the home page displays a padlock is not enough. A digital ecosystem accumulates URLs over the years: variants with or without www, old domains, subdomains, campaign pages, shortcuts, files and third party tools. The audit must follow the paths taken by a real person, not just the configuration of the main domain.
The variants and redirections of the domain
Test at least the old HTTP address, versions with and without www, any subdomains and subdomains used in your campaigns. Each variant must drive cleanly to a canonical HTTPS URL. A chain with several redirections increases the opportunities for error and slows down the course. The ideal is a direct and permanent redirection to the right destination.
Links published outside the site
Review the bio of each social network, YouTube descriptions, professional profiles, email signatures, automated newsletters, old articles, advertising campaigns, print QR codes and still shared PDF documents. These media can continue to generate traffic several years after their creation.
One LinkHub VIFLY can serve as a central control point for your important destinations, provided each button is tested itself. Centralizing links reduces their dispersal, but does not exempt from checking safety and relevance.
Forms, reservations and files
A main site can be HTTPS while a historical form, calendar, downloadable file or payment page still uses an HTTP address. Check the "book", "Buy", "Download", "Request a quote" and "Contact me" buttons. If you use VIFLY Booking to organize your appointments, also check that the published links to the booking page correspond to its current destination, without any previous HTTP intermediary.
Resources loaded within a page also deserve verification. An image, style sheet or script called in HTTP from an HTTPS page falls under "mixed content". Browsers already apply rules specific to this content. This is not exactly the same warning as described in the new announcement, but the audit is a good opportunity to correct both problems.
Two concrete examples to understand the impact
Example 1: the forgotten booking link of a coach
A coach changed booking tool two years earlier. Its current site uses HTTPS and its calendar works correctly. However, an old story on the front page and several free PDFs still refer to http://old-domain.example/reserver. This address redirects to the new secure page.
Before Chrome's change, redirection could be almost invisible. From now on, a visitor can be stopped before redirection and must allow the HTTP connection. The coach must correct editable media, configure a direct and secure redirect on the old domain, and then measure whether the clicks to the booking actually reach the final page.
The lesson is not only technical: an ancient bond is an active promise. As long as public content can be discovered, its destination is part of the proposed experience.
Example 2: the QR code of an artisan leads to an old subdomain
An artisan printed a QR code on her packaging. It leads to a brochure hosted on http://catalogue.example, while its main shop is secure. It cannot immediately reprint all packages, but it can install a valid certificate on the subdomain and point this address to a stable HTTPS page.
It then checks the brochure, pictures, command button and tracking settings. If the QR code uses a shortcut service, it also tests the intermediate URL. The visitor should not have to distinguish between the main domain, the subdomain and the shortcut: he must simply arrive on a secure, coherent and understandable page.
VIFLY: Technical security is part of the content
A link is not a detail placed after the content. This is the promise that the next step will be as reliable as what you just published.
Independents often separate content and technology. On one side, posts, videos, offers and evidence. On the other hand, domains, certificates and redirections. For the user, this separation does not exist. He lives only one route.
VIFLY logic — visibility, understanding, trust, action, opportunity — can fail every transition. HTTP warning acts precisely between trust and action. The person may have already appreciated the content and understood the offer; she hesitates to continue because the browser asks her if she accepts an unsecured connection.
Therefore, a technical audit should not be limited to the IT department. The person responsible for marketing must know the fields used. The person who publishes must check their links. Whoever manages the campaigns must test the actual destination. And the independent who brings together all these functions must keep a small register of its public URLs.
Article VIFLY on blockages between visibility and conversion asks the same question from another angle: what happens in the seconds following interest? Now, the answer must also include the security of the connection.
Nuances, limits and misinterpretation
Chrome does not absolutely prohibit all HTTP. He requests permission before the connection when the protection applies. After approval, the user can continue and will not necessarily review the alert immediately. There are also exceptions for some local environments.
HTTPS does not prove that a company is honest. Encryption protects the transport and the certificate contributes to the technical authentication of the domain. A fraudulent site may also have a certificate. Visitors must always check the domain name, the consistency of the offer and the information provided.
Not all Chrome alerts indicate the same problem. The warning for a site without HTTPS differs from "Your connection is not private", which usually indicates a certificate, date or interception problem. It also differs from the Safe Browsering red screen, associated with a site considered dangerous. The chrome Help Center explains these separate states.
A SEO effect should not be invented. The announcement of 21 October is about safety and navigation experience. It does not declare a new classification factor. On the other hand, an alert that causes abandonment can actually degrade the performance of a campaign or course, regardless of any Google ranking.
The certificate must be maintained. Switching to HTTPS once is not enough if the renewal fails, a subdomain is forgotten, or a redirect returns to an unsecured resource. Automate renewal when possible and monitor errors.
What to do now? Action Plan, FAQ and Sources
- List your domains and subdomains. Include old domains still present in content, QR codes or campaigns.
- Test each variant in HTTP. Check that it switches directly to the correct HTTPS URL without any unnecessary intermediate page.
- Check the certificates. Review their validity, covered names and automatic renewal.
- Browse your public channels. Open the links of bios, signatures, newsletters, advertisements, PDF and professional profiles.
- Test the important actions. Reservation, payment, download, form, contact and registration must be followed until they are confirmed.
- Find mixed content. Correct images, scripts, style sheets or files still called in HTTP.
- Remove redirect chains. Update the links you control to point directly to their secure destination.
- Focus on business risk. Start with the links placed in the most visited ads, bios and pages.
- Repeat regularly. Add this control to every campaign launch, domain change or tool migration.
Does Chrome now block all HTTP sites?
No. Chrome displays an authorization request before setting up an HTTP connection concerned with the protection. The user can choose to continue. Exceptions exist in particular for certain local addresses which cannot receive a public certificate.
Is HTTP redirection to HTTPS enough?
It remains useful, but an old HTTP URL may require an unsecured first connection before receiving redirection. It is therefore best to replace public links with their HTTPS destination and to retain redirect only as a safety net.
How do I know if my site uses HTTPS correctly?
Open all variants of the domain, check that the browser establishes a secure connection, check the validity of the certificate and test subdomains, forms and files. A correct home page does not guarantee that the entire route is.
Is the HTTP warning identical to "Your connection is not private"?
No. The first concerns the absence of an HTTPS connection. The second usually appears when the browser encounters a problem with the certificate or the confidentiality of the connection. The Safe Browsing red screen still corresponds to another alert category.
Should we change all the old QR codes?
Not necessarily if their destination can be secured. Install a valid certificate on the domain or subdomain used, then configure a stable HTTPS redirect. If the QR code passes through an external shortcut, also test this step.