How to Fix 'Not Secure' Website Warning in Google Chrome (2026 Guide)

Nothing destroys customer confidence faster than navigating to a website and seeing a prominent “Not Secure” warning in the Google Chrome address bar. For e-commerce stores, healthcare portals, or corporate agencies, this red flag prompts immediate user abandonment: over 84% of online shoppers state they will immediately exit a website that displays a browser security warning.

Furthermore, Google’s ranking algorithms actively downgrade unencrypted websites in organic search results, and modern advertising networks (Google Ads, Meta) frequently suspend campaigns directing traffic to non-HTTPS landing pages.

Whether your website is completely missing an SSL certificate or has a valid certificate but suffers from Mixed Content errors, this comprehensive 2026 guide will help you eliminate the “Not Secure” warning for good.

---

1. Why Chrome Displays the “Not Secure” Warning

Google Chrome enforces an HTTPS-by-default posture. Chrome flags a connection as “Not Secure” under three distinct architectural scenarios:

┌────────────────────────────────────────────────────────────────────────┐
│                   THE 3 CHROME SECURITY WARNING STATES                 │
├────────────────────────────────────────────────────────────────────────┤
│ SCENARIO A: Plain HTTP (No SSL Certificate Installed)                  │
│  - Address: http://example.com                                         │
│  - Indicator: Grey or Red "Not Secure" pill                            │
│  - Cause: Traffic sent unencrypted in plaintext across the network     │
│                                                                        │
│ SCENARIO B: Mixed Content (SSL Installed, Insecure Assets Embedded)   │
│  - Address: https://example.com                                        │
│  - Indicator: Red triangle or disabled padlock with warning            │
│  - Cause: Secure HTML loads images, scripts, or fonts via http://      │
│                                                                        │
│ SCENARIO C: Expired or Untrusted Certificate Authority                 │
│  - Indicator: Full interstitial warning ("Your connection is not private")│
│  - Cause: Certificate past expiration date or intermediate CA missing  │
└────────────────────────────────────────────────────────────────────────┘

---

2. Step 1: Install a Valid SSL/TLS Certificate

If your website does not have an active SSL certificate installed, this is your immediate priority.

Option A: Enable Free AutoSSL in cPanel

Most modern hosting providers provide free automated SSL certificates via Let’s Encrypt or Sectigo:

1. Log into your cPanel.
2. Navigate to Security > SSL/TLS Status.
3. Select your domain names and click Run AutoSSL.
4. Within 2 to 5 minutes, valid wildcard certificates are provisioned and installed automatically.

Option B: Issue via Certbot (For VPS & Dedicated Servers)

If you manage an unmanaged Linux server running Nginx or Apache, issue a free certificate via Certbot:

# For Ubuntu/Debian running Nginx
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

Certbot automatically modifies your web server configuration files and sets up a systemd renewal timer.

---

3. Step 2: Enforce Full-Site 301 HTTPS Redirection

Installing an SSL certificate is only half the battle. If a visitor types yourdomain.com, browsers will still attempt to load unencrypted HTTP unless your web server forces an immediate 301 Permanent Redirect.

For Apache / LiteSpeed (via .htaccess):

Add the following directives to the very top of your root .htaccess file:

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

For Nginx:

Update your port 80 server block to redirect all incoming traffic to port 443:

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

---

4. Step 3: Eliminate Mixed Content Errors (The #1 Culprit!)

You have an active SSL certificate, yet Chrome still displays “Not Secure”? You are almost certainly suffering from Mixed Content.

Mixed content occurs when your main HTML webpage loads securely over HTTPS, but elements inside the page (such as images, background banners, custom fonts, or third-party tracking scripts) are hardcoded with http:// URLs:

<!-- ❌ MIXED CONTENT TRAP: Triggers Chrome Not Secure Warning -->
<img src="http://example.com/wp-content/uploads/2026/01/logo.png" />

<!-- ✅ SECURE PROTOCOL-RELATIVE OR HTTPS: -->
<img src="https://example.com/wp-content/uploads/2026/01/logo.png" />

How to Detect Mixed Content Instantly:

1. Open your website in Google Chrome.
2. Press F12 (or right-click and select Inspect) to open Chrome Developer Tools.
3. Click on the Console tab.
4. Look for yellow and red warnings reading: Mixed Content: The page at 'https://...' was loaded over HTTPS, but requested an insecure element 'http://...'. This request was automatically upgraded or blocked.

How to Fix Mixed Content in WordPress:

1. Update WordPress Address URLs: Go to Settings > General and ensure both WordPress Address (URL) and Site Address (URL) begin with https://.
2. Database Search & Replace: Use WP-CLI or the “Better Search Replace” plugin to replace all instances of http://yourdomain.com with https://yourdomain.com across all tables.
3. Enforce Upgrade Insecure Requests via CSP Header: Add this Content Security Policy header to your server configuration to instruct browsers to automatically upgrade insecure URLs:

<IfModule mod_headers.c>
Header always set Content-Security-Policy "upgrade-insecure-requests;"
</IfModule>

---

5. Step 4: Implement Strict-Transport-Security (HSTS)

To ensure browsers permanently remember to connect only via HTTPS—even before making their first network request—implement HTTP Strict Transport Security (HSTS):

# Add to .htaccess
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

This protects your visitors against man-in-the-middle SSL stripping attacks on public Wi-Fi networks.

---

6. Enterprise SSL Performance on Dedicated Hardware

On overloaded shared hosting servers, performing TLS handshakes for thousands of visitors can tax shared CPU threads, leading to intermittent SSL timeouts and handshake drops.

Migrating your web applications to high-performance Dedicated Servers provides dedicated cryptographic instruction sets (Intel AES-NI / AMD SHA extensions), dedicated IPv4/IPv6 subnets, and modern TLS 1.3 execution with zero latency overhead.

For domestic Pakistani applications requiring the fastest local SSL handshakes and data sovereignty, deploy on certified Dedicated Servers in Pakistan for sub-10ms response times nationwide.