How to Fix the WordPress “Mixed Content” Warning (HTTP to HTTPS)

How to Fix the WordPress “Mixed Content” Warning (HTTP to HTTPS)

A mixed content warning occurs when your WordPress site loads over HTTPS but some resources — images, scripts, stylesheets, or fonts — are still loaded over HTTP. The fastest fix is to install the Really Simple SSL plugin, which automatically detects and fixes most mixed content issues. For a more thorough fix, run a search-and-replace in your database to change all http://yourdomain.com references to https://yourdomain.com.

Mixed content is one of the most common issues after switching a WordPress site from HTTP to HTTPS. Your SSL certificate is installed, your site loads over HTTPS, and the padlock icon appears in the address bar — but then a browser warning appears, or the padlock shows a warning triangle, or certain resources fail to load entirely. This happens because while your pages are served securely over HTTPS, some resources embedded in those pages are still referenced using the old HTTP URLs.

Browsers handle mixed content in two ways. Mixed passive content (images, videos, audio) typically loads but triggers a warning — the padlock may show a triangle or an “info” indicator instead of the full secure padlock. Mixed active content (scripts, stylesheets, iframes) is blocked entirely by modern browsers because active content loaded over HTTP on an HTTPS page can be intercepted and manipulated by attackers — a serious security risk. If your site’s critical CSS or JavaScript is blocked due to mixed content, pages can break visually or functionally.

What Causes Mixed Content in WordPress?

Hardcoded HTTP URLs in your database. When your site was running on HTTP, WordPress stored all internal URLs — in post content, page content, widget content, plugin settings, and theme customiser settings — using http://. When you switched to HTTPS, the SSL certificate secured the connection, but the database still contains thousands of http:// references. Every image in your blog posts, every internal link, every media URL is still pointing to the HTTP version.

Hardcoded HTTP URLs in theme files. Some themes have URLs hardcoded directly in template files (header.php, footer.php, etc.) rather than using WordPress functions that generate URLs dynamically. These hardcoded references do not update when you change your site URL to HTTPS.

Third-party resources loaded over HTTP. External scripts, fonts, analytics code, or embedded content from third-party services that use HTTP URLs will trigger mixed content warnings on your HTTPS site. Google Fonts, analytics scripts, social media embeds, and advertising code are common sources.

