Why Does My WordPress Site Say “Not Secure”? (And How to Fix It)

unflagdomain Team·UPDATED August 18, 2026

If your WordPress site says "Not Secure," it almost always means one thing: you're missing a valid SSL certificate, so the browser can't confirm the connection is encrypted. It's not a hack, and it's usually a free, same-day self-fix — install or renew SSL, force HTTPS, and clear mixed content.

TL;DR: A grey "Not Secure" label in WordPress is an SSL/HTTPS problem, not a security flag. Since ~97.5% of sites already run on HTTPS (HTTP Archive Web Almanac, 2025), Chrome now labels any site without a working certificate. Fix it free: turn on your host's certificate, force HTTPS, and clean up mixed content. A full red "dangerous" page is a different problem entirely.

Here's the part that catches people out. The words "not secure" get used for two completely different warnings, and the fixes don't overlap. Most WordPress owners seeing this just need a certificate switched on. Let's sort out which one you've got, then fix it.

Why does my WordPress site say "Not Secure"?

Your WordPress site says "Not Secure" because it's being served without a valid SSL/TLS certificate — the thing that turns http:// into https:// and shows the padlock. Chrome now defaults to HTTPS-First for everyone, and with ~97.5% of sites already on HTTPS (HTTP Archive Web Almanac, 2025), any site missing a certificate gets flagged, even clean ones.

That last bit matters, so I'll repeat it: this label has nothing to do with malware, hacking, or blocklists. Your site is fine. The browser simply can't verify the connection is encrypted, so it warns visitors as a precaution.

There are four common reasons WordPress shows the label:

  • No certificate installed — your site is still being served over plain http://.
  • An expired certificate — many certificates last 90 days and need auto-renewal turned on.
  • Mixed content — the page loads over HTTPS but pulls in some images or scripts over insecure http://.
  • HTTPS isn't forced — both http:// and https:// versions exist, and visitors land on the insecure one.

Worth knowing: WordPress runs about 43.4% of all websites (W3Techs, 2025), so this exact question comes up constantly. You're in very ordinary company, and the fix is well-trodden.

Is "Not Secure" the same as the red "dangerous site" warning?

No — and this is the single most important distinction to get right. A grey "Not Secure" text label next to the address is an SSL certificate issue, and the page still loads. A full-page red or grey wall ("Deceptive site ahead," "Dangerous," "The site ahead contains malware") is a security blocklist flag from Google Safe Browsing — a different problem with a different fix.

In our experience running unflag, the quickest way to tell them apart isn't the wording — it's the behaviour. Can visitors still reach the page after the warning? Then it's SSL. Do they hit a full wall that blocks the whole site? That's a blocklist. One is a setting you toggle; the other means content on your site triggered a vendor's scanner.

Here's the gut check:

  • Grey "Not Secure" text, open padlock, page still loads → SSL certificate. Keep reading.
  • "Your connection is not private" / NET::ERR_CERT → also SSL, usually an expired or misconfigured certificate.
  • Full red page blocking the whole site → a blocklist flag, not SSL. WordPress sites get this most often through a hacked plugin.

If it's the red wall you're seeing, the SSL steps below won't help. Start instead with our WordPress-specific walkthrough of the deceptive site ahead warning in WordPress, or the platform-agnostic guide to why your website says "not secure" if you want the bigger picture first.

How do I fix the "Not Secure" warning in WordPress?

For most WordPress owners this is a free, self-serve fix, and it follows the same four steps regardless of host. Nearly every modern WordPress host includes a free certificate via Let's Encrypt — the non-profit certificate authority that now secures hundreds of millions of websites (Let's Encrypt, 2025) — so often you're just switching it on rather than buying anything.

In our experience running unflag, the order matters. We don't touch SSL ourselves — our work begins after a site is clean, when we clear residual blocklist flags — but we see the same certificate mistakes constantly from owners who land on us thinking SSL is the problem. Installing the certificate without forcing HTTPS leaves both versions live, and skipping mixed content means the padlock still won't show clean. Do all four, in sequence, and the label clears on the next load.

Step 1: Check and install your SSL certificate

Log into your host's dashboard and look for "SSL," "HTTPS," or "Security." Hosts like SiteGround, Bluehost, Hostinger, and Kinsta offer one-click activation or have it on by default. If there's no certificate, enable the free Let's Encrypt option — it's standard on shared and managed WordPress hosting alike.

If your certificate exists but expired, turn on auto-renewal so this doesn't recur. Most certificates renew automatically every 90 days when configured correctly; an expired one is a setting that lapsed, not a fault on your part.

Step 2: Update your WordPress address to HTTPS

In WordPress, go to Settings → General and make sure both the WordPress Address (URL) and Site Address (URL) start with https://, not http://. This tells WordPress to build links and load assets over the secure protocol. Save, and you may be logged out briefly — that's normal.

Step 3: Force HTTPS so everyone gets the secure version

Forcing HTTPS redirects all http:// traffic to https://, so visitors and browsers always land on the encrypted version. The easiest route is a free plugin like Really Simple SSL, which handles the redirect with a single click and is trusted on millions of WordPress installs. Prefer no plugin? Your host can usually add the redirect at the server level.

Step 4: Fix mixed content

Mixed content is the sneaky one: the page loads over HTTPS, but a few images, fonts, or scripts are still hard-coded as http://, so the padlock won't go green. Really Simple SSL fixes most of this automatically. For stubborn cases, a plugin like Better Search Replace can swap every old http://your-site.com reference to https:// across the database in one pass.

