WordPress Mixed Content: Fix Every HTTP Warning for Good

Mixed content warnings appear when your WordPress site is served over HTTPS but one or more resources — images, scripts, stylesheets, fonts, iframes — are still requested over plain HTTP. Browsers block or flag those insecure assets, the padlock icon turns grey, broken, or disappears entirely, and visitors (and Google) see a site that isn't fully secure. The fix is straightforward once you know where every HTTP reference is hiding.

What You're Actually Seeing

The symptoms vary slightly by browser, but the pattern is consistent:

• Chrome shows an info icon or broken padlock instead of the solid green/grey lock.
• Firefox shows a padlock with a warning triangle.
• The browser console (F12 → Console) lists lines like: Mixed Content: The page at 'https://example.com' was loaded over HTTPS, but requested an insecure resource 'http://example.com/wp-content/uploads/image.jpg'
• Certain scripts or stylesheets simply fail to load, breaking layout or functionality — this is called mixed content blocking, and it is more severe than a warning.

There are two grades of mixed content. Passive mixed content (images, audio, video) shows a warning but usually still loads. Active mixed content (scripts, stylesheets, iframes, XHR requests) is actively blocked by modern browsers because it can be used to hijack the page. Either way, you want it gone.

Why This Happens on WordPress Sites

You installed an SSL certificate — or your host turned HTTPS on — but the content inside your database and theme files still points to the old http:// URLs. Common culprits:

• Hardcoded URLs in the database — post content, widget text, and theme customizer settings stored as absolute http:// paths.
• WordPress Address and Site Address still set to http:// in Settings → General.
• Theme or page-builder templates with http:// URLs written directly into template files or inline styles.
• External resources — Google Fonts, CDN assets, embeds, or third-party scripts loaded from HTTP endpoints that haven't been updated.
• Plugins that hardcode their own asset URLs using http:// instead of protocol-relative or HTTPS paths.
• After a site migration where the source site was HTTP and the destination is HTTPS.

Step 1: Confirm Your SSL Certificate Is Working

Before chasing down mixed content, make sure the certificate itself is valid and covers the right domain. Visit SSL Labs or simply open your site in an incognito window and look at the URL bar. If the browser shows a full certificate error (NET::ERR_CERT_INVALID, etc.) rather than a padlock warning, you have a different problem — an expired or misconfigured certificate — and that needs fixing at the host level first.

If the cert is valid but the padlock still isn't clean, you have mixed content. Keep going.

Step 2: Fix the WordPress Site URL Settings

Go to Settings → General in your WordPress admin. Both WordPress Address (URL) and Site Address (URL) must start with https://. Change them and save. WordPress will now generate HTTPS URLs for everything it builds dynamically — but it won't rewrite what's already stored in the database.

Step 3: Add the HTTPS Redirect in .htaccess (Apache) or Nginx Config

Every HTTP request should redirect to HTTPS at the server level so users and crawlers always land on the secure version. For Apache, add this above the WordPress block in .htaccess:

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

For Nginx, add return 301 https://$host$request_uri; inside your server block that listens on port 80. If you're on managed hosting, your host's dashboard may have a one-click "Force HTTPS" toggle — use that and skip manual config edits.

Back up before editing server config files. A syntax error in .htaccess causes a 500 error site-wide.

Step 4: Find All HTTP References With Your Browser Console

Open Chrome DevTools (F12) on the affected page, go to the Console tab, and filter by "mixed content." You'll see exact URLs of every offending resource. Write them down — you need to know whether they're in your database, your theme files, or coming from an external service.

For a broader scan, the free Why No Padlock tool checks a URL and lists every mixed content asset found on the rendered page. Run it on your homepage, then any pages that embed third-party content (contact pages, shop pages, pages with video embeds).

Step 5: Run a Database Search-and-Replace

This is the most impactful step for most sites. Serialized data in WordPress means you cannot use a plain SQL FIND/REPLACE — it will corrupt serialized arrays and break your site. Use one of these safe methods instead:

