Why does my site still show mixed content after I changed WordPress to HTTPS?

Because old HTTP URLs can still exist in posts, widgets, plugin settings, theme files, cached pages, or CDN assets. Changing the site URL is important, but it usually is not enough on its own.

Can I just use a plugin to fix mixed content?

Sometimes, but it depends on where the problem lives. Plugins can help rewrite some URLs, but they will not always fix hard-coded theme files, external assets, or CDN configuration issues.

Is mixed content a security risk?

Yes. It weakens the trust signal of your site and can cause browsers to block or warn on insecure resources. It also makes users less confident, especially on checkout, login, and form pages.

Why does the padlock behavior differ between browsers?

Browsers do not all display mixed content the same way. Some show warnings more clearly than others, and some block insecure assets more aggressively, so the exact icon or message can vary.

Why WordPress Padlock Won’t Turn Green: Mixed Content Fix

If your site shows a padlock but it never turns fully green, you usually have mixed content: the page loads over HTTPS, but one or more images, scripts, styles, fonts, or iframes are still being loaded over HTTP. The fix is to find the insecure URLs, replace them with HTTPS, and make sure WordPress stops generating old links in the first place.

The good news is that this is usually fixable without rebuilding the site. The tricky part is that the warning often comes from a few hidden places at once: old database URLs, hard-coded theme files, plugin assets, CDN settings, or a proxy/CDN that is still serving the wrong scheme.

What mixed content actually means

Browsers treat HTTPS as secure only when every asset on the page is also secure. If the page itself loads from https:// but something like an image, CSS file, JavaScript file, font, video, or embedded map still loads from http://, the browser calls that mixed content.

Some browsers block only the insecure pieces. Others warn more loudly, and users may see a padlock that looks broken, missing, or replaced with an alert icon depending on the browser and version. The exact visual behavior varies, but the underlying issue is the same.

What you may be seeing

The padlock never turns fully secure.
The browser shows a “Not secure” warning on pages that should be HTTPS.
Parts of the page load, but images, sliders, fonts, or scripts are missing.
The browser console shows mixed content messages.
Checkout, login, or form pages feel less trustworthy to visitors.

Sometimes the homepage looks fine, but a different page still has warnings. That usually means the site has a mix of old content and newer content, or the problem exists only in a template, widget, or plugin output.

The most common causes

Mixed content on WordPress usually comes from one of these places:

Old site URLs in the database — content created before HTTPS still points to http://.
Hard-coded links in theme files — the theme or child theme outputs insecure asset URLs directly.
Plugin settings — a slider, form, page builder, or gallery stores full HTTP URLs.
Upload or media URLs — image links in posts or widgets still use the old scheme.
CDN or proxy settings — the edge layer is serving HTTP references or mismatched canonical URLs.
External embeds — maps, videos, ad tags, or widgets load insecure resources.

A very common pattern is this: the WordPress Address and Site Address are set to HTTPS, but older page content still contains HTTP links, so the browser keeps finding insecure resources even though the site seems “migrated.”

Fix it safely: the step-by-step approach

Before you change anything, make a full backup. If you have a staging site, use that first. Mixed content fixes are usually safe, but search-and-replace changes can affect a lot of content at once, so it is smart to have a rollback point.

1) Confirm the issue in the browser

Open the page in a browser and use the developer tools console. Look for mixed content warnings. They often tell you the exact file or page where the insecure resource is being loaded from.

If you do not want to use developer tools, you can still inspect the page source and search for http://. This is slower, but it can reveal obvious leftover links.

2) Check WordPress URL settings

In WordPress, go to Settings and confirm both the WordPress Address and Site Address use https://. If either one still uses http://, fix that first.

If your site is forced through a host panel, a CDN, or a reverse proxy, the values in WordPress may be correct while the edge layer is not. In that case, the fix may need to happen at the host or proxy level as well.

3) Replace old HTTP URLs in content

The safest way to clean up a WordPress database is with a tool that understands serialized data. Many hosts and maintenance tools offer this. If you use a database search-and-replace tool, use one that explicitly supports WordPress serialized data so you do not break plugin settings.

Look for old instances of:

http://yourdomain.com
http://www.yourdomain.com

Replace them with the correct HTTPS version. This often fixes posts, pages, widgets, and builder content in one pass.

4) Regenerate image and media URLs if needed

If your images are still loading over HTTP, the problem may be in the content itself or in a plugin that stores image URLs in custom fields. After replacing URLs, clear any cache and reload the page in a private window.

Some page builders also keep their own cached copy of layout data. If the browser still sees HTTP after a database replace, check the builder’s settings or regenerate its CSS and data cache.

5) Fix theme and plugin file references

If the insecure URLs are coming from theme files, search for hard-coded http:// references inside the active theme and child theme. Common places include header, footer, enqueue functions, and custom template parts.

When you find one, change it to a relative path, a protocol-relative pattern only if truly appropriate, or better yet use WordPress functions that output the correct HTTPS URL dynamically. For theme and plugin development, that is the durable fix.

6) Check the browser console for the exact blocker

Many people focus on the first warning they see, but the console often points to the real blocker. For example, a single insecure font file can keep the page from appearing fully secure, even if the visible content looks fine.

If the console shows a CDN file, a Google Font, a third-party script, or an embedded service, the fix may not be in WordPress at all. You may need to update the asset URL at the provider, in the plugin settings, or in the CDN configuration.

7) Clear every cache layer

After changing URLs, clear the browser cache, WordPress cache plugin cache, host cache, and CDN cache. Mixed content warnings can appear “stuck” simply because an older cached HTML page is still pointing to HTTP assets.

If you use a page cache and a CDN together, clear both. It is common for one layer to update while the other keeps serving old markup.

8) Force HTTPS correctly

If the site sometimes loads HTTP, make sure the server redirects all traffic to HTTPS with one consistent redirect rule. Also check that your SSL certificate is valid and matches the domain and any www/non-www version you actually use.

Do not rely on browser auto-upgrades alone. A good redirect setup prevents future HTTP links from being served to visitors and helps stop old bookmarks or internal links from creating confusion.

A quick checklist for the stubborn cases

Search the database for http:// and replace carefully.
Check widgets, custom fields, menus, and builder templates.
Inspect active theme files for hard-coded URLs.
Review CDN settings and cached assets.
Clear all caches after every change.
Test in a private browser window and on mobile, not just your logged-in session.

How to prevent mixed content from coming back

Once you clean up the current warning, the goal is to keep new HTTP links from creeping in again. The best prevention is a site-wide HTTPS setup, plus habits that avoid hard-coding full URLs in content or templates when a dynamic WordPress function will do the job.

For teams that publish a lot of content, it helps to standardize on HTTPS in templates, review plugin settings after installs, and verify page-builder global settings whenever a new element is added. If you move hosts, change domains, or add a CDN, test a few pages with the browser console before declaring the migration finished.

When to call a professional

If you have replaced obvious URLs and the padlock still will not go green, the problem is probably buried in a theme file, serialized settings, a builder cache, or a CDN/proxy layer. That is where a lot of site owners lose time, because the visible symptom stays the same even while the cause moves around.

If you want this fixed quickly and safely, Mend can diagnose the site first and then make the repair on a backup-first workflow. Start with a free diagnosis, or if the site is actively broken for visitors, use Emergency Rescue. Every paid fix includes a plain-English report of what caused the issue and what was changed.

Related fixes that often help

If the warnings appeared right after a migration, update, or host change, these guides may also help:

Need hands-on help? If you want a senior engineer to trace the exact source of the insecure URL and fix it for you, Mend’s free diagnosis will triage the issue first and quote a flat price before any work starts.