What mixed content means
A page loaded over a secure connection is made of many separate pieces: the HTML itself, plus images, stylesheets, scripts, fonts, frames and media. Each piece is fetched by its own address. If the page is secure but one of those pieces is requested using an insecure address, the result is mixed content, a mixture of secure and insecure parts.
The problem is that the secure padlock only means something if everything on the page is protected. An insecure file can be read or altered by someone watching the network, and an altered script in particular could change what the page does.
How browsers react
Browsers treat different kinds of mixed content differently.
- Active content, such as scripts, stylesheets, frames and similar files that can change the page’s behavior, is the more dangerous type. Modern browsers typically block it outright, which can break features or leave the layout unstyled.
- Passive content, such as images, audio and video that cannot alter the page’s behavior, is lower risk. Browsers have increasingly tried to upgrade these to secure addresses automatically or may block them, and in some cases still show a warning that the page is not fully secure.
Exact behavior differs between browsers and versions and changes over time, so the safe approach is to remove all insecure references rather than relying on how a given browser reacts.
Why it matters
Visitors may see a “not fully secure” notice or a missing padlock, which undermines the trust a good https setup is meant to build. Blocked resources can make a page look broken, hide a form or disable a menu. On a store, that can add checkout friction at the worst possible moment. It is a quiet problem that rarely announces itself in the site’s own admin screens.
Mixed content is not typically described as a major ranking factor on its own, but it hurts the experience that search engines want to reward, and it can slow pages if blocked files are retried or replaced.
Where it comes from
The most common causes are:
- Hard-coded addresses. Old posts or pages that embed an image using a full HTTP address, written before the site went secure.
- Templates and theme files. A logo, stylesheet or script referenced with an HTTP address in the theme.
- Content system settings. The site address setting still set to the HTTP version.
- Third-party embeds. Widgets, maps, forms, fonts or analytics code copied from an old snippet.
- Database leftovers. Addresses stored in content, menus, widgets or custom fields.
- Style sheets. Background images referenced in CSS by HTTP address.
- Redirect and delivery layers. Misconfigured settings that tell the server it is being accessed over HTTP when it is not.
Finding it
Browser developer panel. Open the page, open the browser’s developer tools and look at the console. Mixed content warnings are normally listed there with the exact address of each offending file. Check the network tab too, which can be filtered to show requests that start with the insecure prefix.
View the page source. Search the HTML for the insecure prefix. This quickly shows references written directly into the page, though it will not show files requested by scripts or styles.
Check several page types. Templates differ. Test the home page, an article, a category page, a contact page and any page with embeds or forms. A problem in one template can affect hundreds of pages.
Crawl the site. A crawler that checks for insecure resources can sweep every page at once. Many audit tool types include this check, and it is the most practical method for larger sites.
Search your content. If your system lets you search the stored text, look for the insecure address of your own domain. This often turns up older posts that need editing.
Look at the reports you already have. Search reporting tools sometimes flag pages with security issues, but they will not catch everything, so treat them as a supplement.
Fixing it
- Change the reference to the secure address. For files on your own site, use the HTTPS version or a relative path that works on either.
- Check that the secure version exists. Some external resources are only offered over HTTP. If so, find an alternative provider, host a copy yourself if the license allows, or remove the element.
- Fix at the source. Edit the template rather than each page, update the site address setting, and run a careful search-and-replace on stored content. Back up before any bulk replace, and test on a copy where possible.
- Clear caches. After fixing, clear the page cache and any delivery network cache, or you may keep seeing old versions with the old addresses.
- Retest. Reload the pages in a private window and check the console again.
Avoid relying only on a blanket setting that rewrites addresses on the fly. It can be a useful stopgap, but it hides the underlying references and may not cover every file type.
Keeping it fixed
Mixed content tends to return when someone pastes an old snippet, uploads a widget or edits an old template. Build a few habits: use secure addresses when adding any external resource, include a mixed content check in your monthly routine and recheck after theme changes or after a site migration. A short entry in your change log about new embeds helps track where problems may have come from.