HTTPS is the floor, and the floor has four parts
Whether to serve your site over TLS is not a question any more. What is still open on a surprising number of sites is the redirect, the certificate chain, the renewal, and whether the insecure address quietly still answers.
The short answer
HTTPS has four parts, and sites fail on the last three: a valid certificate, a redirect from HTTP to HTTPS, no mixed content, and correct certificate coverage for every hostname served. A padlock on the home page proves the first and says nothing about the others.
Four parts, and the last three are where sites fail
Getting a certificate is the part everybody does. Then there are three more, and each of them fails independently while the padlock in your own browser stays closed.
- The certificate itself. Free, automated and largely solved. Worth knowing it covers specific names: a certificate for
example.comdoes not coverwww.example.comunless it says so, and a wildcard covers one level of subdomain rather than all of them. - The redirect from HTTP. Every insecure address should answer with a permanent redirect to its secure twin. When this is missing, both protocols serve your site, which is a duplicate of every page you have and a live insecure copy of it.
- The assets on the page. An encrypted page can still reference scripts, styles and images over HTTP, which is its own check and the most common way a finished migration turns out not to be.
- The renewal. Automated everywhere and still the cause of most outages in this area, because automation fails silently until the day the certificate expires and every visitor gets a full-page warning.
Those four are worth listing separately because a site can pass the first and fail any combination of the rest, and only the first is what people mean when they say the site is on HTTPS.
The certificate problems nobody sees
Three failures that are invisible in the browser you tested with, which is what makes them worth knowing about specifically.
An incomplete chain. A certificate is presented with the intermediates needed to link it to a trusted root. Browsers cache intermediates they have seen before, so a server that forgets to send them works fine for you and fails for a client that has never visited. Crawlers, command-line tools and freshly installed browsers are exactly that client.
A name mismatch on a redirect target. The site redirects example.com to www.example.com, and the certificate covers only the second. The redirect works, and the first request, the one that had to be trusted to deliver the redirect, does not.
An expiry nobody is watching. Certificates are short-lived now by design, which makes automation essential and makes a broken renewal a scheduled outage. The monitoring worth having is not a calendar reminder, it is a check that alerts on the remaining days, from outside your network.
Test from a client with no memory of your site.
Your browser has cached intermediates, remembered your HSTS policy and possibly kept a DNS answer. A fresh curl from a machine that has never visited is a better approximation of a crawler, and it is the only way the chain problem shows itself.
The other useful instrument is your search console, which reports what the crawler actually received. If it reports fetch failures and your browser is happy, the difference is nearly always trust rather than availability.
Check the protocol on one URL
This reports whether the URL you entered was served over HTTPS. It is the narrowest of the four parts above, and the only one visible from an address, which is worth saying plainly rather than implying more.
No signup required. Each free search audits one page, paste any URL to see it in action.
Does this affect AI search?
Yes, and less through a preference than through a mechanism. Many clients that fetch pages programmatically refuse a certificate they cannot validate, and unlike a browser they offer nobody a button to proceed anyway. A chain that a browser tolerates and a library rejects is a site that is fetchable by people and not by tools.
There is also a trust dimension that is easy to overstate and real at the margin. Assessments of whether a source is reliable include the basics of how the site is operated, and a site served insecurely in the current decade is an anomaly rather than a neutral choice.
The practical version: this is not a check where you gain anything by doing it well, because everyone does it. It is a check where failing puts you outside what a lot of automated clients will accept at all, and that failure is more absolute here than in a browser.
Why encryption is Critical when the site still works
It looks like the wrong rating at first, because an HTTP page loads, is crawled and can rank. Google has described HTTPS as a lightweight signal, not a requirement, and plenty of insecure pages are indexed.
The Critical rating is about the compound failure rather than the signal. Every browser labels the page as not secure, in the address bar, to every visitor. Forms on it are flagged. Automated clients may refuse it. And if the insecure version is answering alongside a secure one, every page on the site exists twice with no statement about which is canonical.
The other justification is that the fix is genuinely finished work. A certificate is free and automated, the redirect is a rule at the edge, and there is no editorial judgement anywhere in it. A finding that is both consequential and fully solvable in an afternoon belongs at the top of a list, not because it is hard but because there is no reason for it to still be open.
Checking all four parts at once
One script covers the redirect, the chain, the expiry and the names on the certificate.
DOMAIN=example.com
# does the insecure address redirect, permanently, to the secure one?
curl -s -o /dev/null -w 'http -> %{http_code} %{redirect_url}\n' "http://$DOMAIN/"
curl -s -o /dev/null -w 'https -> %{http_code}\n' "https://$DOMAIN/"
# expiry and the names the certificate actually covers
echo | openssl s_client -servername "$DOMAIN" -connect "$DOMAIN:443" 2>/dev/null \
| openssl x509 -noout -enddate -subject -ext subjectAltName
# is the chain complete? this fails if intermediates are missing
echo | openssl s_client -servername "$DOMAIN" -connect "$DOMAIN:443" \
-verify_return_error 2>&1 | grep -E 'Verify return code|verify error'The first block should show a 301 from HTTP and a 200 from HTTPS. A 200 from both means the insecure site is live. A 302 means the redirect is temporary and should not be.
The last block is the one that finds the invisible problem. A verify return code of 0 is a complete chain; anything else is a client without your browser's cache being turned away, which includes a good share of the software that fetches pages.
Questions this check raises
- Is HTTPS a ranking factor?
- Yes, and a small one, confirmed by Google in 2014. The larger effect is not the ranking signal: browsers mark HTTP pages as not secure, several APIs refuse to run outside a secure context, and referrer data is dropped on downgrade. The ranking effect is the least of it.
- Do I still need an HTTP to HTTPS redirect if my site is HTTPS?
- Yes. Without it, the HTTP address still serves content or errors, which means a duplicate address, a broken bookmark, or a plaintext response depending on the stack. One permanent redirect at the edge covers it.
- What certificate problems go unnoticed?
- An incomplete chain, which validates in browsers that cache intermediates and fails in command-line clients and some crawlers. Also a certificate covering the apex but not www, or covering the site but not an asset subdomain, both of which fail only on the path nobody tests.