Switching from http to https and back

[doc_z]

Although this topic has been discussed more than once I want to share my experience. See also "Has anyone moved back to http from https?" [webmasterworld.com]

I switched a large site from http to https at October 3rd. From that day traffic and ranking drops continuously. For a long time I thought that this is just a temporarily effect and everything will recover. Therefore, I was giving it time. During the next weeks I had some small technical problems, but I'm sure that they were not related to the drop. After 12 weeks (December 23rd) I decided to switch back to http. I know that this wasn't a guarantee for recovering but at least I want to try it.The next week traffic was recovering a little bit. However, this might be due a general traffic increase at January compared to Christmas. At least the continuous decrease was stopped, but since than everything was unchanged.

This behaviour was reported before from others members. Therefore, it isn't just a single case.

Diagram: [suchmaschinen-doktor.de ]

[keyplyr]

I saw no negative impact on speed after switching almost 3 dozen sites. I tested every single page on every site, often more than once. This is part of any normal optimization process.

You can try to find negative things about HTTPS but there just aren't any.

[seoskunk]

You can try to find negative things about HTTPS but there just aren't any.

Apart from some members reporting a sudden drop in rankings after switching due to suspected increased filtering of inbound links

[mosxu]

How fast a certain tool downloads a website is no indication of a fast website.

Every page loaded by a user has to be measured and https Is slow compared to http

Chrome measures every page... me thinks

[Peter_S]

Every page loaded by a user has to be measured and https Is slow compared to http

It depends on the hardware on which your site is running, and your HTTPS configuration. If your site is running on old hardware, or crowded shared host, then yes, the server will have more difficulties to handle the extra encryption.

But otherwise, "nowadays", there is no reason for a site to be slower when served in HTTPS.

- Use HTTP/2, by itself it will already boost the performances. You can also exploit the push feature to send CSS, JS, etc...

- Use ECDSA instead of RSA,
- Use AES algorithms when serving pages to desktops and Chacha20 for mobiles,

To go further:

- Activate TLSv1.3 (the standard is not yet finalized, but you can use draft 18 or 23 without problem)
- Activate QUIC (but only very few web servers handle it already).
- OCSP stapling might help a little bit, but often it's ignored by browsers.

and your site will be faster than in HTTP/1.1

Don't forget to serve chunked pages so that fragments of page start downloading even if a dynamic page is not finished generating on the server side.

[IanKelley]

Some good tips above, and there are other things to look at as well (google for more) because this:

I saw no negative impact on speed after switching almost 3 dozen sites. I tested every single page on every site, often more than once. This is part of any normal optimization process.

You can try to find negative things about HTTPS but there just aren't any.

Is just silly. Absolutely sites on some servers will see very little impact. On other servers there will be a large impact. HTTP and SSL aren't some perfectly packaged snap ins that are implemented the same way on every server.

With modern hardware and connection speeds, SSL overhead can be small enough to be barely noticeable but, depending on your setup, you may have to do some work to make that happen.

Also keep your audience in mind, if a significant amount of them are accessing via older devices, over slower connections, SSL is going to have a noticeable impact for them even if you can't see it yourself.

[keyplyr]

...sites on some servers will see very little impact. On other servers there will be a large impact.

HTTPS isn't the culprit there, HTTPS is a protocol, nothing more.

You identified one possible issue... it's the configuration of how things are set up on the server. If HTTPS itself was at fault, then everyone would have the same issue. That's not happening, so for those who saw a negative impact, it must be something else, albeit related to the switch.

I've identified 2 issues that could possibly play a role in a negative experience when switching to HTTPS.

1.) Losing ranking:
• May partly be explained if using an old disavow file that included the HTTP protocol. This file should not include protocol at all, just list domain and when applicable, the directory or page/file.

2.) Losing traffic:
• May partly be explained by a significant older age group or 3rd world traffic metric that uses hardware/browsers that do not support SNI and/or HTTPS.

There are many explanations of what could go wrong with a change as significant as this. We don't know how everyone has set up their server, or how shared hosting accounts are issuing security certificates or their paths.

One thing is certain, HTTPS is here to stay, and I can easily imagine even more security measures put in place in the future. If a web page is not secure, it may become irrelevant.

[Wilburforce]

how shared hosting accounts are issuing security certificates or their paths

I don't have any details, but my host has just issued new certs for all shared hosting accounts because Chrome/Google was showing warnings on some sites with valid certificates. Obviously, therefore, there is at least one issue associated with this.

[IanKelley]

HTTPS isn't the culprit there, HTTPS is a protocol, nothing more.

You identified one possible issue... it's the configuration of how things are set up on the server. If HTTPS itself was at fault, then everyone would have the same issue. That's not happening, so for those who saw a negative impact, it must be something else, albeit related to the switch.

I'm not sure I understand what you're getting at. No one is saying there's something fundamentally wrong with the HTTPS protocol. Implementation is what varies, and no matter how you spin it, that's a real thing that has an impact on some people.

