A mixed content warning means your page loaded over https:// but is pulling in an image, script, stylesheet, or font over plain http://. Browsers flag this because the insecure resource breaks the security guarantee of the padlock. Find the hardcoded http:// reference in your site's code or database and change it to https://, or better, a protocol-relative or root-relative path.
Why this happens after adding SSL
Mixed content shows up most often right after a site moves from HTTP to HTTPS. The certificate secures the connection, but any content still pointing at the old http:// URLs doesn't automatically get rewritten. Common sources: images uploaded years ago with an absolute URL baked in, a theme or plugin setting that stores a full URL instead of a relative path, embedded YouTube or Google Maps iframes copied from old code, and third-party scripts (ad tags, widgets, analytics) that still hardcode http://.
Browsers treat two kinds of mixed content differently. "Mixed passive content" (images, video, audio) usually still loads but shows a warning in the address bar. "Mixed active content" (scripts, stylesheets, iframes, fonts) is blocked outright by modern browsers, which is why it tends to break page functionality, not just trigger a warning icon.
Finding the insecure references
Open your site in Chrome or Firefox, load the affected page, and open DevTools (F12) to the Console tab. Every blocked or flagged resource is logged with its exact URL, which tells you precisely what to fix instead of guessing.
For WordPress sites, the most common culprit is the wp_options table storing an http:// siteurl or home value, or post content with hardcoded image URLs from an old migration. You can search your database for lingering http://yourdomain.com references using phpMyAdmin's search feature on most hosting accounts, or a search-replace plugin. If you're comfortable with SQL, a direct search-and-replace across wp_posts and wp_options is faster than paging through pages by hand, but always export a backup first.
For static HTML or custom-built sites, grep your source files for http:// and check each match against your own domain versus legitimate third-party resources that may not support HTTPS at all (in which case they need to be replaced or removed, not just rewritten).
Fixing the references
Once you've found the hardcoded links, use a protocol-relative or root-relative URL rather than assuming https:// forever:
- Change
http://yourdomain.com/wp-content/uploads/image.jpgto/wp-content/uploads/image.jpgso it inherits whatever protocol the page loaded with. - For third-party embeds (maps, video players, widget scripts), check the provider's documentation for an
https://version of their embed code and swap it in directly. - If a third-party resource genuinely has no HTTPS option, it needs to be self-hosted or dropped. There's no way to safely embed an HTTP-only resource on an HTTPS page.
After editing, clear any caching layer sitting in front of your site so you're not looking at a stale version, then reload the page in an incognito window to confirm the warning is gone.
When the certificate itself is the problem
Mixed content warnings are about page content, not the certificate. But if you're also seeing certificate errors alongside the mixed content warning, confirm your SSL is actually active and DNS is pointed correctly, and rule that out as a separate issue first.
When to contact support
If you've swapped every hardcoded http:// reference you can find and the browser console still flags a resource, or you're not sure which plugin or theme setting is generating the insecure URL, open a ticket from the portal's Support section. A real person can trace the specific resource that's triggering the warning and point you to where it's coming from.