Once the certificate is valid, HTTPS is forced, and mixed content is gone, the "Not Secure" label disappears. [INTERNAL-LINK omitted] One honest note: this is a certificate fix, not a blocklist removal — it's something you handle yourself, and unflagdomain doesn't touch SSL.

Why does WordPress still show "Not Secure" after I installed SSL?

If WordPress still shows "Not Secure" after installing a certificate, the cause is almost always mixed content or an unforced redirect — not a faulty certificate. The connection is encrypted, but the page still pulls one or more resources over insecure http://, so the browser downgrades the padlock and keeps the warning.

This trips up a lot of people, so don't assume the certificate failed. Work through these in order:

  • Hard-coded http:// links in posts, theme files, or page builders. Run a search-and-replace to switch them to https://.
  • The HTTPS redirect isn't active. Visiting the http:// version directly still shows insecure — force the redirect site-wide.
  • Browser or CDN cache. Clear your WordPress cache, your CDN (e.g. Cloudflare), and your browser, then reload.
  • Old http:// URLs in the database from before the switch. A search-replace plugin clears these in one pass.

Use your browser's developer console (the "Security" tab in Chrome) to see exactly which resource is loading insecurely — it names the file, which makes the fix fast. Still stuck after all that? Then double-check you're not actually looking at the red blocklist wall, which no SSL change will fix.

What if it's the red "dangerous" warning, not "Not Secure"?

If WordPress is showing a full red page that blocks the entire site, you're dealing with a security blocklist, not SSL — and the fix is completely different. This happens when something on your site triggers Google Safe Browsing, most often a hack that came in through an outdated plugin. WordPress made up the vast majority of the infected CMS sites Sucuri cleaned — around 95% in its hacked-website analysis (Sucuri, 2023).

The reason this version hurts so much is that it stops traffic cold. And the cause usually isn't carelessness: 93% of WordPress vulnerabilities trace to third-party plugins and themes, not WordPress core itself (Patchstack, 2024). An abandoned plugin you forgot about is the classic way in.

Clearing it follows one path: clean the site (or confirm a false positive), then request a re-check from each vendor. Google's Safe Browsing review is manual — you submit it inside Google Search Console, and there's no instant button or automated API. We cover the full WordPress cleanup-and-review process in the deceptive site ahead in WordPress guide.

Here's where it gets tedious: a hacked WordPress site is often flagged by several vendors at once, each with its own form or review process. In our experience running unflag, this is the part owners underestimate — we scan a domain across more than a hundred active security vendors, and a single compromised plugin can light up many of them. Once your site is genuinely clean, you can have unflagdomain email every flagging vendor a removal request for €39 — one payment, with your address as the reply-to so vendor replies land in your inbox, not ours. We write a unique request per vendor rather than blasting identical copy, and the vendors that only take web forms or manual review (Google Safe Browsing among them) become guided dashboard cards instead. We don't scan or clean malware; you clean first, then we clear the residual flags. And to be straight with you: no one can guarantee a vendor will delist you — the vendors decide — but we guarantee the request actually reaches every one of them, with real sent, bounced and failed counts in your dashboard, and we re-send anything that bounces.

When should I worry, and when is "Not Secure" harmless?

For the vast majority of WordPress owners, a grey "Not Secure" label is harmless to your site's safety but bad for trust — so it's worth fixing fast, not panicking over. With ~97.5% of the web already on HTTPS (HTTP Archive Web Almanac, 2025), visitors now expect the padlock, and its absence reads as "sketchy" even when nothing's wrong.

So here's the honest priority list. If you see the grey label, fix the certificate this week — it's free, it takes an afternoon, and it removes a real friction point for visitors and a small SEO disadvantage. Nothing on your site is actually compromised.

If you see the full red wall, treat it as urgent: clean the WordPress install, harden your plugins and logins, and request the Safe Browsing review. That's the version that blocks sales and damages your domain's reputation until it's cleared. Two different warnings, two different stakes — now you know which is which.

// FAQ

  • The page works because "Not Secure" is an SSL warning, not a block. The browser can load your site but can't verify the connection is encrypted, so it warns visitors. Install a valid SSL certificate, force HTTPS, and the label disappears. Your site was never actually broken or hacked.

  • Nearly every WordPress host includes a free certificate via Let's Encrypt, which secures hundreds of millions of sites ([Let's Encrypt](https://letsencrypt.org/stats/), 2025). Log into your host's dashboard, find the SSL or Security section, and enable one-click activation. Then turn on auto-renewal so the certificate never lapses again.

  • It's almost always mixed content or an unforced redirect, not a bad certificate. Some images or scripts still load over insecure http://, so the browser keeps the warning. Use a plugin like Really Simple SSL to force HTTPS and rewrite those resources, then clear your site, CDN, and browser cache.

  • No. "Not Secure" is a grey SSL label and the page still loads. "Deceptive site ahead" is a full red blocklist wall from Google Safe Browsing, usually triggered by a hack — WordPress was 96.2% of infected CMS sites Sucuri cleaned in 2024 ([Sucuri](https://sucuri.net/reports/2023-hacked-website-report/), 2024). They need completely different fixes.

  • Slightly. Google has used HTTPS as a lightweight ranking signal for years, and with ~97.5% of sites already secure ([HTTP Archive Web Almanac](https://almanac.httparchive.org/en/2025/security), 2025), missing it puts you behind the norm. The bigger cost is trust: visitors abandon sites that look unsafe. Installing free SSL fixes both quickly.