WordPress Mixed Content: Find the HTTP Leak and Fix It Safely

You installed SSL. You expected the padlock to behave. Then your WordPress site says that it is not secure, an image disappears, a form refuses to submit, or Chrome shows blocked loading mixed active content in the Console.

That is the usual WordPress mixed content problem: the page loads over HTTPS, but one image, script, stylesheet, font, iframe, form request, embed, or AJAX call is still being requested over HTTP.

TL;DR: Find the exact HTTP resource first, then fix the place that creates it. Mixed content is usually fixed by correcting HTTP assets, WordPress settings, generated output, redirects, or cache.

Most cases are fixable. The mistake is treating mixed content like one problem with one cure. It is more like a water leak: the stain is visible in one place, but the pipe may be somewhere else.

Start with the source. Consider not starting with editing server files, forcing redirects everywhere, or running a site-wide database replacement because one warning appeared. Mixed content is a symptom. Your job is to find the URL behind it.

What the warning means

Mixed content means an HTTPS page is trying to load something through plain HTTP.

The visible problem is the browser warning. The hidden problem is trust. The browser no longer sees the whole page as secure because one part of it arrived through an insecure route.

Browsers do not treat every resource the same way. An old image URL may still load, or the browser may try to upgrade it to HTTPS. Scripts, stylesheets, iframes, fonts, AJAX requests, and form actions are more serious because they can change what the page does. Browsers often block those.

That is why a small-looking warning can break something important. One HTTP script can stop a menu. One HTTP form action can interrupt a lead form. One HTTP admin-ajax.php request can make a plugin feature fail only on the pages where that plugin runs.

Treat mixed active content as urgent. A blocked image is annoying. A blocked script, iframe, stylesheet, font, form action, or request can change how the page works.

Why SSL did not fix everything

SSL gives your site a secure connection. It does not rewrite every URL WordPress has saved, generated, cached, or inherited from an old embed. HTTP URLs can hide in dull places. That is why this error often appears after a migration that otherwise looked successful.

Cache is where people lose time. Cache can make a fixed site look broken, but clearing the cache rarely fixes the original bad URL. It only removes an old copy of the page.

Choose the right fix

Use the warning as a clue, not as a diagnosis.

If you see this	Start here
Not Secure appears on many pages	Check SSL, domain version, and WordPress URLs
One image or media file is HTTP	Edit the page, block, widget, media reference, or run a safe own-domain search-replace
A plugin or theme folder appears in the HTTP URL	Update that component, then check its settings
A builder CSS file or layout uses HTTP	Use the builder’s URL replacement or asset regeneration tool
An outside script, font, badge, map, iframe, or video is HTTP	Switch to HTTPS, replace it, remove it, or host it safely if allowed
Forms, AJAX, checkout, login, or menus break	Check HTTPS detection, CDN/proxy settings, plugin settings, and Console errors
The warning remains after a fix	Clear WordPress, host, CDN, builder, optimization, and browser cache
A certificate warning appears before mixed content	Fix SSL first

The pattern matters: a database replacement will not fix a third-party widget that only serves HTTP. A redirect will not clean an old URL inside a page builder layout.

Find the exact HTTP resource

Before changing anything, find the request the browser is complaining about.

If the Console message is vague, check the Network or Security tab. You are looking for the actual insecure request, not the browser’s summary.

Now ask the simplest question: does the same resource work over HTTPS?

Open the copied URL in a new tab and change http:// to https://. If it loads, the fix is probably to update the stored or generated URL. If it fails, do not force it. Replace the resource, remove it, or use a different source that supports HTTPS.

If browser tools feel too technical, use a scanner such as WhyNoPadlock to list insecure resources. Treat the scanner as a pointer. It tells you where to look; it does not decide the safest fix for your site.

The Network panel is useful when the Console warning does not give you enough detail.

Check more than the homepage. Test old posts, high-traffic pages, landing pages, forms, checkout, login, account pages, pages with embeds, and mobile layouts. Mixed content often appears only on one template, one widget, or one builder section.

A warning on one page does not prove the whole site is broken. It proves that one page is loading at least one insecure resource. Fix by source, then retest the pages visitors actually use.

Check SSL and WordPress URLs

Start with the boring checks because they decide whether WordPress keeps generating the wrong links.

Confirm that the SSL certificate is valid, unexpired, and issued for the exact domain visitors use. example.com and www.example.com are not always interchangeable. If you still need to install an SSL certificate, do that before chasing mixed content. If the certificate is invalid or the browser shows a certificate warning before any mixed content warning, fix that first.

Then go to Settings > General in wp-admin. Make sure WordPress Address (URL) and Site Address (URL) both use https:// and the correct domain version.

If you cannot access wp-admin, ask your host or developer to check the site URL values. Do not guess in the database if you are not comfortable recovering the site afterward. This step is the baseline. It will not rewrite old URLs already saved inside content, builder data, widgets, plugin settings, or custom code.

Fix old URLs in content

