How to Fix a Not Secure Warning on Your Website

Few things damage a visitor's trust as quickly as the words "Not Secure" sitting next to your web address. They don't know whether it means a missing certificate or a hacked site — they just see a warning on the page where they were about to type their email or card number, and most of them leave.

The good news: this is one of the easiest website problems to diagnose. The warning has a small, fixed set of causes, and you can work through them in order. This guide shows you how to find which cause applies to your site and fix it — usually in under an hour.

The Quick Answer: The Warning Means Your Page Isn't Fully HTTPS

Chrome started labelling plain-HTTP pages as "Not Secure" back in July 2018, as part of Google's push toward an encrypted web. The label means the browser cannot confirm a complete, encrypted HTTPS connection for that page. Either the page was loaded over unencrypted HTTP, or HTTPS was attempted but something about the certificate or the page's resources failed the check.

The warning levels — and what each one tells you

Browsers don't show just one warning. The style of the warning is itself a diagnosis:

Click the icon or the "Not secure" text to the left of the address bar. Chrome shows a short explanation there, and the certificate details are one more click away. That panel alone often names your cause.

Cause 1: No SSL Certificate Installed

The most common reason, especially for new sites: the server simply has no certificate, so every page loads over HTTP.

How to confirm in 30 seconds

1. Open your site and look at the address bar — if it starts with http:// (no "s"), that's your answer.
2. Type https:// in front of your domain manually and hit enter. If the HTTPS version fails or shows a certificate error, the site has no valid certificate installed.

How to get a certificate

You have three routes, and the first one is free:

