HTTPS and mixed content: why the padlock disappeared

Aug 29
3 min read

Updated: 3 days ago

Introduction

The certificate was installed, the site loads securely, and one page shows a warning instead of a padlock. Nobody can see anything wrong with the page, and the hosting company reports that everything on their side is correct.

Somewhere in that page, one item is being requested over an insecure connection: an image, a script, an embedded map. The browser will not describe a page as secure when part of it is not, and the warning is entirely accurate. Finding the item usually takes a few minutes once you know where to look, and fixing it normally takes less time than explaining the problem to somebody else would.

1. HTTPS and mixed content are two halves of one problem

Understand the relationship.

A certificate makes the connection to your page secure. Mixed content means the page then requests something over an insecure connection, which undermines that and removes the reassurance the certificate was installed to provide.

2. Know why the warning matters commercially

Not merely a technical nicety.

Visitors asked to enter a name, an email address or card details on a page marked not secure will frequently abandon it. The warning appears at precisely the moment you are asking somebody to trust you.

3. Find the offending item in the browser console

The diagnosis is direct.

Open developer tools, load the page and read the console. Mixed content is reported explicitly, with the exact address of each insecure item, which usually identifies the cause immediately.

4. Look first at content added by hand

Where it nearly always originates.

Images inserted with a full insecure address, an old embedded video, or a script copied from a supplier years ago. Content added through the editor is a far more common source than anything in the site template.

5. Use protocol-relative or secure addresses

The fix for your own content.

Update the addresses to their secure form, or use relative addresses for anything hosted on your own site. Relative addresses cannot become insecure later, which makes them the more durable choice.

6. Check third-party embeds and widgets

The items you do not control.

Maps, booking tools, review widgets and social embeds all load external resources. If a supplier serves something insecurely and will not change it, the choice is between removing the widget and living with the warning on that page. On a page that collects details, removing it is usually the right answer.

7. Redirect insecure traffic at the server

The site-wide requirement.

Every insecure request should be redirected to its secure equivalent automatically, so that anybody arriving from an old link or bookmark ends up on the secure version rather than a duplicate.

8. Update internal links to the secure form

Otherwise every click passes through a redirect.

Internal links written with the insecure prefix still work but add a hop each time. A search and replace across the content resolves it and removes a whole class of redirect chains.

9. Confirm the certificate renews automatically

The recurring failure.

Certificates expire, and an expired one produces a full-page warning that stops visitors entirely. Confirm renewal is automatic and that the notification address is one somebody still reads.

Re-check after adding anything new to a page. Mixed content is reintroduced by a single pasted embed or an image inserted with an old address, and the warning appears only on the page that changed, which makes it easy to miss.

Conclusion

Understand that one insecurely loaded item is enough to remove the secure indicator from an otherwise correct page.

Treat the warning as a commercial problem because it appears exactly where you ask for trust, use the browser console to identify the specific insecure item, look first at content added manually through the editor, switch to secure or relative addresses, check third-party embeds you do not control, redirect all insecure traffic at the server, update internal links so they do not pass through redirects, confirm the certificate renews automatically to an address somebody reads, and re-check any page after adding new embeds.