"Not secure" warning on your website? How to fix HTTPS before Chrome warns your visitors

A website security warning can mean the page uses plain HTTP, the HTTPS certificate has a problem, or some resources load insecurely. The exact warning matters: these are different faults. The fix is to serve every page over HTTPS with a valid certificate, permanently redirect the old HTTP addresses, and update any links or files still using http://. Google confirmed on 21 October 2026 that Chrome now asks permission before insecure HTTP connections by default. An HTTP-only public site can therefore put a warning between a visitor and your page. (Google Chrome Security)

Below is how to check your site, what to fix in what order, and how to manage the search implications without assuming rankings will stay unchanged.

What changed in Chrome

Chrome's 21 October 2026 announcement confirms that its “Always Use Secure Connections” protection has rolled out to all users by default, after an earlier rollout to people using Enhanced Safe Browsing. Chrome attempts HTTPS and asks permission before proceeding with an insecure HTTP connection.

• Once a user approves HTTP for a site, Chrome does not warn again until they have gone at least two weeks without visiting it.
• By default, private addresses such as local router IPs and single-label intranet names are excluded.
• Settings and managed-browser policies can affect behaviour, so not every visitor will see the same warning.

(Google Chrome Security, 21 October 2026; Chrome 154 release notes, checked 26 October 2026)

The release notes list 22 September 2026 as Chrome 154's stable release date and include HTTP prompting by default. The later October announcement confirms the rollout; it is more useful for current status than the original 2025 plan.

For a business, the practical point is simple: a visitor using applicable Chrome settings may see a warning before an HTTP-only public page. Fix the underlying connection rather than asking customers to bypass it.

Does HTTPS affect Google rankings?

Google's current page-experience guidance asks whether pages are served securely, but it also says that page-experience aspects beyond Core Web Vitals do not directly help a website rank higher. Do not treat HTTPS as a promised ranking boost. (Google Search Central, Understanding page experience, updated 22 September 2026)

The reason to fix HTTPS is to protect connections and remove avoidable warnings, not to rescue weak content or guarantee more search traffic.

Step 1: Check what's actually wrong

Open your website in Chrome and click the site-controls icon to the left of the address to inspect connection information. Chrome replaced its address-bar padlock with a tune-style icon; a missing padlock alone is not a fault. (Chromium Blog, lock icon update)

Check all four versions of your address: http://example.com, http://www.example.com, https://example.com and https://www.example.com. For hostnames you use or accept traffic on, configure a valid certificate and redirects to the preferred HTTPS address. Test each page path too, not just the homepage.

If you use Search Console, the HTTPS report (available for Domain properties and HTTPS URL-prefix properties) shows how many of your indexed pages are HTTP versus HTTPS, and why an HTTPS version couldn't be indexed — for example, an invalid certificate, an HTTP canonical tag, a sitemap that still lists HTTP addresses, or an HTTPS page that redirects back to HTTP. (Search Console Help, HTTPS report, checked 26 Oct 2026)

Step 2: Get a valid certificate, and make sure it renews

A TLS certificate (often still called an SSL certificate) is what allows your site to load over HTTPS.

• Check your host or website builder first. Ask whether your plan includes an automatically renewed certificate. Look for an “SSL” or “HTTPS” setting and confirm that renewal is working; do not assume it is included or enabled.
• Cover every version of your domain. The certificate should include both example.com and www.example.com if both are in use.
• Turn on automatic renewal. Publicly trusted TLS subscriber certificates issued from 15 March 2026 have a maximum validity of 200 days. That becomes 100 days for certificates issued from 15 March 2027, and 47 days from 15 March 2029. Existing certificates are not retroactively shortened by these dates. (CA/Browser Forum, section 6.3.2)
• Check your issuer's own schedule. Let's Encrypt's default profile moves to 64-day certificates on 10 February 2027 and 45-day certificates on 16 February 2028; an opt-in profile already offers 45-day certificates. Verify that renewal automation handles shorter lifetimes and alerts you if renewal fails. (Let's Encrypt)

If a paid certificate was bought years ago through a former developer, find out where it's managed and who receives the expiry emails. An expired certificate can cause a full-page warning.

Step 3: Redirect every HTTP address to HTTPS

