Mixed Content After HTTPS: Why Browsers Still Show Not Secure
A practical HTTPS cleanup guide covering mixed content, insecure subresources, and why browsers still show not secure.
Published
May 18, 2026
Reading Time
2 min read
Updated
May 18, 2026
Recovery Playbooks
Restore paths, validation checks, and the gaps teams usually discover too late.
Best For
WordPress administrators, agencies, and platform teams responsible for proving they can recover content and service safely under pressure.
Primary Topics
Editorial Focus
Recovery Drill: Restore paths, validation checks, and the gaps teams usually discover too late. Updated on May 18, 2026.
Full Report
Last reviewed: May 18, 2026
If a site has already moved to HTTPS but the browser still shows Not Secure, mixed content is one of the first things to check. That means the page itself loads over HTTPS while some subresources, such as images, scripts, or stylesheets, still load over HTTP. In the lighter cases the browser upgrades or blocks the request. In the worse cases the page remains partially exposed or breaks visually.
This guide explains what mixed content is, why it survives migrations longer than expected, and what to fix first.
Understand why browsers care
According to MDN, a page is only fully secure when the document and its subresources are loaded over secure channels. An HTTPS page that pulls insecure resources creates an opening for tampering or downgrade behavior, which is exactly what browsers are trying to prevent.
What to inspect first
- Browser console. It usually names the exact insecure resource request.
- Hardcoded asset URLs. Old templates, CMS content, or cached HTML often still point to
http://. - Third-party embeds. External widgets, trackers, or old scripts may still request insecure files.
- Proxy and CDN rewrites. Edge configuration may rewrite some links and miss others.
- Canonical origin settings. The app should consistently generate HTTPS URLs everywhere.
Do not stop at the homepage
Mixed content is often page-specific. One landing page, old article, or legacy asset path can keep the warning alive even if the homepage looks fine. Test templates, archives, article pages, and any pages with embeds or older media.
Common mistakes
- Only checking the padlock on one page. Mixed content can live deeper in the site.
- Fixing the main document URL but ignoring asset generation. The whole resource graph matters.
- Relying on automatic upgrades for everything. Some insecure requests are simply blocked.
- Ignoring third-party resources. External embeds can keep the warning alive.
Production checklist
- Use the browser console to identify the exact insecure requests.
- Replace hardcoded HTTP asset URLs with HTTPS or protocol-safe generation.
- Recheck legacy pages, embeds, and older content.
- Confirm origin and CDN rules generate HTTPS consistently.
- Retest multiple templates after the cleanup.
