Introduction

Mixed content happens when an HTTPS page still loads scripts, styles, images, or requests over plain HTTP. The page may partly render, but modern browsers block or warn on the insecure resources, which can break layouts, tracking, forms, and interactive features.

Symptoms

  • The browser console reports mixed content warnings or blocked requests
  • Padlock icons disappear even though the page uses HTTPS
  • Images may load while scripts or styles fail silently
  • The issue started after forcing HTTPS or moving behind a proxy
  • Only older content, templates, or stored settings seem affected

Common Causes

  • Hard-coded http:// asset URLs remain in templates or content
  • WordPress or application base URLs still reference HTTP
  • Reverse proxy headers do not tell the app the request is already HTTPS
  • CSS, JavaScript, or API endpoints are generated with old absolute URLs
  • CDN or media hosts still serve assets only over plain HTTP

Step-by-Step Fix

  1. Open the browser console on the affected page and list the exact blocked or insecure asset URLs.
  2. Update the application base URL, site URL, or environment variables so new URLs are generated as HTTPS.
  3. Search templates, stored content, and configuration for hard-coded http:// links pointing to local assets or internal endpoints.
  4. If the site is behind a proxy, confirm forwarded protocol headers are trusted so the app knows to generate secure URLs.
  5. Rewrite old media links in the database or CMS only after backing up and confirming the intended hostname.
  6. Check external asset providers, fonts, scripts, and API endpoints to ensure they are available over HTTPS.
  7. Clear application, CDN, and browser caches so you are testing the updated markup rather than stale cached pages.
  8. Reload key pages and confirm the console no longer shows blocked mixed-content resources.
  9. Keep a deployment check for absolute URLs so future theme or template changes do not reintroduce insecure asset links.