How to Fix the “Not Secure” Warning on a WordPress Site

Quick check: open the page in Chrome, press F12 and look at the Console and Security tabs. The browser names the exact problem — an invalid certificate, or a specific insecure resource. Everything below follows from which one it reports.

Case 1: the certificate itself is the problem

Symptoms are a full interstitial warning rather than a subtle "Not secure" label.

Fixes, in order:

1. Issue or renew the certificate in your hosting panel. Most hosts offer free automated certificates; if auto-renewal failed, the usual cause is a DNS change or a redirect interfering with domain validation.
2. Cover every hostname you use — apex and www at minimum, plus any subdomain that serves content.
3. Install the full chain. A certificate that works in a desktop browser but fails on a phone or in curl almost always has a missing intermediate.
4. Confirm the site is served over HTTPS at all. A certificate that exists but is not bound to the site produces a protocol error.

Verify from the command line, which shows the chain and the expiry date:

curl -vI https://example.com 2>&1 | grep -Ei 'subject|issuer|expire|HTTP/'

Case 2: mixed content

The certificate is valid, but the page loads something over HTTP, so the browser removes the padlock and blocks the resource.

The console names each one:

Mixed Content: The page at 'https://example.com/' was loaded over HTTPS,
but requested an insecure image 'http://example.com/wp-content/uploads/photo.jpg'.

Fix at the source rather than papering over it:

1. Set both URLs to https:// under Settings → General, or in wp-config.php if you cannot reach the admin:

   Copy

   <?php
   define('WP_HOME', 'https://example.com');
   define('WP_SITEURL', 'https://example.com');
   

2. Run a serialisation-aware search-and-replace across the database, changing http://example.com to https://example.com. Never use a plain SQL REPLACE, which corrupts serialised option values.

3. Check the theme and any custom code for hard-coded http:// asset URLs.

4. Look at widgets, page-builder blocks and options that store full URLs — these are often missed by a content-only replacement.

5. Purge every cache: plugin, host, CDN, browser.

External resources that only exist over HTTP have to be replaced or self-hosted. You cannot make a third-party HTTP asset secure from your side.

If styles disappear during this work, see WordPress CSS not loading.

Case 3: HTTPS works but HTTP still serves the site

Both versions loading means duplicate content for search engines and an insecure entry point for visitors. Redirect HTTP to HTTPS once, at the server.

Apache or LiteSpeed, above the WordPress block in .htaccess:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Behind a proxy or load balancer, HTTPS may not be set on the origin. Use the forwarded header your host documents, and tell WordPress the request is secure:

<?php
// wp-config.php, above the "stop editing" line.
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Without that, the admin can enter a redirect loop — the symptoms and other causes are in the login redirect loop guide.

Case 4: it is secure for you but not for visitors

Usually caching or a partial rollout:

• a CDN still serving cached HTTP pages — purge it;
• a plugin rewriting URLs only for logged-in users;
• one hostname missing from the certificate, so www visitors see the warning;
• a stale HSTS entry in your own browser making your test misleadingly optimistic.

Test in a private window on a different network before concluding anything.

After the padlock returns

• Update the site address in Search Console and analytics to the HTTPS version, and submit the sitemap again.
• Update internal links that still point at http://, so visitors do not take an extra redirect on every click.
• Check that canonical tags, sitemaps and feeds output HTTPS URLs.
• Confirm certificate auto-renewal actually runs — set a calendar reminder for a week before expiry until you have seen it renew unattended once.
• Verify the headers directly with an HTTP header check rather than trusting the browser icon alone.