“Not secure” in the address bar is about one thing: whether the connection between your visitor and your site is encrypted. Your site has no certificate, the certificate ran out, or one file on the page is still being pulled the old way. None of the three means somebody broke into your site, and none of them is a reason to rebuild it.
What the browser is actually saying
Google’s Chrome help page lists what each marking in the address bar means. For a site with no private connection it says: “The site doesn’t use a private connection. Someone may be able to view and change the information you send and get through this site.” That page carries no update date.
Read that again. It warns about the road between the customer’s phone and your site. It does not say your site is infected. The same page keeps that separate from the marking Chrome uses for a site flagged as dangerous, where the wording is: “We suggest you don’t enter any private or personal information on this page. If possible, don’t use the site.” Not secure is the road. Dangerous is the building.
This has been going on a while. Google wrote on July 24, 2018 that “Starting in the latest version of Chrome (68), you’ll see a new ‘not secure’ notification when visiting HTTP pages.” In that same post Google said “83 of the top 100 sites on the web use HTTPS by default, up from 37”. That was eight years ago, and the warning has not gone anywhere since.
The three things that cause it
- No certificate at all. The site still answers on http:// and one was never installed.
- An expired certificate. There was one and it ran out. Either renewal was manual and nobody did it, or the automatic renewal broke quietly and nobody was told.
- Mixed content. The page itself loads over https, but something inside it still points at http. One old image link in the footer can do it.
There is a fourth, less common one. A certificate lists the exact names it covers. If yours covers yourname.com but not www.yourname.com, some visitors see a warning and some do not, depending on what they typed.
On mixed content, be careful what you assume. Mozilla’s developer documentation, last modified August 15, 2026, says browsers “mitigate the risks of mixed content by auto-upgrading image, video, and audio mixed content requests from HTTP to HTTPS, and block insecure requests for all other resource types.” So treat mixed content as a broken page problem first and an address bar problem second. A blocked file means part of your site does not show up, and you may never notice it on your own laptop.
How to find out which one it is
Four checks, in order. All free, and you can do the first three yourself in a few minutes.
- Type your address with https:// in front of it. If that version loads clean, the certificate is there and the problem is the redirect. Visitors are landing on the old http address and staying there.
- Try it both ways: yourname.com and www.yourname.com. If only one of the two warns you, it is a name coverage problem.
- Click the icon just left of the address, open the connection details, and find the certificate expiry date. That date is a real number you can go read for yourself right now. If it sits in the past, that is your whole answer.
- If all of that looks fine and the warning shows on one page only, ask your host or your web person to open the browser console on that page and read off the mixed content warnings. That one needs a technical eye.
Getting it fixed, and what it should cost
Start in your hosting control panel and look for a certificate setting before you spend anything.
The certificate itself does not have to cost money. Let’s Encrypt’s FAQ, last updated April 28, 2025, says plainly: “We do not charge a fee for our certificates.” It also says “Our default certificates are valid for 90 days” and “We recommend renewing 90 day certificates every 60 days.” Subscribers can opt in to short-lived certificates valid for six days instead.
So here is the honest part. If your host already includes a free certificate, do not buy one. And do not let anyone sell you a whole new website to fix a padlock. A missing certificate is a setting, not a rebuild. If a quote for fixing “Not secure” runs to four figures, get a second opinion first. What a build should actually cover is on the pricing page.
One thing this article does not cover. If you take card payments on your own site, the rules around handling card details are a separate subject. This is not legal or tax advice, and the rules differ from state to state, so ask your payment processor and an attorney in your own state what applies to you.
Why the renewal window keeps shrinking
Certificate authorities that browsers trust all work to one rulebook, the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates. The current version, 2.2.9, is dated August 6, 2026. It sets a schedule worth knowing about:
- From March 15, 2026, the maximum validity period of a subscriber certificate is 200 days.
- From March 15, 2027, it drops to 100 days.
- From March 15, 2029, it drops to 47 days.
Read that as a direction of travel. By 2029 a certificate is good for 47 days at most. Nobody keeps up with that by hand.
Here is the limit of what that rulebook proves. It binds the companies that issue certificates. It says nothing about whether your host actually automated your renewal. Ask your host one question and write down the answer: is renewal automatic, and who gets the email if it fails? If a renewal fails, every visitor gets a warning until somebody notices, which is a good reason to have something watching the site that is not you.
If you are moving hosts, this matters twice over. The certificate has to be issued again on the new host, and that step is easy to skip in a rush. It belongs on the checklist for changing web hosts without going down.
What to do this week
There is a clock on this one. Google announced on October 28, 2025 that Chrome “will ask for the user’s permission before the first access to any public site without HTTPS.” Google said that switches on for Enhanced Safe Browsing users in Chrome 147, releasing April 2026, and that with the release of Chrome 154 in October 2026 it becomes the default setting for everyone. After that, a plain http site does not just look bad. It puts a screen in front of the customer before your page loads at all.
Plain steps:
- Open your site on your phone and write down exactly what the warning says.
- Try https:// and try it both with and without the www. Note which ones warn.
- Open the certificate details and read the expiry date.
- Log into your hosting control panel and look for a free certificate switch. Turn it on.
- Set the site to send every visitor to the https address, so nobody lands on the old one.
- Ask your host in writing whether renewal is automatic and who gets told if it fails.
If nobody has the hosting login anymore, that is a different job, and a fair moment to look at a new build instead of patching. A site built this year should arrive with the certificate already on and renewing. If a quote does not say so out loud, ask before you sign it.