Easy Fix: Was Loaded Over HTTPS, But Requested An Insecure Script

You have just migrated your site from HTTP to HTTPs. You’re  browsing your WordPress site, expecting a secure experience. But, suddenly, a WordPress error message pops up: “Was loaded over HTTPS, but requested an insecure script.”

This is one of those common WordPress issues that can be very disruptive. It can be very confusing. What did you miss during your WordPress migration? Why is this happening? What does it mean to have an insecure script?

In this article, we’ll go over the steps to solve theWordPress problem. You’ll be back to your regular programming in no time. 

TL;DR: Troubleshooting this error involves identifying the insecure scripts causing the issue, typically found in your WordPress theme or plugins. You’ll need to update or replace these scripts to ensure they load over HTTPS safely. However, these require modifications to your WordPress core. So, be weary and take a backup. 

Understanding the “was loaded over HTTPS, but requested an insecure script” error 

If you see the “was loaded over HTTPS, but requested an insecure script” error, it generally means you have mixed content. That means that a secure HTTPS webpage tries to load resources, like scripts or images, over an insecure HTTP connection, compromising security.

HTTPS is designed to provide encryption and security, giving users confidence in the safety of your site. When your site requests resources over HTTP, it breaks the chain of security, which can lead to vulnerabilities. 

Here are some reasons why this may have happened:

• Development oversight: In the hustle of installing an SSL certificate you may have overlooked updating every resource URL. As a result, some URLs remain on HTTP, causing this error. 
• Third-party scripts: Websites often rely on third-party scripts or services, like analytics tools or advertisement networks. If these scripts are not served over HTTPS, they can trigger this error too. 
• Outdated content links: Sometimes links are hard-coded directly into the site’s code or stored in a database. If these links aren’t updated to HTTPS after the switch, it can throw an error too.

Without addressing this, users might receive warnings that your site is not secure. This can harm your site’s credibility and user trust.

How to fix the “was loaded over HTTPS, but requested an insecure script” error?

Now that we’ve unpacked what causes the “was loaded over HTTPS, but requested an insecure script” error, it’s time to roll up our sleeves and dive into the solutions. Understanding the problem is just the start—what really matters is how we can fix it and ensure your WordPress site is as secure as possible.

Step 1: Check SSL certificate

An expired or misconfigured SSL certificate might be the root cause of the “was loaded over HTTPS, but requested an insecure script” error on your WordPress site. To ensure this isn’t the issue, you should check your SSL certificate’s validity. Start by copying your site URL and running it through the Qualys SSL Labs test. This tool will provide comprehensive details about your certificate, including expiry dates.

If the certificate has expired, it’s time to renew your certificate. This process varies depending on the SSL provider, but they often have straightforward instructions or customer support to guide you through it. Once renewed, install the SSL certificate on your server.

Step 2: Identify the insecure scripts

Identifying insecure scripts is a crucial step in resolving the “was loaded over HTTPS, but requested an insecure script” error. By pinpointing exactly which scripts are causing mixed content issues, you gain a clearer picture of what needs fixing. This diagnostic stage is vital because it sets the direction for all subsequent actions to address the problem.

While you can use various browsers like Chrome and Firefox to carry out this task, we’ll focus on Chrome here. With Chrome’s developer tools, you can efficiently track down the insecure scripts. 

1. Open your site in Chrome.
2. Right-click on the page and select Inspect.
3. Navigate to the Console tab.

Here, you’ll find warnings or errors related to mixed content, which will help you see which scripts are loading over HTTP.

Expert tip: This is a great method if you are searching for one or two insecure scripts. But, it can get cumbersome. If there are more than a few insecure scripts, run the site through WhyNoPadlock? This will run a test through your entire site and give you relevant information. 

Step 3: Find and replace HTTP links with HTTPS URLs

The next step is to find and replace insecure content that still loads over HTTP. Manually combing through your WordPress site is a bad idea. Having to locate each insecure script or resource can be a cumbersome and error-prone task. It often leads to overlooked links that can continue to cause the “was loaded over HTTPS, but requested an insecure script” error.

To streamline this process and reduce the risk of mistakes, use a tool like the SSL Insecure Content Fixer plugin. This plugin automates the task, ensuring your site transitions smoothly to HTTPS without the headache of manual intervention.

Here’s how to effectively use the plugin:

