Mixed Content Warnings After Moving to HTTPS

You switched your website to HTTPS. The certificate is installed, the homepage shows a padlock, and then you open a blog post or a product page and the padlock is gone. In its place there is a grey icon or a “Not secure” note, or an image is missing, or a slider has stopped working. Nothing obvious is wrong with the certificate itself.

This is almost always mixed content: a secure page that is still pulling in some of its pieces over plain HTTP. It is common after a move to HTTPS, it is fixable, and the fix is mostly a matter of finding every old address and changing it carefully.

What mixed content actually is

A web page is not one file. The browser loads the HTML, then fetches the images, stylesheets, scripts, fonts and embedded videos the page asks for. When the page itself arrives over HTTPS but some of those requests still use http:// addresses, the page is “mixed”.

Browsers treat this as a weakness, because anything loaded over plain HTTP can be read or altered on the way. A tampered script could change what your page does. So browsers react, and how they react depends on what is being loaded:

• Scripts, stylesheets and iframes loaded over HTTP are blocked outright by modern browsers. This is why a menu, slider, form or embedded map can suddenly stop working.
• Images, audio and video are treated more gently. Chrome, for example, tries to load them over HTTPS automatically and blocks them if that fails. Older browsers may load them but drop the padlock.

Either way, the visitor sees a page that looks broken or less trustworthy than it should.

How to find mixed content in your browser

You do not need special tools to start. Every major desktop browser has developer tools built in.

1. Open the page that has lost its padlock.
2. Right-click anywhere on the page and choose Inspect, or press F12.
3. Open the Console tab and reload the page.
4. Look for messages that start with “Mixed Content”. Chrome writes something like: the page was loaded over HTTPS, but requested an insecure image or script, followed by the exact http:// address.

That address is the clue you need. Write each one down. Then look at where it comes from:

• Your own domain with http://, such as an old image in the media library. This is the most common case, and you can fix it yourself.
• Another site, such as an old embedded widget, a font service or a tracking script. You will need to switch to that provider’s HTTPS address, or remove the embed if it does not offer one.

The Network tab in the same developer tools lists every file the page loaded. Typing http: into its filter box is a quick way to spot anything still on the old protocol. Check several page types, not just the homepage: a blog post, a product page, the cart, the contact page. Mixed content often sits only in older posts or in one template.

Where the old addresses hide in WordPress

Changing the Site Address and WordPress Address in Settings → General to HTTPS only updates two settings. Everything WordPress stored before the switch still has the old address written into it.

In the database

Every post and page you wrote before the move has its images and internal links saved with the full address, including http://. So do widgets, menus, theme customiser settings and the settings of many plugins and page builders. This is usually where most of the mixed content lives.

In the theme

Some themes, especially older custom ones, have addresses typed directly into template files such as header.php or footer.php, or into the theme’s stylesheet as background images. Search the theme folder for http:// followed by your domain. If you find any, change them to https:// or, better, to the WordPress functions that build the address automatically. Make the change in a child theme if one exists, so a theme update does not undo it.

In custom code and settings boxes

Look at “custom CSS”, “header scripts” and “footer scripts” boxes in the theme or in plugins. Old tracking codes and chat widgets pasted years ago often use http://.

Fixing the database with search and replace, carefully

The standard fix is to search the database for http://yourdomain.com and replace it with https://yourdomain.com. It works well, but it touches nearly every table, so it deserves care.

1. Take a full backup first, files and database, and store it off the server. If you are not sure how, see how to back up a WordPress website, and the 3-2-1 backup rule for where to keep copies. A search and replace that goes wrong is not something you can undo by hand.
2. Use a tool that understands serialised data. WordPress stores many settings in a packed format that records the length of each piece of text. Running a plain SQL replace in phpMyAdmin changes the text without fixing those lengths, which can wipe widgets or theme settings. WP-CLI’s wp search-replace command and plugins such as Better Search Replace handle this correctly.
3. Do a dry run first. With WP-CLI, add --dry-run to see how many replacements would be made in each table without changing anything. Better Search Replace has a similar test option.
4. Be exact. Replace http://yourdomain.com with https://yourdomain.com, including the www if your site uses it. Do not replace plain http:// on its own, which would change links to other sites that may not support HTTPS.
5. Leave the guid column alone. WordPress uses it as a permanent identifier for posts, not as a link. With WP-CLI, add --skip-columns=guid.
6. Clear every cache afterwards: any caching plugin, your host’s cache and any CDN. Otherwise you may keep seeing old pages and think the fix failed.

If your site is busy or runs a shop, try the whole process on a staging copy of the site first.

Some page builders keep their own copy of addresses. Elementor, for example, has a Replace URL tool under its Tools settings for this reason. After the database replace, check pages built with a page builder separately.

What about plugins that fix it automatically?

Plugins such as Really Simple SSL can rewrite http:// to https:// as each page is sent to the browser. This makes the warnings disappear quickly, and it can be a reasonable stopgap. But the old addresses are still in your database, so the plugin has to keep doing that work on every page load, and if it is ever removed the problem returns. Fixing the stored addresses is the cleaner long-term answer.

You may also see advice to add an upgrade-insecure-requests security header, which tells browsers to request everything over HTTPS. It helps, but it does not fix third-party files that are simply not available over HTTPS.

Checking the result

• Reload several page types with the Console open and confirm the “Mixed Content” messages are gone.
• Check that sliders, forms, maps and embedded videos work again.
• Make sure HTTP addresses redirect to HTTPS, so old links and bookmarks still arrive at the secure version.
• Confirm the certificate covers both the main domain and www. If you get a full-screen warning rather than a missing padlock, that is a different problem, covered in SSL certificate expired: what visitors see and how to fix it.

If you have not finished the HTTPS move itself, start with how to add an SSL certificate to your website, then come back here for the clean-up.

If you would rather hand it over

Mixed content is rarely difficult, but it is fiddly, and the database step needs a careful hand and a working backup. If you want someone to find the old addresses, replace them safely and check the result page by page, that sits within our website security maintenance work.

Next in this series: How to Stop Contact Form Spam Without Losing Real Leads