GMax Mart
Home Services Pricing Portfolio FAQ Reviews Blog Support Careers Change Language

Trust & Credibility

Mixed content warnings: why the secure padlock disappears

· 6 min read

Mixed content warnings: why the secure padlock disappears

A common support call goes like this: the SSL certificate was installed last week, the site loads with https:// in the address bar, and yet the browser shows a “not fully secure” notice or a broken icon on some pages. The certificate is fine. The problem is that the page still pulls in images, scripts or fonts over plain HTTP. These mixed content warnings are easy to fix once you know where to look, and this guide walks through finding and removing every insecure reference.

What mixed content actually is

When a page is delivered over HTTPS, the browser expects everything that page loads to be encrypted as well. If the HTML arrives securely but an image tag points to http://example.com/banner.jpg, part of the page travelled unprotected. Someone intercepting the connection could swap that file or, worse, inject code.

Browsers group insecure resources into two broad types, and treat them very differently.

Passive or display content

Images, audio and video are considered lower risk because they cannot directly change the rest of the page. Modern Chrome tries to upgrade these requests to HTTPS automatically. If the file is not available over HTTPS, it fails to load, leaving a broken image. Older or other browsers may load it but downgrade the security indicator.

Active content

Scripts, stylesheets, iframes and requests made by JavaScript can rewrite the whole page. Browsers block these outright on HTTPS pages. The symptom is often not a warning at all but a feature that silently stops working: a slider freezes, a map is blank, or a form will not submit.

Why the problem appears after moving to HTTPS

Most sites were built when HTTP was normal, so full addresses got hard-coded everywhere. Typical sources include:

  • Image paths saved inside blog posts and product descriptions in the database.
  • Theme files that reference a logo, background or font with an absolute http:// address.
  • Old embed codes for videos, maps, chat widgets or payment buttons copied years ago.
  • Site settings such as the “site URL” in a CMS still set to the HTTP version.
  • CSS files containing url(http://...) for background images or web fonts.
  • Third-party scripts from a provider that no longer exists or never supported HTTPS.

Because these references live in so many places, one search and replace in a single file rarely catches them all.

How to find mixed content warnings on your pages

Start with the tools already inside your browser, then scale up if the site is large.

  1. Open Chrome DevTools with F12 and switch to the Console tab. Reload the page. Each insecure request appears as a message beginning “Mixed Content”, naming the exact file URL and whether it was blocked or auto-upgraded.
  2. Check the Network tab. Filter by “http:” to see every request that did not use HTTPS, including ones triggered later by scripts.
  3. View the page source and search for “http://”. Ignore plain text links to other websites; focus on src, href for stylesheets, and CSS url() values.
  4. Test several templates, not just the home page. A product page, a blog post, the checkout and the contact page often use different components.
  5. Use a site crawler for larger sites. Many SEO crawling tools can report insecure resources across hundreds of pages in one pass.

Keep a simple list of every offending URL and the page it appeared on. Patterns will emerge quickly, and they tell you whether the fault is in content, theme or settings.

Fixing hard-coded HTTP URLs

The fix depends on where the reference lives. Always take a full backup of files and database before bulk changes.

In the database

For WordPress sites, the WP-CLI command wp search-replace updates http://yourdomain.com to https://yourdomain.com across tables while handling serialised data correctly. Run it with the dry-run option first to preview how many rows change. Avoid raw SQL replacements on serialised fields, which can corrupt settings.

In theme and template files

Replace absolute addresses to your own domain with root-relative paths such as /images/logo.png, or with the correct https:// version. Relative paths keep working even if the domain changes later.

In CMS settings

Update the site address and home URL fields to HTTPS. Clear any page cache and CDN cache afterwards, otherwise old HTML may keep being served.

In third-party embeds

Get a fresh embed code from the provider. Nearly every mainstream service now supplies HTTPS versions. If one genuinely does not, remove it or find an alternative, because browsers will keep blocking it.

A safety net with upgrade-insecure-requests

You can send a Content Security Policy header, Content-Security-Policy: upgrade-insecure-requests, which tells supporting browsers to request every resource on the page over HTTPS automatically. It is a handy backstop while you clean up, especially for old content you cannot easily edit.

Treat it as a safety net rather than the fix. If a resource does not exist on HTTPS, the upgraded request still fails. Pair the header with a permanent 301 redirect from HTTP to HTTPS for the whole site so that old links and bookmarks land securely.

Keeping new mixed content from creeping back

After the cleanup, a few habits stop the problem returning:

  • Upload images through the CMS media library rather than pasting external addresses.
  • Check the Console for mixed content after installing any plugin, widget or tracking code.
  • Ask content writers to avoid copying image links from other sites.
  • Re-crawl the site every few months, or after a redesign or migration.

Your next step is simple: open your five most visited pages with DevTools running and note every warning. If the list is long or the fixes involve database work you are not comfortable with, our support team can help clean it up, and sites on our hosting plans get HTTPS configured correctly from the start.

Frequently asked questions

Do mixed content warnings affect SEO?

Google treats HTTPS as a light ranking signal, and blocked scripts or broken images can damage page experience and usability. Fixing mixed content is worth doing for both visitors and search.

Why does my site show mixed content only on some pages?

Those pages usually contain older content, a specific widget or a template with a hard-coded address. Check the Console on the affected page to see which file is responsible.

Can a plugin fix mixed content automatically?

Some plugins rewrite HTTP links as pages are generated. They can help in the short term, but updating the stored URLs properly is cleaner and avoids extra processing on every request.

Is a link to an HTTP website considered mixed content?

No. A normal clickable link to another site does not load anything into your page, so it does not trigger a warning. Only resources the page loads automatically count.

Thinking about a website?

See what a package covers and what it costs, or ask us about your own project.

Read next

Thinking…