Fix Mixed Content Warnings After Moving Your Site to HTTPS
A broken padlock or missing images after enabling HTTPS usually means mixed content. Find insecure URLs and fix them in WordPress, themes and the database.
You installed an SSL certificate, your site loads over HTTPS, and yet the browser shows "Not secure", a broken padlock, or some images and styles are missing. The most common cause is mixed content: a page delivered over HTTPS that still loads some resources, such as images, scripts or stylesheets, over plain HTTP.
Mixed content weakens the security HTTPS is supposed to provide and, increasingly, modern browsers refuse to load it at all. The good news is that it is straightforward to find and fix.
Two kinds of mixed content
- Passive (display) mixed content: images, audio and video loaded over HTTP. Modern browsers typically try to upgrade these to HTTPS automatically or may block them, and the padlock is affected.
- Active mixed content: scripts, stylesheets, iframes and other code loaded over HTTP. These are dangerous, because a network attacker can alter them and take control of the page. Browsers block them, which is why your layout or features may break.
Fixing it, step by step
Step 1: find the offenders
- Open the affected page in Chrome and the DevTools Console. Mixed content messages name each blocked or warned URL.
- Use the Network tab and search for
http://to list non-HTTPS requests. - Use view-source and search the HTML for
http://. - Crawl the site with a free tool or browser extension that reports insecure resources across many pages, since problems may sit in older posts, widgets or footers rather than your home page.
Step 2: understand where the URLs come from
| Source | Typical fix |
|---|---|
| Post and page content with hard-coded http:// images and links | Update URLs in the database |
| Theme or plugin files with absolute http:// links | Edit the code or update the theme or plugin |
| CSS with http:// background images or fonts | Change the URLs in the stylesheet, or use relative ones |
| Site address in settings still set to http:// | Change WordPress Address and Site Address to https:// |
| Third-party embeds, scripts or widgets using http:// | Use their HTTPS version or replace the service |
| Hard-coded values in widgets, menus and theme options | Edit them in the admin or the database |
Step 3: fix WordPress
- Back up the files and database before making changes.
- In Settings, General, confirm both the WordPress Address and Site Address start with
https://. - Replace old URLs in the database with a search-and-replace tool designed for it, such as WP-CLI's
search-replacecommand or a reputable plugin. These tools handle serialised data correctly, which a plain text replace on the database dump can corrupt. Always run a dry run first and replacehttp://yourdomain.examplewithhttps://yourdomain.example. - Check theme options, widgets, menus and page builder content, which can store URLs in places the global replace missed.
- Clear every cache: the caching plugin, server cache, CDN cache and your browser.
- Re-test the Console.
Step 4: redirect and upgrade
Make sure all HTTP requests redirect to HTTPS with a single 301 redirect, to the canonical host name. In addition, the CSP directive upgrade-insecure-requests tells browsers to treat HTTP subresource URLs as HTTPS, which is a useful safety net while you finish clean-up:
Content-Security-Policy: upgrade-insecure-requests
It does not fix the underlying problem, and it fails for resources that are not available over HTTPS at all, but it removes most warnings quickly. Once your clean-up is done, consider adding HSTS, explained in our article on security headers, so browsers never attempt HTTP for your site again.
Common culprits
- Images in old blog posts added back when the site used HTTP.
- Embedded videos, maps or social widgets using old embed codes.
- Fonts or icon libraries pulled from other domains.
- Hard-coded
http://links in custom JavaScript or form actions. - Sitemap, canonical tags and Open Graph tags still using HTTP, which are not mixed content but should be updated for consistency and SEO.
- A CDN configured to fetch from your origin over HTTP.
Check the certificate chain too
If the browser shows a certificate error instead of a mixed content warning, the issue is different: the certificate may be expired, issued for another domain name, or missing intermediate certificates. Check the certificate details in the browser, and confirm it covers both the bare domain and the www version. If you use Cloudflare, make sure its SSL mode is set so that traffic between Cloudflare and your server is also encrypted and validated, instead of left on a mode that sends plain HTTP to the origin.
Finishing touches
- Update your sitemap and submit it again in Search Console.
- Update external profiles, ads and tools that link to your http:// address.
- Re-test the key pages in more than one browser.
- Check your analytics and tag manager still fire correctly.
A note on third-party embeds
Old embed codes are a frequent cause, because they were copied years ago, before HTTPS became the norm. Replace them with a fresh embed code from the provider, and if a service offers no HTTPS version at all, treat that as a sign to replace it. If you are moving an old HTTP site to a new host and want help getting it onto HTTPS cleanly, the team can assist through the free migration service.
HTTPS from day one
Starting with HTTPS prevents most mixed content problems. Every Zebra Hosting Cloud hosting plan includes free SSL certificates, and the SSL page explains how they work.