1. Install the SSL Insecure Content Fixer plugin. Once installed, click Activate to enable the plugin on your site.
2. Go to Settings > SSL Insecure Content. You’ll find several levels of fixing. Basic suffices for most users. But, here is a quick explanation:

• Basic: Fixes simple issues, ideal for most sites.
• Content: Fixes issues found in your main page content.
• Widgets: Targets widget content.
• Capture: More detailed fix affecting all site content.
• Capture All: Fixes every aspect of your site; use if other levels don’t resolve the issue.

3. Once you’ve selected a level, click Save Changes.
4. Test your site to ensure that the error has been resolved. Change the level if necessary, based on the outcome.

Step 4: Fixing plugin related issues

When diagnosing “was loaded over HTTPS, but requested an insecure script” errors, your browser’s developer tools may indicate that a specific plugin is the culprit due to attempting to load resources over HTTP. 

To address this, first update your plugins through the WordPress dashboard, as developers often release updates to improve security and HTTPS compatibility. After updates, use your browser tools to check if the errors persist. 

If they do, it might be a sign that the plugin is incompatible with HTTPS or lacks necessary updates. Consider finding a more secure and well-supported alternative that explicitly states compatibility with HTTPS. If replacing the plugin isn’t an immediate option, reach out to the plugin’s support for assistance, as they might offer a solution or patch. By addressing these plugin-related issues, you enhance your site’s security and minimize errors effectively.

Step 5: Fixing absolute/hardcoded paths

Absolute or hardcoded paths are specific URLs written into your WordPress site’s code. They point directly to resources using a full URL structure. For example, your theme or content might reference an image or script using http://yourdomain.com/image.jpg, rather than a relative path like /image.jpg. These absolute paths can cause issues when your site is switched to HTTPS, since they continue to request resources over HTTP, leading to the “was loaded over HTTPS, but requested an insecure script” error.

Pro tip: Use BlogVault to take a full backup before you make any changes. 

1. Use the browser developer tools, as we previously discussed. It can pinpoint which URLs are causing the issue.
2. Navigate to Appearance > Theme Editor.
3. Look for HTTP URLs in files such as header.php, footer.php, and functions.php and change them to relative paths wherever possible or update them to https://.

Pro tip: Plugins like Really Simple SSL can help manage this aspect by automatically handling common issues transitioning from HTTP to HTTPS, including addressing hardcoded paths.

Step 6: Update database links

Your site’s database may contain numerous links hardcoded with http://, which, if left unchanged, can lead to the “was loaded over HTTPS, but requested an insecure script” error. By updating these links to https://, you are ensuring that all elements of your site load securely, reinforcing the trustworthiness and integrity of your site’s content.

Pro tip: Before making any changes, always back up your database. This precaution ensures that you can restore your site to its previous state if something goes wrong during the update process.

Use Really Simple SSL to streamline this process by automating the task of finding and replacing HTTP URLs. First install and activate the plugin. Once activated, it will detect your site’s settings. Follow the setup prompts to configure it automatically for HTTPS. 

The plugin will automatically handle many aspects of the transition to HTTPS, including updating links in your database. After setup, review your site to ensure that all resources load over HTTPS.

Step 7: Address third-party scripts

Third-party scripts are resources from external vendors or services that your site integrates to add functionalities, such as analytics or advertising. For example, a third-party script might be used for Google Analytics or social media integration.

To tackle this issue, start by identifying the third-party scripts in use. You can do this through the browser’s developer tools, specifically the Console tab, which will list any scripts that aren’t from your own domain. These might be flagged for trying to load over HTTP.

Once you’ve identified them, the next step involves checking the third-party services’ websites to confirm if they offer their scripts over HTTPS. Most reputable services now provide secure versions due to the web’s emphasis on security. After locating the HTTPS-enabled script, update the URLs in your WordPress settings or directly within your theme files to reflect this secure protocol.

Step 8: Replace JavaScript and media files 

JavaScript and media files often form a significant part of a website’s content and functionality. If these elements load over an HTTP connection while the rest of the site uses HTTPS, it creates security vulnerabilities and can trigger browser warnings. These issues not only compromise user data but can also deter visitors by making the site appear insecure.

Really Simple SSL simplifies the process of managing these content-related issues. This powerful plugin automatically updates your site’s URLs to HTTPS, including JavaScript and media file links stored within your database. It’s the easiest way to replace the files and scripts. 

Step 9: Clear cache

