How to Fix WordPress Mixed Content Warnings (HTTPS to HTTP) in 2026

Last Updated: July 2026

TL;DR: WordPress mixed content warnings appear when your site loads over HTTPS but still serves some resources (images, scripts, stylesheets) over HTTP. The fix involves updating database URLs with Search-Replace, adding force-SSL constants to wp-config.php, correcting hardcoded HTTP links in themes and plugins, and using Really Simple SSL as a safety net. Most sites are clean in under 30 minutes with the steps below.

You installed an SSL certificate, your browser shows the padlock, and then you notice it is gone on half your pages. The address bar shows a warning instead of the green lock, and your browser console is full of “Mixed Content” errors. This is one of the most common post-migration headaches in WordPress, and it happens because moving to HTTPS does not automatically update every URL stored in your database or hardcoded into your theme files.

This guide covers every fix for WordPress mixed content warnings in 2026, in order from quickest to most surgical. Follow each section in sequence and you will not need to touch them again.

What Are Mixed Content Warnings?

Try GigaPress AI Free →

A mixed content warning fires when a browser loads a page over a secure HTTPS connection but discovers that some of the resources on that page are still being requested over plain HTTP. Browsers treat this as a security issue because an attacker could intercept and tamper with those unencrypted HTTP resources even though the main page is encrypted.

Chrome, Firefox, and Safari all block or warn on mixed content. Chrome (which powers roughly 65% of global browsing as of mid-2026) will actively block “active” mixed content such as scripts and stylesheets, and will display a “Not Secure” warning in the address bar. Google also uses HTTPS as a ranking signal, so persistent mixed content warnings can quietly suppress your search visibility.

There are two types of mixed content:

• Passive mixed content — images, audio, video loaded over HTTP. Browsers display a warning but still load the resource.
• Active mixed content — scripts, stylesheets, iframes, XHR requests loaded over HTTP. Browsers block these entirely, which can break site functionality.

Step 1: Find Mixed Content with Browser DevTools in 2026

Before you fix anything, identify exactly what is triggering the warnings. Open Chrome DevTools (press F12 or right-click and choose Inspect), navigate to the Console tab, and reload the page. Every mixed content error will appear there, and each message includes the URL of the offending resource.

Common patterns you will see:

• Mixed Content: The page at 'https://yoursite.com' was loaded over HTTPS, but requested an insecure image 'http://yoursite.com/wp-content/uploads/...'
• Mixed Content: The page at 'https://yoursite.com' was loaded over HTTPS, but requested an insecure script 'http://yoursite.com/wp-includes/...'

