HTTPS Checker: SSL, Redirect and Mixed Content Test

A certificate is not the whole job: redirects, HSTS and mixed content.

Most "SSL checkers" answer one question: is a valid certificate installed? That matters, and it is not what this tool tests. A site can hold a perfect certificate and still serve pages over plain http, forget the header that keeps browsers on https, or load a script over an unencrypted connection. Here is what each of those means, and how to fix it.

SSL, TLS and HTTPS: three names for one idea

HTTPS is ordinary HTTP carried inside an encrypted connection. The encryption protocol was first called SSL, Secure Sockets Layer. Its successor, TLS (Transport Layer Security), replaced it in 1999, and every SSL version has since been formally retired: the IETF prohibited SSL 2.0 in 2011 and deprecated SSL 3.0 in 2015. Today's connections use TLS 1.2 or TLS 1.3.

The old name stuck because it had already been sold. Certificate authorities, hosting control panels and plugins spent years selling "SSL certificates", so that is what people search for, even though the certificate on every modern site is used for TLS. When someone says "the site's SSL", they almost always mean "the site works over https with a valid certificate". This page uses TLS for the protocol and HTTPS for the result, and treats the rest as the same thing.

Certificates and the chain of trust (which this tool does not inspect)

A certificate is a signed statement that a public key belongs to a domain. Your browser does not know your site's certificate in advance. It trusts a short list of root certificate authorities built into the operating system or browser, and your certificate is trusted because it was signed by an intermediate that was signed by one of those roots. That sequence is the chain. A certificate that has expired, names a different domain, or arrives without its intermediate breaks the chain, and the browser shows a full-page warning instead of your site.

Those are real failures, and certificate checkers such as SSL Labs, DigiCert's and SSL Shopper's exist to diagnose them: issuer, expiry date, the names the certificate covers, and whether the chain is complete. This tool reads none of that. Our server does refuse to talk to a site whose certificate it cannot verify, so a broken certificate shows up here as an https door with no response, but the card cannot tell you whether the cause was the certificate, a firewall or a host that is down. For that, use a certificate checker.

It is also worth watching expiry more closely than it used to need. In 2025 the CA/Browser Forum, the body of certificate authorities and browser makers that sets the rules, voted to shorten the maximum life of a public certificate in steps: 200 days from March 2026, 100 days from March 2027 and 47 days from March 2029. Anyone still renewing by hand once a year will need automatic renewal.

The redirect from http to https: one permanent hop, on every door

Installing a certificate makes https available. It does not make http go away. Unless the server redirects it, http://yourdomain.com keeps serving the page unencrypted, and anyone who types the address without the scheme, follows an old link or scans an old QR code can land there. Since July 2018 Chrome has labelled every http page "Not secure" in the address bar.

The fix is a redirect, and three details decide whether it is a good one. It should be permanent, a 301 or 308, so search engines move their signals to the https address rather than treating the move as a detour. It should be one hop, straight to the final URL. And it should cover all four doors: http://example.com, http://www.example.com, https://example.com and https://www.example.com. A site that redirects the bare domain but forgets http://www is the most common gap, because nobody tests the address they never use themselves.

Here is the trace this checker ran for Willowdale Equity's homepage while this page was built. The http request comes back as a single 301, the https response carries the HSTS header, and all four doors end on the same https page:

# http://willowdaleequity.com/, traced 28 Sep 2026
301  http://willowdaleequity.com/
     Location: https://willowdaleequity.com/
200  https://willowdaleequity.com/   # Strict-Transport-Security: yes

# the four doors
http://willowdaleequity.com/       1 hop  → https://willowdaleequity.com/
http://www.willowdaleequity.com/   1 hop  → https://willowdaleequity.com/
https://willowdaleequity.com/      0 hops
https://www.willowdaleequity.com/  1 hop  → https://willowdaleequity.com/

This checker reports whether each door ends on https. Whether all four should end on the same host, www or bare, and whether the chain could be shorter, are redirect questions: the Redirect Checker traces every hop and flags host forms that land on different URLs. For what each status code means on its own, see the HTTP Status Code Checker.

HSTS: the header that closes the first-request gap

