What mixed content means on a website
Mixed content happens when a page loads over HTTPS but pulls in one or more resources over HTTP.
That mismatch weakens the security guarantees of TLS and can trigger browser warnings, blocked assets, or broken layouts.
If you are trying to understand how to find mixed content on website pages, the first step is knowing the two main types: blockable mixed content, such as scripts and iframes, and upgradable mixed content, such as images and audio that browsers may try to rewrite automatically.
Even when a browser does not visibly warn users, mixed content can still create risk and inconsistency.
Why mixed content matters for SEO, security, and conversions
Search engines and browsers increasingly favor secure experiences.
A page with mixed content can lose the browser padlock, display a “Not secure” warning, or fail to load critical assets entirely.
- Security: HTTP resources can be intercepted or modified in transit.
- User trust: Browser warnings reduce confidence and can increase bounce rate.
- Performance: Browsers may block or delay insecure requests.
- SEO: Security signals are part of overall site quality, and broken pages can reduce crawl efficiency and engagement.
For sites built on WordPress, Shopify, Drupal, Magento, or custom stacks, even one legacy image URL or JavaScript file can cause problems after an HTTPS migration.
How to find mixed content on website pages
The fastest way to find mixed content is to inspect the browser’s developer tools and the page source while visiting the HTTPS version of the page.
You are looking for requests that start with http:// instead of https:// or protocol-relative paths that resolve incorrectly.
Check the browser console
Open Chrome, Edge, or Firefox, load the page over HTTPS, and open DevTools.
The Console often reports mixed content with a clear message naming the blocked resource, file type, and exact URL.
- Right-click the page and choose Inspect.
- Open the Console tab.
- Refresh the page.
- Look for warnings that mention mixed content, insecure requests, or blocked resources.
Console messages are especially useful because they usually point directly to the problematic asset, such as a JavaScript file, stylesheet, iframe, font, or image loaded from an HTTP address.
Inspect the Network tab
The Network tab shows every request a page makes.
Filter for http:// or sort by status to identify requests that were blocked, redirected, or served insecurely.
- Load the page with DevTools open.
- Click Network.
- Reload the page.
- Search for insecure URLs or inspect suspicious requests one by one.
This method helps uncover hidden mixed content that may not appear in the console, including assets loaded by third-party scripts or CSS files.
View the page source and rendered DOM
Search the HTML source for http://, //, and legacy file paths.
Also inspect the rendered DOM, because JavaScript can inject insecure links after the initial page load.
Look at:
- Image sources in
imgtags - Stylesheets in
linktags - Scripts in
scripttags - Embedded content in
iframetags - Background images inside inline styles or CSS files
Use site-wide tools to uncover hidden mixed content
Manual inspection is useful, but larger sites need broader scanning.
Site crawlers and security tools can find insecure references across thousands of pages faster than browser testing alone.
Crawl the site with SEO tools
Tools such as Screaming Frog SEO Spider, Sitebulb, Ahrefs Site Audit, Semrush Site Audit, and Sitechecker can crawl pages and report mixed content or insecure URLs.
These tools are helpful when you need to find patterns across templates, category pages, product pages, and old blog posts.
Common findings include:
- Hardcoded HTTP image URLs in content fields
- Insecure links in navigation or footer templates
- Old CDN URLs still pointing to HTTP
- Third-party embeds served over HTTP
Search your codebase and database
If you have server or repository access, search for http:// across theme files, templates, JavaScript, CSS, and content exports.
In many CMS platforms, mixed content hides in the database rather than the codebase, especially in post content, widgets, or page-builder modules.
For WordPress, check:
- Posts and pages
- Theme options
- Custom fields
- Widgets
- Header and footer scripts
Database search-and-replace tools can help, but always back up first.
If possible, run replacements in a staging environment before updating production content.
Common sources of mixed content
Mixed content often comes from the same few places.
Knowing where to look makes it much easier to fix the root cause instead of chasing individual warnings.
- Legacy absolute URLs: Content written before the HTTPS migration still points to HTTP.
- Third-party embeds: Videos, maps, forms, widgets, and ad scripts may use insecure endpoints.
- CDN misconfiguration: Asset URLs or origin settings still reference HTTP.
- Theme and plugin files: Hardcoded asset paths in templates or scripts.
- Inline CSS and JavaScript: Background images, API calls, or dynamically injected resources.
Images are the most common visible issue, but scripts and iframes are often more serious because browsers may block them entirely.
How to fix mixed content after you find it
Once you identify the insecure resource, replace the HTTP URL with an HTTPS version whenever the destination supports it.
If the external service does not support HTTPS, consider replacing the provider or self-hosting the asset.
Update URLs consistently
Change hardcoded links in templates, CMS content, and custom code.
Use site-wide search-and-replace carefully to avoid breaking serialized data or encoded strings.
In many systems, relative or protocol-relative URLs are safer than hardcoded HTTP links, but full HTTPS URLs are usually the best long-term choice.
Fix canonical asset delivery
Make sure your primary domain, CDN, and media library all serve assets over HTTPS.
If you use Cloudflare, AWS CloudFront, Fastly, or another CDN, confirm that SSL is enabled and the origin configuration supports secure delivery.
Review third-party embeds
Some embedded tools still load assets from older endpoints.
Replace outdated embed codes with current versions from the vendor, and check whether the vendor offers a secure iframe or script tag.
Redirect and enforce HTTPS
Use a 301 redirect from HTTP to HTTPS at the server level, and consider enabling HSTS once the site is fully stable on HTTPS.
This does not fix mixed content by itself, but it helps prevent future insecure requests and keeps your preferred version consistent.
How to verify the fix
After making changes, reload affected pages in an incognito window and inspect the Console and Network tabs again.
Confirm that no insecure requests remain and that all key assets load successfully.
You should also test:
- Homepage
- Top landing pages
- Blog posts with embedded media
- Checkout and account pages
- Pages built with older templates
For larger sites, re-run your crawler and export the report so you can compare before-and-after results.
Keep a record of recurring offenders, because mixed content often returns during content updates or plugin changes.
Best practices to prevent mixed content in the future
Prevention is easier than cleanup.
Build HTTPS into your workflow so insecure URLs do not reappear during publishing, development, or redesigns.
- Use HTTPS-only URLs in all new content and templates.
- Audit plugins, widgets, and integrations before installing them.
- Standardize media uploads and CDN rules.
- Test staging sites with the same SSL setup as production.
- Monitor browser console warnings during QA.
- Run periodic crawls after major site updates.
For editorial teams, a short publishing checklist can be effective: verify image URLs, embedded media, and custom HTML blocks before a post goes live.
For developers, code review should flag any hardcoded http:// references.
Quick checklist for finding mixed content fast
- Load the HTTPS page in a modern browser.
- Check the Console for mixed content warnings.
- Inspect the Network tab for insecure requests.
- Search the page source and rendered DOM for
http://. - Crawl the site with an SEO auditing tool.
- Search templates, plugins, and the database for legacy URLs.
- Replace insecure resources with HTTPS equivalents.
- Re-test the affected pages and confirm the warnings are gone.
If you are auditing an entire site, start with high-traffic pages and pages containing embeds, because those are the most likely to expose mixed content quickly and affect the most users.