To fix a WordPress mixed content error, update your WordPress and Site Address URLs to HTTPS, replace all insecure HTTP references in the database using WP-CLI or a plugin, and force HTTPS redirects via .htaccess. Clear all caches and verify with browser DevTools that every resource loads securely.
- Identify insecure HTTP URLs in the browser console and replace them site-wide with HTTPS.
- Use WP-CLI, SQL, or a WordPress SSL plugin for database-level URL replacement.
- Enforce HTTPS redirects and HSTS to prevent future mixed content warnings.
wordpress mixed content error https fix is a common challenge that appears when your WordPress site loads over secure HTTPS, but some resources—images, CSS, JavaScript, or fonts—are still referenced using insecure HTTP URLs. Browsers block these mixed resources or display a warning, breaking page layout, damaging user trust, and hurting SEO. This guide explains exactly how to diagnose, fix, and prevent mixed content warnings in WordPress as of September 2026.
Mixed content warnings fall into two categories. Passive mixed content includes images, video, and audio files. Active mixed content includes scripts, CSS, and iframes. Active mixed content is more dangerous because an attacker could inject malicious code if the HTTP request is intercepted. That is why browsers typically block active mixed content outright while sometimes only warning about passive content.
What Causes Mixed Content Warnings in WordPress
Mixed content occurs when a page is served over HTTPS, but the browser encounters a resource loaded over HTTP. The most common triggers include hardcoded HTTP URLs in the WordPress database, theme files, plugin settings, or custom CSS. When you migrate a site from HTTP to HTTPS without updating every reference, old post content and meta fields often retain insecure URLs. A missing or misconfigured SSL certificate, a CDN serving assets over HTTP, or a proxy that terminates SSL incorrectly can also produce the warning.
For example, an old blog post may include an image tag like <img src=""> that was valid before SSL migration but now triggers a warning. Similarly, a theme option storing a background image URL over HTTP can silently continue loading from a CDN over insecure HTTP. These hidden references often go unnoticed until a user reports a broken padlock or a page element fails to load.
Users typically see a broken padlock icon, and the browser console displays messages like “Mixed Content: The page at ‘https://example.com’ was loaded over HTTPS, but requested an insecure script ‘http://example.com/script.js’.” This affects Core Web Vitals because render-blocking resources may be blocked, increasing load time. The impact is not just cosmetic—Google may flag the page as not fully secure, hurting rankings and conversions.
Immediate Quick Fixes for Emergency Situations
If your site is live and customers are seeing security warnings, start with a low-risk temporary fix. Install a plugin such as Really Simple SSL or SSL Insecure Content Fixer from the WordPress repository. These tools automatically detect mixed content and rewrite HTTP URLs to HTTPS on output, often resolving the issue within minutes. Also check Settings > General and verify that both WordPress Address (URL) and Site Address (URL) use https://. Clear any caching plugin settings and your browser cache immediately after making changes.
If you use Really Simple SSL, enable the mixed content fixer option and optionally the 301 redirect. SSL Insecure Content Fixer offers granular levels, such as Simple for basic rewriting or Content for more aggressive fixes. Avoid running multiple mixed content plugins simultaneously, because conflicting output buffers can cause blank pages or unexpected behavior.
Warning: Plugin-based fixes are excellent for immediate relief, but they do not correct the underlying database content. If you later deactivate the plugin, mixed content warnings may return. Treat this as a stopgap, not a permanent solution.
Difficulty: Beginner | Estimated time: 5–10 minutes
Proper Diagnostic Process to Isolate Mixed Content
Before applying a permanent fix, identify exactly which resources are insecure. Open your browser’s Developer Tools (F12), navigate to the Console tab, and reload the page. Look for red mixed content warnings that list the exact URLs. Switch to the Network tab and filter by “http:” to see all insecure requests. Online tools like Why No Padlock can also scan the page and list every HTTP resource.
Next, determine whether the insecure URLs come from the database, a theme, or a plugin. Temporarily switch to a default WordPress theme such as Twenty Twenty-Four. If the warning disappears, the issue is in your theme. Disable plugins one by one to isolate conflicts. For deeper inspection, log into your server via SSH and search theme and plugin files using grep:
grep -R "http://yourdomain.com" wp-content/themes/yourtheme/
Once you find insecure URLs, note whether they use your own domain or a third-party service. Third-party scripts, such as social sharing widgets or tracking pixels, may need to be replaced with HTTPS-compatible versions or removed entirely if the provider does not support secure connections.
Pro Tip: Use WP-CLI’s built-in search-replace with the --dry-run flag first to preview all database changes before writing anything. This reduces risk on production sites.
Permanent Solutions for WordPress Mixed Content Error HTTPS Fix
A permanent wordpress mixed content error https fix requires updating every insecure URL at the source. Start by forcing HTTPS in wp-config.php so WordPress always uses secure URLs:
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');
Then replace all remaining HTTP references in the database. The table below compares the most reliable methods so you can choose based on your access level and technical comfort.
| Method | Difficulty | Estimated Time | Best For |
|---|---|---|---|
| Plugin-based URL replacement | Beginner | 5 minutes | Non-technical users |
| WP-CLI search-replace | Intermediate | 10 minutes | Developers with SSH access |
| SQL query (phpMyAdmin) | Intermediate | 15 minutes | No SSH access, shared hosting |
| Manual file edits + .htaccess | Advanced | 20 minutes | Full server control |
If you have SSH access, run the following WP-CLI commands to replace all HTTP URLs with HTTPS across every table:
wp search-replace 'http://example.com' 'https://example.com' --all-tables --precise --dry-run
wp search-replace 'http://example.com' 'https://example.com' --all-tables --precise
Without SSH, use phpMyAdmin to run the same replacement manually. Always back up your database first:
UPDATE wp_options SET option_value = replace(option_value, 'http://example.com', 'https://example.com') WHERE option_name = 'home' OR option_name = 'siteurl';
UPDATE wp_posts SET post_content = replace(post_content, 'http://example.com', 'https://example.com');
UPDATE wp_postmeta SET meta_value = replace(meta_value, 'http://example.com', 'https://example.com');
If you cannot use WP-CLI, the free Better Search Replace plugin provides a safe database replacement with support for serialized data. Before running any replacement, export your database and test on a staging site if possible. If you use a page builder like Elementor, remember that some modules store background images and link fields as serialized arrays. The manual SQL query above does not safely handle serialized strings, so in those cases prefer WP-CLI or Better Search Replace.
Finally, add a permanent HTTPS redirect in your .htaccess file to ensure all future traffic uses HTTPS:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Security consideration: After any database replacement, verify that serialized data is not corrupted. WP-CLI handles serialized strings safely, but manual SQL replacements can break widgets or theme options. Test the entire site, especially forms and custom post types, after applying changes.
Prevention Strategies and Ongoing Maintenance
Avoid mixed content errors before they happen by enforcing HTTPS everywhere. Run the WordPress site health check regularly, and monitor your SSL certificate installation for expiration. Configure your CDN to serve assets over HTTPS, and set a Content Security Policy header that upgrades insecure requests. Add the following line to your .htaccess to enforce HTTP Strict Transport Security (HSTS):
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
A stronger Content Security Policy can also instruct browsers to automatically upgrade HTTP requests to HTTPS. Add this header to your .htaccess or server config:
Header always set Content-Security-Policy "upgrade-insecure-requests"
Note that this applies only to resources on the same origin. Third-party HTTP resources will still be blocked unless the external service supports HTTPS.
Train content editors to use relative URLs or always use the HTTPS prefix when adding images and links. Schedule weekly backups with a tool like UpdraftPlus, and test restores quarterly. Keep WordPress core, themes, and plugins updated, and review your caching plugin settings after every update to avoid serving stale HTTP references. Because mixed content affects Core Web Vitals, a proactive approach protects both user experience and search rankings.
Troubleshooting Checklist and When to Get Help
Use this checklist to verify your fix and catch hidden mixed content:
- ☐ Confirm both WordPress Address and Site Address use
https://. - ☐ Run a full site scan with your browser console and an online SSL checker.
- ☐ Replace all HTTP database references using WP-CLI or SQL.
- ☐ Clear server cache, plugin cache, and CDN cache.
- ☐ Verify the padlock icon appears on every page, including checkout and login.
- ☐ Test forms, sliders, and third-party embeds for broken functionality.
Expert Tip: For WooCommerce or LearnDash sites, pay special attention to payment gateways and course content. Some gateways load external scripts over HTTP, triggering mixed content even after a database cleanup. Contact your hosting provider if server-level redirects are not working, or if you lack SSH and phpMyAdmin access. Seek professional help from a WordPress developer if serialized data becomes corrupted or if the error persists after all database replacements.