A redirect has one weakness. The first request still goes out over plain http, and on a hostile network (a café's Wi-Fi, a compromised router) that single request can be intercepted and answered by someone else before your server ever gets to redirect it. HTTP Strict Transport Security removes that step. It is a response header, sent over https:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

That exact line is what Willowdale Equity's server sends. Once a browser has seen it, for the next max-age seconds (63,072,000 is two years) it rewrites every http request to that site as https before sending anything, and it refuses to let a visitor click through a certificate warning. includeSubDomains extends the rule to every subdomain, so add it only when every subdomain serves https, including the old ones. Browsers ignore the header if it arrives over plain http, which is why this checker reads it from the https response.

HSTS still leaves the very first visit exposed, because the browser has not seen the header yet. The preload directive and the list at hstspreload.org close that: browsers ship with the list built in. The submission rules there ask for a max-age of at least one year, includeSubDomains, the preload directive and a redirect from http to https on the same host. Preloading is slow to undo, so treat it as the last step, not the first.

verand.ai, the site this page is on, fails this check today: its http requests are redirected to https with a 301, but the https response carries no Strict-Transport-Security header. It is the failing example the card shows if you enter it.

Mixed content: an https page that loads http

Mixed content is what a mixed content checker looks for: a page delivered over https that pulls in a resource, an image, a script, a stylesheet, a frame, over plain http. The page's own address has a padlock, but part of what it displays travelled unencrypted and could have been read or changed on the way. A script is the dangerous case: whoever can alter it can alter the whole page, including the form a visitor is about to fill in.

Browsers deal with it themselves. Scripts, stylesheets and frames loaded over http are blocked outright, which is why mixed content so often shows up as a broken layout or a missing widget rather than a warning. Current versions of Chrome and Firefox try to upgrade images, audio and video to https automatically and drop them if the upgrade fails. Either way, the page a visitor sees is not the page you built.

It usually arrives by accident: an image inserted into a post before the site moved to https, a theme setting with a hard-coded http:// address, an embed code copied from a vendor years ago. The line that triggers it looks like this:

<img src="http://example.com/uploads/team.jpg" alt="Our team">   # mixed
<img src="https://example.com/uploads/team.jpg" alt="Our team">  # fixed

This checker reads the served HTML for img, script, link, iframe, source, audio, video and embed tags whose src or href starts with http://, the same rule Verand's crawl applies to every page of every customer site. It reports whether it found at least one, not which: to find the culprit, open the page in Chrome, then the developer tools console, where each blocked or upgraded request is named. Two cautions about the rule. A link tag counts even when it is not something the browser loads, such as an old canonical or alternate link written with http://. And it reads only what the server sent: images in a srcset, backgrounds in CSS and anything a script inserts after the page loads are not seen.

How to fix mixed content

• Change the addresses at the source. Replace http:// with https:// in the post, template or setting that holds them. Check first that the resource is available over https; if the third party does not serve it that way, host it yourself or replace it.
• Use root-relative paths for your own files. /uploads/team.jpg works on any scheme and never goes stale when the domain changes.
• On WordPress, fix the stored URLs, not just the settings. Set both the WordPress Address and Site Address to https, then replace old http addresses in the database. WP-CLI does it in one line: wp search-replace 'http://example.com' 'https://example.com'. Back up first.
• Use upgrade-insecure-requests as a safety net. The response header Content-Security-Policy: upgrade-insecure-requests tells the browser to fetch every http resource on the page over https instead. It rescues resources that exist on https and does nothing for ones that do not, and a checker reading the HTML will still see the http:// addresses, so it is a net under the fix, not the fix.

Forms, third-party scripts and the promise in your privacy policy

For a firm in a regulated field, this is where HTTPS stops being a technical detail. Contact, intake and scheduling forms collect names, phone numbers and sometimes account or health details, and many privacy policies promise that information is encrypted in transit. A valid certificate does not keep that promise on its own. The promise holds only if every door redirects to https, the browser is told to stay there, and nothing on the page, least of all the script that runs the form, is loaded over plain http.

Two gaps are worth checking by hand, because this tool does not. A form whose action posts to an http:// address sends its data unencrypted even from an https page; Chrome warns visitors before they submit one. And scheduling, chat and analytics widgets are third-party code: if a vendor's embed snippet still uses http://, the mixed content check above catches it in the HTML, but a widget loaded by another script will not appear there. View the page source, search for http://, and look at every <form tag's action.

Does HTTPS affect Google rankings?

A little, and the size matters. Google announced HTTPS as a ranking signal in August 2014 and described it then as very lightweight, affecting fewer than 1% of global queries. It separates otherwise similar pages; it does not lift a weak page past a strong one. The larger effects are indirect: Chrome's "Not secure" label on http pages, browsers blocking the scripts that mixed content depends on, and redirects that split signals between two versions of a URL. The Canonical Tag Checker shows which version a page tells search engines is the real one; it should be the https one.

Using it as an HTTPS redirect checker after a migration

After moving a site to https, or to a new host or platform, enter the bare domain. A good result is a single 301 or 308 from http to https, all four doors ending on https, an HSTS header on the https response and no mixed content. Then enter two or three of your most important inner pages, such as the contact page and a form page, because the redirect and the page content can differ by path, and mixed content almost always lives on individual pages rather than the homepage.