CDN configuration. If your CDN is configured to serve assets over HTTP while your site uses HTTPS, every CDN-served resource (images, CSS, JS) will trigger mixed content. Your CDN must be configured to serve assets over HTTPS — or protocol-relative URLs (starting with // instead of http:// or https://).

Step 1: Update WordPress URL Settings

First, ensure your WordPress Address and Site Address use HTTPS. Go to Settings → General. Verify that both “WordPress Address (URL)” and “Site Address (URL)” begin with https://. If they still show http://, change them to https:// and save. If you cannot access the admin, update these via wp-config.php — see our guide to changing WordPress URLs.

Step 2: Run a Search-and-Replace on Your Database

This is the most important step. You need to find every instance of http://yourdomain.com in your database and replace it with https://yourdomain.com. This updates image URLs in your post content, internal links throughout your site, media library URLs, widget content, plugin settings that store URLs, and theme customiser settings.

Method A: Better Search Replace Plugin (Easiest)

Install the Better Search Replace plugin from Plugins → Add New. Go to Tools → Better Search Replace. In “Search for,” enter http://yourdomain.com. In “Replace with,” enter https://yourdomain.com. Select all database tables. Check “Run as dry run” first to see how many replacements will be made without actually changing anything. If the dry run shows expected results, uncheck “Run as dry run” and click “Run Search/Replace” to apply the changes.

After the replacement completes, deactivate and delete the Better Search Replace plugin — you only need it for this one-time operation.

Method B: WP-CLI (For Technical Users)

If you have SSH access, WP-CLI’s search-replace command handles this cleanly:

wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --all-tables --precise

The --all-tables flag ensures custom tables (created by plugins like WooCommerce, Yoast, Rank Math) are included. The --precise flag handles serialised data correctly — this is important because WordPress stores many settings as serialised PHP arrays, and a naive search-and-replace can corrupt serialised data by changing string lengths without updating the length declarations.

Method C: Really Simple SSL Plugin (Quick Fix)

The Really Simple SSL plugin detects mixed content issues and fixes them dynamically — rewriting HTTP URLs to HTTPS in the page output. Install, activate, and click “Go ahead, activate SSL!” The plugin handles URL rewriting, sets WordPress URLs to HTTPS, and adds an HTTP-to-HTTPS redirect.

Really Simple SSL is a good quick fix, but it works by filtering output at runtime rather than fixing the database itself. This adds a small amount of processing overhead on every page load. For a permanent, clean fix, the database search-and-replace (Method A or B) is preferred. You can use Really Simple SSL as an immediate fix and then perform the database cleanup later.

Step 3: Add HTTP-to-HTTPS Redirect

After fixing mixed content in your database, add a server-level redirect so any visitor (or search engine) accessing an HTTP URL is automatically redirected to the HTTPS version. Add this to the top of your .htaccess file (for Apache servers):

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

This 301 redirect tells browsers and search engines that the HTTP version has permanently moved to HTTPS. It also ensures that any remaining HTTP links — from external sites, bookmarks, or search engine indexes — resolve to the secure HTTPS version.

If your host uses Nginx instead of Apache, add the equivalent redirect in your server block configuration (contact your host if you cannot edit Nginx config directly). Really Simple SSL adds this redirect automatically if you use that plugin.

Step 4: Check Theme and Plugin Files for Hardcoded HTTP URLs

Some mixed content issues are not in the database but in theme or plugin files — hardcoded URLs in PHP templates, JavaScript files, or CSS stylesheets. The database search-and-replace from Step 2 does not fix these.

Use your browser’s Developer Tools to identify remaining mixed content. In Chrome, open DevTools (F12), click the Console tab, and look for warnings about mixed content. Each warning identifies the specific resource URL that is loading over HTTP and the page element that references it.

If the source is a theme file, edit the file (ideally in a child theme) and change the HTTP URL to HTTPS or to a protocol-relative URL (e.g., //fonts.googleapis.com/... instead of http://fonts.googleapis.com/...).

If the source is a plugin, check the plugin’s settings for URL configuration options. If the plugin has a hardcoded HTTP URL with no settings to change it, update the plugin — most plugin developers have updated their code for HTTPS compatibility. If the plugin is outdated and the developer has not updated it, consider replacing it with an alternative.

Step 5: Update CDN and External Service URLs

If you use a CDN (Cloudflare, BunnyCDN, KeyCDN), verify that it is configured to serve assets over HTTPS. In Cloudflare, ensure your SSL/TLS encryption mode is set to “Full” or “Full (Strict)” — not “Flexible” (which can cause redirect loops and mixed content issues). For other CDNs, check that your CDN pull zone or origin settings use HTTPS.

For external services — Google Analytics, Facebook Pixel, advertising scripts, embedded maps, video embeds — verify that the embed code or script URL uses HTTPS. Most major services have supported HTTPS for years, but older embed codes from before the switch might still use HTTP.

Step 6: Verify Everything Is Fixed

After completing the above steps, verify that all mixed content is resolved.

Browser check: Visit your homepage, several internal pages, and (for WooCommerce) your shop and checkout pages. Check for the full green padlock in the address bar. If the padlock shows a warning triangle or an “info” icon, mixed content remains.

Developer Tools check: Open Chrome DevTools (F12) → Console tab. Reload each page. If no mixed content warnings appear, you are clean.

Online scanner: Tools like Why No Padlock (whynopadlock.com) or JitBit SSL Checker (jitbit.com/sslcheck/) scan a page and list all HTTP resources. Run your homepage and key pages through these tools to catch anything you might have missed.

Google Search Console: After fixing mixed content, check Google Search Console over the following days for any HTTPS-related issues or coverage changes.

Frequently Asked Questions

Will mixed content affect my SEO?

Yes. Google prefers fully HTTPS sites. Mixed content — particularly blocked active content that breaks page functionality — signals to Google that the HTTPS implementation is incomplete. Additionally, mixed content warnings can scare visitors away, increasing bounce rates. Fixing mixed content ensures your HTTPS implementation is complete and provides the full SEO benefit of a secure site.

I fixed mixed content but the padlock still shows a warning. Why?

Some reasons: your browser has cached the old mixed content page (clear cache and reload), there is a resource loading from a third-party domain over HTTP that you have not identified yet (check DevTools Console for warnings), or your SSL certificate itself has an issue (check the certificate by clicking the padlock icon). If your certificate shows any errors, see our guide on fixing “Your Connection Is Not Private” errors.

Can I just use protocol-relative URLs instead of HTTPS?

Protocol-relative URLs (starting with // instead of http:// or https://) were once recommended as a way to serve content over whichever protocol the page uses. However, as of 2026, the web community and most style guides recommend using explicit https:// URLs because virtually all modern websites and services use HTTPS. Protocol-relative URLs still work but are considered outdated practice.

My WooCommerce checkout has mixed content warnings. Is this a security risk?

Yes — this should be fixed immediately. Mixed content on payment pages can trigger browser security warnings that cause customers to abandon the checkout. More critically, if mixed active content (JavaScript) loads over HTTP on a payment page, it could theoretically be intercepted and modified by an attacker — though modern browsers block mixed active content precisely to prevent this. Fix mixed content on checkout and payment pages as a top priority. See our WooCommerce checkout troubleshooting guide.

Need Expert Help? Let WP Ministry Handle It

Mixed content issues after an HTTP-to-HTTPS migration can be widespread and tedious to track down — especially on large sites with thousands of posts, extensive media libraries, and multiple third-party integrations. Our team handles SSL configuration and mixed content cleanup as part of our security service and migration service.

Call (901) 249-0909 for assistance, or choose a care plan for ongoing SSL management and security monitoring.

View our care plans →

Related Articles

How to Fix “Your Connection Is Not Private” Error on WordPress

How to Install a Free SSL Certificate on WordPress

How to Change Your WordPress URL (Site Address and WordPress Address)

Like this article?

Share on Facebook
Share on Twitter
Share on Linkdin
Share on Pinterest

Leave a comment