Option A: Better Search Replace Plugin (Recommended for Most Users)

1. Install and activate the free Better Search Replace plugin.
2. In the Search field enter: http://yourdomain.com
3. In the Replace field enter: https://yourdomain.com
4. Select all tables, check Run as dry run first, and click Replace.
5. Review the count of rows that would change. If it looks reasonable, uncheck dry run and run it for real.
6. Delete the plugin after you're done — it's a powerful tool that should not live on a production site longer than needed.

Option B: WP-CLI (For Developers With SSH Access)

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

Remove --dry-run once you've confirmed the output looks correct. WP-CLI handles serialized data safely.

Step 6: Fix Theme and Plugin Files With Hardcoded HTTP URLs

After the database replace, reload a page and check the console again. Remaining HTTP warnings are almost always coming from theme template files or plugin PHP/CSS files. Use your host's file manager or an SFTP client to search for http:// inside /wp-content/themes/your-theme/ and /wp-content/plugins/. Replace absolute HTTP URLs with either their HTTPS equivalent or a protocol-relative URL (//example.com/resource).

Do not edit files in a parent theme directly — updates will overwrite your changes. If the HTTP reference is in a parent theme, raise it with the theme author or override it via a child theme.

Step 7: Deal With External HTTP Resources

Some HTTP references point to third-party domains you don't control — an embed from an external service, a web font loaded over HTTP, a widget pulling in an insecure script. Your options:

• Check if the third party supports HTTPS — most do. Update the URL in your content or plugin settings.
• Self-host the asset — download the font, script, or image and serve it from your own HTTPS server.
• Remove the embed if the provider doesn't offer HTTPS. A single insecure embed breaks your padlock just as much as a hundred.

Google Fonts is a common source of confusion after migrations. Make sure your theme or plugin is loading the Google Fonts URL over HTTPS (https://fonts.googleapis.com/…), not HTTP.

Step 8: Clear Every Cache Layer

After all changes, clear your WordPress cache (Autoptimize, WP Rocket, W3 Total Cache, LiteSpeed Cache — whatever you have), your CDN cache if you use one (Cloudflare, etc.), and your browser cache. Then re-scan with Why No Padlock and your DevTools console. The padlock should now be clean.

If you're on Cloudflare, also check that your SSL/TLS mode is set to Full (strict) in the Cloudflare dashboard, not Flexible. Flexible mode can appear to work while actually serving HTTP between Cloudflare and your origin server — a security gap that also causes redirect loops.

Preventing Mixed Content in the Future

• Always confirm HTTPS is working on a staging site before migrating to production. See our guide on moving WordPress to a new host without broken links.
• Follow the pre-update checklist before installing plugins or theme updates — some reintroduce hardcoded HTTP paths.
• Use protocol-relative or root-relative asset references in custom theme code rather than absolute URLs.
• Add a Content-Security-Policy: upgrade-insecure-requests header as a safety net — it tells browsers to silently upgrade HTTP sub-resources to HTTPS. It doesn't fix the underlying problem but prevents visible breakage while you audit.
• Run regular scans. A monthly check with Why No Padlock catches new mixed content from freshly added content before users notice.

When to Call a Professional

Most mixed content is fixable in under an hour with the steps above. You may want expert help if:

• The database replace ran but dozens of HTTP URLs still appear from an unknown source.
• Your site broke after editing .htaccess or server config — see how to fix the WordPress 500 error if that happened.
• You're running a WooCommerce store and can't afford to experiment with the live database.
• Mixed content warnings are appearing on checkout or payment pages, where the stakes are highest.

If you're not confident digging into server config and database tables, Mend's Quick Fix service is built for exactly this — a senior engineer will locate every HTTP reference, run the database replace correctly, fix file-level issues, and verify the padlock is clean across your key pages, all on a backup-first workflow with a flat, agreed-up-front price. If it's not fixed, you don't pay.

For larger sites or anything involving a migration gone wrong, a free Diagnosis will triage the full picture and quote a flat price before any work starts — no card required.