en
/login
Koval SEO

A secure page references active content at http:// addresses

In the reportActive mixed content

mixed_content_active · Issue

Short answer

This appears when a page loaded over https:// references a script, stylesheet, frame, object or embed at an http:// address. Browsers block such requests, so the part of the page that depends on them can stop working. Load each file from an https:// address.

Severity: High. Fix it soon: a blocked script or stylesheet can break how the page works or looks for every visitor.

Why it matters

Scripts, stylesheets and frames can change the rest of the page, so browsers block them when a secure page requests them over HTTP. Google also lists insecure dependencies other than images on an HTTPS page as a signal against its usual preference for the HTTPS address.

What to do

  1. Look at the finding: it lists up to ten http:// references with their kind, such as script or stylesheet, and a count of the rest.
  2. Open each file at its https:// address to confirm it is served there, then change the address in the theme, plugin or template that adds it.
  3. If a file is not available over HTTPS, host a copy on your own site or replace it.

What we read

We read each crawled page that ends on an https:// address and answers 200 with complete HTML, up to 2 MiB, without running JavaScript. We look at <script src>, <link rel="stylesheet" href>, <iframe src>, <object data> and <embed src>, skipping those inside <noscript> or <template>.

A page is reported when at least one of these addresses is written with http://; relative and // addresses are not. A page whose Content-Security-Policy header or meta tag includes upgrade-insecure-requests is not reported, even when the meta tag stands outside the head, where browsers ignore it; a report-only policy does not count. The check does not confirm that a browser applied the policy, and the files themselves are not fetched.

Example & evidence

Illustrative example — one page, not a live audit.

https://bakery.example/order/ answers 200 and sends no Content-Security-Policy. Its HTML contains:

<script src="http://cdn.bakery.example/order.js"></script>

The script's address uses http://, so the page is reported: script: http://cdn.bakery.example/order.js.

A possible correction, once the file is served over HTTPS:

<script src="https://cdn.bakery.example/order.js"></script>

Confirm & check again

Check for yourself: open the page in Chrome with developer tools and look in the Console for "Mixed Content" messages, and view the source and search for http:// in src, href and data attributes.

Check again: Full audit — run a new audit of the site. The finding closes when the page is crawled again as a complete HTML page with no such http:// reference, or with upgrade-insecure-requests in its policy, or now permanently redirects within your site. A page that is only a frame for scripts, or is not reached by the crawl, cannot be confirmed.

Limits & sources

Files added by JavaScript or loaded from CSS, for example through @import, are not seen, and a relative address that an http:// <base href> turns into http:// is not reported. The check does not show whether a browser blocked the file or whether the page visibly broke.

Confidence: High because each address is read exactly as written in the HTML.

Sources

  • MDN, Mixed content — lists scripts, stylesheets, iframes and objects as blockable content that browsers should block, and says upgrade-insecure-requests upgrades these requests to HTTPS. Checked 25 September 2026.
  • Google, How to specify a canonical URL with rel="canonical" and other methods — lists insecure dependencies other than images on an HTTPS page as a signal against Google's HTTPS preference. Checked 25 September 2026.

Editorial review: 29 September 2026