Most sites moved to HTTPS years ago. Most of them still have a few leftovers: an old section that never redirected, a CMS block with a hard-coded http:// image, a third-party widget loading a script over HTTP. Visitors see a “Not secure” label or a broken image, and you rarely hear about it.
This guide covers the three HTTPS problems worth checking on any site, why they matter, and how to find them across every page.
Does HTTPS still matter for SEO?
It matters most for users. Browsers mark HTTP pages as “Not secure” and treat insecure resources on secure pages as a risk.
For rankings, Google announced HTTPS as a ranking signal in 2014, describing it as “a very lightweight signal” carrying “less weight than other signals such as high-quality content”. Don’t expect a ranking jump from fixing leftovers; do expect fewer warnings, fewer duplicates and fewer broken resources.
What are the three HTTPS problems to check?
1. Pages still served over HTTP
Pages that load on http:// without redirecting. They show the “Not secure” warning and can be indexed alongside their HTTPS twins as duplicates.
Fix: serve every page over HTTPS and 301-redirect each HTTP URL to its HTTPS equivalent.
2. HTTP that doesn’t redirect to HTTPS
The site works on HTTPS, but http://example.com/ still returns a page instead of redirecting. Old links, bookmarks and typed URLs land on the insecure version.
Fix: add a site-wide 301 redirect from HTTP to HTTPS at the server or CDN, so every path redirects, not just the homepage. Combine it with your www/non-www and trailing-slash rules so each URL takes a single hop; see redirect chains.
3. Mixed content on HTTPS pages
web.dev’s guide to mixed content defines it as an HTTPS page that loads resources over HTTP, and splits it in two:
| Type | Examples | What browsers do |
|---|---|---|
| Passive (upgradable) | Images, audio, video | Chrome tries to upgrade them to HTTPS; if the HTTPS version doesn’t exist, the resource breaks |
| Active (blockable) | Scripts, stylesheets, iframes | Blocked by default, because they can take over the page |
Active mixed content usually breaks something visible: a missing stylesheet, a dead widget. Passive mixed content fails more quietly: an image that simply doesn’t appear.
Fix: load every resource over HTTPS. Replace hard-coded http:// URLs in templates, CMS content and theme settings, and switch or remove third-party resources that don’t support HTTPS.
How do you find HTTPS problems across a site?
One page: open Chrome DevTools. Mixed content shows up in the Issues tab and the Console.
The whole site: crawl it. Crawlens checks the protocol of every crawled page, requests the HTTP version of the site to see whether it redirects, and looks at the images each HTTPS page loads:
| Check | What it flags | Severity |
|---|---|---|
| Pages served over HTTP | Crawled pages answering on http:// |
Warning |
| HTTP version does not redirect to HTTPS | The site’s HTTP homepage not redirecting to HTTPS | Warning |
| Mixed content | HTTPS pages that load images over HTTP, with the list of insecure image URLs | Warning |
Crawlens’s mixed content check covers images. For scripts, stylesheets and iframes, check a page per template in DevTools, since a broken script or stylesheet usually comes from a shared template or plugin.
A cleanup that sticks
- Redirect at the edge. One site-wide HTTP-to-HTTPS rule at the server or CDN covers every URL, including ones you’ve forgotten.
- Search and replace hard-coded URLs in the database and templates:
http://yourdomaintohttps://yourdomain, andhttp://CDN URLs to their HTTPS versions. - Update internal links, canonicals, hreflang and sitemaps to HTTPS so they don’t depend on redirects.
- Re-crawl and compare with the previous crawl: HTTP pages and mixed content should show up as fixed.
- Keep it fixed. A scheduled crawl catches new
http://images the next time someone pastes one into the CMS.
Checklist
- Every page served over HTTPS
- Site-wide 301 from HTTP to HTTPS, every path, in one hop
- No images loaded over HTTP on HTTPS pages
- No scripts, stylesheets or iframes over HTTP (check a page per template in DevTools)
- Internal links, canonicals, hreflang and sitemaps use HTTPS URLs
- Scheduled crawl to catch new insecure resources
Frequently asked questions
What is mixed content?
Mixed content is when a page is loaded over HTTPS but some of its resources, such as images, scripts, stylesheets or iframes, are loaded over HTTP. Browsers warn about it, upgrade it or block it, depending on the type.
Is HTTPS a Google ranking factor?
Yes, but a light one. Google announced HTTPS as a ranking signal in 2014, describing it as very lightweight and carrying less weight than signals like high-quality content. The bigger benefits are security and user trust.
What's the difference between passive and active mixed content?
Passive mixed content, like images, audio and video, can't change the rest of the page; Chrome tries to upgrade it to HTTPS. Active mixed content, like scripts, stylesheets and iframes, can take over the page, so browsers block it by default.
Do I need to redirect HTTP to HTTPS if my site already uses HTTPS?
Yes. If the HTTP version still loads, it can be indexed as a duplicate and visitors who type or follow an old HTTP link browse insecurely. Add a site-wide 301 redirect from HTTP to HTTPS.
How do I find mixed content on a single page?
Open the page in Chrome DevTools: mixed content is reported in the Issues tab and the Console. For a whole site, use a crawler that checks the resources each page loads.