Once HTTPS works, the old HTTP addresses need to send visitors and Google to the HTTPS version.

• Use permanent server-side redirects (301 or 308) from each HTTP URL to the matching HTTPS URL — page to page, not everything to the homepage.
• Avoid chains. http://example.com/services should go straight to https://www.example.com/services, not hop through two or three redirects.
• Keep the redirects long-term. Google treats HTTP to HTTPS as a site move with URL changes and advises keeping redirects for as long as possible, generally at least a year. (Google Search Central, Site moves with URL changes, checked 26 Oct 2026) In practice, leave them in place permanently.
• No Change of Address needed. Search Console's Change of Address tool is for moving to a new domain. Google says you don't need it for HTTP to HTTPS moves. (Google Search Central)

Check your platform's HTTPS and redirect documentation. Some provide a “Force HTTPS” switch; others require host or developer configuration. Back up settings and test important pages and forms after changing them.

Google warns that rankings can fluctuate temporarily during a move; the size and duration are not guaranteed. Where practical, plan the change for a quieter period and monitor indexing and traffic afterwards. (Google's site-move guidance)

Step 4: Fix mixed content

Mixed content is when an HTTPS page loads something — an image, script, stylesheet, font or embedded form — over http://. Browsers increasingly upgrade or block these requests: images may be upgraded automatically if they exist on HTTPS, while insecure scripts are blocked, which can break features such as sliders, booking widgets or contact forms. (web.dev, Fixing mixed content, checked 26 Oct 2026)

How to find and fix it:

1. Open Chrome DevTools (right-click > Inspect > Console) on each important page. Mixed content warnings are listed there.
2. Search your content for http://. Check resource URLs in posts, page-builder content and theme settings. An ordinary link that navigates to another HTTP page is not itself mixed content; a resource loaded into the current HTTPS page is.
3. Change each resource to https:// if it's available there. If it isn't, host the file yourself (where you're allowed to), find another provider, or remove it.
4. Check embeds and third-party tools — old maps, video embeds, chat widgets and form scripts are common culprits.

A developer can add the upgrade-insecure-requests Content Security Policy directive, using Content-Security-Policy: upgrade-insecure-requests, to request secure versions automatically. It's useful as a safety net, but resources that don't exist on HTTPS will simply fail to load, so it doesn't replace fixing the links. (web.dev)

Step 5: Tidy up the signals Google sees

After the switch, make sure your site consistently points to HTTPS:

• Canonical tags should use the HTTPS address. An HTTP canonical tag is one of the reasons Search Console lists for keeping the HTTP version indexed. (Search Console Help, HTTPS report)
• Internal links in menus, footers and body text should use HTTPS (or relative links), so they don't rely on redirects.
• Your XML sitemap should list only HTTPS URLs. Submit it in Search Console.
• Search Console property: a Domain property covers both HTTP and HTTPS. If you only have an old http:// URL-prefix property, add the HTTPS version or a Domain property so you can see the right data. Our Search Console set-up guide walks through this.
• Everywhere else your address appears: your Google Business Profile, social media bios, email signatures, ads and directory listings. Redirects will catch old links, but updating them avoids an unnecessary hop.

Avoid combining a protocol move with unrelated redesign or URL changes where possible; Google's guidance recommends changing one thing at a time. If a wider project is necessary, use our website redesign SEO checklist.

A hypothetical example

[Business name], a small tuition centre, has a website built several years ago on http://. After Chrome's change, a parent who clicks the link from a WhatsApp message may see a warning before the homepage loads.

The fix might look like this: turn on the free certificate in the hosting panel for both www and non-www; switch on "Force HTTPS"; search the site for http:// and update a dozen old image links and a timetable embed; update the canonical tags and sitemap; add a Domain property in Search Console; and update the website link on social profiles. The next week, check the HTTPS report and the four address versions again.

This example is illustrative; the exact steps depend on the platform and host.

What's in your control, and what isn't

In your control: whether your site has a valid certificate that renews automatically, clean redirects, no mixed content, and consistent HTTPS links, canonicals and sitemaps.

Not in your control: how browsers present warnings, how individual visitors respond to them, and how Google ranks your pages. Fixing HTTPS removes a barrier; it doesn't guarantee more traffic or better rankings.