How to Fix 'Not Secure' Warnings on Your Site

You've probably seen it: a red warning in the browser address bar that says "Not Secure" next to your domain. Visitors see it too, and many will leave before they ever read your content or add anything to a cart. The good news is that in most cases this warning is caused by a handful of fixable issues, and you can resolve them yourself without a developer.

This guide walks through the common causes of "Not Secure" warnings and gives you a practical order of operations to clear them for good.

First, figure out which warning you actually have

Browsers show different warnings depending on the problem, and the fix is different for each:

• "Not Secure" in the address bar — usually means your site is loading over plain HTTP, or it's loading a mix of secure and insecure resources.
• "Your connection is not private" or a full-page interstitial — means the SSL certificate is missing, expired, or doesn't match your domain.
• A padlock with a warning triangle — usually mixed content: the page itself is HTTPS, but some images, scripts, or fonts are still loading over HTTP.

Open your site in a browser and look closely at the address bar icon. That single detail tells you which of the fixes below you need.

Cause 1: Your site isn't on HTTPS at all

If the address bar shows http:// instead of https://, your site doesn't have a working SSL certificate, or it isn't being used.

The fix:

1. Check with your hosting provider. Most modern hosts include a free certificate (often via Let's Encrypt) and can enable it with a single toggle in your control panel.
2. If your host doesn't offer one, you can install a certificate yourself or through a CDN that terminates SSL for you.
3. Once the certificate is active, make sure your site actually serves over HTTPS. In most control panels there's a setting like "force HTTPS" or "redirect to HTTPS."

If you're not sure whether your certificate is valid, your host's dashboard or an online SSL checker will tell you the expiry date and whether the certificate matches your domain.

Cause 2: Mixed content (the most common cause)

This is the one that trips up most site owners. Your homepage loads securely, but one image, script, or font is still being pulled from an http:// URL. Browsers treat that as a security risk and downgrade the padlock.

How to find it:

1. Open your site in Chrome or Firefox.
2. Right-click and choose Inspect to open developer tools.
3. Go to the Console tab. Mixed-content warnings appear here with the exact URL of the offending resource.
4. Note each http:// URL — those are what you need to fix.

How to fix it:

• In your CMS: If you're on WordPress, a search-and-replace plugin can safely rewrite http://yourdomain.com to https://yourdomain.com across your database. Back up first.
• In your theme or templates: Hard-coded image URLs, font links, or script tags need to be edited to use https:// or protocol-relative URLs.
• In your page builder: Check any custom HTML blocks or embed codes — old YouTube or Google Fonts embeds are frequent offenders.
• In third-party scripts: Some analytics, chat, or ad snippets still load over HTTP. Update them to the HTTPS version or remove them.

After each fix, reload the page and check the console again. Mixed content often comes in clusters, so expect to repeat this a few times.

Cause 3: Your certificate expired or doesn't match

If visitors see a full-page warning instead of a padlock, the certificate itself is the problem. Common reasons:

• The certificate expired (free certificates often renew automatically, but the renewal can fail silently).
• The certificate was issued for www.yourdomain.com but visitors are hitting yourdomain.com (or vice versa).
• You changed hosting providers and the certificate wasn't migrated.

The fix: renew or reissue the certificate, and make sure it covers both the www and non-www versions of your domain. Then set up a single canonical version — usually by redirecting one to the other — so visitors always land on the covered hostname.

Cause 4: Redirects that drop back to HTTP

Even after you've enabled HTTPS, an old redirect rule can send visitors back to an insecure page. This often happens after a redesign or a host migration.

The fix:

1. Test your key URLs (homepage, a product page, a blog post) by typing them in with http:// and watching where you land.
2. In your server config or redirect plugin, make sure the redirect target uses https://.
3. Add a site-wide rule that forces all HTTP traffic to HTTPS. On Apache this is typically a rewrite rule in .htaccess; on Nginx it's a return 301 in your server block. Your host's documentation will have the exact snippet.

Verify the fix from a visitor's perspective

Once you've made changes, don't just check the homepage on your own device. Do a quick pass:

• Load your homepage, a product or service page, and a checkout or contact page.
• Check each in a private/incognito window so you're not seeing cached assets.
• Look at the address bar on both desktop and mobile.
• Re-open the console and confirm no mixed-content warnings remain.
• Click through a few internal links to make sure nothing redirects back to HTTP.

If everything shows a clean padlock, you're done.

Why this matters beyond the warning

A "Not Secure" label is one of the fastest trust-killers on a website. Visitors who see it may abandon a form, hesitate at checkout, or simply bounce. Fixing it isn't just about avoiding a browser message — it's about removing a visible reason for someone to doubt your site.

Once HTTPS is clean, it's worth checking the rest of your trust signals too: contact information, privacy policy, reviews, and clear ownership cues. You can run a free audit to see how your site scores across trust, speed, and SEO in one pass, and get a prioritized list of what to fix next.

For more step-by-step fixes like this one, browse the guides library.

A quick troubleshooting order

When a "Not Secure" warning shows up, work through this sequence:

1. Confirm whether the page is loading over HTTP or HTTPS.
2. Check the certificate status with your host.
3. Open the browser console and fix any mixed-content URLs.
4. Verify redirects point to HTTPS, not HTTP.
5. Re-test in an incognito window on desktop and mobile.

Most site owners can clear the warning in an afternoon by following these steps in order. If a specific page still shows the warning after all five, the console will tell you exactly which resource is responsible — and that's usually the last thing standing between you and a clean padlock.

More guides · Compare audit tools · Run a free website audit