Running your WordPress site over HTTPS is no longer optional. 🔒 Not only is it more secure (everything is encrypted, nothing passed in plain text), but it also builds trust, is an SEO ranking factor, and provides more accurate referral data. Performance issues tied to encryption have been fixed for the most part thanks to HTTP/2 and Let’s Encrypt has changed the entire industry by providing you with an easy way to get free SSL certificates.
For some businesses though, one of the most important reasons is that web browsers such as Chrome and Firefox are cracking down on those not running over HTTPS and showing stricter warnings. That’s the last thing you want your visitors to see!
We have an in-depth guide on how to migrate from HTTP to HTTPS, and a very common problem website owners encounter afterward is “mixed content warnings.” Today we’ll show you a few different ways you can fix these on your WordPress site.Boost your WordPress site’s speed up to 200% just by moving to Kinsta.
A mixed content warning appears in a user’s browser when the WordPress site is loading both HTTPS and HTTP scripts or content at the same time. You can’t load both as they are completely separate protocols. When you migrate to HTTPS, everything needs to be running over HTTPS.
Wired actually documented their transition from HTTP to HTTPS and a mixed content warning snag they ran into:
Below are some examples of what happens in the browsers if you don’t fix these warnings.
Here is an example of what happens in Chrome when a mixed content warning fires on a WordPress site. According to NetMarketShare, Chrome currently leads in the pack in terms of browser market share, being used by over 60% of the web. So the following warning is most likely what most of your visitors would see.
Chrome mixed content warning
Here is an example of what happens in Firefox when a mixed content warning fires on a WordPress site.
Firefox mixed content warning
Here is an example of what happens in Microsoft’s Edge browser when a mixed content warning fires on a WordPress site.
Microsoft Edge mixed content warning
Here is an example of what happens in Internet Explorer when a mixed content warning fires. As you can see, IE is probably one of the worst because it actually breaks the rendering of the page until the popup is clicked. Thankfully, Internet Explorer doesn’t hold that much of the browser market share anymore.
Internet Explorer mixed content warning
We’ve found that the most common time mixed content warnings appear is right after someone migrates their WordPress site from HTTP to HTTPS. HTTP links simply get carried over and this causes mixed content warnings to start firing. Another reason could be that you just added a new service or plugin.
Here are some additional examples of what might cause a warning:
- Plugin developers sometimes use absolute paths (
- Images have hardcoded URLs (
http://yourdomain.com/image.png) that point to HTTP. These could be within a post, page, or even a widget.
- Your linking to HTTP versions of external scripts. (Hosted jQuery, Font Awesome, etc.)
- You have embedded video scripts using HTTP instead of HTTPS.
Follow the simple steps below to fix your WordPress mixed content warnings. This assumes you have already done the following:We grew our traffic 1,187% with WordPress.
We’ll be using our development site (wpdev.ink) in the examples.
The first thing you need to do is find out which resources are still loading over HTTP. Browse to the page where it’s happening and launch Chrome DevTools. Remember, it might only be happening in certain areas of your site, not globally.
- Windows: F12 or CTRL + Shift + I
- MAC: Cmd + Opt + I)
You can also open Chrome DevTools from the tools menu.
Launch Chrome DevTools
There are are a couple places you can check which resources aren’t loading over HTTPS. The first is the “Console” tab. Note: You might need to refresh the page after you have Chrome DevTools open for it to properly load everything.
Below we can easily see that there is an insecure image being linked to an HTTP version of the site and a link pointed to an HTTP hosted version of jQuery.
Chrome DevTools mixed content in console
You can also look in the “Security” tab. It will show you the non-secure origins and you can click to “View the request in the network panel.” Note: You might need to refresh the page after you have Chrome DevTools open for it to properly load everything.
Chrome DevTools security
And last but not least, you can view the requests in the “Network” tab. Note: You might need to refresh the page after you have Chrome DevTools open for it to properly load everything.
Chrome DevTools network
If you aren’t using Chrome, or just want a quick summary of the errors, you can also use a free tool like Why No Padlock. It scans an individual page and shows you all of the insecure resources.
Why No Padlock?
If you’re worried about the rest of your site you might want to check it in bulk. Here are some recommended options.
- There is a free little tool called SSL Check from JitBit which you can use to crawl your HTTPS WordPress site and search for insecure images and scripts that will trigger a warning message in browsers. The number of pages crawled is limited to 200 per website.
- The Ahrefs audit tool now has the ability to detect HTTPS/HTTP mixed content. If you already have access to this, or someone on your marketing team does, this can be a great way to be thorough.
- HTTPS Checker is desktop software you can install that will scan your site. It can help you check for “not secure” warnings and content after big changes. It is available on Windows, Mac, and Ubuntu. The free plan allows you to check up to 100 pages.
The next step is confirming that those resources loading over HTTP are accessible over HTTPS. They most likely are, you just need to update the links. If our example above we’ll use the insecure image and hosted jQuery.Struggling with downtime and WordPress problems? Kinsta is the hosting solution designed to save you time! Check out our features
If we take both of those URLs, input them into our browser’s address bar, and append HTTPS on the beginning, we can see that they load just fine. Therefore we simply need to proceed to do a search and replace on our site.
There are are a lot of different ways in which you can perform a WordPress search and replace. In this post, we will walk you through two different recommended options.
If you’re curious, we don’t recommend using the Really Simple SSL plugin. While it’s a great plugin, you shouldn’t rely on a plugin like this long term. You won’t be migrating back to HTTP later, so do it the right way and update your HTTP URLs in your database (as we’ll show you below).
If you’re a Kinsta client, you can use our search and replace tool that is available from right within the MyKinsta dashboard. Under Sites click on “Manage” next to the site you want to run a search and replace on. Then click on “Tools” and you’ll find the Search and Replace tool at the bottom.
Kinsta search and replace tool
- Enter in the search field the value you want to search for in the database, which in this case is our HTTP domain:
- Enter in the replace field the new value that should be used to replace the value that you are searching for. In this case, it is our HTTPS domain:
- Ensure the “Dry Run” option is selected first, as this will count how many replacements will be made without actually making the replacements. Then click “Replace.”
Important: Ensure you don’t include any leading/trailing whitespace in either of the fields as this might produce undesirable results.
HTTP to HTTPS search and replace
You’ll see a warning confirming that you want to run the command to calculate how many replace will be made. Click on “Replace” to confirm. Note: In “Dry Run” mode this will not make any database changes.
Search and replace calculate replacements
You’ll then see the total number of replacements that will be made.
Number of replacements
You can then un-select “Dry Run” and click on “Replace” again to perform the search and replace, making changes in your database. Note: A backup is automatically taken when this is run (backup identifier:
beforesearchandreplace). So you can always revert back if needed.
Live search and replace
You’ll then see one final confirmation of the number of replacements made.
Confirmation on live search and replace
If you aren’t a Kinsta client, you can do this same task with the free Better Search Replace plugin and then simply delete the plugin after you’re done.
Better Search Replace plugin
You can download it from the WordPress repository or by searching for it within your WordPress dashboard under “Add New” plugins. After activating it just search for your HTTP domain (http://yourdomain.com) and replace with your HTTPS domain (https://yourdomain.com).
Better Search Replace options
After you finish doing the search and replace you’ll want to double check your site to confirm the mixed content warnings are gone. We recommend just visiting your site and clicking around on a few pages while looking at the browser status indicator up in the address bar.
On our site, we can see that the insecure image is now fixed, but the hosted jQuery warning still remains. The reason is that we ran a search and replace on resources loading from our own domain. This is an external script which has to be manually updated.
Mixed content warning
In this case, the script had been manually added in our WordPress header (
header.php). The script should be using a relative URL, so we updated it to:
HTTP external script
For most of you, the search and replace will most likely fix all of your issues. It’s really own those of you that have hardcoded something on your WordPress site that might run into additional issues. If you think there is an external script hardcoded in one of your plugins or theme, and you’re having trouble tracking it down, feel free to reach out to the developer for assistance.
Here is an example of what happens in Chrome when everything is loading correctly over HTTPS with no mixed content warnings.
Chrome no mixed content warnings
Here is an example of what happens in Firefox when everything is loading correctly over HTTPS with no mixed content warnings.
Firefox no mixed content warnings
Here is an example of what happens in Microsoft Edge when everything is loading correctly over HTTPS with no mixed content warnings.
Microsoft Edge no mixed content warnings
Some of you might be wondering why you can’t simply use HSTS (HTTP Strict Transport Security) fix this. HSTS was created as a way to force the browser to use secure connections when a site is running over HTTPS. It’s a security header in which you add to your web server and is reflected in the response header as Strict-Transport-Security.
HSTS isn’t a quick fix for all mixed content warnings. HSTS merely handles redirects whereas the mixed content warning is a feature of the browser itself. You also don’t have control over third-party sites enabling HSTS. Therefore you need to always update
Esa Jokinen dives deeper into the reasons in this Server Fault discussion.
- If you’re using the Elementor page builder, you must also go into the Elementor settings and update your site’s URL there so that the CSS files will regenerate with the new URL. Once you have done this, clearing the cache should clear out any insecure warnings due to Elementor.
- If you’re using the Kinsta CDN, it’s recommended to purge the CDN Zone as well.
For most of you a simple search and replace should quickly resolve your mixed content warnings and have your site back to normal in just a few minutes. If it doesn’t fix everything, it’s most likely there are one or two scripts left behind that are hard coded. For these, you’ll need to find them and manually update them.
If you have any feedback or run into any issues, let us know below in the comments.