Chrome HTTPS by Default: Site Owner Checklist

This guide is for site owners, bloggers, agency staff and small businesses who run a website and want to make sure visitors never meet a browser warning page. Chrome now switches on its “Always Use Secure Connections” protection by default. If any page, subdomain or embedded file on your site still depends on plain HTTP, some visitors may be asked for permission before they can reach it. Below is what was announced, and a practical checklist to work through with your host and your WordPress dashboard.

Contents

What Chrome has announced
What visitors will see
Step 1: Test your site with the setting turned on
Step 2: Confirm every page and subdomain has valid HTTPS
Step 3: Check certificate renewal with your host
Step 4: Set up HTTP-to-HTTPS redirects in WordPress
Step 5: Find and fix mixed content
1. Typical sources in WordPress
Key takeaways
FAQ
Sources

What Chrome has announced

The Chrome Security Team published a post titled “HTTPS by default” on the Google blog, dated October 28, 2025, and written by Chris Thompson, Mustafa Emre Acer, Serena Chen, Joe DeBlasio, Emily Stark and David Adrian. Its key statement is that with the release of Chrome 154, “we will change the default settings of Chrome to enable ‘Always Use Secure Connections’.” The post specifies that it is the setting’s public-sites variant that becomes the default. The post also says that Chrome will ask for the user’s permission before the first access to any public site without HTTPS, and that Chrome will only warn users when they visit a new (or not recently visited) site without using HTTPS.

The post describes an earlier step too: in Chrome 147, users who had opted in to Enhanced Safe Browsing got the public-sites version of the warning first. It also distinguishes public from private sites, noting that HTTP on private sites can only be abused by an attacker who is also on your local network. Finally, it strongly recommends that website developers and IT staff turn the setting on today to find sites that need migrating.

Where things stand now: Chrome’s official release notes for Chrome 154 give a stable release date of September 22, 2026, and list a privacy and security change called “Ask before HTTP on by default”, under which Chrome prompts users by default when they connect to a site over an insecure (http) connection. The release notes use that name rather than the setting name in the 2025 announcement, and Chrome changes often reach users gradually, so not every visitor may see the prompt yet. Either way, the change is no longer a future plan, and the preparation steps below are the same.

Enjoying this? Get our best tips by email

Practical SEO, link building and content strategies, straight to your inbox.

What visitors will see

Chrome Help describes the setting this way: when it is on, Chrome upgrades URLs to HTTPS and displays a warning before you visit a site that does not support it. If a page loads without HTTPS, the address bar shows “Not Secure”. On desktop you find the option at More (three dots) > Settings > Privacy and security > Security, under “Secure connections”, then “Always use secure connections”. Two modes exist: “Warns you for insecure public sites” and “Warns you for insecure public & private sites”.

The practical point for a business: a warning interstitial before your page loads is a poor first impression, and many people will simply leave. The fix is not complicated, but it has to cover every address your visitors might type or click.

Step 1: Test your site with the setting turned on

The Chrome team’s own advice is to enable the setting yourself. Turn on “Always use secure connections” in Chrome using the path above, then visit your site the way a visitor would, including by typing the address without “https://”.

Open a new window and type your bare domain (for example, example.com) and the “www” version.
Visit the main pages: home, contact, checkout or booking, login, blog posts, and any landing pages used in ads or email links.
Repeat for each subdomain, such as blog., shop., app. or a staging site that is publicly reachable.
Note any warning page, “Not Secure” label or page that looks broken.

Step 2: Confirm every page and subdomain has valid HTTPS

Having a certificate on your main domain is not enough. Each hostname people can reach needs a certificate that covers it. The usual gaps are:

The “www” or non-“www” version is not covered.
An old subdomain (a campaign page, a help desk, a forgotten test site) has no certificate or an expired one.
A custom domain pointed at a landing-page tool or booking system was never set up for HTTPS on that vendor’s side.

Make a simple inventory: every domain and subdomain you own, where it is hosted, and who is responsible.

Step 3: Check certificate renewal with your host

An expired certificate causes a browser warning of its own, regardless of Chrome’s new default. Ask your host, or look in its control panel, for these answers for each site:

