Why Is My Website Showing "Not Secure" in Chrome?

When Chrome shows "Not Secure" next to your web address, it's telling visitors your site doesn't have a valid SSL certificate, the thing that encrypts the connection and puts https at the front of your URL. It's not saying you've been hacked. It's saying the browser can't confirm the connection is private. The cause is almost always a certificate that expired, was never installed, or isn't being applied to every page. The good news: SSL is usually free now, so fixing this is quick.

Confirm whether the certificate is expired or missing

Click the "Not Secure" text or the icon to the left of the address in Chrome, then look at the certificate or connection details. It'll tell you whether there's a certificate at all and, if so, when it expired. An expired date means you had SSL and it lapsed, usually because auto-renewal failed. No certificate at all means one was never installed for this domain. That one distinction points you straight to the right fix.

Install or renew the SSL certificate

If the certificate is missing or expired, this is the core fix. Most hosting providers now include free SSL through Let's Encrypt, and many offer a one-click button in the control panel to install or reissue it. Log into your host, find the SSL or security section, and enable or renew it. If your host doesn't offer free SSL, a service like Cloudflare can provide it, or you can buy a certificate. Once a valid certificate is in place, allow a little time for it to take effect, then reload your site.

Certificates from Let's Encrypt renew automatically every 90 days when set up correctly. If yours expired, that auto-renewal broke somewhere, so after reinstalling, confirm renewal is actually running so you don't land back here in three months.

Force https on every page

A valid certificate isn't enough on its own if visitors can still reach the insecure http version of your pages. You want every request redirected to https. On WordPress, set both your Site Address and WordPress Address to the https version under Settings, and a plugin or a rule in your server config can force the redirect site-wide. This closes the gap so nobody stumbles onto an unencrypted page and sees the warning.

Chrome shows Not Secure but the certificate is valid

This is the version that drives people up the wall. The certificate checks out, https is forced, and one page still won't show the padlock. That's almost always mixed content: the page itself arrives over https, but something inside it, an image, a script, a stylesheet, a font, a map or a video embed, is requested over plain http. Chrome judges the page by its weakest request, so one leftover http image URL from 2018 is enough to strip the padlock off an otherwise perfect page.

Two different things then happen, and knowing which is which saves you a lot of guessing. Passive content, meaning images, audio and video, gets auto-upgraded by Chrome to https when the file happens to exist at the secure address, and Chrome logs a console message either way. Active content, meaning scripts, stylesheets and XHR requests, is blocked outright rather than downgraded. That's why mixed content often shows up as a feature that just quietly stopped working, a slider that won't slide or a form that won't submit, rather than as a visible warning.

Finding it in Chrome DevTools

Open the page in Chrome and press F12, or Command plus Option plus I on a Mac. Go to the Console tab and reload the page with the console open, because these messages clear on navigation and you'll miss them if you open DevTools after the fact. What you're looking for reads like this: "Mixed Content: The page at 'https://yoursite.com/' was loaded over HTTPS, but requested an insecure image 'http://olddomain.com/logo.png'." Every one of those names the exact file, which is the whole job. Chrome's Privacy and security panel (labeled Security in older versions) gives you the same information grouped by origin, which is handier when one third-party host is responsible for a dozen of them. Check more than the homepage. Mixed content usually hides on an old blog post or a page with an embed nobody has touched in years.

Fixing it on WordPress

Start with Settings > General and make sure both WordPress Address (URL) and Site Address (URL) begin with https. Then deal with the database, because years of posts have http:// baked into image tags and links. Take a full backup first, this step edits your database. Install the Better Search Replace plugin, go to Tools > Better Search Replace, put http://yourdomain.com in the search field and https://yourdomain.com in the replace field, select all tables, and run it once with Dry run ticked to see the count before you commit. Then untick it and run for real. An SSL plugin like Really Simple SSL or SSL Insecure Content Fixer is the faster route and rewrites the URLs as the page is built, which is fine, but understand the trade: the plugin fixes the output while the search-and-replace fixes the data. Only one of those survives deactivating the plugin. Whichever you pick, check widgets, custom CSS and theme options by hand afterward, and note that an external file that genuinely only exists over http can't be rewritten. That one has to be replaced or hosted on your own domain.

Fixing it on Squarespace

Squarespace's SSL setting lives at Settings > Advanced > SSL, with three options: Secure (Preferred), which is the default and redirects visitors to https, HSTS Secure, and Insecure. Confirm you're on one of the first two. Everything Squarespace hosts for you is already served over https, so mixed content here is always something you added: a code block, an embed block, custom CSS, or a third-party integration pointing at an http address. Squarespace says plainly that custom code and mixed content are outside what their support will help with, so the fix is yours to make. Open each code and embed block and change http:// to https://.

Fixing it on Wix

Wix's own troubleshooting guidance is blunt about the cause: an HTML element containing http in its code will make the browser report the site as not fully secure. In the editor, click the embed or custom code element, choose Edit Code, replace every http:// with https://, and publish. Do the same for any app or widget you've pointed at an http URL. If a page has several embeds, check all of them, since one is enough.

When to hand it off

Enabling free SSL from a host's one-click button is genuinely simple, and if that clears the warning, you're done. It gets more involved when auto-renewal keeps failing, when a certificate name mismatch needs server-level attention, or when stubborn mixed content is buried across a large site. Those are worth handing to someone who works with certificates and DNS regularly, especially since a misstep can take the site offline entirely. If the one-click route doesn't solve it, that's your signal to get help.

How we keep the padlock from ever dropping

An expired certificate is one of the most visible, and most avoidable, trust failures a site can have. On our maintenance plans, starting at $99 a month, we track SSL expiry dates and make sure auto-renewal actually runs, so your visitors never hit a "Not Secure" warning in the first place. We also watch for mixed content after edits and force https site-wide. We're based near Seattle, and we handle this kind of fix within one business day if it ever does come up.