Make a note of the file types and URL patterns. If every offending URL is on your own domain (http://yoursite.com rather than http://some-external-cdn.com), the problem is almost entirely database and config-level. If you see third-party HTTP URLs, those require a different fix covered later in this guide.

You can also use the free online tool Why No Padlock (whynopadlock.com) to scan any public URL and get a full list of mixed content items without needing to open DevTools manually on every page.

Step 2: Update WordPress Site URL Settings

The most common cause of widespread mixed content warnings after migrating to HTTPS is that WordPress still has your old HTTP URL stored in its core settings. Go to Settings, then General in your WordPress dashboard. Check both the WordPress Address (URL) and Site Address (URL) fields. Both must start with https://, not http://. Update them if needed and save.

If your site breaks when you save (which can happen if SSL is not fully configured at the server level), you can set these values directly in wp-config.php instead:

define( 'WP_HOME', 'https://yoursite.com' );
define( 'WP_SITEURL', 'https://yoursite.com' );

Add these two lines above the line that reads /* That's all, stop editing! Happy publishing. */ in your wp-config.php file. This forces WordPress to use HTTPS for all internal URL generation regardless of what is stored in the database, and takes priority over the database settings.

Step 3: Force HTTPS in wp-config.php

WordPress uses a constant called FORCE_SSL_ADMIN to enforce HTTPS on the admin panel, but you also need to tell WordPress to treat all incoming requests as HTTPS when you are behind a reverse proxy or load balancer (which is common on managed hosting plans). Add these lines to wp-config.php:

define( 'FORCE_SSL_ADMIN', true );

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

The HTTP_X_FORWARDED_PROTO header is how most CDN and proxy layers (Cloudflare, AWS ALB, Nginx reverse proxies) communicate to PHP that the original connection was HTTPS. Without this check, WordPress may generate HTTP URLs even when the visitor’s browser is connecting over HTTPS, producing mixed content warnings on every page.

If you are on a GigaPress managed WordPress hosting plan, HTTPS and SSL termination are handled at the infrastructure level and these constants may already be configured. Check with your hosting dashboard before duplicating settings. For a broader look at how HTTPS and HTTP/2 interact on managed infrastructure, see our guide on WordPress HTTP/2 and HTTPS Setup for Maximum Speed in 2026.

Step 4: Run a Database Search-Replace for HTTP URLs

Even after fixing the Site URL settings, thousands of HTTP references can remain baked into your database: post content, widget data, theme customizer settings, and plugin option rows. The most reliable way to clean these up is a serialization-safe search-replace using WP-CLI or the Better Search Replace plugin.

Using WP-CLI (recommended for developers):

wp search-replace 'http://yoursite.com' 'https://yoursite.com' --skip-columns=guid --all-tables

The --skip-columns=guid flag prevents WP-CLI from updating the guid column in the posts table, which WordPress uses as a permanent identifier and should not be changed. The --all-tables flag ensures the replacement runs across every table in your database, including plugin-specific tables.

Always take a full database backup before running a search-replace. For a complete backup workflow, see Automating WordPress Backups to the Cloud: A Complete Guide 2026.

Using Better Search Replace plugin (no SSH access required):

• Install and activate Better Search Replace from the WordPress plugin directory.
• Go to Tools, then Better Search Replace.
• In the Search For field, enter: http://yoursite.com
• In the Replace With field, enter: https://yoursite.com
• Select all tables.
• Run a dry run first to see the count of replacements before committing.
• Uncheck “Run as dry run” and click Run Search-Replace.

Better Search Replace handles PHP serialized data correctly, which is critical because WordPress stores many options as serialized arrays. A naive find-and-replace (including phpMyAdmin’s built-in replace function) will corrupt serialized strings and break your site.

Step 5: Fix Hardcoded HTTP Links in Themes and Plugins

Some themes and plugins contain hardcoded http:// URLs in their PHP or JavaScript files, particularly older themes or custom-built templates. A database search-replace will not touch these because they live in files, not the database.

Use WP-CLI to search your theme files for hardcoded HTTP references:

grep -r "http://yoursite.com" /wp-content/themes/your-theme/

If you find hardcoded URLs in a child theme or custom theme, replace them directly in the file. If they are in a third-party theme’s core files, consider using a child theme to override the affected template, or contact the theme developer. Editing parent theme files directly means your changes will be overwritten on the next theme update.

For plugin files, a similar grep across /wp-content/plugins/ will surface any offenders. However, modifying plugin files directly is discouraged. Instead, check if the plugin has a setting to specify its own URL, or look for an update that addresses HTTPS compatibility.

Pay particular attention to the WordPress Heartbeat API and any scripts it loads. If a plugin enqueues scripts using hardcoded HTTP URLs in its Heartbeat integration, those will appear as mixed content on every page where the Heartbeat API is active. Our article on the WordPress Heartbeat API covers how to identify and control which scripts are loaded through that mechanism.

Step 6: Use Really Simple SSL as a Safety Net

Really Simple SSL (available on WordPress.org) is a plugin specifically designed to handle the HTTPS migration for WordPress. It automatically sets the WordPress URLs to HTTPS, adds a 301 redirect from HTTP to HTTPS at the WordPress level, and uses a JavaScript-based output buffer to rewrite any remaining HTTP references in page output before they reach the browser.

As of version 8.x (current in 2026), Really Simple SSL also includes a site scanner that identifies mixed content sources and reports them in the plugin dashboard. Install it, activate it, and review the scan results. If it finds issues, enable the “Mixed content fixer” option under Settings, then Really Simple SSL, then the Mixed Content tab.

A few important caveats about relying on Really Simple SSL alone:

• The JavaScript content fixer adds a small amount of overhead to every page load. It is a safety net, not a substitute for cleaning the database.
• The fixer cannot catch HTTP URLs in external resources (images from third-party sites that do not offer HTTPS). Those must be replaced manually.
• If you later deactivate Really Simple SSL without having cleaned the database, mixed content warnings will return immediately.

Think of Really Simple SSL as a final catch layer after you have completed Steps 2 through 5. Do not skip those steps and rely on the plugin alone.

Step 7: Handle Third-Party and External HTTP Resources

If your browser console shows mixed content errors pointing to external domains (not your own site), you have a different type of problem. Common sources include:

• Embedded Google Maps iframes using an HTTP src attribute (replace with HTTPS manually in the embed code).
• Old social media sharing buttons hardcoded in theme files with HTTP API endpoints.
• Images from external image hosts that have since moved to HTTPS (update the URL in your post content).
• Fonts or scripts loaded from third-party CDNs using HTTP (update the enqueue call in your functions.php or child theme).

For external resources that do not support HTTPS at all, the only correct fix is to host the resource yourself or replace it with a modern alternative. Do not use Content-Security-Policy: upgrade-insecure-requests as a permanent solution; it is a browser instruction, not a fix, and it will not work on all browsers or all resource types.

Verifying the Fix: A 2026 Mixed Content Checklist

After completing all the steps above, verify your site is clean:

• Open Chrome DevTools on your homepage, your most popular post, your shop page (if applicable), and your checkout or contact page. The Console tab should show zero mixed content errors.
• Check the Network tab and filter by “http://” to look for any HTTP requests that are not being upgraded.
• Run a scan with Why No Padlock or SSL Labs (ssllabs.com) for a third-party confirmation.
• Confirm the padlock icon appears in Chrome, Firefox, and Safari across multiple page types.
• Check your security plugin’s scan report (Wordfence, Sucuri, or similar) for any remaining HTTP asset references.

If you find remaining issues after all steps, clear your caching plugin and CDN cache first. Many mixed content warnings that persist after a correct fix are actually stale cached versions of old pages. See our guide to Best WordPress Caching Plugins for Faster Page Loads in 2026 for cache-clearing procedures specific to each major plugin.

Mixed Content and Your Hosting Environment

The type of hosting you use can make mixed content issues easier or harder to resolve. On shared hosting, you typically manage SSL certificates through cPanel, and the HTTP-to-HTTPS redirect must often be configured in an .htaccess file manually. On managed WordPress hosting, SSL certificates are provisioned automatically and HTTPS redirects are enforced at the server level, which eliminates an entire class of mixed content problems before they start.

If you are still on shared hosting and dealing with recurring SSL and mixed content issues, it may be worth evaluating an upgrade. Our comparison of Shared vs Managed WordPress Hosting covers the full difference in how each environment handles SSL, caching, and security out of the box.

For sites on managed hosting where mixed content warnings persist despite correct configuration, the most common culprit is a plugin that enqueues assets using a hardcoded domain that differs from the canonical domain (for example, using a staging domain URL that leaked into production). A targeted grep across your active plugins’ asset registration functions will surface this quickly. You can also check whether the WordPress Malware Removal guide applies if you suspect injected HTTP content from a compromised plugin.

Want a Pro WordPress Site in Minutes?

GigaPress AI builds you a full WordPress site in about 15 minutes — AI handles layout, styling, content, and images. Free to design, only pay when you’re ready to go live. Every GigaPress site is provisioned with SSL and HTTPS enforcement from day one, so you never have to chase mixed content warnings after launch.

Frequently Asked Questions

Why do I still see mixed content warnings after installing an SSL certificate?

Installing an SSL certificate only secures the connection between the browser and your server. It does not change the URLs stored in your WordPress database or hardcoded in your theme and plugin files. Those HTTP references must be updated separately using the steps in this guide, starting with Search-Replace on the database.

Is it safe to run WP search-replace on a live site?

Running WP-CLI search-replace on a live site is common practice, but you should always take a full database backup first. Use the dry-run flag to preview changes before committing. The operation itself takes seconds on most sites and causes no downtime. If you prefer a zero-risk approach, run the command on a staging copy first, then deploy the database to production.

Will fixing mixed content warnings improve my Google rankings?

Yes, indirectly. Google uses HTTPS as a positive ranking signal, and a valid, warning-free HTTPS connection is part of that. More importantly, active mixed content (blocked scripts and stylesheets) can degrade your Core Web Vitals scores by preventing above-the-fold resources from loading correctly, which directly affects your Largest Contentful Paint and First Input Delay scores. Fixing mixed content improves both trust signals and measured performance.

What does the –skip-columns=guid flag do in WP-CLI search-replace?

The guid column in the wp_posts table stores the original permalink assigned to each post when it was first created. WordPress uses it as a permanent identifier for feed readers and syndication. Changing the guid from HTTP to HTTPS can break RSS feeds and confuse feed aggregators that track posts by guid. Skipping this column is the standard practice recommended by WordPress.org documentation.

Can Really Simple SSL replace a database search-replace?

No. Really Simple SSL’s mixed content fixer works by rewriting page output in PHP before it reaches the browser, but this adds processing overhead on every page load and does not clean the underlying data. If you deactivate the plugin, all mixed content warnings will return. A proper database search-replace plus corrected wp-config.php constants is the permanent fix. Use Really Simple SSL as a diagnostic and safety net, not as a replacement for the underlying cleanup.