HTTPS on Every Page, Not Most of Them

Secure is per request, not per site

Installing a certificate secures the connection that delivers a page.

A page then asks for other things: images, stylesheets, scripts, fonts, and embedded content, each of which is its own request.

If any of those is requested over an insecure connection, the page is partly insecure regardless of the certificate, and the browser responds.

That is mixed content, and it is the reason a site can have a valid certificate and still not show a padlock.

Two kinds, treated differently

The distinction that determines whether you have a cosmetic problem or a broken page.

Passive mixed content is images, video, and audio. Browsers generally load it and downgrade the security indicator, so the page works and the padlock disappears or is marked.

Active mixed content is scripts, stylesheets, and embedded frames, which can change the page itself. Browsers block it outright.

Which means a missing script produces a page with broken layout, a form that does not submit, or a feature that silently does nothing.

The second is the version worth finding urgently, because the symptom looks like a bug rather than a security warning.

Where it comes from

• Old content with insecure addresses written into it.
• Images in the database with full insecure addresses.
• A plugin or theme loading something insecurely.
• Embedded content from another site.
• Hard-coded addresses in a template.
• An external service that has not moved to secure.

The second is the biggest source on established sites, since years of content can contain full addresses recorded when the site was insecure.

How to find it

Two methods, both free and neither requiring anything installed.

Open a page in a browser, open the developer console, and reload. Mixed content is reported explicitly, naming each offending address.

That is the definitive method and takes a minute per page.

For a whole site, an online mixed content checker will crawl and list them, which is more practical than checking pages individually.

Check a range of page types rather than only the homepage, since the problem frequently lives in older blog posts and product pages rather than in the templates.

A worked example

A business moved their site to a secure address and the padlock appeared correctly on the homepage.

Several months later they noticed the padlock was missing on their older articles, and that a map embedded on the contact page had stopped displaying entirely.

The console reported both: images in older posts referenced with full insecure addresses stored in the database, and the map loading over an insecure connection and being blocked.

The images were passive, so they loaded with a downgraded indicator. The map was active, so it was blocked, which is why it had vanished.

A database search and replace across the content fixed the images, and updating the embed code fixed the map.

The map had been missing for months and nobody had connected it to the security change, because it looked like a broken feature.

Fixing it properly

The approach that lasts, rather than the one that suppresses the symptom.

Where the resource is your own and available securely, change the address. A database search and replace across content handles years of posts in one operation, and should be done with a backup taken first.

Better still, use addresses that omit the protocol entirely where possible, so a resource is requested however the page was.

Where the resource belongs to somebody else and is not available securely, the honest options are to find an alternative or to remove it, since there is no safe way to include it.

An external service that still cannot be loaded securely is a reasonable prompt to ask whether you should still be using it.

Redirecting is not fixing

A distinction worth making because it is where people stop too early.

A rule redirecting insecure requests to the secure version is correct and necessary, and it handles visitors arriving at the wrong address.

It does not fix mixed content, because the browser evaluates what the page requests before any redirect resolves, and an active resource is blocked rather than followed.

So a site can redirect everything correctly and still have blocked scripts and a downgraded padlock.

Both are needed: the redirect for arrivals, and correct addresses inside the pages themselves.

Check after any change

Because this reappears rather than being fixed once.

A new plugin, a new embed, a pasted block of code, or content copied from an older page can each reintroduce an insecure address.

Add a console check to whatever you already do after publishing something with embedded content, which is a few seconds.

And check the console on a service page and an older article once or twice a year, since that is where it accumulates.

The padlock disappearing is the visible symptom, and a silently blocked script is the one that costs you something.

The counter-case

Passive mixed content is a modest problem.

An older article loading one image insecurely produces a downgraded indicator on that page and nothing else, and for a small site with a handful of such pages it is housekeeping rather than urgency.

There is also real risk in a site-wide database replace performed carelessly, which can alter content it should not, so it needs a backup and preferably somebody who has done it before.

Active mixed content is different and should be fixed promptly, because something on the page is not working and the symptom does not announce itself as a security issue.

Find both, fix the active ones now, and clear the passive ones when convenient.

The check

1. Open the console and reload three page types.
2. Note whether each item is passive or active.
3. Fix active ones first, since they are blocked.
4. Search and replace insecure addresses in content.
5. Take a backup before any database operation.
6. Replace or remove third-party resources that cannot be secured.
7. Keep the redirect as well as fixing the addresses.

Step three is the priority, since active mixed content presents as a broken feature rather than as a security warning and can sit unnoticed for months.

What a certificate does and does not cover is in the certificate that expires on a Sunday.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.