When you migrate a WordPress network to a secure protocol, you expect a smooth transition. However, many administrators are met with the frustrating “Not Secure” warning in the browser bar. This usually happens because your site is loading images, scripts, or stylesheets over an insecure HTTP connection while the main page is on HTTPS. Successfully fixing mixed content https issues on wordpress multisite requires a systematic approach that looks at the database, theme files, and server configuration simultaneously.
In a multisite environment, this challenge is magnified. You aren’t just dealing with one site; you are managing a network where settings might be inherited or overridden at the individual site level. I have spent years untangling these complex networks, and I know how easy it is to miss a single hardcoded link that breaks the green padlock for hundreds of subdomains.
In this comprehensive guide, I will walk you through the exact steps I use to audit and repair these issues. We will cover everything from database search-and-replace techniques to advanced Content Security Policies. By the end of this article, you will have a clear, actionable roadmap for ensuring your entire WordPress network remains secure and professional.
Whether you are running a university network with thousands of sub-sites or a small business portfolio, these strategies are designed to scale. We will explore how to identify the root causes of insecure warnings and how to implement permanent fixes that won’t break during the next WordPress update. Let’s dive into the technical nuances of securing your WordPress multisite network once and for all.
1. Understanding the Root Causes of Mixed Content on Multisite
Before we start fixing mixed content https issues on wordpress multisite, we must understand why they occur. Mixed content happens when the initial HTML of a page is loaded over a secure HTTPS connection, but other resources are called via HTTP. This triggers a browser warning that can scare away visitors and hurt your SEO rankings.
In a multisite setup, the architecture itself can introduce unique vulnerabilities. For example, a global theme might use a hardcoded HTTP link for a logo that affects every site in the network. Alternatively, a plugin might be storing absolute URLs in the database that still point to the old protocol.
I recently worked with a large digital agency that managed a multisite network for 40 different franchises. They had installed SSL certificates for every domain, but the “Not Secure” warning persisted. We discovered that a custom widget used across all sites was calling a JavaScript library from an external HTTP source, which invalidated the security of the entire network.
Identifying Passive vs. Active Mixed Content
It is helpful to distinguish between passive and active mixed content. Passive content refers to items like images or videos. While they trigger a warning, browsers often still display them. Active content, such as scripts or iframes, is much more dangerous because it can be used to intercept user data.
Most modern browsers will automatically block active mixed content. This means if your multisite network relies on insecure scripts, your site’s functionality will break entirely. Understanding this distinction helps you prioritize which fixes are most urgent for your network’s stability.
The Impact of Subdomains vs. Subdirectories
The way your multisite is structured also dictates how mixed content appears. Subdirectory installs often have fewer issues because they share the primary domain’s SSL certificate structure. Subdomain installs, however, require wildcard SSLs or individual certificates, which can complicate how resources are mapped.
If a sub-site on `blog.example.com` tries to pull a script from the main `example.com` via HTTP, the browser will flag it. I once saw a network where the main site was secure, but all 200 subdomains were broken because the “Site Address” in the network settings hadn’t been updated to HTTPS.
Why Multisite “Search and Replace” is Different
On a single WordPress site, a simple database search and replace usually does the trick. On a multisite, you have to be careful about site-specific tables. Each sub-site has its own set of tables (e.g., `wp_2_options`, `wp_3_options`), and a global search must account for these variations without corrupting the serialized data.
2. Performing a Comprehensive Network Audit
You cannot fix what you cannot find. The first step in fixing mixed content https issues on wordpress multisite is a thorough audit. You need to scan your network to find exactly which files and database entries are still using the `http://` prefix.
I recommend starting with a browser-based tool like “Why No Padlock” or the Chrome DevTools Security tab. For a multisite network, however, checking every page manually is impossible. You need an automated solution that can crawl your entire network and report back on insecure assets.
A developer friend of mine once spent three days trying to find a mixed content error on a client’s multisite homepage. It turned out to be a single CSS file loading a background image from a staging server over HTTP. An automated scan would have found that in thirty seconds.
Using Network Scanning Tools
There are several specialized tools designed to crawl WordPress networks. Screaming Frog SEO Spider is a fantastic desktop application that can crawl thousands of URLs. You can set it to specifically look for “Insecure Content” and it will give you a list of every HTTP resource found on your HTTPS pages.
For those who prefer a plugin-based approach, “SSL Insecure Content Fixer” is a popular choice. It has a “Network” mode that can help identify issues across all sites. However, I always suggest using these tools for identification first, rather than relying on them as a permanent “band-aid” fix.
Inspecting the Browser Console
If you are seeing a warning on a specific sub-site, right-click and select “Inspect,” then go to the “Console” tab. Browsers like Chrome will explicitly list every blocked resource. It will tell you the exact URL of the insecure file and which line of code or script requested it. Look for the “Mixed Content” error message in red. Check if the resource is an image, script, or stylesheet. Note the source file, such as `style.css` or `scripts.js`.
Auditing External API Calls
Many multisite networks fetch data from external sources, like weather widgets or stock tickers. If these APIs are called via HTTP, they will trigger security warnings. In 2024, almost every reputable API provider offers an HTTPS endpoint, so the fix is usually as simple as changing the request URL in your code.
I encountered a scenario where a corporate multisite was pulling an employee directory from a legacy internal server. The internal server didn’t have an SSL certificate, causing every profile page on the secure public site to show a warning. We had to set up a reverse proxy with SSL to resolve the conflict.
3. Database Search and Replace Strategies
The most effective way of fixing mixed content https issues on wordpress multisite is by updating the database. Most links in WordPress—including those for images, post content, and site settings—are stored as absolute URLs. When you switch to HTTPS, these thousands of entries need to be updated.
You should never try to do this with a standard SQL query like `UPDATE table SET column = replace(…)`. WordPress stores a lot of data in “serialized” format. If you change the length of a string (like changing `http` to `https`), the serialization will break, and your site settings or widgets will disappear.
Using WP-CLI for Large Networks
For developers and advanced users, WP-CLI is the gold standard for SSL protocol errors and database management. It includes a `search-replace` command that handles serialized data perfectly. It is also incredibly fast, allowing you to update a network of hundreds of sites in seconds.
The command usually looks like this: `wp search-replace ‘http://example.com’ ‘https://example.com’ –url=example.com –network`. This tells the system to look through every table in the entire network and swap the old protocol for the new one. Always run this with the `–dry-run` flag first to see how many changes will be made without actually committing them.
Recommended Plugins for Database Updates
If you aren’t comfortable with the command line, the “Better Search Replace” plugin is an excellent alternative. It is multisite-compatible and allows you to select all tables in your network. It also includes a “Dry Run” feature, which is essential for preventing accidental site breakage.
Backup your entire database before proceeding. Install and Network Activate the plugin. Go to the Network Admin settings. Enter the HTTP version of your domain in the “Search for” field. Enter the HTTPS version in the “Replace with” field. Select all tables and run the process.
4. Configuring Network-Wide Redirects in .htaccess
Once your database is clean, you need to ensure that any remaining HTTP traffic is automatically forced to HTTPS. This is a crucial step in fixing mixed content https issues on wordpress multisite. Even if your content is secure, if a user types the HTTP version of your URL, you want them redirected instantly.
The `.htaccess` file on Apache servers is the best place to handle this. By placing the redirect rules at the server level, you ensure that the redirection happens before WordPress even starts loading. This is faster and more secure than using a WordPress plugin to handle redirects.
Standard Redirect Code for Multisite
For a standard WordPress multisite, you need a rule that handles both the main domain and all subdomains or subdirectories. I’ve seen many people use a simple “Single Site” redirect code that accidentally creates an infinite redirect loop on multisite networks.
The following logic is typically used: if the request is not on port 443 (HTTPS), redirect it to the same URL but with the HTTPS prefix. This should be placed at the very top of your `.htaccess` file, before the standard WordPress rewrite rules. This ensures the security check happens first.
Troubleshooting Redirect Loops
Redirect loops are the most common issue when fixing mixed content https issues on wordpress multisite via `.htaccess`. This often happens if your site is behind a load balancer or a service like Cloudflare. In these cases, the server might not “know” the request is already HTTPS because the load balancer communicates with the server via HTTP.
To fix this, you might need to check for the `X-Forwarded-Proto` header. This header is sent by the load balancer to tell the server that the original request from the user was secure. If you don’t account for this, your server will keep trying to redirect a request that is already technically “secure” in the eyes of the user.
Forcing HTTPS in wp-config.php
In addition to `.htaccess`, you should define the secure protocol in your `wp-config.php` file. Adding `define(‘FORCE_SSL_ADMIN’, true);` ensures that the WordPress dashboard is always accessed over HTTPS. For multisite, this is non-negotiable, as it protects the login credentials of all your network users.
I recall a case where a network admin had secure front-ends, but the login page was still accessible via HTTP. A malicious actor on the same public Wi-Fi as a site editor could have intercepted the login cookies. Setting the constant in `wp-config.php` prevents this vulnerability entirely.
5. Fixing Hardcoded Links in Themes and Plugins
Sometimes, the database isn’t the problem. The issue might be living in your code. When fixing mixed content https issues on wordpress multisite, you must audit your active themes and plugins for hardcoded `http://` strings. This is common in older themes or custom-coded solutions.
If a developer wrote “ directly into the `header.php` file, no amount of database searching will fix it. You have to manually edit the file or, better yet, update the code to use protocol-agnostic links or proper WordPress functions.
Searching Your Theme Directory
If you have SSH access, you can use the `grep` command to find every instance of “http://” in your `wp-content` folder. This is a lifesaver. Run `grep -r “http://” wp-content/themes/` and it will print out every file and line number where an insecure link exists.
I once found a mixed content issue on a university network that only appeared on mobile devices. It turned out the theme had a separate `mobile-header.php` file that hadn’t been updated in five years. It was still calling an old version of jQuery via HTTP. A quick grep search identified the culprit in seconds.
Using Relative URLs and WordPress Functions
The “correct” way to link to assets in WordPress is to use functions like `get_template_directory_uri()` or `plugins_url()`. These functions automatically detect if the site is running on HTTPS and return the correct protocol. If your theme uses these, you won’t have to worry about database search and replace issues in the future. Replace `http://yoursite.com/wp-content/…` with `echo get_stylesheet_directory_uri() . ‘/path/to/asset’;` Ensure all calls to Google Fonts or external APIs use `https://`. Check your CSS files for `url(‘http://…’)` in background-image properties.
Updating Plugin Settings
Some plugins, especially sliders and page builders, store their own configuration files or CSS caches. If you’ve updated your site to HTTPS but the slider still looks broken, you might need to “Clear Cache” or “Regenerate CSS” within the plugin’s own settings menu.
A real-world example of this is the Elementor page builder. After a migration, you often need to go to Elementor > Tools > Replace URL to ensure all the CSS generated by the builder uses the new secure paths. This is a common step that people forget when managing a multisite network.
6. Implementing Content Security Policy (CSP) Headers
As we move into 2025 and 2026, relying solely on redirects isn’t enough. A powerful modern technique for fixing mixed content https issues on wordpress multisite is implementing a Content Security Policy (CSP). A CSP is an extra layer of security that tells the browser which sources of content are trusted.
One specific CSP directive, `upgrade-insecure-requests`, is a “magic bullet” for mixed content. When this header is present, the browser will automatically attempt to load all HTTP resources over HTTPS before failing. This can fix thousands of minor mixed content errors across a multisite network with a single line of code.
How to Add CSP to WordPress Multisite
You can add CSP headers via your `.htaccess` file or by using a PHP function in your theme’s `functions.php`. For a multisite, adding it to `.htaccess` is more efficient because it covers every site in the network without needing to touch individual theme files.
The code looks like this: `Header always set Content-Security-Policy “upgrade-insecure-requests;”`. This tells the visitor’s browser: “If you see anything on this site trying to load via HTTP, try to find the HTTPS version instead.” It’s incredibly effective for network-wide security headers management.
Monitoring with CSP Reporting
You can also set your CSP to “Report-Only” mode. This allows you to see what would be blocked or upgraded without actually changing anything for the user. You can point the reports to a service like URIports or Sentry, which will give you a detailed log of every mixed content instance across your entire multisite network.
I worked with a government multisite that had very strict security requirements. We used CSP reporting to find “ghost” mixed content—resources being called by browser extensions or obscure third-party scripts that weren’t even in the site’s code. This allowed us to clean up the network to a degree that traditional scanning couldn’t match.
Potential Pitfalls of CSP
While `upgrade-insecure-requests` is great, it only works if the resource is actually available via HTTPS. If you are calling an old image from a server that doesn’t have an SSL certificate, the browser will try to upgrade it, fail, and the image won’t load at all.
This is actually a good thing for security, but it can lead to broken images. This is why the audit phase is so important. You need to make sure your external sources support HTTPS before you force the upgrade via CSP.
7. Managing Media Library and GUID Issues
The Media Library in WordPress can be a major source of headaches when fixing mixed content https issues on wordpress multisite. Images uploaded to sub-sites are stored with absolute URLs in the database. Furthermore, WordPress uses something called a GUID (Globally Unique Identifier) for RSS feeds, which often contains the original HTTP URL.
While the common advice is “never change the GUID,” this applies to sites that have already been indexed by RSS readers. If you are doing a fresh migration to HTTPS, ensuring your GUIDs match your secure URL structure can prevent “Mixed Content” warnings in feed readers and certain aggregators.
Fixing Attachment Metadata
When you upload an image, WordPress doesn’t just store the URL in the post content. It also stores it in the `wp_postmeta` table as `_wp_attached_file` and within serialized arrays for different image sizes. If your search and replace tool doesn’t handle serialized data correctly, your thumbnails will continue to load over HTTP.
I remember a photography network where the main images were secure, but all the gallery thumbnails triggered mixed content warnings. We had to use a specialized tool to regenerate the metadata because the initial search and replace had missed the serialized arrays inside the `postmeta` table.
The Problem with Hardcoded CSS Paths
Many themes allow you to upload a background image or a logo through the Customizer. These URLs are often saved in the `wp_options` table. In a multisite, if a sub-site user changes their logo, that URL is saved at that moment. If the site was HTTP at the time, that HTTP link stays there forever until updated.
Navigate to the Network Admin. Use a plugin like “Network Media Library” to centralize assets if needed. Run a specific search and replace on the `wp_options` and `wp_postmeta` tables for all site IDs. Clear any image optimization or CDN caches that might be serving old URLs.
FAQ: Common Questions About Multisite SSL Issues
Why does my multisite still show “Not Secure” after I installed an SSL?
Installing the certificate is only the first step. Your database and theme files likely still contain links that use `http://`. The browser sees these insecure resources (images, scripts) being loaded on a secure page and triggers the warning to protect the user.
Can I use a free Let’s Encrypt certificate for a WordPress Multisite?
Yes, but it depends on your multisite structure. For subdirectory installs, a single certificate works. For subdomain installs, you will need a Wildcard SSL certificate or a server setup (like those provided by Kinsta or WP Engine) that automatically generates certificates for new subdomains.
Will fixing mixed content affect my SEO?
Actually, it will help it. Google uses HTTPS as a ranking signal. Sites with mixed content warnings provide a poor user experience and may be penalized in search results. Resolving these issues ensures you get the full SEO benefit of your SSL certificate.
What is the fastest way to fix mixed content on 100+ sites?
The fastest way is using WP-CLI to perform a network-wide search and replace in the database, followed by adding the `upgrade-insecure-requests` CSP header to your `.htaccess` file. This combination addresses both the stored data and any missed hardcoded links.
Does “Really Simple SSL” work for multisite networks?
Yes, the Pro version of Really Simple SSL has specific features for WordPress Multisite. It can handle network-wide redirects and help identify mixed content. However, for long-term performance, I recommend fixing the root causes in the database rather than relying on a plugin to “fix” them on every page load.
Why are my images missing after switching to HTTPS?
This usually happens if you have a Content Security Policy that forces HTTPS, but the images are hosted on a different server that doesn’t support SSL. The browser tries to upgrade the request, fails, and blocks the image. Ensure all external image sources are HTTPS-capable.
Is it safe to run a search and replace on the entire multisite database?
It is safe only if you use a tool that handles serialized data (like WP-CLI or Better Search Replace) and if you have a full backup. Never perform this action without a way to revert, as an incorrect search/replace string can break the entire network.
Conclusion
Securing a WordPress network is a significant undertaking, but it is essential for modern web standards. Fixing mixed content https issues on wordpress multisite is not just about aesthetics; it is about protecting your users’ data and maintaining the professional integrity of your network. By following a structured approach—auditing, database cleaning, code updates, and server-level redirects—you can eliminate those pesky “Not Secure” warnings for good.
We have explored how the complexity of multisite architecture requires specialized tools like WP-CLI and specific `.htaccess` configurations. We’ve also seen how modern solutions like Content Security Policies can act as a safety net for any links you might have missed. Remember that a secure site is a trustworthy site, and in the competitive landscape of 2025, trust is your most valuable currency.
Take the time to perform these steps carefully. Start with a full backup, run a dry-run audit, and then systematically update your network. Once you see that green padlock across every one of your sub-sites, you’ll know the effort was worth it. If you found this guide helpful, consider sharing it with other network administrators or leaving a comment with your own troubleshooting tips. Your journey to a fully secure WordPress multisite starts with that first scan!
