Skip to content
Browse all guides

Issue #2 · critical

Issue 2

What is this issue?

This issue checks whether your HTTPS pages load any resources (scripts, stylesheets, iframes, images, etc.) over insecure HTTP connections.

What this issue checks

  • All resource URLs on HTTPS pages use https:// scheme (not http://)
  • No active resources (scripts, stylesheets, iframes) load over HTTP
  • No passive resources (images, videos, audio) load over HTTP
  • Protocol-relative URLs (starting with //) are acceptable as they inherit the page's scheme

What is considered a passing implementation

A passing implementation means:

  • All resource URLs on HTTPS pages use HTTPS
  • No mixed content warnings in browser console
  • All subresources are loaded securely

Real-world example

If your page is served over HTTPS at https://example.com, all resources should use HTTPS:

Good:

<script src="https://cdn.example.com/app.js"></script>
<img src="https://example.com/image.jpg" />

Bad (mixed content):

<script src="http://cdn.example.com/app.js"></script>
<img src="http://example.com/image.jpg" />

Browsers block active mixed content (scripts, stylesheets) entirely, causing functionality to break.

Why does it matter?

Mixed content is critical for security and SEO:

Crawlability

If browsers block scripts or stylesheets due to mixed content, your page may not render correctly for search engine crawlers, affecting indexing and ranking.

Indexability

Search engines may not be able to properly index pages with mixed content if critical resources are blocked by browsers.

Rankings

Google considers page security as a ranking factor. Sites with mixed content signals security negligence, potentially affecting rankings.

User Experience

Browsers block active mixed content (scripts, stylesheets, iframes) entirely, causing page functionality to break silently. Passive mixed content (images, videos) triggers security warnings and removes the HTTPS padlock icon. Users see "Not Secure" warnings, which damages trust.

AI Search / AEO

AI-powered search engines and assistants prioritize secure, properly configured sites. Mixed content indicates poor security practices.

SEO Health Score Impact

Resolving this issue improves your overall SEO health score by ensuring your HTTPS pages are fully secure and functional, protecting users from man-in-the-middle attacks.

How to fix it

Follow these steps to fix mixed content issues:

Step 1: Identify all HTTP resource URLs

Identify all HTTP resource URLs in your HTML source code, including:

  • <script src="http://...">
  • <link rel="stylesheet" href="http://...">
  • <iframe src="http://...">
  • <img src="http://...">
  • <video src="http://..."> or <audio src="http://...">

Step 2: Replace http:// with https://

Replace http:// with https:// for all resource URLs:

  • Update HTML templates, CMS settings, theme files
  • Update database-stored content (blog posts, product descriptions)
  • Update third-party widget/plugin code

Step 3: Verify HTTPS availability

Verify that each https:// URL returns a valid response (HTTP 200).

Step 4: Handle third-party resources without HTTPS

For third-party resources that don't support HTTPS:

  • Contact the vendor to request HTTPS support
  • Replace with an alternative service that supports HTTPS
  • Remove the resource if it's not essential

Step 5: Use protocol-relative URLs (optional)

For resources that need to work on both HTTP and HTTPS, use protocol-relative URLs:

<script src="//cdn.example.com/app.js"></script>

Note: On HTTPS pages, // automatically becomes https://.

Step 6: Add CSP upgrade-insecure-requests

Add CSP upgrade-insecure-requests as a safety net:

Content-Security-Policy: upgrade-insecure-requests

This tells browsers to automatically upgrade HTTP requests to HTTPS.

Step 7: Test thoroughly

Test thoroughly using browser developer tools to verify no mixed content warnings appear.

Examples

Example 1: Insecure Script Loading

Problem: A script is loaded over HTTP on an HTTPS page.

What fails:

<script src="http://cdn.example.com/jquery.js"></script>

What passes:

<script src="https://cdn.example.com/jquery.js"></script>

Example 2: Insecure Image References

Problem: Images are referenced over HTTP.

What fails:

<img src="http://example.com/logo.png" />

What passes:

<img src="https://example.com/logo.png" />

Example 3: Protocol-Relative URL (Acceptable)

Scenario: Using protocol-relative URLs that work on both HTTP and HTTPS.

What passes:

<script src="//cdn.example.com/app.js"></script>
<link rel="stylesheet" href="//fonts.googleapis.com/css?family=Roboto" />

These URLs automatically use the same protocol as the page (HTTPS on HTTPS pages).

How PixyScan detects this

PixyScan checks whether your HTTPS pages load any resources (scripts, stylesheets, iframes, images, etc.) over insecure HTTP connections.

Detection process

PixyScan follows these logical steps to identify mixed content issues:

  1. Verify HTTPS page - PixyScan first checks if your page loads over HTTPS, since mixed content only applies to HTTPS pages.

  2. Parse HTML document - PixyScan parses the full HTML document of your HTTPS page to find all resource references.

  3. Collect resource URLs - PixyScan collects resource URLs from:

    • Active resources: <script>, <link rel="stylesheet">, <iframe>, <object>, <embed>
    • Passive resources: <img>, <video>, <audio>, <source>
  4. Detect insecure schemes - PixyScan filters for URLs with http:// scheme (not https://, not protocol-relative //).

  5. Classify mixed content - PixyScan classifies mixed content as:

    • Active: Scripts, stylesheets, iframes (browsers block these)
    • Passive: Images, videos, audio (browsers warn about these)

When the issue is flagged

The issue is flagged when any of these conditions are met:

  • Active mixed content is detected (CRITICAL - browsers block these resources, causing functionality to break)
  • Passive mixed content is detected (WARNING - browsers warn about these, and the HTTPS padlock is not shown)

When the issue passes

The issue passes when:

  • All resource URLs on HTTPS pages use https:// scheme
  • No mixed content warnings appear in browser console
  • All subresources are loaded securely
  • Protocol-relative URLs (starting with //) are present (these inherit the page's scheme and are acceptable)

References