Mixed Content Warning After SSL? How to Fix It (2026)

You installed an SSL certificate. The padlock should be green. Instead, your browser still says "Not Secure" — and a mixed content warning is hiding in the console. Here's the good news: your certificate is almost certainly fine. The page loads over HTTPS; a few stray files — an image, a script, a font — are still loading over plain HTTP. That's the whole problem. This guide shows you how to find every insecure resource and clear the warning for good, whether you run WordPress, custom PHP, or a site behind a CDN, without breaking anything.

Quick Answer: A mixed content warning appears when an HTTPS page loads at least one resource — image, script, stylesheet, font, or iframe — over HTTP. Your SSL certificate isn't broken. The real cause is old http:// URLs still sitting in your database, theme files, or third-party embeds. Fix it by listing those URLs in your browser console, then switching each one to https:// or a protocol-relative path.

What a Mixed Content Warning Actually Means

Picture HTTPS as a sealed envelope. Every asset on the page is meant to travel inside it, encrypted over port 443. A mixed content warning fires the second one asset tries to travel in the open over port 80 instead — readable by anyone sitting on the network between you and your visitor.

Browsers sort this into two buckets, and the difference matters more than people think.

• Active mixed content — scripts, stylesheets, iframes, AJAX calls. These can rewrite your entire page, so Chrome and Firefox simply block them. Layouts collapse, JavaScript dies, checkout forms quietly stop submitting.
• Passive mixed content — images, audio, video. Lower risk, so browsers usually load them but strip the padlock and slap on the "Not Secure" label.

Neither one means your certificate failed. Ever since Chrome 68 shipped in July 2018, browsers have flagged non-HTTPS resources hard — so a single forgotten http:// logo can sink the padlock on an otherwise flawless install.

On our own Nginx → Apache stack at Hostaccent, the SSL tickets we see after an install almost never trace back to the certificate. They trace back to leftover HTTP resources on HTTPS pages — usually a hardcoded image or an aging plugin embed. Encryption was never the issue. The old URLs were.

Why You Still See 'Not Secure' After SSL

Installing a certificate encrypts the connection. It does not rewrite a single URL inside your content. So every http:// link you saved before going secure is still sitting there, quietly producing the dreaded not secure after SSL message. Here are the causes, ranked by how often they actually show up.

1. Hardcoded image and logo URLs in your database (by far the most common). Old posts, page-builder blocks, and your media library still reference http://yoursite.com/logo.png. This single cause outnumbers all the others.

2. Theme and plugin files. A theme header, footer, or stylesheet hardcodes an HTTP asset — a web font, an icon set, a tracking pixel.

3. Third-party embeds. Aging sliders, video embeds, web fonts, chat widgets, or ad scripts that still call out over HTTP.

4. CDN or proxy misconfiguration. If your CDN sits in "Flexible SSL" mode, it talks HTTPS to the visitor but HTTP back to your origin — guaranteed mixed content. Switch it to Full (strict).

5. Browser or server cache. You fixed everything, yet you're staring at a cached copy. This one fools people constantly, so we'll come back to it.

Pro Tip: Don't reach for a "fix everything" plugin first. Those rewrite URLs on the fly for every single request, which adds overhead and buries the real problem still living in your database. Use one as a temporary bandage during a migration — never as the permanent cure.

How to Find Every HTTP Resource on Your HTTPS Site

You can't fix what you can't see. Spend two minutes here before you touch anything.

Open the page over HTTPS, then:

1. Press F12 (or right-click → Inspect) and open the Console tab. Mixed content errors print the exact offending URL — red for blocked active content, yellow for passive.
2. Switch to the Network tab, reload, and sort by scheme or filter for http://. Every insecure request lands here.
3. For a whole-site sweep, run a free crawler like Why No Padlock or JitBit's SSL Check (most cap free scans around 400–500 pages).

Screenshot or copy every http:// URL you find. That list is your to-do list — nothing more, nothing less.

Step-by-Step: Fix Mixed Content on Any Website

With your list in hand, work top to bottom. This order is the fastest stable path we've found.

Step 1 — Force HTTPS at the server. Make sure every visitor lands on HTTPS through a single 301 redirect. On Apache, add this to .htaccess:

bashCopy
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

On Nginx, redirect port 80 to 443 in your server block:

bashCopy
server {
    listen 80;
    server_name yoursite.com www.yoursite.com;
    return 301 https://$host$request_uri;
}

A botched rule here is a classic trigger for 403 Forbidden errors, so always test in a private window after you save.

Step 2 — Update the hardcoded URLs. Swap each http:// reference for https://, or use a protocol-relative path (//yoursite.com/logo.png) so the asset just matches whatever the page is already using. Edit theme files over SFTP and update embeds in your editor.

Step 3 — Add a transition safety net with CSP. The upgrade-insecure-requests directive tells browsers to auto-promote HTTP requests to HTTPS:

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

Start with Content-Security-Policy-Report-Only so you can watch what would break before you enforce it. One caveat: this masks the noise — it is not a replacement for fixing the source URLs.

How to Fix Mixed Content WordPress Sites

