Surprising fact: over 40% of sites that enable HTTPS still show a broken padlock because a few resources load over HTTP.
This guide shows how you stop that scary browser message and restore the secure padlock for your visitors. You’ll learn quick checks in the address bar and DevTools so you spot warnings or error items fast.
Free certificates are common now, and simple plugins can rewrite links automatically. For tougher cases, you can bulk-update your database after a full backup and add server rules that force a secure connection.
We also cover caching — browser, CDN, and builder caches can keep old HTTP assets alive. You’ll get practical steps to regenerate CSS in page builders so nothing stays stale and the site shows a clean https connection.
Key Takeaways
- Spot warnings in the address area and DevTools to find every error quickly.
- Use a plugin for automatic URL rewriting, and step up levels only when needed.
- Bulk-update HTTP to HTTPS in the database after backing up your website.
- Force HTTPS at the server and use upgrade-insecure-requests for modern browsers.
- Clear all caches and regenerate builder CSS to remove stale assets.
- HSTS helps, but you must update HTTP URLs to truly remove issues.
What “mixed content” means in 2025 and why it hurts trust, SEO, and security
A single non-secure asset can turn a safe-looking URL into a broken trust signal for your visitors.
Mixed content happens when an HTTPS page loads resources over plain HTTP. Modern browsers now auto-upgrade images and some media, but they block risky items like scripts and styles to protect users.
Padlock basics: secure vs. not secure messages in the address bar
The padlock and the address bar are quick trust checks. A green padlock signals a secure connection and boosts conversions.
If any blocked resource exists, the browser shows a broken padlock or a “Not secure” message. That visual cue is a content warning your visitors notice instantly.
How mixed items lead to blocked scripts, broken layouts, and ranking drops
When a script is blocked you can lose functionality and layout. The Console will show exact errors like “This request has been blocked; the content must be served over HTTPS.”
Search engines use security signals in rankings, so these warnings can lower your site visibility. In short, mixed content warnings cause UX issues, tracking risks, and SEO drops.
“The console and Security panel point to the exact resource causing the problem, letting you address the root cause.”
| Symptom | Browser Behavior | Impact |
|---|---|---|
| Image uses HTTP | Often auto-upgraded | Visual OK, small risk |
| Script uses HTTP | Blocked by default | Broken features, errors |
| Stylesheet uses HTTP | Often blocked | Layout problems, UX loss |
| Mixed asset found | Padlock shows warning | Trust and SEO decline |
- Quick tip: use the Console to map the error to the resource URL and fix the address at the source.
- Full HTTPS everywhere is the modern expectation; anything less triggers warnings and risks your connection with visitors.
Spot the problem fast: finding mixed content warnings in your browser
Quick checks in your browser reveal the exact insecure assets causing the broken padlock. Start with a short inspection and you’ll know whether images, scripts, or styles are to blame. Use the browser tools before you chase server rules or database changes.
Use Chrome DevTools to pinpoint insecure files
Open DevTools and go to the Console to see blocked or auto-upgraded requests. The Security panel lists non-secure origins so you can spot any HTTP resources quickly.
In Network, filter for failed or blocked requests to catch styles or scripts the browser refused to load. Note that Chrome (since version 79) blocks risky items by default and may auto-upgrade some images and media.
Check Firefox and Edge behavior
Firefox and Edge show similar warnings but use slightly different phrasing. The cure is the same: update the HTTP URLs to HTTPS so the site runs fully and the padlock returns.
Quick scanners to save time
Use fast tools when you need a scan across multiple pages. Why No Padlock gives a quick list of insecure items. JitBit SSL Check and HTTPS Checker crawl many pages to reveal patterns you might miss during manual testing.
Ahrefs Site Audit’s HTTPS checks are useful if you already run audits regularly. Inside WordPress, the SSL Insecure Content Fixer plugin can reveal and rewrite problematic URLs for quick wins.
Reading the message: auto-upgraded vs. blocked requests
- Console shows whether a request was auto-upgraded or completely blocked.
- Auto-upgraded images may look fine but scripts blocked in the Console break functionality.
- Use the address bar and DevTools together to confirm the page is fully secure.
“Start in the Console — it points to the exact URL that caused the error and speeds up your search.”
mixed content ssl fix wordpress using a plugin (SSL Insecure Content Fixer)
Start by installing the SSL Insecure Content Fixer plugin from your dashboard. Activate it, then open Settings → SSL Insecure Content to see the options.
Choose the right fix level
Begin with Simple. It targets scripts, styles, and media and has minimal performance impact.
If problems remain, step up to Content or Widgets.
Use Capture or Capture All only when needed. These scan header-to-footer and may slow your site.
Detection, scope, and testing
Set HTTPS detection for Cloudflare or Nginx if your stack sits behind a proxy. Use the default detection otherwise.
Enable plugin/theme-specific options when you recognize those tools on your website. Turn on “Only fix content pointing to this site” to avoid rewriting third-party links.
| Action | When to use | Impact |
|---|---|---|
| Simple | First pass | Fast, low risk |
| Widgets / Content | Still see warnings | Wider rewrite, moderate cost |
| Capture / Capture All | Persistent issues | Most aggressive, can slow site |
Save settings, clear any cache, and re-test pages in the browser Console. If warnings persist, move up one level and repeat. Keep the least aggressive level that solves your issues to preserve performance.
Manually update hard-coded HTTP links to HTTPS across your site
If plugin tools don’t clear every warning, you must update hard-coded URLs yourself. Start with a full backup so you can roll back if something goes wrong.
Better Search Replace is the easiest way to update your database safely. Go to Tools → Better Search Replace, enter http://yourdomain.com in Search for and https://yourdomain.com in Replace with.
Run a Dry run first to confirm the matches. If results look correct, select all tables and run the real replace. This converts old absolute links across your database and fixes lingering mixed content errors.
When manual file edits are needed
Some external scripts or theme files won’t change via database search. Check header/footer templates, plugin templates, and any hard-coded scripts like hosted jQuery or icon kits.
Edit those files to use HTTPS or protocol-relative URLs, then test pages in the Console to ensure no errors remain.
“Always test with a dry run and keep a changelog of edits so you can undo steps if needed.”
| Action | When to use | Result |
|---|---|---|
| Dry run (Better Search Replace) | Before making changes | Preview matches, avoid mistakes |
| Real replace (all tables) | After verification | Updates URLs across database |
| Manual file edits | External scripts or templates | Fixes hard-coded http links |
Enforce HTTPS at the server level with .htaccess and security headers
A server-level redirect is the fastest way to send every visitor to the secure version of your site. Implementing redirects and headers at the host removes many browser warnings before the page loads.
Edit the .htaccess file in your site root and add these lines:
This forces a 301 redirect to https and asks modern browsers to upgrade eligible http requests automatically.
301 redirects with Apache RewriteRules
Add the RewriteEngine block near the top of .htaccess to avoid conflicts. Keep the rules minimal so you don’t create loops with other rewrite settings.
Upgrade-Insecure-Requests via Content-Security-Policy header
The CSP header with upgrade-insecure-requests tells browsers to attempt secure versions of assets. It helps reduce visible errors, but it doesn’t replace updating hard-coded http URLs in your codebase.
- Test pages after saving and clear caches so DevTools shows current results.
- If your host uses Nginx, apply equivalent server rules rather than editing .htaccess.
- If you proxy through Cloudflare or an edge, apply redirects at the edge for a faster redirect way.
- Verify the address bar lock and confirm the Security panel reports a full secure connection.
“Place rules carefully to avoid conflicts with existing directives and then confirm the padlock appears across your website.”
Pro tips: caching, CDNs, and special cases that trigger stubborn errors
After you update URLs, caches and generated files often keep old http assets alive. Clear every layer so the browser and CDN serve the new secure links.
Purge all caches: clear your plugin cache, host cache, and CDN zones. Then clear your browser cache so old files don’t keep resurfacing. If you use Cloudflare, set SSL mode to “Full” or “Full (strict)” and purge its cache.
Regenerate builder files: page builders like Elementor create generated CSS and asset files. After URL changes, regenerate those files so generated URLs point to https and not stale sources.
If warnings persist, run a bulk scan with tools such as Why No Padlock, JitBit SSL Check, Ahrefs, or HTTPS Checker. These scans find stubborn scripts, widget assets, or absolute paths that database search-and-replace can miss.
- Double-check plugin settings that store absolute addresses and update them to https.
- Database replacements can miss externally hosted scripts — edit those in theme or plugin files directly.
- Watch the Console after each pass to confirm the number of warnings drops.
- If you expect brief visual hiccups, add a maintenance banner so visitors know you’re working on the site.
“HSTS enforces HTTPS in the browser over time, but it won’t rewrite bad links — you still must update the underlying URLs.”
Conclusion
Close the loop: find the last warning in the Console, correct any http resource at its source, and reload until the error disappears.
Start with the insecure content fixer plugin at the lowest level, then back up and run a careful database search-replace. Add server redirects and the CSP upgrade-insecure-requests header to catch stray hits.
Clear all caches and regenerate builder CSS so generated files use https. Re-scan for mixed content warnings and update theme or plugin files that a database pass can’t reach.
When every address shows the padlock, you’ve resolved the issue. Make this a quick post-update check to keep your site secure and visitors confident.
FAQ
What does “mixed content” mean and why should you care?
Mixed content happens when a page served over HTTPS still loads resources over HTTP. That can remove the padlock in the address bar, trigger browser warnings, break scripts or layout, and hurt search rankings. Fixing it restores trust and secures visitor connections.
How can I spot insecure resources quickly in my browser?
Open Chrome DevTools and check the Console and Security panels for blocked or upgraded requests. The Network tab shows which requests use HTTP. Firefox and Edge show similar warnings, so test across browsers to catch all issues.
Can a plugin solve these issues without touching code?
Yes. The SSL Insecure Content Fixer plugin can correct many requests by choosing levels like Simple, Content, Widgets, Capture, or Capture All. Activate it, pick a level, clear caches, and revisit pages to see if warnings disappear.
When should you perform a find-and-replace in the database?
Use a find-and-replace tool like Better Search Replace after you make a full backup. This is ideal for updating hard-coded http:// links in posts, meta, and serialized data. Test on a staging site first to avoid breaking serialized strings.
What server-level measures should you use to enforce HTTPS?
Implement 301 redirects in .htaccess or your web server config to send HTTP traffic to HTTPS. Add security headers such as Content-Security-Policy with upgrade-insecure-requests and consider HSTS once you’re sure all resources load securely.
How do CDNs and caching affect warnings?
Cached or CDN-served assets can keep serving old HTTP URLs. Clear your WordPress cache, purge CDN zones, and ensure the CDN origin and cached objects use HTTPS. Then reload and re-audit pages.
Why do some builder plugins still show issues after changes?
Page builders like Elementor store static CSS or inline URLs. After switching to HTTPS you may need to regenerate CSS, re-save templates, and clear builder-specific caches to update embedded links.
What about sites behind Cloudflare, Nginx, or reverse proxies?
Configure HTTPS detection in your plugin and server so code sees the original protocol. For Cloudflare, use “Full” or “Full (strict)” SSL and set the plugin to respect X-Forwarded-Proto or CF-Visitor headers to avoid misdetection.
Is HSTS enough to fix insecure resource loading?
No. HSTS forces browsers to use HTTPS but doesn’t rewrite insecure resource URLs on your pages. Fix the source URLs or use CSP upgrade-insecure-requests; then consider HSTS to strengthen future connections.
How do I handle third-party scripts that load over HTTP?
Replace them with HTTPS versions from the vendor, host the resource locally if allowed, or contact the provider. As a last resort, remove the script to avoid warnings and protect your visitors’ secure sessions.
What steps should I take if warnings persist after changes?
Clear all caches (site, object, browser), purge CDN, re-run DevTools checks, and try stricter plugin levels or manual URL checks. Review theme and plugin files for absolute URLs and re-test until the address bar shows a secure padlock.
Which tools help automate scanning for insecure URLs?
Use site scanners like SSL Check, No Padlock, and online site audits plus browser DevTools. These help list HTTP requests, blocked resources, and give a fast inventory of files you must update.
