Not Secure Warning Chrome: How to Fix It in 2026

By our senior hosting engineers. Reviewed as of 2026.

Quick Answer: The not secure warning Chrome shows means your site is loading over plain HTTP or has a broken HTTPS setup. It rarely means you were hacked. Fix it in three moves: install a valid SSL certificate, force every URL from HTTP to HTTPS with a 301 redirect, then clear any leftover mixed content still loading over HTTP. Most sites turn green within minutes of that last step.

You opened your own website in Chrome, and there it sat next to the address bar in flat grey text: Not Secure. No padlock. Maybe a small warning triangle. When a visitor sees that before they see your homepage, a lot of them just leave. So the worry is real, and I understand why you're here.

Now the reassuring part. The not secure warning Chrome puts on your site almost never means you've been broken into. It points to one specific thing: the connection between the browser and your server isn't fully encrypted. Either there's no SSL certificate at all, the certificate is expired or invalid, or the page is quietly pulling a file or two over plain HTTP.

We resolve 20 to 30 site issues like this every day, and this guide is written straight from that hands-on work so you can do the fix yourself without paying anyone a penny. On the stacks we run at Hostaccent, where Cloudflare sits in front of Nginx and Apache, the cause almost always traces to one of four things. Below, we rank them by how often they actually turn up, walk through the exact fix for each, then lock the warning out for good.

What the "Not Secure" Warning in Chrome Actually Means

Chrome flags a page as Not Secure when it can't confirm the connection is encrypted end to end. That's the whole story. It isn't a virus alert, and it isn't an accusation that your site is dangerous. Since Chrome 68 shipped in 2018, every page served over plain HTTP gets this label, and pages that ask for passwords or card details get a louder version of it.

Here's the underlying mechanics. Plain HTTP talks to your server on port 80 with no encryption, so anyone sitting between your visitor and your server can read the traffic. HTTPS uses port 443 and wraps that traffic in TLS encryption, proven by an SSL certificate. No valid certificate, or a page that mixes secure and insecure requests, and the browser drops the padlock. So when Chrome says not secure, read it as one thing: this connection isn't encrypted, nothing more.

A website not secure warning is Chrome withholding the padlock until the connection is provably safe. The label is browser-side and public: every visitor on Chrome, Edge, Brave or any Chromium browser sees the same thing. Google has also confirmed HTTPS is a ranking signal, so an unsecured site can quietly cost you traffic on top of trust. The good news is that because this is a configuration issue, it is almost always fixable in a single sitting.

Insider Insight: The warning is about the connection, not the content. A perfectly clean, malware-free site will still show Not Secure if it's served over HTTP. Don't burn an hour scanning for malware when the real fix is a certificate and a redirect.

What Causes the Not Secure Warning Chrome Shows (Ranked by How Often We See It)

Four causes account for nearly every case that reaches us, and knowing which one you have saves you from fixing the wrong thing. Here they are in order of real-world frequency, most common first, so you can start where the odds are best. In our experience, the second one on this list is the sneakiest, because the site genuinely looks fixed while the browser still refuses the lock.

1. No SSL certificate installed. The site was never set up for HTTPS and loads on http:// only. By far the most common cause on new sites and small business pages built in a hurry.
2. Mixed content after SSL was added. The certificate is installed and the page loads over HTTPS, but a few images, scripts or stylesheets still point to http://. One insecure file is enough to break the padlock.
3. Expired, invalid, or self-signed certificate. The certificate exists, but the browser won't trust it. Free certificates renew on a 90-day cycle, and an auto-renewal that silently failed is a classic culprit.
4. HTTP not redirecting to HTTPS. SSL works, but the old http:// version of each page is still reachable and never forwards to the secure one. Bookmarks and old links keep landing on the insecure copy.

From the Ticket Queue: According to Hostaccent's own support-queue data as of 2026, SSL and HTTPS problems make up roughly 20% of the tickets we handle each month, and the biggest sub-category by far is mixed content on sites that "already have SSL." If you installed a certificate and the warning refuses to clear, skip ahead to the mixed content section, because that is very likely you.

Install SSL and Force Your Whole Site onto HTTPS

If you have no certificate yet, this is your fix, and it clears the majority of cases on its own. The goal is two things done in order: get a valid SSL certificate onto the server, then make every visitor actually use it. This is also the heart of how to remove the not secure warning WordPress owners hit most often right after launch.

Step 1: get and install an SSL certificate. Most control panels do this for free now. In cPanel, open Security → SSL/TLS Status, tick your domains, and click Run AutoSSL; a certificate issues in a minute or two. On a raw server, Let's Encrypt issues free, browser-trusted certificates that auto-renew every 90 days. Prefer the control-panel route when you have one, since it handles renewal for you.

