Mixed content is when a page served securely over HTTPS pulls in some of its files, such as images, scripts, stylesheets or embedded videos, over plain HTTP. The page is then only partly secure, and browsers respond by upgrading or blocking those files and flagging the page as less secure.
How mixed content works
When someone visits an HTTPS page, the connection is encrypted by an SSL/TLS certificate, so nobody between the visitor and the server can read or alter it. If that page then asks for http://example.co.uk/logo.png, the request for that one file travels unencrypted, and someone on the same public Wi-Fi could in principle see or swap it.
Browsers split mixed content into two types:
- Active mixed content Scripts, stylesheets, iframes and anything else that can change the page. Modern browsers block these outright, because a tampered script could rewrite a form or steal card details.
- Passive mixed content Images, audio and video. Current versions of Chrome and Firefox try to load these over HTTPS instead and block them if that fails; older browsers may show them with a security warning in the address bar.
The result is often a page that looks broken for no obvious reason: missing styles, a slider that will not move, a blank space where a map should be.
Why it matters
It usually appears after a move from HTTP to HTTPS. The site itself now loads securely, but thousands of old image links in posts, theme settings and page builder data still point to http://. Visitors may see a security warning in the address bar or a broken layout, and on a site that takes payments or enquiries that loses trust quickly.
Google treats HTTPS as a light ranking signal and indexes the secure version when it can. Mixed content does not cause a penalty, but blocked scripts and stylesheets can change how Google renders the page, and a broken layout hurts the visitors you have worked to attract. For any UK business collecting personal data through forms, keeping every part of the page encrypted is also part of the appropriate security that UK GDPR expects for that data.
Common mistakes
- Installing a certificate and stopping there. HTTPS on the homepage does not update the URLs stored in your database.
- Fixing only what you can see. Background images in CSS, scripts in the footer and embeds in old posts are easy to miss.
- Relying on a plugin forever. Plugins that rewrite URLs on every page load add work to each request and hide the real problem.
- Hard-coding third-party embeds. Old widget code for maps, review badges or booking tools may still call HTTP addresses.
- Forgetting redirects. HTTP versions of every page should 301 redirect to HTTPS, or search engines and visitors can keep reaching the insecure version.
How to act on it
Open a page in Chrome, press F12 and check the Console; mixed content warnings name each insecure file. To find every instance, crawl the site with a tool that reports insecure content, as Screaming Frog does. On WordPress, a careful database search and replace from http://yourdomain to https://yourdomain, with a backup taken first, fixes most cases at the source.
Update theme settings and third-party embed codes by hand, and remove any widget whose provider no longer supports HTTPS. A Content-Security-Policy header with upgrade-insecure-requests is a useful safety net while you finish. If you are planning a move to HTTPS or cleaning up after one, it is part of my technical SEO service.