How to Fix Mixed Content Warnings After Installing an SSL Certificate

You finally installed your SSL certificate, forced HTTPS across the whole site, and then the dreaded message appears in the browser console: Mixed Content: The page at ‘https://yoursite.com’ was loaded over HTTPS, but requested an insecure resource. The padlock is gone, the warning icon shows up, and your client is calling. Sound familiar?

This guide is built for developers and site owners who just enabled SSL and now need a practical, no-nonsense way to hunt down every insecure asset and patch it for good. We will go beyond the usual “install a plugin” advice and cover database search-replace, source code audits, and Content-Security-Policy headers.

What Is a Mixed Content Warning on an SSL Site?

A mixed content warning happens when a page is served over HTTPS but loads one or more sub-resources (images, scripts, stylesheets, fonts, iframes, XHR endpoints) over plain HTTP. Because part of the traffic is unencrypted, an attacker on the same network could intercept or modify those resources, breaking the security guarantees the SSL certificate is supposed to provide.

Browsers split mixed content into two categories, and they behave very differently:

Type	Examples	Browser Behavior
Passive (display)	Images, audio, video	Loaded, but padlock is removed and a warning is logged
Active	Scripts, stylesheets, iframes, XHR/fetch, web fonts	Blocked outright by modern Chrome, Firefox, Edge and Safari

Since 2020 onward, browsers have been auto-upgrading or blocking most mixed content by default, so in 2026 even a single insecure script can break your layout completely.

Step 1: Identify the Insecure Resources

Use Browser DevTools (the fastest method)

Open the page in Chrome or Firefox, press F12, and look at the Console tab. Mixed content errors are clearly labeled. You will typically see something like:

Mixed Content: The page at 'https://vibemidia.com/blog' was loaded over HTTPS, 
but requested an insecure image 'http://cdn.example.com/logo.png'. 
This content should also be served over HTTPS.

For a complete inventory, switch to the Network tab and:

1. Reload the page with cache disabled
2. Click the filter input and type scheme:http (Chrome) or sort by Protocol
3. List every request still using HTTP

Use an Online Mixed Content Checker

For bulk scanning across many URLs, these tools save hours:

• whynopadlock.com – single page deep scan
• httpschecker.net – crawls multiple URLs
• Screaming Frog SEO Spider in HTTPS mode with the “Insecure Content” report

Check the HTML Source Directly

Right-click and “View Page Source”, then search for http://. Ignore anchor links (those are fine), focus on src=, href= on stylesheets, action= on forms, and url() inside inline styles.

Step 2: Fix Mixed Content in the Database (WordPress, Magento, Drupal)

Most CMS-based sites store full URLs in the database. After SSL migration, those URLs still point to http://. A targeted search-replace is the cleanest fix.

WordPress

Use WP-CLI from SSH, which handles serialized data correctly (something a raw SQL query will break):

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

If you do not have CLI access, use the Better Search Replace plugin and always run a dry run first.

Magento 2

UPDATE core_config_data SET value='https://yoursite.com/' WHERE path='web/unsecure/base_url';
UPDATE core_config_data SET value='https://yoursite.com/' WHERE path='web/secure/base_url';
bin/magento cache:flush

Drupal

Use the Search and Replace Scanner module or Drush with a custom script. Always back up the database before running any replace operation.

Step 3: Fix Hardcoded URLs in Theme and Template Files

Database fixes won’t catch URLs written directly into theme files, JavaScript bundles, or third-party widgets. Run a recursive grep on your codebase:

grep -rn "http://yoursite.com" /var/www/html/
grep -rn "http://" /var/www/html/wp-content/themes/your-theme/

Common culprits to inspect:

