How to fix the “Not secure” warning

What the warning actually means

Browsers show “Not secure” in the address bar when the page itself arrived over HTTP, without encryption. Anyone on the same Wi-Fi, a compromised router or the network operator can read and change what the visitor sends and receives, including passwords and contact forms. A padlock with a warning, or a missing padlock on an https:// page, usually means mixed content: the page is HTTPS, but an image, script or form on it still uses http://.

The warning has become harder to ignore. With Chrome 154, released in October 2026, the “Always Use Secure Connections” setting is on by default: Chrome first tries HTTPS, and if that fails it shows a full-page warning and asks the visitor before opening a public HTTP site. Chrome also shows this warning when any redirect on the way to your page uses HTTP, even if the final page is HTTPS.

Step 1: Install a free certificate

Most hosts include a free certificate. Look for “SSL/TLS”, “Let’s Encrypt” or “AutoSSL” in your control panel and turn it on for both yourdomain.com and www.yourdomain.com. If you manage your own server, Certbot gets a free Let’s Encrypt certificate and renews it automatically:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com
# Apache: install python3-certbot-apache and use --apache instead of --nginx

Paying for a certificate doesn’t make the connection more secure. A free domain-validated certificate gives the same encryption and the same padlock.

Step 2: Redirect HTTP to HTTPS

A certificate alone isn’t enough: people still type your address without https://, and old links point to http://. Answer every HTTP request with a permanent (301) redirect to the same path on HTTPS. On nginx:

server {
    listen 80;
    listen [::]:80;
    server_name yourdomain.com www.yourdomain.com;
    return 301 https://yourdomain.com$request_uri;
}

On Apache or shared hosting, put this at the top of the .htaccess file in your site root:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Behind Cloudflare, turn on SSL/TLS → Edge Certificates → Always Use HTTPS, and set the SSL mode to Full (strict) once your server has its own valid certificate. The “Flexible” mode combined with a redirect on your server is a common cause of endless redirect loops.

Step 3: Switch WordPress (or your CMS) to https://

In WordPress, open Settings → General and change both WordPress Address and Site Address to https://. Links already saved inside posts and widgets still say http://. With WP-CLI you can replace them in one go; run the dry run first and take a database backup before the real run:

wp option get siteurl
wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --all-tables --dry-run
# looks right? back up the database, then run it again without --dry-run

Step 4: Fix mixed content

Open the page, press F12 and look at the Console: browsers list every resource they blocked or downgraded because it was requested over http://. Change those URLs to https:// (or to relative paths), and replace any third-party widget that doesn’t support HTTPS. The redirects and mixed content guide has search commands and a Content-Security-Policy line that upgrades leftover requests automatically.

Step 5: Check every hop of the redirect chain

Chrome’s new warning also fires when a redirect step uses HTTP, for example https://yourdomain.com → http://www.yourdomain.com → https://www.yourdomain.com. Follow the chain from each starting address and make sure only the very first request is http://:

for u in http://yourdomain.com http://www.yourdomain.com https://yourdomain.com https://www.yourdomain.com; do
  echo "== $u"; curl -sIL "$u" | grep -iE '^(HTTP/|location:)'
done

Ideally every address reaches the final page in one redirect. Also update links you control: your Google Business Profile, social profiles, email signature and ads.

Step 6: Lock it in with HSTS

When every page and subdomain works over HTTPS, add the Strict-Transport-Security header so browsers skip HTTP entirely on later visits. Start with a short max-age and raise it once you’re confident. See HSTS explained.

Still seeing a warning?

• A full-page certificate error (for example NET::ERR_CERT_DATE_INVALID) is a different problem: see SSL certificate errors explained.
• Only on some pages: those pages still load something over http://, or a form posts to an http:// address.
• Only for some visitors: an old bookmark or link to http://, a cached redirect, or a subdomain without a certificate.
• After a host or CDN change: the new server may not have the certificate yet, or it serves a certificate for another name.

What HackGrade checks

HackGrade’s free scan checks the HTTP-to-HTTPS redirect, whether the certificate is trusted and when it expires, the TLS version, HSTS and mixed content on your homepage, and explains the first fixes in plain language. It only reads what any visitor’s browser can see.