How to Fix Mixed Content Warnings on a WordPress Site

Your fan site has an SSL certificate, the address bar should show a padlock, and instead it shows a warning or a grey "Not secure" label. Half the guild thinks the site was hacked. In almost every case the real cause is mixed content warnings: the page loads over HTTPS, but some images, scripts or fonts inside it still load over plain HTTP, and the browser refuses to call the page secure.

This guide walks through how to find every insecure request on a WordPress site, fix it at the source rather than hiding it, and stop new ones from creeping back in after the next theme update or guest post.

What mixed content warnings actually mean

When a browser loads a page over HTTPS, it expects every resource on that page to arrive the same way. If your header banner is still referenced as http://yoursite/wp-content/uploads/2021/04/banner.jpg, the browser has a choice to make. Modern Chrome, Firefox, Edge and Safari all handle it in two tiers.

• Passive mixed content such as images, audio and video is usually upgraded automatically to HTTPS or loaded with a warning. The padlock disappears, but the page still works.
• Active mixed content such as scripts, stylesheets, iframes and fonts is blocked outright. This is where things break: a missing stylesheet means a raw, unstyled page, and a blocked script can kill your raid calendar or Discord widget.

So the warning is not just cosmetic. One blocked file can take out a whole sidebar.

Where insecure URLs hide on a WordPress site

Most sites that switched to HTTPS did it by changing the two address fields under Settings, General. That changes new links, but it leaves years of old ones untouched. On a typical fan site that has run for three or four years, insecure URLs pile up in five places:

1. Post and page content. Every image inserted before the switch carries a hardcoded http:// address in the database. A site with 600 posts can easily have 4,000 of these.
2. Widgets and custom HTML blocks. Old banner ads, clan recruitment graphics and copied embed codes.
3. Theme options. Logo and background image fields saved in the theme customizer, often stored as serialized data.
4. Hardcoded theme or child theme files. A functions.php that enqueues a font from an http:// address, or a header.php with a pasted tracking script.
5. Third party embeds. Old forum signatures, server status images and stat cards from services that may not support HTTPS at all.

How to find every mixed content warning in about 15 minutes

Start with the browser, because it tells you exactly which file is the problem.

Use the console on your worst pages

Open your homepage, press F12, and switch to the Console tab. Reload. Each insecure request appears as a line beginning with "Mixed Content" followed by the full URL. Do the same on your oldest post, a category archive and any page with embeds. Copy each URL into a plain text file. Patterns appear fast: if every warning points to /wp-content/uploads/, the fix is a database update. If one points to a font CDN, it lives in the theme.

Search the database directly

If you have WP-CLI access through your host, run its search-replace command from http://yoursite to https://yoursite with the dry run flag added. That counts the problem without changing anything. The dry run lists every table and how many replacements it would make. A count in wp_posts is normal. A count in wp_options usually means theme settings. A count in a forum or plugin table tells you which plugin stored old links.

No WP-CLI? A plugin like Better Search Replace does the same job through the dashboard, including a dry run option. Delete it once the job is done.

Fixing it properly, one layer at a time

Take a fresh backup before touching the database. If you have never tested a restore, read our guide to WordPress backups that actually restore first, because a bad search and replace is one of the few mistakes that can corrupt a whole site in under a minute.

1. Run the real search and replace. Replace http://yoursite with https://yoursite across all tables. WP-CLI and Better Search Replace both handle serialized data safely. Never do this with a raw SQL UPDATE query, because it breaks serialized string lengths and wipes theme settings.
2. Check the www version too. If your site ever ran as http://www.yoursite, run a second pass for that exact string.
3. Fix theme files by hand. Search your child theme for "http://" in a code editor. Change each one to https://, or remove the protocol entirely if the resource supports both.
4. Replace dead embeds. If a third party image service has no HTTPS version, no code change will save it. Download the image, upload it to your own media library, or remove the widget.
5. Clear every cache. Plugin cache, server cache and CDN cache. Many people fix the database, see the same warning, and assume the fix failed when they are looking at a cached page from yesterday.

After this, reload the same pages with the console open. On most sites the warning list drops to zero or one or two stubborn embeds.

Why a "fix SSL" plugin is not the answer

The most common advice on forums is to install a plugin that forces HTTPS and rewrites URLs on the fly. It works, in the sense that the padlock comes back. We still recommend against leaving one running long term.

These plugins rewrite the page output on every single request. That adds processing time to every page view, and on a busy patch day with 3,000 visitors an hour it is wasted server work. Worse, it hides the problem. The database still holds thousands of http:// links, so if the plugin is ever deactivated during a plugin audit or a conflict, every warning returns at once. Some of these plugins also add their own redirect rules that fight with your host's redirects and create loops.

Use one as a temporary bandage for a day while you plan the proper fix if you must. Then fix the data and remove it.

Stopping new mixed content from appearing

Once the site is clean, two small settings keep it that way.

• Force HTTPS at the server. Set a 301 redirect from HTTP to HTTPS in your host panel or .htaccess, so every old link someone shares on Reddit lands on the secure version.
• Add the upgrade-insecure-requests header. A Content-Security-Policy header with the value upgrade-insecure-requests tells browsers to try HTTPS for any stray http:// resource before giving up. It is a safety net, not a replacement for clean data.
• Check guest content before publishing. Writers who paste embed code from old guides bring old URLs with them. A ten second console check on the preview catches it.

Then confirm in Google Search Console that the HTTPS property shows your pages as indexed. If you have not added the HTTPS version yet, our walkthrough on how to set up Google Search Console for a fan site covers it.

Frequently asked questions

Do mixed content warnings hurt SEO?

Not directly as a ranking penalty, but they cause real side effects. Blocked scripts and stylesheets can break layout, which hurts engagement, and Chrome may show visitors a "Not secure" label that makes them leave. Fixing the warnings removes both problems.

Why do I still see mixed content after changing my WordPress URL to HTTPS?

Changing the site address only affects new links WordPress generates. Every image and link saved in old posts, widgets and theme settings still holds the original http:// address. You need a database search and replace to update them.

Is it safe to run search and replace on a live WordPress database?

It is safe if you use a tool that handles serialized data, run a dry run first and take a backup you know can be restored. Doing it on a staging copy first is even better for large sites. Avoid raw SQL replacements entirely.