Cache refers to the temporary storage of web pages, images, and other online content. This storage allows browsers or servers to load websites faster by reusing previously downloaded data, rather than fetching it anew from the server each time. There are different types of WordPress cache, such as browser cache, which stores data locally on a user’s computer, and server cache, which holds data on the web server.

When caches hold outdated or insecure HTTP resources, users might still access old, unsecured versions, even if you’ve already fixed the issues on your site. This can lead to persistent errors. By clearing the cache, you ensure that all users receive the most recent, updated version of your site with correct HTTPS resources.

Step 10: Test everything

After clearing the cache, revisit your site to verify that all elements load securely over HTTPS, and check that the “was loaded over HTTPS, but requested an insecure script” error has been resolved. Ensure that no browser warnings are displayed.

How to prevent the “was loaded over HTTPS, but requested an insecure script” error?

After you’ve painstakingly fixed the “was loaded over HTTPS, but requested an insecure script” error, it’s clear that the process can be time-consuming and disruptive to your site’s routine maintenance. Not only does it consume valuable time and resources, but the error can also negatively affect the user experience by presenting security warnings. To avoid facing this issue repeatedly, it’s wise to take preventive measures from the outset.

• Maintain SSL Certificates: Regularly renew and manage your SSL certificates. An expired certificate can cause mixed content issues and disrupt the security and functionality of your site. Use an SSL Monitor to keep track of everything. Consistent Use of HTTPS: From the start of development, always use HTTPS URLs for all resources and links in your website’s code to ensure everything loads securely.
• Apply Site-wide Redirects: Implement server-side redirects that automatically route any HTTP requests to HTTPS. This prevents unintentional HTTP access to your site.
• Automate HTTPS URL Conversion: Use plugins or similar tools for CMS platforms like WordPress to automatically convert any new content and links to HTTPS. This automation saves time and reduces manual errors.
• Secure Third-party Integrations: Choose third-party services that support or require HTTPS to ensure that all external resources accessed by your site are secure.

Final thoughts

It’s evident that manually tackling the “was loaded over HTTPS, but requested an insecure script” error can be a daunting task. Navigating through countless scripts, links, and media files not only tests your patience but also risks introducing new errors. 

Thankfully, we’ve reached an era where robust plugins and tools simplify these complex processes, automating many of the tedious tasks involved in securing your WordPress site. Plugins like Really Simple SSL and Better Search Replace offer incredible solutions. 

However, it’s crucial to remember that these tools often require adjustments to critical files, like theme templates, and database tables. Before you dive into applying these automated solutions, a website backup of your site is a non-negotiable step. This precaution ensures you have a fallback should anything go awry, preserving your hard work and protecting your data.

FAQs

How to Resolve “This Request Has Been Blocked, the Content Must Be Served Over HTTPS”?

This message usually indicates a mixed content issue, meaning some elements on your page are being loaded over HTTP on an HTTPS website. To resolve it:

• Identify Insecure Elements: Use the browser’s developer tools, such as the Console tab in Chrome, to locate which resources are loading over HTTP.
• Update URLs: Update any HTTP links to HTTPS in your theme files, plugins, and database.
• Use Plugins: Consider using plugins like Really Simple SSL to automate the conversion of internal URLs to HTTPS.
• Check Third-party Resources: Ensure any third-party resources or scripts you are using offer an HTTPS version and update them accordingly.

How to Fix Mixed Content HTTPS?

Fixing mixed content involves ensuring all elements of your site are loaded over HTTPS:

• Automatic Redirects: Set up server-side redirects to ensure all traffic uses HTTPS.
• Update Database Links: Use plugins to update all URLs in your database from HTTP to HTTPS.
• Modify Theme Files: Manually update any hardcoded URLs in your theme files.
• Browser Developer Tools: Use these tools to identify mixed content and resolve it systematically.

Is HTTPS a Secure Version of HTTP? True or False?

True. HTTPS is indeed a secure version of HTTP. It uses encryption protocols like SSL/TLS to provide a secure communication channel over the internet, protecting user data from being intercepted by attackers.

Why Should You Not Use Any HTTP Resources Over HTTPS?

Using HTTP resources on an HTTPS site creates mixed content issues. This reduces security and leads to browser warnings. Mixing HTTP and HTTPS undermines the encryption and can expose data to potential attacks. Always ensure all resources are loaded over HTTPS for a secure and consistent user experience.