SiteAud!tLint Support

Warning Security

Mixed content

Severity
Warning
Impact
Medium
Effort to fix
Low
Issue code
mixed_content

Why it matters

An HTTPS page loads resources over HTTP. Browsers may block them and show security warnings.

How to fix it

Load every resource over HTTPS.

What counts as mixed content

A page loaded over HTTPS references a resource over plain HTTP. Browsers treat the two kinds differently:

  • Active mixed content is anything that can change the page: scripts, stylesheets, iframes, fonts and fetch or XHR requests. Modern browsers block it outright, so the script never runs and the stylesheet never applies.
  • Passive mixed content is images, audio and video. Chrome and Firefox now try to upgrade these to HTTPS automatically. If the file is not available over HTTPS, it fails to load and the visitor sees a broken image.

A form that submits to an http:// address is also flagged. Browsers warn the visitor before sending the data.

Example

https://example.com/pricing loads its stylesheet from http://cdn.example.com/css/site.css. The browser blocks the request, the page renders without styling, and the console shows a Mixed Content error. Googlebot renders pages much like Chrome does, so it sees the same broken layout.

Why it matters for SEO

Mixed content does not trigger a ranking penalty on its own. The damage is indirect:

  • Blocked scripts and stylesheets change what Google renders. Content injected by a blocked script is missing from the rendered page.
  • Broken images lose their image search visibility, and their alt text no longer describes anything a visitor can see.
  • Browser warnings erode trust, which shows up as lower engagement and conversions.

Common causes

  • Hardcoded URLs in old content. Posts written before an HTTPS migration still contain http:// image and embed links. This is the most common cause on WordPress sites.
  • Theme or template code. A logo, font or script path written with http:// in a header template affects every page at once.
  • CSS files. background-image: url(http://...) inside a stylesheet is easy to miss because it never appears in the HTML.
  • Third-party embeds and old CDN addresses. A widget, map or video embed copied years ago may still use HTTP.
  • Responsive image sets. One http:// entry inside a srcset attribute is enough.

How to find every instance

  1. Open the URL details for an affected page. The issue lists the HTTP images, scripts, iframes and stylesheets referenced in the page's HTML. References inside CSS files and srcset are not part of this check, so use step 2 to find those.
  2. To find instances across the whole site, run a custom source search for src="http:// and url(http://. Matches inside templates usually repeat on many pages, so fix the template first.
  3. For a single page, open the browser console. Each blocked resource is logged with its full address.

How to fix it

  1. Change each http:// reference to https://, after confirming the resource actually loads over HTTPS.
  2. For resources with no HTTPS version, host a copy on your own domain or replace the provider.
  3. On WordPress, run a search and replace on the database for your old http:// domain, using a tool that handles serialized data.
  4. Add Content-Security-Policy: upgrade-insecure-requests as a safety net. It upgrades requests you missed, but it cannot fix a resource that has no HTTPS version, so treat it as a backstop, not the fix.

Verify the fix

Recrawl the site and compare it with the previous audit in the Action Plan. Pages fixed at the template level should all move to fixed in the same crawl. Any that remain point to content-level references, usually inside individual posts.

Mixed content often shows up alongside a missing HSTS header. Fixing both completes an HTTPS migration.

How it affects your score

Finding this issue on any page costs the Security score 3 points, plus up to 12 more depending on the share of crawled pages affected. Weakens rankings, crawling or measurement. Fix after critical issues.

Find the affected URLs

Open Crawl > Issues and pick Mixed content. Each affected URL is listed with its evidence, and Copy URLs or Export URLs hands the list to a developer. The issue also appears in the Action Plan, ranked by impact (medium) and effort (low), and in the issues CSV under the code mixed_content. After fixing, run a new audit and use Compare to confirm the URLs moved to fixed.