How to Fix Mixed Content & “Not Secure” SSL Errors in WordPress

← Back to all WordPress fixes

Introduction

You installed an SSL certificate and moved your WordPress site to HTTPS — but the browser still shows “Not Secure” in the address bar, or a padlock with a warning. This is the classic mixed content problem: your pages load over secure HTTPS, but some resources on them — images, scripts, or stylesheets — are still being requested over insecure HTTP. Browsers flag the whole page as not fully secure until every resource is served over HTTPS. Here’s how to fix it for good.

What “Mixed Content” Actually Means

When a single page mixes secure (HTTPS) and insecure (HTTP) resources, that’s mixed content. The page itself may be secure, but if it pulls in an image or script over http://, the browser can’t guarantee the whole page is safe — so it drops the padlock or shows a warning. The cause is almost always old http:// URLs still saved in your database or hardcoded in your theme.

Step 1: Confirm the Certificate and Site URLs

First, make sure the foundation is right. Your host must have a valid SSL certificate installed (most offer free Let’s Encrypt certificates). Then, in WordPress, go to Settings → General and confirm both WordPress Address (URL) and Site Address (URL) start with https://. If they still say http://, update them, save, and log back in.

Step 2: Find What’s Loading Over HTTP

To see exactly which resources are insecure, open the problem page in your browser, right-click and choose Inspect, and look at the Console tab. Mixed content warnings list each http:// resource by URL — often images in old posts, a hardcoded logo, or an asset from a plugin or theme. This tells you precisely what needs fixing.

Step 3: Update Old HTTP URLs in the Database

The most common fix is a database search-and-replace that swaps every http://yourdomain.com for https://yourdomain.com. Two safe ways to do it:

• The easy way — the free Really Simple SSL plugin detects insecure URLs and rewrites them to HTTPS automatically, which resolves most mixed content issues in one click.
• The manual way — a search-replace plugin like Better Search Replace lets you replace the URLs across your database directly.

Important: WordPress stores a lot of data in serialized form, and a careless raw SQL find-and-replace can corrupt it. Always use a tool that handles serialized data correctly — the same care matters when migrating a site or changing its domain. And before running any database-wide replace, take a backup so you can revert instantly if something looks off.

Step 4: Force HTTPS for Every Visitor

Once your URLs are fixed, make sure no one can still reach the insecure version. The Really Simple SSL plugin handles this automatically. To do it manually on Apache, add a redirect to the top of your .htaccess file that sends all HTTP traffic to HTTPS. (Back up .htaccess first — a bad rule there can cause a 500 error.)

Step 5: Clear Every Cache

After making these changes, clear your WordPress caching plugin, your host’s server cache, any CDN cache, and your browser cache. Cached pages often still reference the old HTTP URLs, which can make it look like the fix didn’t work when it actually did.

Frequently Asked Questions

Why does my homepage show secure but some posts don’t?
Those posts contain hardcoded http:// image or link URLs saved in their content. A database search-replace (Step 3) updates them all at once.

Is Really Simple SSL enough on its own?
For most sites, yes — it fixes insecure URLs and forces HTTPS. Sites with assets hardcoded in theme files may still need a small manual edit to those files.

Do I need to fix this for SEO?
Yes. HTTPS is a ranking signal, and a “Not Secure” label scares away visitors. Fixing mixed content protects both your rankings and your conversions.

Could a search-replace break my site?
Only if it mishandles serialized data — which is why you should use a proper search-replace tool and take a backup first. With both in place, it’s safe and reversible.

Conclusion

The “Not Secure” warning isn’t about your certificate being broken — it’s about leftover http:// resources on otherwise-secure pages. Confirm your certificate and site URLs, update old URLs in the database with a serialized-safe tool, force HTTPS, and clear your caches. Do that, and the padlock comes back for good.