Your website says “Not secure” because the browser could not confirm a private HTTPS connection for that page. In most cases the cause is one of six things: there is no SSL certificate, the certificate has expired, the certificate does not match the address the visitor typed, the page loads some files over plain HTTP (mixed content), HTTP is not redirected to HTTPS, or you are looking at an old cached copy.
The fix is almost always free. Install a certificate (Let’s Encrypt issues them at no charge and most hosts install one with a click), make sure it covers every version of your domain, change any http:// links on the page to https://, and add a redirect so all traffic ends up on HTTPS. The rest of this guide walks through each cause in the order you should check them, with how to confirm the fix worked.
Why Chrome shows “Not secure” at all
In February 2018 the Chromium team announced that, starting with Chrome 68 in July 2018, Chrome would mark all HTTP sites as “not secure”. Since then, any page served over plain HTTP gets that label in the address bar, even if it is a simple brochure site with no login or checkout.
Google’s Chrome help page explains what the icons mean. A secure connection means information you send or get through the site is private. “Not secure” means the site is not using a private connection, so others may be able to see or change what is sent. A red “Dangerous” warning is different: that comes from Safe Browsing and means the site has been flagged as unsafe, which is a malware or phishing problem, not a certificate problem.
For a small business, the label costs real money. Visitors see the warning next to your name, and Chrome’s own advice for “Not secure” pages is not to enter personal information. That is exactly what a contact form, booking form or checkout asks for.
How to check what is wrong (the padlock details)
Open your site in Chrome and click the icon to the left of the web address. Chrome shows a short summary of the connection. If it says the connection is not secure, look at the address itself: if it starts with http://, the page is not on HTTPS at all. If it starts with https:// but still shows a warning, the certificate or the page content is the problem.
From the same panel you can open the connection details and view the certificate. Check two fields: the dates it is valid between, and the names it was issued for. An expired date or a name that does not match your address tells you exactly which fix you need.
If the certificate looks fine, open Chrome DevTools (right-click, Inspect). According to web.dev, Chromium-based browsers report mixed content in the Issues tab, while Firefox and Safari log it in the console. Each message names the exact file that is loading over HTTP.
Cause 1: no certificate, so the site runs on plain HTTP
If your address starts with http:// and typing https:// in front of it gives an error, your site has no certificate. This is common on older sites, sites moved to a new host, and domains that were recently pointed at a new server.
The fix: log in to your hosting control panel and look for SSL, TLS or “AutoSSL” settings, and turn on a free certificate for your domain. Let’s Encrypt does not charge for its certificates, and its FAQ notes that some hosting providers may still add a small fee for the service. If your host has no built-in option, an ACME client such as Certbot can request and install a Let’s Encrypt certificate on a server you control.
One requirement trips people up: the common HTTP-01 validation method only works on port 80, so your domain must already point at the server and port 80 must be reachable when the certificate is requested. If your DNS still points somewhere else, the request will fail.
Cause 2: the certificate expired because renewal failed
If the site was secure for months and suddenly is not, check the certificate dates. Let’s Encrypt’s default certificates are valid for 90 days, and it recommends renewing them every 60 days. Renewal is meant to be automatic, so an expired certificate almost always means the automatic renewal broke.
Typical reasons: the domain’s DNS was changed so validation now reaches a different server, a firewall or CDN started blocking port 80, the hosting plan lapsed, or a renewal job on the server stopped running. Visitors then usually see a full-page privacy warning instead of your site, which is worse than the address-bar label.
The fix: renew the certificate from your control panel (or run your ACME client’s renew command), then find out why the automatic renewal failed and fix that too, or it will expire again. Set a calendar reminder to look at the expiry date a few weeks before it is due until you trust the automation.
Cause 3: the certificate is for the wrong name (www vs non-www)
A certificate only protects the exact names listed on it. If it was issued for example.com but a visitor types www.example.com (or the other way round), the browser treats the certificate as invalid for that address and shows a warning.
The fix: reissue the certificate so it covers both the bare domain and the www version. Most control panels include both automatically once both names point at your server, so check that a DNS record exists for www as well. Then pick one version as your main address and redirect the other one to it, so people and search engines always land in the same place.
The same applies to subdomains such as shop.example.com or booking.example.com. Each one has to be listed on a certificate, or covered by a wildcard certificate, which Let’s Encrypt only issues through DNS validation.
Cause 4: mixed content (HTTP images and scripts on an HTTPS page)
MDN defines mixed content as a securely loaded page that fetches some of its resources over HTTP. The page address shows https://, but an image, script, stylesheet, font or embedded iframe inside it still uses an http:// link. This is the most common reason a site keeps saying “Not secure” after SSL was installed.
Browsers handle it in two ways. Images, audio and video are automatically upgraded to HTTPS where possible, while scripts, stylesheets, iframes, fonts and similar resources are blocked. So mixed content can either trigger the warning or quietly break parts of your page, such as a missing menu or an embedded map that never loads.
The fix: find every http:// link in your pages, theme files and settings and change it to https://. On WordPress and similar systems, also update the site address setting and run a search-and-replace on old http:// URLs in the database. For third-party files, switch to their HTTPS version or replace the provider. As a safety net, MDN describes the Content-Security-Policy directive upgrade-insecure-requests, which tells the browser to upgrade every request to HTTPS, including scripts and stylesheets. Resources that do not exist on HTTPS will still fail, so it does not replace fixing the links.
Cause 5: HTTP is not redirecting to HTTPS
Having a certificate is not enough if people can still reach the HTTP version. Old links, printed flyers, bookmarks and some search results may still point to http://, and those visitors will see “Not secure” even though https:// works perfectly.
The fix: add a permanent (301) redirect from every HTTP address to the matching HTTPS address. Many control panels have a “Force HTTPS” switch. On Apache hosting it is usually a rewrite rule in .htaccess; on Nginx it is a server block that returns a redirect. Test it by typing http://yourdomain.com and http://www.yourdomain.com and confirming both end up on the HTTPS version of your chosen main address.
After the redirect works, update the links you control: your Google Business Profile, social media bios, email signature and any directory listings, so visitors skip the redirect entirely.
Cause 6: you are seeing an old cached page
If you have fixed everything and still see the warning, your browser, a CDN or a caching plugin may be serving an older copy of the page that still has HTTP links. This is especially common right after a fix, or when you checked the site on the same device many times before.
The fix: open the site in a private or incognito window, or on your phone using mobile data. If it looks secure there, clear your browser cache. If it still fails, purge the cache in your CDN or caching plugin and test again. Once a fresh visit shows the padlock details with a valid certificate and DevTools shows no mixed content issues, you are done.
If you would rather not manage certificates yourself
Most “Not secure” problems come from small things that are easy to miss: a renewal that silently stopped, a missing www record, one old image link. If you do not want to keep checking expiry dates and redirects, a managed website can take that off your plate.
OneSol Max is a done-for-you small-business website where your domain is connected for you and served over HTTPS, with the CRM and basic SEO set up as well. It costs $1 for the first month and then $29 per month. Whatever you choose, run the six checks above in order and your visitors should see a secure connection instead of a warning.