Website Says “Not Secure”? How to Fix It, and What to Check First

If your website says "Not Secure" in the browser bar, the fix depends on which of three things is happening: the page is loading over plain HTTP, an HTTPS page is pulling in a file over HTTP, or the browser does not trust the certificate. This guide walks a site or store owner through how to fix each one, in the order that usually finds the cause fastest.

You do not need a security team for this. You need a private browser window, the browser's developer tools, and access to your hosting or platform settings.

First, read what the browser is actually telling you

Click the icon to the left of the address. Chrome's help page on checking whether a site's connection is secure separates a plain "Not secure" label from a red "Not secure" or "Dangerous" warning. The first usually means the connection is not private. The second is more serious, and Google advises visitors not to enter personal information on that page.

Then look at the address itself:

• It starts with http://. The page is not using HTTPS at all. Chrome has marked every HTTP page as "Not secure" since Chrome 68 in July 2018, as the Chromium team announced in A secure web is here to stay.
• It starts with https://, but the label still appears. Usually something on the page is loaded over HTTP (mixed content), or a form posts to an HTTP address.
• You get a full-page warning instead of the site. That is a certificate problem, not a label. Expired, issued for the wrong name, or missing part of its chain.

Write down which one you see and on which URL. A homepage that looks fine says nothing about the product page, the cart, or a landing page from last year's campaign.

How to fix "Not Secure" when the page loads over HTTP

If the address bar shows http://, the site either has no certificate or is not sending visitors to the HTTPS version.

1. Check that HTTPS works at all. Type the same address with https:// in a private window. If it loads cleanly, the certificate exists and the problem is the redirect. If it fails, turn on a certificate in your host or platform first. Most hosts and hosted store platforms offer one in their dashboard. Let's Encrypt's FAQ explains how its free certificates work if your host uses them.
2. Redirect HTTP to HTTPS on the server. Google's guidance on moving a site with URL changes, which covers HTTP to HTTPS moves, recommends server-side permanent redirects such as 301 or 308, and redirecting straight to the final URL instead of chaining hops.
3. Update the site's own idea of its address. On WordPress, the WordPress Address and Site Address in the general settings should both begin with https://. The WordPress developer handbook page on HTTPS for WordPress covers the setup in more detail. If you use a CDN or proxy in front of the site, check that its SSL mode matches how the origin server is configured, or you can end up in a redirect loop.

Once every page redirects to HTTPS, you can look at HSTS, which tells browsers to use HTTPS for your domain even if someone types http://. Roll it out carefully. Our guide to HSTS for website owners explains how to do that without locking yourself out of a subdomain that still needs HTTP.

When HTTPS is on and the page still says "Not Secure"

This is the case owners find most confusing, because the certificate looks fine. The usual cause is mixed content: the page itself arrives over HTTPS, but an image, script, stylesheet, font, iframe, or form target still uses an http:// address.

MDN's page on mixed content explains that browsers try to upgrade some of these requests, such as images, audio, and video, to HTTPS and block the rest. In practice that means two different symptoms. Sometimes the page looks normal but the padlock is downgraded. Sometimes a script or embed is blocked, and a menu, slider, chat widget, or checkout step quietly stops working.

To find the file:

1. Open the page in a private window.
2. Open the browser's developer tools and look at the Console. Mixed content warnings name the exact http:// URL.
3. Reload with the Network tab open and filter for "http:" to catch anything the console missed.
4. Repeat on the pages that matter most to you: product pages, cart, checkout, contact forms, and any promo landing page.

To fix it, change each reference at the source. Google's web.dev guide to fixing mixed content suggests checking whether the resource is available at the https:// version of the same URL, and if it is, updating the link in your code or content. If it is not available over HTTPS, host the file yourself or find another provider.

Common places for old http:// links: images pasted into old posts, theme settings, page-builder blocks, hard-coded footer scripts, and third-party embeds. On WordPress, a search-and-replace tool can update old URLs in the database. Take and test a backup first, because a database-wide replace is hard to undo.

The Content-Security-Policy directive upgrade-insecure-requests, documented on MDN, tells the browser to request HTTP resources over HTTPS. It can be a useful safety net, but it only works if each resource is actually available over HTTPS. It does not fix the source, so keep fixing the links.

When the browser blocks the page with a certificate warning

A full-page warning means the browser does not trust the certificate. Owner-side causes you can check:

• Expired certificate. Look at the expiry date in the certificate viewer. If auto-renewal failed, find out why before you renew by hand, or it will happen again.
• Wrong name. A certificate for example.com does not automatically cover www.example.com or shop.example.com. Check every hostname you actually use.
• Incomplete chain. The server should send the intermediate certificates too. Let's Encrypt's certificate compatibility notes are a reminder that older devices may trust certificate chains differently.

The OWASP Transport Layer Security Cheat Sheet covers the server-side settings in depth, for you or your developer.

Do not tell customers to click through the warning. If a visitor's device clock is wrong, or their network inspects traffic, they may see warnings your other visitors do not. That is worth knowing, but rule out the causes on your side first.

What this check does and does not prove

Walking these steps shows that the pages you opened, at that moment, loaded over HTTPS with a trusted certificate and without mixed content. It does not prove the site is secure. A padlock means the connection is encrypted. It says nothing about outdated plugins, weak admin passwords, or a malicious script that is itself served over HTTPS. If you want the bigger picture of what HTTPS does and does not cover, our post on whether www or HTTPS is safer explains it.

Re-check after any theme change, new app or plugin, CDN change, or certificate renewal. Those are the moments a "Not Secure" label usually comes back.

A free outside-in scan, if you want a second look

We build HackerMe, a free outside-in website security scanner owned by Agura. If you want a second look at TLS settings, HTTPS redirects, and security headers, you can run a free scan of a domain you own or have explicit permission to test. The scan reports what it observed from outside on that run. It cannot see inside your server or admin panel, and it does not replace checking your key pages in a browser.

Read the browser first. Fix the cause it points to. Then check again on the pages your customers actually use.

Originally published on the HackerMe Substack.