[keyplyr]

Yes, it is how some implement HTTPS. Once again for those interested...

- Generic Steps to Switch from HTTP to HTTPS -

• Read all info at your host concerning certificates & switching to HTTPS and when applicable, follow those instructions.

• Install security certificate.

• Have your host enable HTTPS (if needed.) This will enable access from both HTTP & HTTPS allowing normal access while you test.

• Go through site, page by page & make sure all file paths are relative (no protocol.) Test by accessing site using HTTPS and look for any browser alerts.

• Install 301 code in .htaccess file

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Note: your server may require different code

• Go through site again, page by page, and test. Any remote absolute links will need to be HTTPS including those found in scripts & pluggins. If you publish Adsence or other advertising, links in these scripts need to be HTTPS also (or just remove the protocol altogether.)

• Update sitemap.xml (if applicable) and submit to appropriate agencies (Google, Bing, Yandex, etc)

• In Google Search Council create a new site using HTTPS (do not use the Change of Address form.) It will take a few days to start populating information. This is normal & traffic to old site (HTTP) will drop off accordingly.

• Bing Webmaster Tools, Yandex & others should update automatically once they crawl your new pages. Updating/re-submitting sitemap.xml should speed up this process.

[samwest]

Bad 301 redirects and mixed content are the likely problem. Are you running WP? If so, use a plugin like "Really Simple SSL" to handle the mess. I diagnose my issues with Screaming Frog and find the code using String Locator. It will likely show you where your problems really lie. I've had single issues that manifest in dozens of cache results. Most of these were related to unsecured affiliate links and images, so don't overlook those.
I'll bet you still have more than a few pages that come back as http;//. I personally think is was very unwise to switch back without doing a thorough diagnosis and giving more that a 12 month chance. Like many have said here, eventually it will be required. Moving forward, Aways start a site out with https:// using a free SSL cert like Let's Encrypt to avoid this messy situation. Bottom line, when it comes to SSL, close enough is not good enough.

[RedBar]

Bottom line, when it comes to SSL, close enough is not good enough.

Absolutely, I had two sites supposedly running the same template and style sheets, my old non-responsive sites. One validated https the other wouldn't.

I banged my head aginst the wall for days yet couldn't find the problem so eventually uploaded the validated site scripts and, hey presto, it worked.

I've compared these two style sheets etc and cannot find any difference in them however there must be something somewhere!

FWIW all my responsive html 5 sites validated first time.

[samwest]

I forgot one other useful site to help you diagnose your SSL pages - Google the term "Why No Padlock" or JitBit. I use it all the time. I'm using it now, because even after switching years ago, I seem to keep finding issues on old pages. Converting an large, old http site can be like trying to plug holes in the proverbial dike...it never seems to end.

[londrum]

some people definitely suffer when they switch over because i was one of them. https fans might not like to admit it, but it's true. (people sure do get defensive when it comes to talking about https - it's almost like you're having a pop at their football team!)
Everyone says oh yeah it must have been this, that and the other, you didn't do the 301s, redirects, canonicals, server settings, etc, but I checked everything about ten million billion squillion times and passed that Labs test - everything was fine.
who knows what the reason was, but it can all be traced back to the moment I switched over.
when i switched back i got some of the missing traffic back (but not all of it)

[RedBar]

who knows what the reason was, but it can all be traced back to the moment I switched over.

Which type of server are you using?

My sites are hosted on Plesk servers and it was a breeze to use once I knew what to do since it has Let's Encrypt built into its system. All it needed was another couple of checkboxes and 5 minutes later a site was encrypted with no further work necessary ... PLUS it was free:-)

[bumpski]

All you have to do is enable your network stats on your browser and type in google.com on the address bar: There's a 301 redirect to a 302 redirect, before the visitor even starts loading google's extremely slow home page. I've posted about Google's own performance degradation in the past. Please stop needlessly changing to https, if you have a need, great, I'm all for it. But I don't like (Waiting for TLS!)

Google's home page, who doesn't type "google.com" into their address bar.
[webpagetest.org...]

As a 3.2 Mbps DSL user the incredible waste, of needless transition to https, with all of the incredible excess padding, has trashed the internet's performance. I truly doubt many claims here of no performance degradation actually measure up, for low bandwidth users.
Google transitioned to https so no intermediaries could capture the search keywords. Is that your reason? Why did you do it? Because all the other kids did? You can support both, but that's more work.

It's like Microsoft, they must test with high bandwidth links and many, many gigs of memory, it's tiresome, WIN 10 needs 2 gigs just to start!.

[Peter_S]

The concept behind switching to HTTPS is not necessarily to make the Internet faster, but to make it more secure.

[lucy24]

who doesn't type "google.com" into their address bar

Who does type "google.com"--or anything else--directly into their address bar? You and me and the readers of the current forum, but ordinary humans, nuh-uh. Just try telling someone to go to suchandsuch site. Look over their shoulder, biting your tongue if necessary. They will do everything in the world except enter the sitename into the address bar. Even if they do start typing, the browser will helpfully make suggestions based on past visits, and they'll grab one of those suggestions.

