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.
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.
Here is an example of what happens in Firefox when a mixed content warning fires on a WordPress site.
Here is an example of what happens in Microsoft’s Edge browser when a mixed content warning fires on a WordPress site.
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.
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:
http://yourdomain.com/image.png) that point to HTTP. These could be within a post, page, or even a widget.
Follow the simple steps below to fix your WordPress mixed content warnings. This assumes you have already done the following:
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.
You can also open Chrome DevTools from the tools menu.
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.
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.
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.
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.
If you’re worried about the rest of your site you might want to check it in bulk. Here are some recommended options.
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.
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.
Important: Ensure you don’t include any leading/trailing whitespace in either of the fields as this might produce undesirable results.
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.
You’ll then see the total number of replacements that will be made.
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.
You’ll then see one final confirmation of the number of replacements made.
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.
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).
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.
Send this to a friend