Stored HTTP URLs are the most common cause after an HTTPS migration.

If there are only a few, edit them by hand. Open the affected page, post, image block, menu item, widget, custom HTML block, or builder section. Replace your own-domain http:// URL with the correct https:// version.

If there are many, use a WordPress-safe bulk method such as Better Search Replace or WP-CLI. Before a bulk change:

For broad own-domain replacements, a dry run gives you a count to review before anything changes.

If the site handles orders, leads, memberships, bookings, or paid traffic, do not skip the backup. A bad search-replace can break more than the warning you started with.

Fix plugins, themes, builders, and outside resources

Use this section when the warning keeps returning after the obvious content URLs are fixed. If the HTTP URL is generated by a component or an outside service, database cleanup may not stick. The same bad URL can be printed again on every page load.

The clue is usually in the URL path. /wp-content/plugins/ points you toward a plugin. /wp-content/themes/ points you toward a theme. A domain you do not own points you toward an outside service.

For managed maintenance workflows, consider WP Remote’s safe updates are relevant before broad plugin or theme changes.

Use a mixed content plugin carefully

A mixed content plugin can help when you need quick relief or when WordPress still outputs HTTP URLs after a migration.

Plugins such as SSL Insecure Content Fixer or Really Simple SSL can rewrite some insecure URLs before visitors see the page. That is useful when the HTTP resources are on your own domain and already work over HTTPS.

Use this path as a bridge, not a permanent hiding place. If an old HTTP URL is stored in the database, the cleaner fix is to update the stored URL. If a plugin, theme, or builder generates the bad URL, fix that source.

Start with the lowest-impact setting that removes the warning. Aggressive capture, AJAX, or output-buffering modes can affect speed or break forms on some sites, so test important pages after each change.

A runtime fixer works while it is active and configured. Source cleanup is better when you can do it safely because the site no longer depends on a plugin intercepting bad output.

Force HTTPS without creating loops

HTTPS redirects are useful. They send visitors from the HTTP version of a page to the HTTPS version. They are not a complete mixed content fix.

Your HTTPS page can still print an HTTP script, image, iframe, or form request. A redirect may happen after the request, but the browser can still warn, and active content can still be blocked. Use one clear HTTPS enforcement method:

Do not enable every option at once. Multiple redirect systems can create loops, especially behind a CDN or reverse proxy.

HSTS is not a quick repair either. It tells browsers to remember HTTPS for your domain, but it does not clean old WordPress URLs. CSP upgrade-insecure-requests can help in advanced setups, but it should support cleanup, not replace it. The redirect is traffic control. It is not the cleanup crew.

Clear cache and retest

After fixing the source, clear your WordPress cache and every layer that may still hold old page output.

If another HTTP URL appears, repeat the same process. Mixed content cleanup often happens one source at a time. Annoying, yes. Still better than making a broad change that breaks production.

Prevent it from returning

Once the site is clean, make HTTPS part of normal site maintenance.

Prevention is not “fix once.” It is “check after anything that changes page output.”

When to ask for help

You can fix a visible image, page URL, widget, or simple embed yourself if you can edit it and test it.

The rule is simple: fix clear content issues yourself. Escalate server, database, proxy, and code fixes when guessing could take the site down.

FAQs

What is WordPress mixed content?

WordPress mixed content happens when an HTTPS WordPress page loads at least one resource over HTTP. That resource may be an image, script, stylesheet, font, iframe, form request, AJAX request, video, or embed.

How do I fix mixed content in WordPress?

Find the exact HTTP resource in the browser Console or a scanner, then fix the source. That may mean updating WordPress URLs, editing content, running a safe search-replace, updating a plugin or theme, regenerating builder assets, replacing an external resource, correcting CDN settings, and clearing cache.

Why does my WordPress site still say Not Secure after SSL?

SSL protects the connection, but it does not rewrite old HTTP URLs saved in WordPress. Your certificate can be valid while a page still loads an insecure image, script, iframe, font, or form request.

What causes blocked loading mixed active content in WordPress?

It usually means an HTTPS page tried to load active content over HTTP, such as JavaScript, CSS, an iframe, a font, an AJAX request, or a form action. Browsers block these because they can affect how the page behaves.

Can a plugin fix WordPress mixed content?

Sometimes. A plugin can rewrite insecure URLs at page output, which helps for quick relief. It is not always permanent. If the bad URL is stored in the database or generated by a plugin, theme, or builder, fixing the source is better.

Conclusion

Mixed content looks like a browser warning, but the real problem is usually a URL source inside WordPress, a plugin, a theme, a builder, a CDN, cache, or an outside service. Find the exact HTTP URL first. Then choose the fix that matches the source.

Work in this order: confirm SSL and WordPress URLs, clean old stored URLs, fix generated or external resources, use plugins only where they fit, clear cache, and retest the pages that matter.

That keeps the repair focused, avoids risky guesswork, and gives visitors the secure page they expected when they saw HTTPS.