HTTPS and SEO: what it actually changes

Moving a site to HTTPS changes four things concretely. Ranking is one of them, and it is by a wide margin the least significant, which is unfortunate, because it is the one everybody argues about. The other three are visible immediately, they can be measured, and they cost real money until they are dealt with.

The four effects, in order of real importance

The right-hand column explains the order in the left-hand one: the first three effects can be observed, the fourth has to be assumed.

1. Browsers label the site

This is the real cost of staying on HTTP, and it has nothing to do with search engines. Modern browsers mark plain HTTP pages as "Not secure" in the address bar, and show an explicit warning as soon as a form asks for anything: an email address, a password, a phone number.

Your visitor does not know what a protocol is. They know the browser is telling them something is wrong, at the precise moment you are asking them to trust you. It is a conversion problem before it is a technical one, and on its own it justifies the migration.

2. You lose your referrer data

This one surprises people. When someone clicks from an HTTPS page to an HTTP page, the browser sends no referrer at all. The destination cannot tell where the visit came from.

Since almost the whole web is now on HTTPS, an HTTP site sees a large share of its incoming traffic recorded as "direct". You are not missing the visits: you are missing the ability to know where they came from, which is worse, because it quietly corrupts every decision you make from analytics. A channel that works perfectly well can look useless for months, and get cut.

3. Certain browser features stop working

Geolocation, service workers, camera and microphone access, notifications, and a growing list of modern APIs only run in what browsers call a secure context. On HTTP they simply do not exist.

This is not a warning you get in advance; the feature just fails, often silently, and the developer who picks the project up spends half a day hunting a bug that does not exist.

4. Ranking, a little

Google has said for years that HTTPS is a lightweight signal: the kind that separates two otherwise equivalent results. It is real, and it is small. A page that is not ranking is not being held back by its protocol.

Treat it as the fourth reason, not the first. And be sceptical of stories about sites whose traffic jumped after moving to HTTPS: in almost every case the migration came with a URL clean-up, proper redirects and a regenerated sitemap, and that is the work that paid.

How long before you see an effect

This is the question that always follows, and the honest answer is a little disappointing.

The first three effects are immediate: the label disappears with the first page served, the referrer comes back with the first click, the browser APIs work on the next reload. Nothing to wait for, nothing to watch.

The fourth is invisible. The new URLs have to be crawled, the old ones have to give way, and for a few weeks both versions coexist in the index. A temporary dip in traffic is normal during that period, and it says nothing about the quality of the migration. What does say something is the share of old URLs answering properly after a single redirect.

The practical rule: judge an HTTPS migration on its redirects, not on its traffic curve two weeks in. The curve comes back; a forgotten redirect does not.

What HTTPS does not do

This needs saying, because the word "secure" causes a lot of damage.

HTTPS encrypts the transport between the browser and your server. It does not make your site safe: an application flaw, a weak password or a compromised plugin remain exactly what they were. It does not hide which domain was visited, only the path and the content. And it says nothing about the honesty of the site: a phishing site gets a free certificate in three minutes, exactly as you do.

The padlock means "this connection is encrypted", not "this site can be trusted". That confusion is widespread, including among serious people.

The part that actually deserves care

Switching to HTTPS means every URL on your site changes. http://example.com/guide and https://example.com/guide are two different addresses as far as search engines and your own internal links are concerned.

So it is a migration, with the usual work: a redirect for every old URL, canonical tags updated, sitemap regenerated, and, the one people forget, absolute http:// links written inside the content, which keep pointing at the old protocol and trigger a redirect for every reader. The migration link check-list covers the whole sequence; nothing about it is specific to HTTPS, which is exactly the point.

One thing deserves watching in the following weeks: URLs that answered over HTTP and have no HTTPS equivalent produce 404s in bulk. Not all of them deserve a fix, but the ones another site still points at do, and they come first.

Mixed content, the failure that comes next

A page served over HTTPS that loads an image, a script or a stylesheet over http:// produces mixed content. Browsers block the scripts and stylesheets outright, and flag the rest.

The symptom is disorienting: the page displays, the layout is broken, and no server error appears anywhere. The browser console is the only place that says so. That is why an HTTPS migration is verified page by page on the main templates, and not just by checking the padlock on the homepage.

HSTS, enabled knowingly

The Strict-Transport-Security header tells the browser to use HTTPS only for your domain, for a duration you set. It is good practice, and it is also a commitment that is hard to undo: while the duration runs, a visitor who has been before can no longer reach your site over HTTP, even if you wanted them to.

The sensible method is to enable a short duration, verify that the whole site and every subdomain answer properly over HTTPS, then extend it. The reverse, a one-year duration set on day one, turns a forgotten certificate on a subdomain into an outage nobody can work around.

And then it needs maintaining

A certificate is not a one-off purchase. It expires, and when it does your visitors get a full-page security block rather than a discreet warning, usually because an automatic renewal failed silently weeks earlier.

And that failure looks like nothing your tools are watching: the server answers, the site is up, and yet nobody gets in. It belongs to the same reflex as the first fifteen minutes of any incident, namely looking at what a visitor receives before looking at what the machine believes it is serving.

One last effect, visible only from outside: every link other sites gave you now points at a redirect. They all keep working, and they all take one extra hop. What becomes of a backlink when your URLs change is worth reading before the switch, not after.

The move to HTTPS is a day of work. Keeping it valid is the ongoing part, and it is the one that actually costs people traffic.