Fix "Mixed Content: ... This request has been blocked"

Mixed Content: The page at 'https://example.com/' was loaded over HTTPS, but requested an insecure script 'http://example.com/js/app.js'. This request has been blocked; the content must be served over HTTPS.

Common causes

• Hard-coded http:// URLs in theme files, templates or JavaScript
• Old http:// links stored in the database after moving a site to HTTPS
• WordPress home and siteurl options still set to http://
• Third-party embeds or CDNs referenced with http:// or that do not support HTTPS
• The app is behind a proxy or CDN and builds URLs with http:// because it does not see the original HTTPS scheme
• API base URLs in .env or front-end config still using http://

How to fix it

1. List the blocked URLs. Open DevTools > Console and note each Mixed Content message, or check the Security panel. Each message gives the exact http:// URL to fix.
2. Fix site URLs. In WordPress set Settings > General URLs to https://, or define WP_HOME and WP_SITEURL in wp-config.php. In other apps update APP_URL or the base URL setting.
3. Replace http:// in the database. Run a serialization-safe replacement, for example wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-run, then without --dry-run. Back up first.
4. Fix templates and scripts. Search the codebase with grep -rn "http://" wp-content/themes/your-theme and change asset links to https:// or root-relative paths.
5. Tell the app it is behind HTTPS. Behind a proxy, configure trusted proxies so the app reads X-Forwarded-Proto, for example $_SERVER['HTTPS'] = 'on' when that header is https in wp-config.php.
6. Add upgrade-insecure-requests as a safety net. Send Content-Security-Policy: upgrade-insecure-requests so browsers fetch remaining http:// same-site resources over HTTPS. It only works if those resources are actually available over HTTPS.

WP-CLI + HTTP header

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

# Nginx
add_header Content-Security-Policy "upgrade-insecure-requests" always;

How to stop it happening again

• Use https:// or root-relative URLs for all assets
• Run a full database search and replace when migrating to HTTPS
• Check the console for mixed content after adding plugins or embeds
• Enable HSTS once the whole site works over HTTPS