• header.php and footer.php – hardcoded logo, tracking pixels
• functions.php – enqueued scripts using http://
• Custom widgets and shortcodes
• JavaScript files calling external APIs over HTTP
• CSS files with background-image: url(http://...)

The safest replacement pattern is protocol-relative URLs when you cannot guarantee the resource hostname:

// Bad
<script src="http://cdn.example.com/lib.js"></script>

// Better (if cdn.example.com supports HTTPS)
<script src="https://cdn.example.com/lib.js"></script>

// Acceptable fallback
<script src="//cdn.example.com/lib.js"></script>

Step 4: Handle Third-Party Resources You Cannot Edit

Sometimes the insecure URL comes from an external partner, an old advertising network, or a legacy API. Your options:

1. Check if the provider offers HTTPS – 99% of legitimate services do in 2026
2. Proxy the resource through your own server using a reverse proxy or a serverless function
3. Replace the provider if they refuse to support HTTPS
4. Self-host the asset when licensing allows

Step 5: Use HTTP Headers to Enforce HTTPS Site-Wide

Upgrade-Insecure-Requests

Add this Content-Security-Policy directive to automatically upgrade any HTTP request to HTTPS at the browser level:

Content-Security-Policy: upgrade-insecure-requests;

In Apache (.htaccess):

Header set Content-Security-Policy "upgrade-insecure-requests;"

In Nginx:

add_header Content-Security-Policy "upgrade-insecure-requests;";

Block-All-Mixed-Content (legacy but still useful)

If you want the browser to refuse any remaining mixed content rather than upgrade it, use:

Content-Security-Policy: block-all-mixed-content;

HTTP Strict Transport Security (HSTS)

Once everything is clean, lock HTTPS in permanently:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Warning: Only enable HSTS after you are 100% sure HTTPS works on every subdomain. It is sticky and hard to roll back.

Step 6: Verify and Monitor

After every change, re-test:

• Hard refresh in an incognito window (cache lies)
• Run SSL Labs test for the certificate chain
• Use the report-uri directive in CSP to collect violations in production
• Set up a weekly automated crawl with Screaming Frog or a custom Puppeteer script

Example CSP with reporting:

Content-Security-Policy: upgrade-insecure-requests; report-uri https://yoursite.com/csp-report;

Common Mistakes That Bring Mixed Content Back

• Importing a staging database into production without re-running search-replace
• Pasting old embed codes from YouTube, Vimeo or social platforms using http://
• Page builders (Elementor, Divi) caching old URLs in their own meta fields – regenerate CSS after the fix
• CDN configurations pointing to HTTP origins
• Forgetting to update siteurl and home in wp_options

Quick Troubleshooting Checklist

Symptom	Likely Cause	Fix
Padlock missing, no console error	Passive mixed content (image)	Search-replace in DB
Layout broken after SSL	Blocked stylesheet or script	Update enqueue URLs in theme
Forms not submitting	Form action over HTTP	Edit template or plugin settings
Videos not playing	HTTP iframe embed	Update embed to HTTPS
Random AJAX failures	XHR endpoint over HTTP	Update API base URL in JS

FAQ

Why does my site still show a mixed content warning after I fixed everything?

Browser and CDN caching are the usual suspects. Clear your CDN cache, flush your CMS cache, and test in a private window. If the warning persists, scan again with a fresh tool because something was likely missed.

Is upgrade-insecure-requests a replacement for fixing URLs?

No. It is a safety net, not a solution. The CSP directive only works when the destination actually supports HTTPS. If http://cdn.example.com/file.js does not exist over HTTPS, the upgrade will fail. Always fix the source URLs first.

Can I just allow mixed content in Chrome to make the warning go away?

You can for local testing, but never recommend this to visitors. Allowing mixed content disables the very protection SSL is meant to provide and most users will not change their browser settings anyway.

Does mixed content hurt SEO?

Yes, indirectly. Google rewards fully secure sites, and a broken padlock damages user trust which increases bounce rates. Blocked scripts can also break critical rendering, hurting Core Web Vitals.

Should I use protocol-relative URLs in 2026?

Generally no. Since HTTPS is the default everywhere now, hardcoding https:// is clearer, slightly faster, and avoids edge cases when the page is opened locally over file://.

Final Thoughts

Fixing a mixed content warning SSL issue is rarely about one big problem. It is about systematically hunting down dozens of small ones across the database, theme files, third-party integrations, and HTTP headers. Follow the steps above in order, automate the verification, and ship a CSP policy to keep regressions away. Your padlock will stay green and your users will stay safe.

Need help auditing your post-migration SSL setup? The team at Vibe Midia handles full HTTPS migrations and security hardening for production sites every week. Get in touch and we will run a free mixed content audit on your domain.