WordPress SSL & Mixed Content Errors – Not Secure Fix

This guide has been written and checked for accuracy but not yet re-verified in a single named environment. The steps are standard and safe; where a step carries risk it is flagged inline.

Quick answer: The padlock is missing or the browser warns “Not secure” for one of two reasons. Either your SSL certificate is not installed or has expired — a server-level problem your host fixes — or the certificate is fine but the page loads some images, scripts, or styles over insecure http://. That second case is “mixed content,” and you fix it by pointing WordPress and its content at https:// everywhere.

Two different problems that look the same

Both of these show up as a browser security warning, but they have completely different fixes, so the first job is telling them apart:

No valid certificate. The browser says the certificate is invalid, expired, or missing (errors like NET::ERR_CERT_INVALID or “Your connection is not private”). The site has no working SSL. This is a hosting problem.
Mixed content. The site loads fine over HTTPS but the padlock is missing or crossed out, and the browser console warns about content loaded over HTTP. The certificate is fine; some resources on the page are still insecure. This is a WordPress content problem.

Open the page, click the padlock area in the address bar, and check what the browser actually says. A certificate complaint sends you to Step 1. A working HTTPS page with a broken padlock sends you to Step 2.

Step 1: Fix a missing or invalid certificate

If there is no valid certificate, WordPress cannot solve this — the certificate lives on the server. Check your hosting panel for an SSL section. Most hosts now offer a free Let’s Encrypt certificate you can enable in one click, and many install one automatically. If yours is missing, expired, or shows an error:

Enable or reissue the free SSL certificate from your hosting panel’s SSL screen.
Wait for it to activate — a new certificate can take a few minutes to an hour to propagate.
If it will not issue, the usual blocker is DNS: the domain must point at this host for the certificate authority to validate it. Confirm your domain’s DNS is correct, or ask your host, who can see why issuance is failing.

A specific mismatch error — the certificate is for a different domain, or covers example.com but not www.example.com — also belongs to the host. Ask them to issue a certificate that covers the exact hostname you are using.

Step 2: Fix mixed content

If the certificate is valid but the padlock is broken, some resources on the page are loading over http://. Find them first: open the page, open the browser’s developer console (F12), and look for warnings that say “Mixed Content” — each one names the exact insecure URL, usually an image, script, or stylesheet.

Set the site to HTTPS

In Settings → General, make sure both WordPress Address and Site Address begin with https://. If they still say http://, that alone causes mixed content everywhere. Update both, save, and log back in.

Update insecure URLs in your content

Old posts and settings often contain hard-coded http:// links to your own images and files, saved before SSL existed. These must be updated to https://. The reliable way is a database search-and-replace — using a trusted plugin like Better Search Replace, or WP-CLI if you have server access:

wp search-replace 'http://yoursite.com' 'https://yoursite.com' --skip-columns=guid

Back up the database before a search-replace. It rewrites content across every table and cannot be undone without a backup. The --skip-columns=guid flag matters too — rewriting the guid column can disrupt feed readers, so leave it out of the replacement.

The quick route, if you prefer

A plugin such as Really Simple SSL handles both of the above automatically — it sets the URLs and rewrites insecure resources on the fly. It is the fastest fix and fine for most sites. Doing it manually as above is cleaner long-term because it fixes the content at the source rather than rewriting on every page load, but either works.

Step 3: Force HTTPS so no one lands on the insecure version

Once HTTPS works, redirect all HTTP traffic to it so visitors and search engines only ever use the secure version. Add this near the top of your .htaccess file, above the # BEGIN WordPress block, replacing the domain:

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

Most SSL plugins add an equivalent redirect for you, so you may not need this by hand.

Rollback

If a search-replace went wrong, restore the database backup you made first — this is exactly why you made it. If the .htaccess redirect caused a redirect loop or a 500, remove the block you added. An SSL plugin can be deactivated to undo its automatic changes.

Frequently asked questions

My site says “not secure” but I have a certificate. Why?

That is mixed content: the certificate is valid, but the page loads at least one resource over HTTP, so the browser cannot call the whole page secure. The developer console names the offending URLs. Fixing those, per Step 2, restores the padlock.

Do I need to redirect HTTP to HTTPS, or is having the certificate enough?

You should redirect. Without it, both an insecure and a secure version of every page exist, which splits your SEO and lets visitors land on the unprotected one. The redirect in Step 3 makes HTTPS the single canonical version.

Will switching to HTTPS hurt my search rankings?

The opposite — HTTPS is a positive ranking signal and browsers now actively warn against sites without it. There can be a brief settling period as search engines recognise the move, which the 301 redirect handles cleanly by telling them the secure URL is now canonical.