Step 2: point WordPress (or your CMS) at HTTPS. In WordPress, go to Settings → General and change both WordPress Address and Site Address from http:// to https://, then save. This single change fixes a surprising number of "still not secure" cases, because the site was serving its own URLs insecurely.

Step 3: force the redirect. Now send every HTTP request to HTTPS with a permanent 301. On Apache, add this to the top of .htaccess:

bashCopy
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

On Nginx, redirect at the server block instead:

bashCopy
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Reload the server and every http:// hit now lands on the secure version. Get the redirect logic wrong, though, and you can trade one problem for another, like a redirect loop or a 404 Not Found error. If your certificate is valid but Chrome throws an SSL error instead of a padlock, our walkthrough on Cloudflare Error 526: How to Fix Invalid SSL Fast (2026) covers the origin-certificate side of that specific failure.

Pro Tip: Don't rely on a WordPress plugin alone to "force HTTPS" if you can edit server config. A server-level 301 is faster, survives plugin updates, and won't collide with your cache. Plugins are fine as a stopgap; server config is the real fix.

Still Not Secure After Installing SSL? Fix Mixed Content

This is the case that drives people up the wall: the certificate is valid, the URL says https://, and Chrome still won't show the padlock. Almost always the culprit is mixed content, an HTTPS page loading one or more resources over HTTP. A single insecure image, font or script is enough for the browser to withhold the lock. It's the case our team clears most often right after a migration.

How do I find what's actually loading insecurely?

Let Chrome tell you. Open the page, press F12 (or Ctrl+Shift+I) to open DevTools, click the Console tab, and reload. Every insecure request gets listed with its exact file path, usually with the words "Mixed Content" in front of it. That list is your to-do list. External scanners like Why No Padlock do the same job from outside if you can't use DevTools.

Once you know which files load over HTTP, fix them at the source:

• Database references (the usual cause). Old posts and images saved full http:// paths before you moved to HTTPS. Run a search-and-replace across the database, either with a trusted plugin like Better Search Replace or, on the command line, with WP-CLI: wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid. Back up the database first.
• Theme and plugin files. Hardcoded http:// links in template files or widgets. Grep the theme folder and update them by hand.
• Third-party embeds. A video, map or ad embed pulling over HTTP. Swap the embed URL to its https:// version.

For the full spec on what browsers treat as insecure and why, the MDN mixed content reference is the authoritative source.

Live site and no time to experiment with the database? Our engineers fix this exact warning for a small one-time fee, and you'll see the exact quote before anyone touches a file. Hosted with Hostaccent already? Then a warning like this is simply covered by support, at no cost. Have an engineer fix it.

The Cloudflare and Server Gotcha Most Guides Skip

Most articles stop at "install SSL and redirect." When there's a proxy or CDN in front of your site, there's a trap they miss, and it's one we hit constantly on our own Cloudflare → Nginx → Apache setup. When Cloudflare sits in front of your origin, its SSL/TLS encryption mode decides how it talks to your server, and the wrong mode either shows a false padlock or throws the site into a redirect loop.

If Cloudflare is set to Flexible, it serves HTTPS to visitors but talks to your origin over plain HTTP. The padlock looks fine, but the origin leg is unencrypted, and if your server also forces HTTP to HTTPS, the two redirects fight each other into an infinite loop. The fix: once a valid certificate is on the origin, set the mode to Full (Strict) and let Cloudflare's Always Use HTTPS rule handle the visitor-side redirect. This all resolves at the server and DNS layer, before PHP or WordPress even loads, which is exactly why it's more reliable than a plugin.

Here's a simple order of operations we use so we never chase the wrong layer. Call it the Padlock Trace:

1. Certificate layer: is a valid, unexpired cert actually on the origin? Check this first.
2. Redirect layer: does http:// forward cleanly to https:// with no loop? Test in a private window.
3. Content layer: does the Console show any HTTP resources on the page? Clear those last.

Work them top down, in that order, and you never fix step three while step one is still broken. If you manage your own box and want the proxy layer done properly, our Nginx Rate Limiting: Basic DDoS & Bot Protection guide shows how we structure the server block that also carries these redirects.

Pro Tip: After any SSL change behind Cloudflare, purge the edge cache before you judge whether it worked. We've watched people fix mixed content correctly and still see the warning for twenty minutes, purely because a stale HTTP asset was sitting in cache.

Confirm It's Fixed and Keep the Warning From Coming Back

Once the certificate, redirect and mixed content are all sorted, confirm it properly instead of trusting a single page load. Open your site in a fresh incognito window (Ctrl+Shift+N) so no cache can lie to you, click into a few inner pages, and look for the padlock on each. Then check both the www and non-www versions of your domain, because a certificate can cover one and not the other.