Be that as it may: by the usual predictable coincidence, it is only an hour or two since I noted something similar while testing an unrelated bit of code. If I type "example.com" into my browser's address bar, the browser (current Firefox) sends the request along as HTTP. If I had not been testing a rule that kicks in before the HTTPS redirect, I would never have noticed. It occurred to me at the time (i.e. earlier today) that this is yet another thing browsers will eventually change. By and by, HTTPS will become the default when no protocol is specified.

[bumpski]

Google had a "yuge" financial reason to switch to HTTPS; no intermediaries could spy on the keywords used in a search.
Nobody has a specific answer why THEY switched they all did it just 'cause Google did! All the other kids did it!

What is your reason for slowing down the internet for low bandwidth users? I see no reason for all the security except for the uses for which it was already properly being used.

I actually have the load times for Google before and after they switched and there is a big degradation, as is the case with all sites needlessly switching to https.

[Errioxa]

all did it just 'cause Google did!

You right, always the same, Google going to make us jump through hoops, AMP, HTTPS, Android... What will be the next step?

[vegasrick]

We moved our biggest site over last Tuesday (I think). A 15 year old site with 4 million uniques per month.

Based on what I can tell, the majority of our link juice has remained, majority of keywork ranks have remained..

Has there been rank loss? Yes there has for certain keywords. Could be temporary, who knows at the moment.

For our third largest keyword in terms of organic traffic, we dropped from number 2 to number 6. What really steams me, is the five sites now ahead of us are all using HTTP and get less traffic than us... I'd say three of them get far less traffic.

[bumpski]

Here are some tips and they could impact ranking. (See secret subdomains below.)
If you do support both http: and https: and allow Google to crawl both, you may see duplicate listings in Google SERPS, it certainly was true when Google first started crawling both protocols.
So make sure you use:
<link rel="canonical" href="http://www.example.com"> or <link rel="canonical" href="https://www.example.com"> on your web pages, choosing appropriately for however you desire your site to be indexed (example.com or https://example.com shown in the Google SERPS).
I dynamically add the canonical link on https:// pages pointing to the http:// version, in doing this when Google initiated crawling both protocols the duplicate SERP listings disappeared quickly.
In doing this you can also avoid one of the many causes of the infamous Google message:

"In order to show you the most relevant results, we have omitted some entries very similar to the 214 already displayed.
If you like, you can repeat the search with the omitted results included."

Many Webmasters have probably used redirects to fix this but the canonical tag will work as well.

Finally the most subtle problem that may make Google think there are four copies of your website, if you allow http: and https: versions is, the secret subdomain the webhosts invariably supply low-end webmasters. Your webhost is "example.com". Your secret webhost subdomain is; some "mangled version of your domain" "mangledversiondomain.example.com". (Or your webhost may use another domain entirely for this purpose) Your webhost allows Google to crawl this subdomain copy of your entire website, AND, your webhost provides both an http and https version of your site, with all links modified to work correctly. Google indexes hundreds of thousands of these copies of sites and webmasters have no idea! Normally you will not see these copies of your site in Google's result, but still they are indexed by Google. So your site's content may have been indexed under https: before you even started to migrate to https!

If you are a low-end Webmaster, figure out your secret subdomain and then use Google's "site:" command to see if it is indexed. Then again, use "link rel canonical" to remove both the http and https copy of your "secret subdomain" content from Google's index. My webhost's have assured me, time and again, Google will not find these secret copies; it's just not the case, Google knows ALL!

[keyplyr]

@bumpski -
5 common mistakes with rel=canonical [webmasters.googleblog.com]

[bumpski]

@Keyplyr Good reference for webmasters!

Just a note regarding secret subdomains and eliminating them from Google's index:
I realized I had also followed up with:
"X-Robots-Tag:noindex"
in the response header of all the pages using the webhost's secret subdomain for my sites.
So I'm happy to say I never see Google's message:

"In order to show you the most relevant results, we have omitted some entries very similar to the 214 already displayed.
If you like, you can repeat the search with the omitted results included."

But all this potential duplication of content with secret subdomains and http:// and https:// may well be affecting Google's ranking of some websites that try to migrate their content from one protocol to the other.

[vegasrick]

From what I can tell, almost no effect on Google after 3 weeks of switching from http to https. Some rankings fell for a few days, but are now back to normal.

On Bing and Yahoo however, some serious rank droppings. I can't even find the site under certain keywords. We had one keyword rank on Yahoo at number 2 for the last 12 years and now long longer found. Ironically, we're getting more traffic these days from both - but that could be Yahoo News and Bing News.

[keyplyr]

On Bing and Yahoo however, some serious rank droppings. I can't even find the site under certain keywords.

I found it really helps to resubmit your updated sitemap.xml to Bing. This reduces the time it takes them to reindex all those new URLs with HTTPS.