Mixed content

Active content — `<script>`, `<link rel=stylesheet>`, `<iframe>`, `XMLHttpRequest`, `fetch` — can change the page. A network attacker who can modify it controls the page entirely, so browsers block it and log a console error. The symptom is a feature that silently does nothing.

Passive content — `<img>`, `<audio>`, `<video>` — cannot change the page structure. Modern browsers autoupgrade these requests to HTTPS and block them if the upgrade fails. The symptom is a missing image.

Because the handling differs, a page can look completely fine and still be loading blocked scripts. The console is the reliable place to look, not the rendered page.

Hard-coded absolute URLs in content written before the site moved to HTTPS — the largest source, and the hardest, because they live in the database rather than the code.

Third-party embeds and widgets whose snippets were copied years ago.

CSS: `background-image: url(http://…)` inside a stylesheet does not appear in the HTML at all.

Redirects and canonical tags pointing at `http://`, which are not blocked but propagate the old protocol.

Open the page and read the browser console. Mixed content produces an explicit message naming the blocked or upgraded URL — this is the fastest and most reliable single check.

Search the served HTML for `http://` followed by your own domain or a known third party. Remember that CSS and JavaScript files need searching too.

A `Content-Security-Policy: upgrade-insecure-requests` header instructs browsers to rewrite http references to https before requesting them. It is a good safety net, and it is not a fix: it hides the references rather than removing them.

Change the references to HTTPS, or to protocol-relative-free absolute HTTPS URLs. For content in a database, a careful search-and-replace on the stored HTML is usually the only practical route, and it should be done on a copy first.

Replace third-party resources that do not offer HTTPS. In practice, in 2026, one that still does not is one to remove.

Add `upgrade-insecure-requests` as a transitional measure while the references are cleaned up, not as the end state.

Check the CSS and the JavaScript, not only the HTML. A single `url(http://…)` in a stylesheet is enough to keep the problem alive.

`transport.mixed_content` scans the served HTML of each crawled page for resource references using `http://` and reports them with the page they appear on.

It sits alongside `transport.https` and `transport.http_redirect`, which answer the prior question: whether the site serves HTTPS and whether the plain-HTTP version redirects to it at all.

Code is the easy part: a handful of `http://` references in templates, found in one search and fixed in one commit. The references that survive migrations live in stored content, and they behave differently.

Years of articles with embedded images whose absolute URLs were correct when they were written. Every one is stored HTML, and no code change touches them.

The safe approach is a copy first. Dump the database, run the replacement against the copy, and diff. A blind search-and-replace on a production content table is how apostrophes get mangled and how `http://` inside a code sample — where it is quoted text, not a live reference — gets silently rewritten.

Scope the replacement narrowly. Replace `http://yourdomain.com` and the specific third-party hosts you have identified, rather than every occurrence of `http://`. External links to sites that are still HTTP-only are not mixed content and must not be rewritten.

Do not forget serialised data. Content stored as JSON or as PHP-serialised strings carries byte lengths that a naive replacement invalidates, which corrupts the record rather than updating it. Tools exist for this on every major CMS, and hand-written SQL is the wrong instrument.

Finally, re-crawl rather than spot-check. The references are spread across years of content, and the pages most likely to still carry them are the old ones nobody opens.