Website still says “Not secure”? Find the cause and fix it this week

A “Not secure” label next to your address is a quiet sales killer. Nobody calls to tell you about it. A customer who was about to fill in your quote form sees the warning, wonders whether the site is safe, and goes back to the search results. Since Chrome started asking people before opening plain-http public sites, a broken setup can also mean a full warning screen before your page loads at all.

This guide gives you a symptom table, a ten-minute test you can run from a phone and a laptop, the seven causes we see most, step-by-step fixes for WordPress, Squarespace, Wix and Cloudflare, and a short monthly check so the padlock stays put.

Why does my website still say Not secure after installing SSL?

Because installing a certificate and using it everywhere are two different jobs. The site may still answer on http:// without redirecting, a page may pull an image, font or script over http:// (called mixed content), or the certificate may cover only example.com and not www.example.com. Expired certificates and caches cause the rest.

Match what you see to the likely cause before changing anything:

What the Not secure label actually means

In Chrome, “Not secure” on a normal page means the connection isn’t private. Google’s Chrome help page on connection security explains that someone may be able to view or change what a visitor sends through the site. For a business, that covers your contact form, booking page and any login.

Two other states look similar but mean something different. A red full-page warning about a private connection means the certificate itself is wrong: expired, issued for another name, or self-signed. A red page flagged by Safe Browsing as dangerous is a malware or phishing problem, not an SSL problem, and needs a security cleanup first.

The stakes went up this autumn. Google announced on its security blog that Chrome 154, scheduled for October 2026, would turn on “Always Use Secure Connections” for public sites by default. With that setting on, Chrome asks before opening a public site that doesn’t offer HTTPS, with a choice to continue or go back. Google says regular visitors won’t be warned repeatedly, so the people most affected are exactly the ones you want: first-time visitors from search and ads.

The ten-minute check

Do this before touching any settings, so you fix the real cause instead of the first one you read about.

1. Type four addresses. In a private window, open http://example.com, http://www.example.com, https://example.com and https://www.example.com (with your domain). All four should end on the same https:// address with a padlock or the tune icon, not a warning.
2. Check the certificate. Click the icon left of the address, then the connection details. Note who issued the certificate, which names it covers and when it expires.
3. Open your money pages. Contact form, booking page, service pages, blog posts with embeds. Mixed content often hides on one old page.
4. Read the console on any page with a warning. On a laptop, right-click the page, choose Inspect, open the Console tab and reload. Mixed content messages name the exact http:// file causing trouble.
5. Repeat on a phone on mobile data. This rules out your office network, browser cache and any extension.
6. Run an outside test. A free checker such as Qualys SSL Labs shows whether the certificate chain is complete and which hostnames it covers.

Write down what you found for each address. That list is also what your host or web designer needs if you hand the fix over.

The seven causes and how to fix each

• 1. No redirect to https://The certificate works, but http:// still loads the old version. Turn on the “force HTTPS” or “redirect to HTTPS” option in your host or builder, or add a server-level 301 redirect. Test all four addresses again afterwards.
• 2. Mixed contentThe page is https:// but loads something over http://. According to MDN’s mixed content guide, browsers try to upgrade images, video and audio and block other insecure files like scripts. Change those links to https://, or replace embeds that only offer http://.
• 3. Certificate misses www (or the bare domain)One hostname is covered, the other isn’t. Reissue the certificate for both names, or pick one as primary and make sure the other redirects before the browser checks the certificate.
• 4. Expired certificateFree certificates renew automatically only while the renewal job keeps working. Let’s Encrypt certificates, for example, last 90 days. If renewal failed after a DNS change or host move, reissue it and check that auto-renew is on.
• 5. Incomplete installationA manually installed certificate without its intermediate (chain) file can look fine on your laptop and fail on some phones. SSL Labs flags this as a chain issue. Reinstall with the full bundle your certificate provider supplies.
• 6. Site address still set to http://Common in WordPress: the site generates its own links with http:// even though HTTPS works. Update the site address settings, then search the content for old http:// links.
• 7. Caching and old linksPage caches, a CDN or a visitor’s browser keep serving the old version. Clear the plugin and CDN cache after each fix, then retest in a private window. Update links you control, like your Google Business Profile website field and social bios.

