A WordPress website can have a valid SSL certificate and still load insecure content.
This happens when the page itself uses HTTPS but one or more resources are still requested over HTTP.
Those resources might be images, stylesheets, JavaScript files, fonts, iframes or third-party services.
The result is known as mixed content.
Modern browsers may automatically upgrade some HTTP requests to HTTPS, while other insecure resources are blocked completely. That can make mixed content confusing because the website may appear to work while still producing warnings or missing assets.
This guide explains how to find the exact source of mixed content in WordPress and fix it safely.
What Is Mixed Content?
Mixed content occurs when an HTTPS webpage requests another resource using an insecure HTTP URL.
For example, the page itself might load from:
https://example.com/about/
but contain an image requested from:
http://example.com/wp-content/uploads/photo.jpg
The visitor has established a secure connection to the page, but the image request is still using HTTP.
Mixed content can involve:
- Images
- Stylesheets
- JavaScript
- Fonts
- Videos
- Audio
- Iframes
- Background images
- API requests
- Third-party embeds
- Plugin assets
The underlying problem is the same in each case: part of the supposedly secure page is still being requested through an insecure connection.
How Browsers Handle Mixed Content
Older articles about HTTPS often refer to green padlocks, yellow warnings or red browser messages.
Browser interfaces have changed substantially since then.
What matters now is whether the insecure request is upgraded, allowed or blocked.
Browsers may automatically upgrade some less dangerous HTTP resources to HTTPS.
Other types of mixed content, particularly scripts, stylesheets, fonts and iframes, are generally treated more strictly because loading them insecurely could affect the behaviour or appearance of the page.
A blocked request may cause:
- Missing styles
- Broken layouts
- Missing fonts
- JavaScript errors
- Non-working forms
- Empty embeds
- Missing images
- Broken interactive features
The best way to diagnose the problem is therefore not to rely only on the browser’s address bar.
Use the browser’s developer tools to find the exact request causing the issue.
Confirm That Mixed Content Is the Problem
Open the affected page in a browser such as Chrome or Firefox.
Then open the browser’s developer tools.
In Chrome, you can normally do this by right-clicking the page and choosing Inspect.
Open the Console tab.
Mixed content problems will usually be reported there with the insecure URL involved.
You may see a message explaining that an HTTPS page attempted to request an HTTP resource.
Copy or make a note of that URL.
The Network tab can also help.
Reload the page with the Network panel open and inspect the requests being made.
You are looking for resources that use:
http://
rather than:
https://
Do this on the actual page showing the problem rather than checking only the homepage.
A mixed content issue may exist on one page, template or plugin feature without affecting the rest of the site.
Find the Exact Insecure URL
Once you know which URL is causing the warning, work out where it comes from.
For example:
http://example.com/wp-content/uploads/old-image.jpg
is probably an old WordPress media URL stored somewhere in the database.
A URL such as:
http://cdn.example.com/font.woff2
might come from a stylesheet, theme setting or CDN configuration.
A third-party address could come from:
- An embedded video
- Tracking code
- A marketing service
- A booking system
- A chat widget
- An iframe
- An external font
- A plugin integration
Do not start making global changes until you know what you are trying to correct.
Finding the source first makes the fix much safer.
Check WordPress Address and Site Address
If the website has recently moved from HTTP to HTTPS, check WordPress’s main URL settings.
Under Settings → General, the following will normally use HTTPS:
- WordPress Address (URL)
- Site Address (URL)
For example:
https://example.com
rather than:
http://example.com
On some WordPress setups these fields may be controlled through configuration rather than the dashboard.
If the website has not yet been fully migrated to HTTPS, fix that first rather than treating mixed content in isolation.
Our guide to adding SSL and HTTPS to WordPress covers the complete migration process, including certificates, redirects, WordPress settings and CDN configuration.
Fix Old HTTP URLs in the WordPress Database
One of the most common causes of mixed content is an old HTTP version of the site’s own domain stored in the database.
This often happens after a site has been migrated from:
http://example.com
to:
https://example.com
Old references might exist inside:
- Post content
- Pages
- Page-builder data
- Widgets
- Plugin settings
- Theme options
- Custom fields
- Media references
Before performing any database replacement, create a current backup.
Do not simply search for every occurrence of:
http://
and replace it with:
https://
That is too broad.
Your database may contain legitimate external HTTP URLs, historical text or references to services that do not support HTTPS.
Instead, target the site’s own old domain.
For example:
http://example.com
to:
https://example.com
Use a Serialization-Aware Search and Replace
WordPress data is not always stored as ordinary text.
Themes, plugins and page builders may store structured or serialized values.
A normal text replacement can corrupt this data if the stored length information is not updated correctly.
Use a WordPress-aware tool.
WP-CLI provides a search-replace command designed for this purpose.
For example, you could first perform a dry run:
wp search-replace 'http://example.com' 'https://example.com' --all-tables-with-prefix --dry-run
A dry run reports what would change without writing the changes.
Review the result before running the real replacement.
On a production website, this is much safer than making a blind database-wide change.
Some WordPress search-and-replace plugins also understand serialized data, but the same rule applies: back up first, target the correct domain and test what will change.
Check Page Builders and Plugin Settings
Not every URL is stored in normal post content.
Page builders and plugins often store their settings separately.
If the database replacement does not fix the warning, check areas such as:
- Page-builder templates
- Global sections
- Headers and footers
- Sliders
- Pop-ups
- Widgets
- Forms
- Theme options
- Plugin settings
- Custom fields
An image URL may have been pasted manually into one of these settings years ago and remained there after the main site moved to HTTPS.
The browser console gives you the resource URL.
You then need to trace where WordPress is generating it.
Check the Theme and Child Theme
Some mixed content comes from hard-coded URLs in theme files.
Possible locations include:
- PHP templates
- CSS
- JavaScript
- Theme configuration files
- Custom fonts
- Background images
- Inline styles
Search the active theme and child theme for:
http://
Pay particular attention to the exact hostname shown in the browser warning.
For example, CSS might contain:
background-image: url("http://example.com/wp-content/uploads/background.jpg");
That should normally use a secure URL.
If the site uses a child theme, make changes there where appropriate rather than directly editing a parent theme that may be overwritten during an update.
Always back up theme files before changing them.
Check CSS for HTTP Resources
CSS is a common place for hidden mixed content.
A page can look correct in the WordPress editor while the stylesheet still loads an insecure resource.
Check for HTTP references to:
- Background images
- Fonts
- Icons
- Cursor files
- Other stylesheets
Generated CSS can also be involved.
Page builders and optimisation plugins may create cached CSS files based on values stored in WordPress.
In that situation, correcting the stored URL may not immediately change the generated stylesheet.
You may need to regenerate CSS or clear the relevant plugin cache afterwards.
Check Third-Party Resources
An insecure URL does not always belong to your website.
It could point to another service.
For example:
http://external-service.example/widget.js
Before changing it to HTTPS, check whether the service actually supports HTTPS.
Do not assume that changing:
http://
to:
https://
will automatically work.
If the provider offers a secure version, update the integration to use it.
If HTTPS is not available, your options may include:
- Replacing the service
- Removing the resource
- Using a newer integration
- Hosting an appropriate asset locally where permitted
- Contacting the provider
An external resource that cannot be loaded securely may no longer be suitable for use on an HTTPS website.
Check Embedded Iframes
Iframes can cause mixed content warnings when they embed an HTTP page inside an HTTPS page.
Common examples include:
- Maps
- Videos
- Booking systems
- Forms
- Older analytics dashboards
- External widgets
Inspect the iframe’s src URL.
If the provider supports HTTPS, replace the insecure address with its HTTPS version.
If it does not, the embed may need to be replaced entirely.
Check CDN and Reverse-Proxy URLs
If your website uses a CDN or reverse proxy, mixed content can be introduced outside WordPress itself.
Check whether assets are being served from a hostname such as:
http://cdn.example.com/
rather than:
https://cdn.example.com/
Also check that the CDN itself has a valid certificate for the asset hostname.
Possible causes include:
- Old CDN URLs stored in WordPress
- Incorrect CDN rewriting
- Cached HTML containing HTTP URLs
- Cached CSS containing HTTP resources
- A CDN hostname without HTTPS configured
- Old optimisation-plugin settings
If you have recently changed CDN or hosting configuration, clear cached versions after correcting the settings.
Check Reverse-Proxy HTTPS Detection
Sometimes WordPress sits behind a reverse proxy or CDN.
The visitor may connect over HTTPS while the proxy communicates with the origin server separately.
WordPress still needs to understand that the original visitor request was secure.
If HTTPS detection is configured incorrectly, WordPress or a plugin may generate HTTP URLs even though visitors are browsing the secure site.
This can also contribute to redirect loops and login problems.
Check that your proxy or CDN passes the correct scheme information and that the origin is configured to interpret it properly.
If you use Cloudflare or another reverse proxy, the wider setup is covered in our SSL and HTTPS guide.
Clear Every Relevant Cache
You can fix the underlying URL and still continue seeing mixed content because an old version remains cached.
After making changes, clear the relevant caching layers.
These may include:
- WordPress caching plugin
- Page-builder cache
- Generated CSS cache
- Server cache
- CDN cache
- Reverse-proxy cache
- Browser cache
You do not necessarily need to clear every system on every site.
Clear the layers actually used by your setup.
Then reload the page and check the developer console again.
Why View Source Does Not Always Show the Problem
Searching the page source for:
http://
can sometimes help, but it is not enough on its own.
Some resources are added after the initial HTML loads.
For example, JavaScript may insert an iframe or dynamically request another file.
Stylesheets may also contain HTTP URLs that are not visible in the main page source.
That is why the Console and Network panels are normally more useful for troubleshooting.
They show what the browser actually tries to request.
Why Search and Replace May Not Fix Everything
A database replacement can resolve many mixed content problems, particularly after an HTTP to HTTPS migration.
It cannot fix every possible source.
A remaining insecure request may come from:
- Theme files
- Child-theme files
- Generated CSS
- External services
- Plugin code
- Plugin settings
- CDN configuration
- JavaScript
- Hard-coded templates
- Cached output
If a search-and-replace reports no remaining old URLs but the browser still reports mixed content, follow the request shown in the developer tools rather than repeatedly running broader replacements.
Check More Than the Homepage
Mixed content may exist only on certain pages.
For example:
- An old blog post may contain an HTTP image
- One landing page may use an outdated embed
- A WooCommerce product may contain an old gallery URL
- A contact page may load an insecure map
- A specific template may reference an old font
After making changes, test representative parts of the site.
Useful pages to check include:
- Homepage
- Main service pages
- Blog posts
- Contact page
- Forms
- Landing pages
- WooCommerce shop
- Product pages
- Basket
- Checkout
- Account pages
If the site has many pages, start with important templates and pages receiving significant traffic.
Check the Site While Logged Out
Test the frontend while logged out of WordPress.
Administrators can receive different output because of:
- Page caching exclusions
- Admin toolbars
- Logged-in cookies
- Plugin behaviour
- Different optimisation rules
A page that looks correct while logged in may still serve an older cached version to normal visitors.
Use a private browsing window if helpful.
Check Internal URLs After the Fix
Once mixed content is resolved, it is worth confirming that the site consistently uses HTTPS elsewhere.
Check:
- Internal links
- Canonical URLs
- XML sitemap URLs
- Image URLs
- Open Graph URLs
- Structured data URLs
- Form actions where relevant
Old HTTP URLs may redirect correctly, but it is cleaner for your own website to link directly to the HTTPS version instead of relying on redirects.
Mixed Content Troubleshooting Checklist
If your WordPress site reports mixed content, work through these steps:
- Open the affected page.
- Check the browser Console.
- Identify the exact HTTP request.
- Check whether the URL belongs to your site or a third party.
- Confirm WordPress Address and Site Address use HTTPS.
- Back up the database before making replacements.
- Replace the old HTTP version of your own domain using a WordPress-aware tool.
- Check page-builder and plugin settings.
- Search theme and child-theme files.
- Check CSS, fonts and background images.
- Check third-party embeds and iframes.
- Check CDN and proxy configuration.
- Clear relevant caches.
- Reload the page while logged out.
- Recheck the Console and Network panel.
- Test several representative pages.
Do not consider the problem solved simply because the homepage appears secure.
The aim is to remove the underlying insecure requests across the site.
Fix the Source Rather Than Hiding the Warning
Mixed content is usually straightforward once you identify where the insecure URL is coming from.
The difficult part is often tracing the request back through WordPress, a theme, a plugin, generated CSS, a CDN or an external integration.
Avoid fixes that merely hide the warning or broadly rewrite URLs without understanding them.
Find the insecure resource, determine why WordPress is requesting it and correct the source.
If you have a mixed content warning that you cannot trace, our one-off WordPress support can investigate the affected page, find the insecure request and fix the underlying WordPress, theme, plugin or hosting configuration.
