How to Fix Mixed Content Warnings in WordPress

Mixed content warnings are one of the most common issues WordPress site owners run into after switching from HTTP to HTTPS. They happen when your site loads over a secure HTTPS connection, but some resources on the page (images, scripts, stylesheets, iframes) are still being requested over plain HTTP. Browsers treat this as a security risk, and rightfully so. The good news is that mixed content is straightforward to fix once you understand where it comes from.

What Mixed Content Warnings Look Like in Your Browser

When a page has mixed content, browsers respond in different ways depending on the type of resource. For "active" mixed content (scripts, iframes, stylesheets), most browsers block the resource entirely and show a warning in the developer console. For "passive" mixed content (images, audio, video), the resource may still load, but the padlock icon in the address bar will either disappear or show a warning triangle.

In Chrome, you will see messages like "Mixed Content: The page at 'https://example.com' was loaded over HTTPS, but requested an insecure resource" in the console. Firefox displays a grey padlock with a warning triangle. Safari may silently block some resources without obvious visual feedback, which makes debugging trickier.

The practical result is that your site looks broken to visitors. Images may not load, styles may be missing, and scripts may fail to execute. Worse, Google considers HTTPS a ranking signal, so mixed content issues can indirectly hurt your SEO.

How to Find Every Mixed Content Source on Your Site

Before you can fix anything, you need a complete list of HTTP resources being loaded. There are several reliable ways to do this:

• InspectWP scan: Run a scan on your site. The HTML section lists every insecure URL found on the page, giving you a clear inventory of what needs fixing.
• Browser DevTools console: Open your browser's developer tools (F12 or Cmd+Shift+I on Mac), go to the Console tab, and reload the page. Every mixed content warning will appear here with the exact URL of the offending resource.
• Why No Padlock tool: Visit whynopadlock.com and enter your URL. It crawls the page and reports all insecure resources in a simple list.
• SSL Labs test: While primarily for checking your SSL certificate, the Qualys SSL Labs test can also flag mixed content issues.

For sites with many pages, you may want to check more than just the homepage. Test key landing pages, blog posts (especially older ones), and any pages with embedded media or third-party content.

Common Causes of Mixed Content in WordPress

Mixed content rarely comes from a single source. Here are the most frequent culprits:

• Hardcoded HTTP URLs in post content: If you created posts and pages before switching to HTTPS, all image URLs, links, and embedded media in the content editor will still use http://. WordPress stores these as absolute URLs in the database.
• Theme files with hardcoded URLs: Some themes hardcode image paths or external resource URLs with http:// instead of using protocol-relative URLs or WordPress functions.
• Plugin assets: Older or poorly maintained plugins may enqueue their CSS and JavaScript files using HTTP URLs.
• External embeds and iframes: Google Maps embeds, YouTube videos (older embed codes), social media widgets, and advertising scripts sometimes use HTTP.
• Custom CSS or widget content: Background images, font imports, or other resources specified in custom CSS fields or text widgets.
• CDN configuration: If you use a CDN, it might be configured to serve assets over HTTP rather than HTTPS.

Step 1: Update WordPress and Site URLs

Before anything else, make sure your core WordPress URLs are correct. Go to Settings, then General, and verify that both the WordPress Address (URL) and Site Address (URL) start with https://. If they still show http://, update them and save. This tells WordPress to generate all internal links using HTTPS.

Step 2: Search and Replace HTTP URLs in the Database

The most effective fix for the vast majority of mixed content is a database-wide search and replace. This catches hardcoded URLs in posts, pages, widget text, custom fields, theme options, and serialized data.

Using WP-CLI (the recommended method for anyone comfortable with the command line):

# Always run a dry run first to see what will be changed
wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-run

# Check the output carefully, then run for real
wp search-replace 'http://example.com' 'https://example.com' --all-tables

# If your site also uses the www subdomain, run both variations
wp search-replace 'http://www.example.com' 'https://www.example.com' --all-tables

WP-CLI handles serialized data correctly, which is critical. Many plugins store settings as serialized arrays in the database, and a naive SQL find-and-replace would break the serialization format.

Fixing Mixed Content with Better Search Replace Plugin

If you do not have command line access, the Better Search Replace plugin provides a user-friendly alternative:

1. Install and activate Better Search Replace from the WordPress plugin directory.
2. Go to Tools, then Better Search Replace.
3. In the "Search for" field, enter http://example.com (your actual domain).
4. In the "Replace with" field, enter https://example.com.
5. Select all tables in the table list (Ctrl+A or Cmd+A).
6. Check "Run as dry run" first, then click "Run Search/Replace".
7. Review the results. If the replacements look correct, uncheck "Run as dry run" and run it again.

After the replacement, clear any caching plugins and check your site again.

Using Really Simple SSL as a Quick Fix

The Really Simple SSL plugin takes a different approach. Instead of fixing URLs in the database, it dynamically rewrites HTTP URLs to HTTPS on the fly using output buffering and WordPress filters. Install it, activate it, and it handles the rest automatically.

This works well as an immediate fix, but it adds a small amount of processing overhead to every page load. For best performance, it is better to fix the URLs at the source (database level) and then deactivate the plugin. Think of Really Simple SSL as a safety net rather than a permanent solution.

Fixing Theme and Plugin Files Manually

Some mixed content comes from hardcoded URLs in theme or plugin files rather than the database. Search your active theme directory for http:// references:

# Search for hardcoded HTTP URLs in your theme
grep -r "http://" /path/to/wp-content/themes/your-theme/ --include="*.php" --include="*.css" --include="*.js"

Replace any hardcoded HTTP URLs with HTTPS, or better yet, use protocol-relative URLs (//example.com/resource.js) or WordPress functions like esc_url() that respect the site's protocol setting.

For third-party plugins, do not edit plugin files directly (updates will overwrite your changes). Instead, contact the plugin author or look for a newer version that supports HTTPS. If a plugin consistently loads assets over HTTP, consider replacing it with a better-maintained alternative.

Adding an HTTP to HTTPS Redirect

After fixing all mixed content in the database and files, set up a server-level redirect so that any remaining HTTP requests are automatically forwarded to HTTPS:

# Add to .htaccess (Apache)
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

For Nginx servers, add this to your server block:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Force HTTPS in wp-config.php

If your site is behind a reverse proxy or load balancer, WordPress may not detect HTTPS correctly. Add the following to your wp-config.php file:

define('FORCE_SSL_ADMIN', true);

// If behind a reverse proxy or load balancer
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Verifying Your Fixes and Preventing Future Mixed Content

After making all changes, run a fresh InspectWP scan. The insecure URLs list in the HTML section should be empty. Also open your browser's developer console and confirm that no mixed content warnings appear.

To prevent mixed content from creeping back in:

• Set a Content-Security-Policy header: Adding Content-Security-Policy: upgrade-insecure-requests as a response header tells browsers to automatically upgrade HTTP requests to HTTPS. This is a good safety net.
• Use relative or HTTPS URLs: When embedding images or resources manually, always use https:// or protocol-relative URLs.
• Check third-party embeds: Before pasting embed codes from external services, verify they use HTTPS.
• Audit regularly: Set up automatic InspectWP reports to catch any mixed content that appears after content updates or plugin changes.