Website Not Secure? What It Means + 4 Fixes
)
Every browser now passes judgment on your site before a visitor reads a single word. Chrome prints Not Secure next to your address, Safari warns the connection is not private, and on a phone the warning fills the screen with a scary full-page interstitial. Visitors do not parse the technical details; they see a warning next to your business name and hit back. The cause is almost always one missing or misconfigured certificate, and the fix is usually free and done in under an hour. This guide walks the four fixes in order of likelihood, with a check to confirm each one worked.
A visitor types in your address, your site loads, and before they read a single headline the browser tells them not to trust you. "Not Secure", right there in the address bar. Chrome has shown that label on every plain HTTP page since version 68 shipped in July 2018, and Safari, Edge, and Firefox all do a version of the same thing.
Here is the part most guides skip: the warning almost never means you were hacked. It means the connection between your visitor's browser and your site is not encrypted, so anything they type (a contact form, an email address, a password) travels as readable text. Browsers punish that, and so does Google, which has used HTTPS as a ranking signal since 2014.
What does "Not Secure" mean on a website?
In plain terms: the browser could not set up an encrypted connection to the page, or set one up but caught something on the page loading without it. It is a statement about the connection, not a verdict that the business is a scam or that the site is infected. When the address starts with http:// instead of https://, nothing you send to that page is scrambled on the way, which is why browsers flag it the moment a page asks for an email address or a password.
One variant confuses people: the certificate is valid, the address says https://, and Chrome still says "not secure" or shows a padlock with a warning. That is not a certificate problem. It almost always means mixed content, which is Step 4 below.
The good news is that there are only four common causes, and they are easy to tell apart. Work through them in order. Most sites are fixed at step 1 or step 4.
What the warning looks like (and what the fix looks like)
Here is the difference between an HTTP site and an HTTPS site in Chrome's address bar.
)
)
Step 1: Install a certificate (if you have none)
An SSL/TLS certificate is what lets your site speak HTTPS. Fifteen years ago these cost real money. Today they are free through Let's Encrypt, a nonprofit certificate authority that issues certificates for hundreds of millions of websites.
Log in to your hosting control panel and look for "SSL", "Security", or "Let's Encrypt". Nearly every host (Bluehost, SiteGround, Hostinger, and the rest) has a one-click enable button on this screen.
Enable the certificate for both yourdomain.com and www.yourdomain.com. This matters for Step 3.
Turn on the "Force HTTPS" or "HTTPS redirect" option on the same screen so visitors who type the old http:// address get sent to the secure version automatically.
How to verify: open your site in a private browsing window and check the address bar shows https:// with no warning. Then paste your domain into the free Qualys SSL Labs test. Anything graded B or above means the certificate itself is fine.
Step 2: Renew an expired certificate
Certificates have a shelf life. Let's Encrypt certificates last 90 days and are meant to renew automatically. When you see "certificate expired", the renewal robot at your host has stalled.
In your hosting panel's SSL screen, look for the expiry date. If it is in the past, click renew or reissue.
Check that auto-renewal is switched on. If the panel shows renewal errors, the most common cause is a domain that no longer points at that host (see Step 3).
If you bought a paid certificate years ago, consider letting it lapse and switching to the free auto-renewing kind. Manual renewal is how sites end up here every year.
How to verify: click the padlock, open certificate details, and confirm the "valid until" date is in the future. Set a calendar reminder 2 weeks before it, once, to confirm auto-renewal actually worked the first time.
Step 3: Fix a domain mismatch
A certificate is issued for specific names. If it covers yourdomain.com but a visitor arrives at www.yourdomain.com (or the other way round), the browser treats it as the wrong ID and shows a full-page warning.
Decide your canonical address: with www or without. Either is fine; pick one.
Reissue the certificate so it covers both names. Most host panels do this by default; look for both names listed on the SSL screen.
Set a 301 redirect from the non-canonical name to the canonical one so every visitor and every search engine ends up in the same place.
How to verify: type all four variants into the browser (http://, https://, with and without www). All four should land on the same secure address with no warnings.
Step 4: Clear mixed content (the sneaky one)
This is the case where you already installed a certificate, the padlock should be there, and the browser still says the page is not fully secure. The cause is almost always mixed content: your page loads over HTTPS but one or more things on it (an image, a font, a script, an embedded widget) still loads over plain HTTP.
Open the problem page in Chrome, right-click, choose Inspect, and click the Console tab.
Look for lines that start with "Mixed Content: The page was loaded over HTTPS, but requested an insecure resource". Each line names the exact file at fault.
Fix each one at the source: edit the page or theme setting and change the address from http:// to https://. Old logo files, YouTube embeds pasted years ago, and third-party widgets are the usual suspects.
If the resource has no https:// version at all, replace it or delete it. A page is only as secure as its least secure part.
Google's developer team keeps a thorough reference on this in Fixing mixed content if you hit an unusual case.
How to verify: reload the page with the Console open. No mixed content lines and a clean padlock means you are done.
| What the browser says | What it actually means | Your step |
|---|---|---|
| Not Secure (grey text) | Page loaded over plain HTTP, no encryption | Step 1 |
| Your connection is not private (cert date invalid) | Certificate expired | Step 2 |
| Your connection is not private (common name invalid) | Certificate issued for a different name | Step 3 |
| Padlock with warning / "not fully secure" | Page is HTTPS but loads insecure files | Step 4 |
Worth your time
One-click Let's Encrypt via your host
Force-HTTPS redirect turned on
Certificate covering www and non-www
A single Console check for mixed content after big edits
Not worth your money
Paid "premium" certificates for a small business site (encryption strength is identical)
Site seals and trust badges sold as security
Annual manual renewal when free auto-renewal exists
"SSL fix" services charging for a 10-minute panel setting
The padlock is not a technical detail. It is the first trust decision a visitor makes about your business, and it happens before they read a single word.
"I clicked on a Not Secure website." Am I at risk?
Plenty of people land on this page from the other side of the screen, so here is the visitor answer. Simply opening a Not Secure page does not infect your device or leak your data. The risk is what you type: anything entered on an HTTP page (passwords, card numbers, your address) can be read by someone on the same network, which is a real concern on public Wi-Fi. Reading is fine; typing anything sensitive is not. Google's own guidance on checking whether a site's connection is secure says the same thing. If the warning is the full-page red "Your connection is not private" screen, treat it more seriously and do not click through unless you know the site.
If you are the site owner, this is exactly why the warning costs you customers: your visitors have been taught to leave. It is also one of the first items flagged in any audit; our guide to reading an SEO audit report shows where it sits among the fixes worth doing first.
Or skip the whole checklist
Everything above assumes you are running your own hosting stack, because that is where these problems live. Modern managed platforms handle it for you: every StoryPress site ships with HTTPS on from day one, certificates that renew themselves, and no plugin or panel setting that can silently expire. If you would rather never think about padlocks again, that is the simplest fix of all.
Either way, do the SSL Labs check today. It takes two minutes, and "Not Secure" is the one website problem where every single visitor sees the damage.
One practical website fix in your inbox each week
The Client Handoff That Stops Late-Night Edits
There is a version of every agency where half of Tuesday disappears into two-line copy edits for sites that launched months ago. The client cannot change a headline without you, so every typo becomes an email, every seasonal update becomes a ticket, and neither side is happy about the arrangement. The problem is not the client; it is a handoff that made you the only person who can touch the site. This guide covers the handoff that ends it: what to set up before launch, what to teach in the last meeting, which platforms make client editing safe, and where the line sits between edits and rebuilds.
Sitemaps and Robots.txt: A 5-Minute Check
Two small text files quietly govern how search engines treat your entire site. The sitemap lists every page you want found; robots.txt sets the rules for what crawlers may read. Most owners have never opened either, which is usually fine, until a redesign ships a robots file that blocks the whole site, or a sitemap keeps advertising pages deleted a year ago. Errors here are silent: nothing looks broken to a visitor while your pages fall out of the index. This guide is the five-minute check: where the files live, what healthy ones look like, and the mistakes worth fixing today.