Who issues the certificate, and is renewal automatic or manual?
What is the expiry date, and where would a renewal failure notice be sent?
Is the notification email address one someone actually reads?
Does the certificate cover the bare domain, “www” and every subdomain in use?

If you are on a hosting plan where HTTPS is an extra or manual step, that is worth weighing the next time you compare plans; our guide to choosing a hosting plan covers what to look at.

Step 4: Set up HTTP-to-HTTPS redirects in WordPress

Once the certificate works, make sure old HTTP links lead to the secure address. Start inside WordPress. Under Settings > General, the WordPress.org developer documentation says both the WordPress Address and the Site Address “should include the https:// part and should not have a slash / at the end.” If those fields are greyed out, the values are probably set by the WP_SITEURL and WP_HOME constants in wp-config.php, and you will need to change them there. The WordPress.org Settings General documentation confirms that when those constants are defined, the value appears in the field and cannot be edited from the dashboard.

Next, handle requests that arrive over HTTP. Many hosts offer a “force HTTPS” toggle; otherwise a permanent (301) redirect rule at the server level does the job. WordPress’s HTTPS documentation also describes defining FORCE_SSL_ADMIN as true in wp-config.php to force logins and admin sessions over SSL, noting that SSL must already be configured on the server. If your site sits behind a reverse proxy or CDN, the same documentation warns about redirect loops and says the forwarded-protocol header must be handled correctly. For the mechanics of permanent redirects, see our guide to setting up 301 redirects on WordPress safely.

Before you edit URLs or server files, take a fresh copy of the site; our walkthrough on automatic off-site WordPress backups explains how. For database changes, WordPress.org’s migration documentation warns that a plain search and replace can break serialized data, and that the GUID column should never be changed.

Step 5: Find and fix mixed content

Mixed content means a page loads over HTTPS but pulls in some resources, such as images, scripts or stylesheets, over HTTP. MDN explains that browsers split it into upgradable content (for example images and media, which are automatically upgraded to HTTPS) and blockable content (scripts, stylesheets, iframes, fonts and fetch requests, which are blocked). web.dev adds that active content such as scripts can let an attacker take control of the page, while passive content such as images can still be swapped or used to track users.

Type	Examples	Browser behavior (per MDN)
Upgradable	Images, audio, video	Request is upgraded to HTTPS; console warning logged
Blockable	Scripts, stylesheets, iframes, fonts, fetch	Request is blocked; console warning logged

To find the problems, open the page in Chrome, open DevTools and look at the Issues tab, which web.dev says lists insecure and blocked resources with guidance for each. The console shows warnings too. MDN also mentions crawling the site with a mixed-content checker for larger sites.

Typical sources in WordPress

Images and files inserted years ago with http:// links in post content.
Theme or page-builder settings with hard-coded http:// URLs, such as logos, background images or custom CSS.
Old embed codes, tracking scripts or widgets.

MDN’s fix is to serve everything over HTTPS and use HTTPS or relative URLs for internal resources, and to switch external resources to HTTPS where the provider offers it. MDN also describes the Content-Security-Policy directive upgrade-insecure-requests as a migration aid for legacy sites with many HTTP references, but stresses it is not a substitute for fixing the references, and the resource must exist over HTTPS. Treat it as a stopgap.

Key takeaways

Chrome 154, stable since September 22, 2026, asks before loading HTTP sites by default, as the Chrome Security Team announced in 2025.
Visitors to public sites without HTTPS can be asked for permission before the first visit.
Turn the setting on in your own Chrome and test the bare domain, “www” and every subdomain.
Confirm certificate coverage and renewal with your host.
Set both WordPress URLs to https://, add a redirect, and fix mixed content using DevTools.

FAQ

Will my site be blocked completely?

The announcement describes a warning in which Chrome asks for the user’s permission before the first access to a public site without HTTPS. It does not describe a permanent block. Even so, many visitors will not click through, so treat it as a real risk.

Does this affect private or internal sites?

The default described in the announcement targets public sites. Chrome Help lists a separate mode that also warns for private sites, such as an intranet, which users can choose.

Is a plugin enough to fix mixed content?

A plugin may help, but the sources opened for this article recommend fixing the underlying HTTP references. MDN calls upgrade-insecure-requests a migration aid, not a replacement for fixing them.