Mixed Content (HTTP Resources on HTTPS): How to Fix It

Your audit flagged "Mixed Content - HTTP Resources on HTTPS." This means at least one page on seoprocheck.com is served securely over HTTPS, but it pulls in one or more sub-resources over insecure HTTP. The result is a page that looks protected but is not fully protected, which weakens both the user experience and the security guarantees that HTTPS is supposed to provide. This guide explains what is happening, why it matters, and exactly how to resolve it.

What mixed content is

A web page is made up of a main HTML document plus many sub-resources: images, JavaScript files, CSS stylesheets, web fonts, videos, audio and embedded frames. When the main document is delivered over HTTPS but one or more of those sub-resources is requested over HTTP, the page is said to contain mixed content. The page is a mix of secure and insecure connections.

According to MDN, mixed content is a problem because any resource sent over an insecure connection can be viewed and potentially modified by an attacker positioned between the visitor and your server. Even a single insecure image request undermines the privacy and integrity promise that the padlock implies.

Active vs passive mixed content

Browsers split mixed content into two categories based on how much damage a tampered resource could do.

Active mixed content

Active, or blockable, mixed content includes scripts, stylesheets, iframes and other resources that can change the rest of the page. If an attacker swaps out an HTTP script, they could rewrite the whole page, steal form data or redirect users. Because the risk is high, browsers block active mixed content by default, which often breaks layout or functionality outright.

Passive mixed content

Passive, or optionally blockable, mixed content includes images, video and audio that cannot alter other parts of the page. The risk is lower, so browsers historically displayed it while downgrading the security indicator. Modern browsers increasingly try to upgrade these requests to HTTPS automatically, and will block them if no HTTPS version is available.

Why it matters

Security. The entire point of HTTPS is an encrypted, tamper-resistant channel. An insecure sub-resource creates a gap an attacker can exploit to read or alter what loads on the page, defeating the protection on that view.

Blocked resources and broken functionality. Because browsers block active mixed content by default, an HTTP script or stylesheet may simply never load. That can break navigation, forms, sliders, tracking and styling, leaving visitors with a page that does not work as intended.

A broken padlock. When a page contains mixed content, the browser removes or downgrades the padlock and may show a "Not fully secure" warning. Google Search Central is clear that HTTPS is a ranking signal and that it expects secure pages to load their resources securely, so a degraded security state can erode both user trust and search confidence.

How to diagnose it

Browser console. Open the affected URL, then open developer tools and check the Console and Security tabs. Browsers log explicit "Mixed Content" warnings naming each insecure resource and whether it was blocked or upgraded. This is the fastest way to see exactly which files are at fault.

Crawler. A crawler such as Screaming Frog can scan the whole site and surface every page that references an http:// resource, which is far more practical than checking pages one by one. This is the same method behind your audit finding, and it lets you confirm the fix at scale once you are done.

How to fix it

The core fix is simple: serve every sub-resource over HTTPS. Locate each hardcoded http:// reference in your templates, theme files, page content, CSS and database, and update it.

Prefer absolute HTTPS URLs. Where the resource lives on a host that fully supports HTTPS, point directly at the secure version.

<img src="http://seoprocheck.com/logo.png">
<script src="http://cdn.example.com/app.js"></script>

<img src="https://seoprocheck.com/logo.png">
<script src="https://cdn.example.com/app.js"></script>

Protocol-relative URLs (starting with //) inherit whatever protocol the page uses, so they resolve to HTTPS on an HTTPS page. They are an acceptable interim pattern, but explicit https:// is clearer and is the modern recommendation.

<link rel="stylesheet" href="http://example.com/style.css">

<link rel="stylesheet" href="//example.com/style.css">
<link rel="stylesheet" href="https://example.com/style.css">

As a safety net for legacy references you may have missed, add the CSP upgrade-insecure-requests directive. As MDN describes, it tells the browser to rewrite insecure URLs to HTTPS before any request hits the network. Note that if a resource genuinely has no HTTPS version the request will fail, so this is a backstop, not a substitute for cleaning up your URLs.

Content-Security-Policy: upgrade-insecure-requests

For a database-driven site like WordPress, run a search-and-replace across the content tables to convert stored http:// references to https://, and make sure your site and home URLs use HTTPS.

Common mistakes

Forgetting hardcoded URLs buried in theme files, inline styles, widgets and old posts is the most frequent cause of lingering mixed content. Another is relying only on upgrade-insecure-requests while leaving genuinely HTTP-only resources in place, which causes those resources to fail silently. Third-party embeds and ad or tracking snippets that still use http:// are easy to overlook. Finally, treating one fixed page as proof the whole site is clean: always re-crawl after changes to confirm no insecure resources remain anywhere.

FAQ