A few habits keep the warning from ever returning:

• Turn on auto-renewal. Most Not Secure surprises months later are just an expired certificate. Control-panel AutoSSL and Let's Encrypt both auto-renew; confirm it's actually enabled and not silently failing.
• Add an HSTS header. HTTP Strict Transport Security tells browsers to only ever load your site over HTTPS, so nobody hits the insecure version again.
• Update Google Search Console. Add the HTTPS property, submit the HTTPS sitemap, and make sure your HTTP URLs redirect, so Google indexes the secure version.
• Harden the box while you're in there. If you run your own VPS, our Linux VPS Security Baseline (Ubuntu 24.04) in 30 Min covers the wider hardening that pairs with a clean HTTPS setup, including backups.

Verify once, automate the renewal, and this becomes a problem you solved permanently rather than one you keep re-solving. Done right, it protects both performance and the padlock.

Your Next Step: A Site That Loads Green by Default

Now that you know the not secure warning Chrome flags is almost always a certificate, a redirect, or a stray HTTP file, and not some deep security breach, you've got two honest options. You can run the three-layer check above yourself this weekend, or you can start on a stack where SSL, the HTTPS redirect and auto-renewal are already wired in and the padlock is simply the default.

That second path is what we build. We're the team behind the stack this guide was written on: Hostaccent, a UK-registered host (Companies House 11431799) operating since 2012 and incorporated in 2018, with our own engineers on support and more than 10,000 sites launched and 4,000+ migrations handled. Shared hosting starts at Economy — $1.99/mo with free SSL, NVMe SSD storage, a 99.9% uptime guarantee and a 30-day money-back guarantee. One honest caveat: Economy is sized for a single site, so if you're running several client projects, Standard fits you better.

If you'd rather just get this off your plate, start on the Economy plan and the HTTPS side is handled for you. Still stuck on a site hosted elsewhere? Open a ticket and our engineers will sort it for a small one-time fee, with the quote shown before any work starts. Not sure what you need long-term? Our Domain & Hosting Buying Guide: What to Check First lays out what actually matters.

Frequently Asked Questions

Why does Chrome say my website is not secure?

Chrome shows the label when it can't confirm your connection is encrypted end to end. In practice that means one of four things: no SSL certificate is installed, the certificate is expired or invalid, the page loads some files over HTTP (mixed content), or your HTTP pages never redirect to HTTPS. It's a connection-configuration issue, not proof your site is hacked, and it's almost always fixable in a single session once you know which cause you're dealing with.

How do I fix the not secure warning Chrome shows on my WordPress site?

Install an SSL certificate (most hosts offer free AutoSSL or Let's Encrypt), then in Settings → General change your WordPress and Site Address to https://. Add a server-level 301 redirect from HTTP to HTTPS, and finally clear mixed content by finding HTTP resources in Chrome DevTools and running a database search-replace to update old http:// URLs. Test in an incognito window afterward. Most WordPress sites clear the warning within minutes of the mixed-content fix.

Why does my site still say not secure after I installed SSL?

Because the certificate is only half the job. If the page still pulls any image, script, stylesheet, font or embed over HTTP, the browser treats the whole page as insecure and hides the padlock. This is mixed content. Open Chrome DevTools, check the Console for flagged HTTP resources, and update them to HTTPS at the source, usually a database search-replace for old URLs plus a few hardcoded theme links. One insecure file is enough to break the lock.

Is a website that shows "Not Secure" dangerous to visit?

Not inherently. The warning means the connection isn't encrypted, not that the site carries malware. Browsing a static page over HTTP is low-risk. The real danger is entering sensitive data, passwords, card numbers, personal details, on an unsecured page, because that traffic can be intercepted in transit. If you own the site, treat it as urgent anyway: visitors don't read the nuance, they just see "Not Secure" and leave, and your rankings take a quiet hit.

Does the not secure warning hurt my Google rankings?

Yes, in two ways. Google has publicly confirmed HTTPS is a ranking signal, so an unsecured site starts at a small disadvantage against secure competitors. The larger effect is behavioural: when visitors bounce off the warning, your engagement metrics drop and that feeds back into rankings. Content quality still matters more than HTTPS alone, but there's no upside to leaving it unsecured. Fixing it is one of the cheapest SEO wins available.

How long does it take for the warning to disappear after I fix it?

Usually minutes, not days. Once the certificate is valid, the redirect is live and mixed content is cleared, Chrome shows the padlock on the next load. Clear your browser cache or use an incognito window to confirm, since a cached HTTP version can fool you into thinking it failed. Behind a CDN like Cloudflare, purge the edge cache too. At Hostaccent we typically see the padlock return the moment the last HTTP asset is corrected.