• Free certificates (Let's Encrypt). Let's Encrypt is a free, automated certificate authority — the most widely used CA on the internet since launching in 2015. Certificates are domain-validated (DV), trusted by all major browsers, and valid for 90 days with automatic renewal. Many hosting control panels (cPanel, Plesk) install them in a couple of clicks.
• Host-provided SSL. Many hosts bundle certificate installation and renewal into their plans — check your hosting panel's security section before buying anything separately.
• Paid certificates. Worth considering if you need organization validation (OV) or extended validation (EV) — the kind that verifies your company identity, not just domain control. Let's Encrypt only issues DV certificates.

Once the certificate is installed and the site loads over HTTPS, the grey "Not secure" label disappears.

Cause 2: Expired Certificate

This is the classic "it worked last week" scenario. Certificates have fixed lifetimes — Let's Encrypt certificates last 90 days, paid ones typically one year — and when one lapses, browsers flip the warning on overnight.

Checking the expiry date

Click the "Not secure" text or the icon in Chrome's address bar, then Certificate (or "Connection is secure" → "Certificate is valid" on a working page). The details panel shows the exact expiry date. If it's in the past, you've found your cause.

Renewing — and why auto-renewal matters

Renewal itself usually takes minutes: reissue through your host's panel or, with Let's Encrypt, let Certbot handle it automatically. The real lesson is the 90-day lifetime — if renewal isn't automated, it will eventually break silently. After renewing, confirm auto-renewal is actually enabled (a cron job or panel setting), and set yourself a calendar reminder a week before the next expiry as a safety net. If your site went down because of a lapsed cert once, it will happen again without automation.

Cause 3: Certificate Doesn't Cover Your Domain

Your certificate can be perfectly valid and still trigger the warning — because it was issued for a different name than the one visitors use.

The www vs non-www trap

This is the single most common version of the problem: the certificate covers example.com but not www.example.com (or vice versa). A visitor who types the "wrong" version gets the full-page "Your connection is not private" error. When requesting a certificate, always include both the root domain and the www version as subject alternative names.

Subdomains and how to cover them

The same applies to blog.example.com, shop.example.com, and any other subdomain you actually use. Options:

• A wildcard certificate (*.example.com) covers all first-level subdomains with one cert — Let's Encrypt supports these via DNS-based verification.
• A multi-domain (SAN) certificate lists each specific hostname explicitly.
• Or simply issue separate certificates per subdomain.

Check which hostnames your current certificate covers in the certificate details panel — the mismatch is usually visible in seconds.

Cause 4: Mixed Content

This one confuses people because the certificate is fine: HTTPS works, but Chrome still shows a warning. The reason is mixed content — the page itself loaded over HTTPS, but some of its resources (images, scripts, fonts, stylesheets, videos) were requested over plain HTTP.

Mixed content is extremely common after a site migrates from HTTP to HTTPS without updating old links: the theme, database, or media library still references http:// URLs, and the browser either blocks those resources or downgrades the page's security indicator.

Finding the insecure files with DevTools

1. Open the affected page in Chrome and press F12 to open Developer Tools.
2. Go to the Console tab.
3. Look for messages mentioning "mixed content" — Chrome lists the exact file URLs still loading over HTTP.

This tells you precisely what to fix instead of guessing.

Fixing old http:// links

• Simple sites: open the page source and replace http://yourdomain with https://yourdomain in image src, script src, and stylesheet href attributes.
• WordPress sites: the old URLs live in the database (posts, media library, widgets). Use a search-and-replace tool on the database (many migration plugins include one), update the Site Address and WordPress Address under Settings → General to https://, and check your theme and plugin settings for hardcoded HTTP URLs.
• Third-party embeds: if an external widget or ad script only offers an HTTP version, replace it — modern services all support HTTPS.

After fixing, hard-refresh (Ctrl+F5) and re-check the Console. When it's clean, the padlock returns.

Cause 5: Missing HTTP-to-HTTPS Redirect

Even with a perfect certificate, visitors who type http:// (or follow an old HTTP link) land on the insecure version — and see the grey "Not secure" label. The fix is a 301 redirect that pushes every HTTP request to HTTPS.

On Apache servers, this goes in .htaccess in your site root:

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

(WordPress users: many security/SSL plugins add this redirect for you — check the plugin settings before editing files by hand.)

Google has confirmed that 301 or 302 redirects from HTTP to HTTPS cause no loss of page rank, so there's no SEO reason to hesitate. HTTPS has been a Google ranking signal since 2014, which means the redirect can only help.

Rare Causes: Incomplete Chain and Self-Signed Certificates

Two less common culprits, worth knowing in case the first five don't apply:

• Incomplete certificate chain. Browsers trust your certificate because it chains up to a root authority — but the server must also send the intermediate certificates in between. If the host installed your certificate without its intermediates, some browsers show an error while others don't (the inconsistency is the signature of this problem). Reinstalling with the full chain — usually provided as a "CA bundle" — fixes it.
• Self-signed certificate. Fine for local development, useless in production: browsers don't trust certificates you signed yourself. Replace it with one from a public CA like Let's Encrypt.

An external SSL checker (search for "SSL Labs SSL Server Test") grades your installation and flags chain problems explicitly — useful when you've exhausted the obvious causes.

The Full Fix Checklist

Work through this list top to bottom. When every item checks out, Chrome stops showing the warning:

• [ ] SSL certificate is installed and active
• [ ] Certificate has not expired
• [ ] Certificate covers every hostname you use (www and non-www, subdomains)
• [ ] Certificate chain is complete (no missing intermediates)
• [ ] HTTP requests redirect to HTTPS site-wide (301)
• [ ] Site/home URLs use https://
• [ ] Internal links point to HTTPS
• [ ] No mixed content (Console is clean)
• [ ] Forms submit data over HTTPS
• [ ] Third-party assets load over HTTPS
• [ ] Padlock appears in the address bar, no DevTools warnings

Frequently Asked Questions

Is it safe to visit a website that says "Not Secure"?

Reading a plain page is low risk. Entering information is not. Never type passwords, card details, or personal information into a page showing this warning — that data travels unencrypted and can be intercepted by anyone on the same network, and public Wi-Fi makes interception much easier. If you only need to read, you're fine; if the site asks for data, wait until the owner fixes it.

Why does my website say "Not Secure" even though I have an SSL certificate?

Four usual causes: mixed content (some page elements still load over HTTP), a missing HTTP-to-HTTPS redirect (visitors land on the old HTTP version), an incomplete certificate chain (the intermediate certificate was never installed), or a hostname mismatch — the certificate was issued for example.com but the visitor opened www.example.com, or vice versa. The checklist above covers all four.

Why did my site become "Not Secure" overnight when it worked last week?

Almost always an expired certificate. Less common triggers: a plugin or CMS update that overwrote your HTTPS settings, or a recent hosting migration where the certificate wasn't carried over. Check the expiry date first (click the warning → Certificate). Renewal takes minutes, but set up auto-renewal so it doesn't happen again.

Will moving to HTTPS hurt my search rankings?

No. Google has confirmed that redirects from HTTP to HTTPS do not cause a loss of page rank, and HTTPS itself has been a ranking signal since 2014. The far bigger ranking risk is staying on HTTP — visitors bounce when they see the warning, and Google prefers secure pages.

How long does it take to fix the "Not Secure" warning?

Usually under an hour. If your host offers one-click certificate installation (most do, often with free Let's Encrypt certificates), the certificate itself takes minutes. Mixed content cleanup is the part that varies — a small site takes ten minutes, a large WordPress site with years of old media links can take longer.

I fixed everything but Chrome still shows the warning. Why?

Three things to check: (1) browser cache — hard-refresh with Ctrl+F5, or test in an incognito window; (2) the redirect — type the http:// version manually and confirm it actually lands on https://; (3) DevTools Console — one overlooked http:// image is enough to keep the warning alive. If all three are clean, test with an external SSL checker to rule out a chain issue.

Setting up a new site and want SSL handled from day one? Read our guide to choosing a hosting plan before you buy — SSL setup and renewal is one of the details worth checking in any plan's fine print.