WordPress scatters absolute URLs all through the database, so it needs its own quick routine. (If a 500 pops up mid-edit, that's almost always a syntax slip — here's how to clear a 500 Internal Server Error in WordPress before you carry on.)

1. Set the URLs. Go to Settings → General and change both WordPress Address and Site Address to https://. If those fields are greyed out, they're hardcoded in wp-config.php via WP_HOME / WP_SITEURL — edit them there instead.
2. Run a database search-replace. Use the Better Search Replace plugin (or WP-CLI) to swap http://yoursite.com → https://yoursite.com across every table. Back up first, every time.
3. Clear every cache. Page cache, object cache, CDN cache, browser cache — all of them.
4. Last resort: a plugin. Really Simple SSL or SSL Insecure Content Fixer will catch stragglers, but treat them as a patch on top of the real fix, not the foundation.

In the migration tickets our team handles at Hostaccent, the single most common WordPress offender is a logo hardcoded with http:// in the theme header. Fix that one line and the padlock usually goes green on the spot.

Insider Insight: WooCommerce checkout pages deserve their own test. A blocked payment-gateway script throws no visible layout error — the form just silently refuses to submit, and you lose the sale without ever seeing a warning on screen. Always run a real test transaction over HTTPS once you think you're done.

How to Confirm the Fix and Stop It Coming Back

Don't trust one page load. Caches lie. Here's how to verify properly, as of 2026:

• Hard-refresh in incognito (Ctrl+Shift+N) to dodge cached copies, then re-check the console — zero warnings is the only acceptable result.
• Re-scan the whole site with your crawler, not just the homepage.
• Pick one canonical domain (www or non-www) and 301 everything else to it — inconsistent hostnames quietly reintroduce mixed content. (Still deciding on the domain itself? Our .com vs .net vs .io guide covers that side.)
• Set your CDN to Full (strict) with a valid certificate at the origin. "Flexible" mode is the silent killer here — learn how the encryption layer actually works at Cloudflare's SSL guide.

When our team clears one of these tickets at Hostaccent, the final step is always a re-test of checkout and contact forms across two browsers — that's where the last stubborn embed usually hides.

Once the site is 100% HTTPS — and only then — turn on HSTS to force TLS on every future visit:

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

That max-age is one year in seconds. Don't switch it on before you're fully clean, or you'll lock visitors out of any page that still depends on HTTP.

Last piece: automate your certificates. A free, auto-renewing SSL (Let's Encrypt issues 90-day certs that renew themselves) means an expired cert never re-triggers this mess. And if you're choosing infrastructure, edge-terminated SSL on a properly tuned server — like a high-performance EU VPS — keeps the whole path encrypted from origin to browser.

Keep Your Padlock Green

A mixed content warning looks alarming and fixes easy. Three things to carry away:

• Your certificate isn't broken — old http:// URLs are. That's almost always the entire story.
• Find them in the console, replace each with https://, then clear every cache.
• Lock it in with Full (strict) SSL, HSTS, and an auto-renewing certificate.

If you'd rather not babysit SSL at all, that's the real case for managed hosting. Hostaccent Limited — a UK-registered host running since 2018, with a Bangladesh branch and customers worldwide — bundles free auto-renewing SSL and forced HTTPS on every plan, starting with the Economy Linux Shared Hosting plan at $1.99/yr. To be straight with you: it won't rewrite a hardcoded URL buried in your own theme — nothing can do that part for you — but it takes the certificate, renewal, and redirect headaches off your plate entirely.

Frequently Asked Questions

Why does my site still say 'Not Secure' after I installed an SSL?

Because the certificate only encrypts the connection — it doesn't rewrite the URLs inside your content. If any image, script, or font still loads over http://, the browser drops the padlock. Find those resources in your console and switch each one to https://.

What is a mixed content warning, exactly?

A mixed content warning means an HTTPS page is pulling at least one resource over insecure HTTP. Active content like scripts and stylesheets gets blocked outright; passive content like images loads but breaks the padlock. Both should be fixed so the page is fully encrypted and trusted.

How do I fix mixed content in WordPress fast?

Set both URLs to https:// under Settings → General, run a database search-replace with Better Search Replace, then clear all caches. Back up first. A plugin like Really Simple SSL can mop up stragglers, but updating the database is the durable fix.

Will a mixed content warning hurt my SEO?

Yes, indirectly. Google favours fully secure pages, and a broken padlock erodes visitor trust, which drags on conversions and engagement. Active mixed content can also block analytics or A/B-testing scripts, so you lose measurement data on top of the ranking signal.

Do I need a dedicated IP or a special certificate to fix this?

No. Thanks to SNI, modern servers run many HTTPS sites on one IP, each with its own certificate. A standard free certificate is plenty. Hosts like Hostaccent issue auto-renewing SSL by default, so the certificate side is rarely where the problem lives.

Is the CSP upgrade-insecure-requests directive enough on its own?

It helps during a migration by auto-upgrading HTTP requests, but treat it as a safety net, not a cure. It hides the symptom while the bad URLs stay in your database. Fix the source URLs first, then keep the directive around as backup.