How HTTP and HTTPS differ
The protocol is the part of an address before the colon, and it decides how the page travels between the server and the visitor. Plain HTTP sends everything as readable text. Anyone handling the connection along the way — a shared office network, a mobile operator, a compromised router in a cafe — can read what is being sent and, in principle, change it before it arrives.
HTTPS is the same protocol wrapped in TLS. The browser and the server agree on keys, using a certificate to confirm the server really is the hostname it claims to be, and everything after that is encrypted and tamper-evident. Two other things follow from it. Browsers only offer their newer, faster protocol versions over an encrypted connection, so a secure site can be quicker as well. And Google has said publicly that HTTPS is a ranking signal, though a light one — it is a baseline expectation now, not an advantage.
Why the difference matters
The visible cost comes first. Browsers mark plain HTTP pages as not secure, and put a sharper warning on any page with a form on it. A visitor about to type a phone number into an enquiry form and seeing that warning usually does not finish. On a site that sells or collects leads, this is a conversion problem before it is an SEO one.
The measurement cost is less obvious. When someone follows a link from a secure page to a plain one, the browser withholds the referring address. That traffic arrives in analytics with no source at all and lands in the direct bucket, so a plain HTTP site systematically under-reports where its visitors came from.
And if both protocols answer, the site exists twice. Links split across the two versions, and a crawler has to work through both to find the same content.
Common mistakes with the move to HTTPS
The most frequent is installing a certificate and stopping there. The secure version now works, but the plain version still answers, so nothing has actually been consolidated. The second is redirecting through several hops — plain to secure, then across hostnames, then to fix a slash — when one rule could send each request straight to its final address.
After that come the leftovers: internal links and canonical tags still written with the plain protocol, an XML sitemap listing the old addresses, ad accounts pointing paid clicks at a URL that redirects, and images or scripts still requested insecurely, which is what causes mixed content warnings.
How to act on it
Get a certificate covering both the www and bare forms of your hostname; hosts commonly include one, and Let’s Encrypt issues them at no charge. Then redirect every plain address permanently to its secure equivalent, in a single hop, keeping the path intact so each page lands on its own counterpart rather than the home page.
Update internal links, canonicals, the sitemap, hreflang and ad final URLs to the secure form. Clear any mixed content the pages still request, add the secure hostname in Search Console, and only once everything is stable consider adding HSTS so browsers stop trying the plain version at all. Confirm the whole thing with a crawl before you call it done.