What a WordPress mixed content warning means
Mixed content is a browser security issue, not simply a missing padlock icon. The page itself has loaded through HTTPS, but something inside it, such as an image, stylesheet, JavaScript file, font or iframe, is still being requested through an insecure http:// address.
Modern browsers treat insecure subresources differently depending on the resource type. Some may be upgraded to HTTPS automatically, while more sensitive resources can be blocked. A blocked stylesheet or script can make menus, layouts, checkout functions or other interactive features stop working.
The fix is to find the original HTTP reference and correct it. Do not treat a browser warning suppression or a blanket content security rule as a substitute for fixing the stored or generated URL.
Why mixed content appears on WordPress sites
Mixed content often starts after a site is moved from HTTP to HTTPS, migrated to a new domain or restored from an older backup. WordPress may be serving the current page securely while old absolute URLs remain in content, theme settings or plugin data.
- WordPress Address or Site Address still uses HTTP. This can make WordPress generate insecure internal URLs.
- Old links are stored in the database. Page builder content, widgets, custom fields and plugin settings can retain the previous HTTP domain.
- Theme or custom CSS contains hard-coded URLs. Background images and fonts are frequent examples.
- An external resource has no HTTPS version. A third-party script, image or iframe can remain insecure even when your own site is configured correctly.
- A cache or CDN serves stale HTML. The database may be corrected while an older cached page still contains HTTP references.
Reverse proxies and CDNs can also create redirect or scheme-detection problems if the origin server and proxy disagree about whether the original visitor connection used HTTPS.
How to fix WordPress mixed content safely
Before editing files or changing stored URLs in the database, take a full backup of both files and database. Then work through the following steps in order.
- Find the insecure request. Open the affected page in your browser's developer tools and check the Console and Network panels for requests beginning with http://. Record the exact resource URL and the page that requested it.
- Check the WordPress URLs. In Settings, General, confirm that WordPress Address and Site Address use the correct https:// domain, provided HTTPS is already working correctly on the server.
- Correct isolated references. Update old image, iframe, CSS or plugin settings at their source. For third-party resources, use an HTTPS URL only if the provider actually supports it.
- Use a serialization-safe database replacement for widespread old URLs. WP-CLI understands serialized WordPress data and can perform a dry run first. Replace the example domain with your own.
wp search-replace 'http://example.com' 'https://example.com' --all-tables-with-prefix --skip-columns=guid --dry-runIf the dry run is correct, repeat the command without --dry-run. Do not run a raw SQL find-and-replace across serialized data.
Finally, clear WordPress, server and CDN caches, reload the page, and recheck the browser console.
When a mixed content warning needs technical help
Stop and get help if changing the WordPress URLs causes a redirect loop, the insecure reference is generated by custom code, or a database replacement would affect multiple domains or a multisite network. Proxy and CDN configurations also need care because forcing HTTPS at the wrong layer can create repeated redirects.
Do not keep replacing URLs if the resource itself is unavailable over HTTPS. In that case the correct fix may be to host the resource securely, replace it, or remove it.
For a one-off fault, our Emergency Fix is £249 per incident with a response within 2 working hours. Care plans start from £59 a month for ongoing maintenance and support.