How to fix it on WordPress, Squarespace, Wix and Cloudflare

WordPress

1. Make sure your host has issued a certificate (most include a free one in the control panel) and that https:// loads without a red error.
2. Go to Settings → General and change both WordPress Address (URL) and Site Address (URL) to https://. Save, and log in again if asked.
3. Check Tools → Site Health; recent WordPress versions report whether the site uses HTTPS and can offer to update links for you.
4. Fix leftover http:// links in posts, theme settings and page-builder modules. A search-and-replace tool helps here, but back up the database first.
5. Turn on the host’s HTTPS redirect, clear the cache plugin, and rerun the four-address test.

If the site sits behind a proxy or CDN and you get a redirect loop, see the WordPress HTTPS documentation for the reverse-proxy setting.

Squarespace

Squarespace issues certificates automatically for connected domains. Open the SSL panel in your site settings and check the security preference. Secure is the setting you want; Insecure allows plain http:// and is still set on some domains connected years ago. Keep the HSTS Secure option on. Squarespace’s SSL help article says changes can take up to 48 hours. If your primary domain is a subdomain, its Use WWW Prefix setting can cause certificate errors.

Wix

According to Wix’s SSL help page, every Wix site with a connected domain gets a free certificate automatically and you can’t switch it off. So on Wix, a warning almost always means the domain isn’t fully connected (DNS still pointing partly elsewhere) or an embedded widget loads over http://. Check the domain’s connection status in your dashboard and replace the offending embed.

Cloudflare

If you see “too many redirects”, check your SSL/TLS encryption mode. Cloudflare’s documentation explains that Flexible mode talks to your server over http://, so a server that redirects http to https loops forever. The fix is to remove the server redirect or, better, give the server its own certificate and switch to Full (strict).

Does Not secure hurt my Google rankings?

A little, and probably less than it hurts your conversions. Google confirmed back in 2014 that HTTPS is a lightweight ranking signal, and its page experience guidance asks whether pages are served securely. The bigger cost is people: visitors who leave at the warning or skip your form never become calls.

After the fix, make sure your XML sitemap lists https:// URLs, internal links use https://, and the https:// version is verified in Search Console. Google will update the addresses it shows as it recrawls; you don’t need to do anything dramatic. Moving to HTTPS is a site move in Google’s eyes, so permanent 301 redirects matter more than anything else here.

Mistakes that make it worse

• Buying a paid certificate to fix mixed content. A more expensive certificate doesn’t change an http:// image link. Most hosts and builders include a free one that works fine for a local business.
• Turning on HSTS before everything works. HSTS tells browsers to refuse http:// for a long time. If a subdomain or old page still needs http://, you lock visitors out of it. Fix first, then enable.
• Fixing the home page only. The warning that costs you leads is usually on the contact or booking page, often because of an old embedded form.
• Ignoring your form after the switch. Changing the site address can break form plugins or email delivery. Send yourself a test enquiry, and if it doesn’t arrive, work through our guide to contact form emails not being received.
• Letting the domain or hosting card expire. Auto-renew fails quietly when a card expires, and the certificate goes with it. Put the renewal dates in the calendar of someone who will still be at the business next year.

Where to start this week

Run the four-address test today and write down the results. If all four end on https:// with no warning, check your contact and booking pages and the console, then fix any mixed content. If one hostname fails, it’s a certificate coverage or redirect job for your host. While you’re testing, tap your phone buttons too; our click to call troubleshooting guide covers the next most common silent leak.

If the setup is tangled (several hosts, an old developer, a CDN nobody remembers), that’s the kind of cleanup our small business website design team handles, alongside conversion optimization for the pages that bring in leads. Service businesses like law and accounting firms, whose contact forms carry sensitive details, can see how we approach websites for professional services.