Website says “Not secure” in Chrome: causes and how to fix it

“Not secure” is not “Dangerous site”

Chrome shows different warnings for different problems, and it pays not to mix them up:

• “Not secure” next to the address: the page does not use a private connection (HTTPS). Whatever is sent can be read or changed on the way. It is a configuration problem.
• “Your connection is not private” as a full-page warning: the certificate has a problem (expired, issued for another domain, issued by someone who should not) or something is wrong on the network.
• “Connection is not secure” before you get in: it appears when the browser has “Always use secure connections” turned on and the site has no HTTPS.
• A red “Dangerous site” or “Deceptive site ahead” screen: Google Safe Browsing has detected malware or phishing. This one is a hack, and it is covered in the guide Google says my site is dangerous.

On top of that, Google announced that with Chrome 154, in October 2026, “Always use secure connections” is turned on by default for public sites: before the first visit to a site without HTTPS, Chrome asks the user for permission. A site without HTTPS goes from carrying a discreet label to interrupting the visit.

Cause 1: the site has no HTTPS

This is the most common one on older sites. If your address starts with http://, everything sent travels unencrypted and Chrome flags it. The fix is to install a TLS certificate (what everyone calls “SSL”):

1. Turn on the certificate in your hosting. Almost every provider offers free Let's Encrypt certificates with automatic renewal; in cPanel it is usually under SSL/TLS Status or AutoSSL. You do not need to buy one for a normal website or for an online store.
2. Redirect all HTTP traffic to HTTPS with a permanent (301) redirect, so nobody stays on the unencrypted version.
3. Change the site's URLs. In WordPress, under Settings → General, “WordPress Address (URL)” and “Site Address (URL)” must start with https://. In PrestaShop, under Shop Parameters → General, enable SSL and SSL on all pages.
4. Update the internal links stored in the database (next section).

On Apache, the redirect in .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

If your site sits behind Cloudflare or another proxy, this rule can create a redirect loop; in that case, turn on the redirect in the proxy itself.

Cause 2: expired or invalid certificate

The site had HTTPS and one day it starts throwing errors. The usual reasons:

• It has expired and the automatic renewal failed (a change of DNS, hosting or server).
• It does not cover the name being visited: the certificate is for your-site.com and the visit arrives at www.your-site.com, or the other way round. Both names must be on the certificate.
• The intermediate certificate is missing: it works in some browsers and not in others. Typical of certificates installed by hand.
• The visitor's computer clock is wrong. If only one person gets the error, that is the first thing to check.

Renewing by hand is no longer realistic. Since March 15, 2026, new public certificates last at most 200 days, and the CA/Browser Forum approved cutting that in stages down to 47 days in 2029. With timelines like that, renewal has to be automatic.

Cause 3: mixed content

The page loads over HTTPS, but inside it requests resources over http://: an image, a script, a font, a form that submits to an unencrypted address. It happens all the time after moving to HTTPS, because the database is still full of old links.

Current browsers try to load images, audio and video over HTTPS, and block scripts, stylesheets, frames and fonts that arrive over HTTP. The result can be a site that loses its design, a cart that does not work, or a padlock that never quite shows up.

How to fix it:

• Find it: F12 → Console tab. Each mixed resource shows up with its exact address.
• In WordPress, change the URLs in the database with WP-CLI (first with --dry-run to see what would change) or with a search-and-replace plugin that respects serialized data:

wp search-replace 'http://your-site.com' 'https://your-site.com' --dry-run

• Check the theme and the plugins: sometimes the address is written in the code or in the theme options (logo, background, custom scripts).
• As a safety net, the Content-Security-Policy directive upgrade-insecure-requests tells the browser to turn every request into HTTPS. It does not replace fixing the links, but it covers the ones that slip through. I explain it in the guide to security headers.

How to check the certificate

In Chrome: click the icon to the left of the address, then “Connection is secure” and “Certificate is valid”. You will see which names it was issued for, who issued it and until what date it is valid.

From the terminal (OpenSSL ships with macOS and Linux, and with Git on Windows):

openssl s_client -connect your-site.com:443 -servername your-site.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -ext subjectAltName

notAfter is the expiry date and subjectAltName is the list of names it covers. If www or the bare domain is missing, that is your problem.

The free scan checks the certificate, its expiry, the redirect to HTTPS, HSTS and mixed content on the home page.

After moving to HTTPS

With the padlock in place, a few loose ends are left that people tend to forget and that affect both search rankings and security:

• Search Console: if you had the property verified as a URL prefix with http://, add the https:// version too (or verify the whole domain with a DNS record, which covers both). Submit the sitemap again.
• Sitemap and canonical: check that the sitemap and the canonical tags of your pages use https://. Many SEO plugins do it on their own when the site address changes, but not all of them.
• Redirect chains: http://www → https://www → https:// is three hops. Ideally, any variant reaches the right one in a single redirect.
• HSTS: once everything has worked over HTTPS for a few days, add the Strict-Transport-Security header so the browser never tries the unencrypted version again. Start with a short value.
• External tools: Google Analytics, Google Ads, social media profiles and your Google Business Profile listing often keep the old address. Update them to save a redirect on every visit.
• Emails and invoices: the store's email templates and invoice PDFs sometimes carry the address typed in by hand.
• robots.txt and llms.txt: the Sitemap: line in robots.txt and the links in llms.txt use full addresses; change them to https://. What llms.txt should contain is in the llms.txt guide.

And keep an eye on certificate renewal. What I see most is not a site that never had HTTPS, but one that had it and lost it after a DNS or hosting change broke the automatic renewal. An email alert before expiry (many hosting providers send one) gives you time to react.

When the warning is red

If what you see is not the gray “Not secure” label but a red screen saying the site is dangerous or deceptive, the problem is not the certificate: Google has detected malware, phishing or unwanted software on your site. No certificate removes it. The site has to be cleaned and a review requested in Search Console; I explain it step by step in Google says my site is dangerous, and if you need me to handle it, see hacked website repair.

Sources

• Chrome Help: check if a site's connection is secure
• Google: HTTPS by default in Chrome
• MDN: mixed content
• CA/Browser Forum: ballot SC-081 on certificate validity periods