Mixed content (HTTP resource on an HTTPS page)
mixed_contentShort answer
The page is HTTPS but references at least one resource with an http:// address. Browsers block HTTP scripts, styles and iframes on an HTTPS page and try to upgrade images to HTTPS; a resource that is blocked or can't be upgraded makes the page look incomplete or broken. Change the addresses to https://; if the resource is not available over HTTPS, host it yourself or remove it.
Why it matters
A blocked stylesheet means an unstyled page; a blocked script means a feature that silently does not work; a blocked iframe means an empty box. Chrome also removes the padlock and may show a warning. Googlebot renders with the same rules, so what is blocked for users is blocked for indexing too.
How Glimana detects it
During rendering Glimana counts resources on HTTPS pages whose URL starts with http://. The rule fires when the count is above zero; the evidence shows the number. Protocol-relative URLs (//cdn.example.com/x.js) resolve to HTTPS on an HTTPS page and are not counted, but they are still worth replacing with explicit https://.
How to fix it
- Find the affected pages in Glimana. Open Issues › Mixed content (HTTP resource on an HTTPS page). Every affected page is a row; open one to see the evidence Glimana recorded for it (the measured value, the offending element or the target URL). The same list sits on the task card under Tasks, and the page's own detail view under Pages shows its full signals.
-
Apply the fix on your platform.
Run a search-replace for
http://yourdomain→https://yourdomainin the database (WP-CLI or Better Search Replace). Check theme options for hard-coded logo or background URLs, and widgets with embedded HTML. Really Simple SSL's mixed-content fixer rewrites remaining cases at output time.Theme assets are always HTTPS. Mixed content on Shopify comes from pasted HTML in product descriptions, blog posts or theme settings (an
<img src="http://…">or an old embed). Edit the content and usehttps://.Grep the codebase and the database for
http://. SetContent-Security-Policy: upgrade-insecure-requestsas a safety net so browsers upgrade what you missed, andblock-all-mixed-contentonce you are clean. -
Publish and clear caches. Save and publish, then make sure the crawler will see the new version: WordPress — clear the page cache in your cache plugin and purge the CDN; Shopify — theme and content changes go live on save, but purge any CDN in front of the store; custom code — deploy and purge the edge cache. Check in a private window or with
curl -s https://your-domain/page | grep -i '<title\|canonical\|robots'that the live HTML has changed; Glimana reads what the server sends, not what your browser has cached. - Verify in Glimana. Open the task under Tasks and click Mark as done. The affected pages are queued for a verification crawl within a few hours, and the task closes when the page has no HTTP resources. If the check still fails, the task returns to New with a note; when it passes, the task is listed under Resolved technical issues on Impact reports. To check sooner, use Re-crawl affected pages on the issue.
How the fix is verified
Re-crawl; the task closes when the page has no HTTP resources.