You finally successfully installed an excellent Let’s Encrypt SSL certificate on your web server. You load your domain expecting to see the comforting, secure padlock icon next to your URL. Instead, Chrome throws a harsh gray warning icon, and Firefox boldly declares: "Parts of this page are not secure."
This is the infamous Mixed Content Error. It occurs when the core foundational HTML of a page loads securely over HTTPS://, but images, videos, stylesheets, or scripts hardcoded inside that HTML are still being blindly requested over the insecure HTTP protocol.
Browsers view this as an active security vulnerability, because attackers can manipulate an insecure image file to compromise a secure framework. Here is how to track down the leaks and fix the warning permanently.
Problem 1: Unchanged Database URLs
When you install an SSL certificate, WordPress doesn't magically search backward in time through your entire database and update 10,000 old historical blog posts to use the https:// prefix for old media uploads.
If you wrote an article in 2021 and inserted a logo, the source code in the database physically looks like this: <img src="http://domain.com/wp-content/uploads/logo.jpg">. Even if the site is secure now, the browser is forced to request that archaic insecure URL.
The Fix: You need to aggressively rewrite the old database entries.
- Take a verified full backup of your MySQL database.
- Install a reputable Search and Replace plugin (like Better Search Replace).
- Search strictly for:
http://yourdomain.com - Replace it with:
https://yourdomain.com - Run the tool to sanitize your old post content natively in bulk.
Problem 2: Hardcoded Theme Assets
Sometimes the database is perfectly clean, but the mixed content warning persists heavily on the homepage or the site footer.
This is nearly always caused by an older, lazily coded theme or custom child theme. An older developer may have physically typed an insecure http:// address directly into the header.php or footer.php file when referencing a specific Google Web Font, a third-party tracking script, or a raw background image file.
The Fix:
Navigate through the browser’s Developer Tools Console. It will explicitly list out exactly what URL triggered the mixed content barrier. If the URL points to an external font or a CSS stylesheet, you must physically open your theme files (or use the built-in Customizer) to scrub and replace the http:// declaration directly in the PHP templates with either https:// or protocol-relative sizing //.
Problem 3: The Cloudflare "Flexible" Loop
If you are using Cloudflare as your primary DNS and CDN provider, there is a notorious configuration that causes massive SSL confusion.
If you have a real, valid SSL certificate natively installed on your origin server (like Nginx/Apache), but your Cloudflare SSL mode is globally set to "Flexible," Cloudflare essentially intercepts secure traffic from visitors, decrypts it, and then requests the data from your server using an insecure HTTP tunnel. WordPress detects an insecure tunnel and tries to force a redirect back to HTTPS, causing an infinite, totally breaking redirect loop.
The Fix: If your web host natively provides its own SSL certificate (most do), log into your Cloudflare dashboard immediately. Navigate to the SSL/TLS tab, and forcibly change your encryption mode from Flexible to Full or Strict. This ensures secure encryption is strictly maintained end-to-end, and easily resolves 90% of massive proxy-level SSL errors.