What will happen if I don't switch to HTTPS?

possible downside of non-secure pages

[keyplyr]

Many site owners are still deciding if or when they will follow the new SSL standard of using a security certificate and switching to HTTPS.


Possible downside of not switching to HTTPS*

• Visitors may start to decline. As discussions about secure web sites become more popular, visitors may avoid non-secure web sites.

• Browsers are still transitioning but the warnings will get more explicit for ALL pages, not just Credit Card or forms. These warnings may further scare off visitors.

• Google has made statements that secure sites will gain advantage in mobile & desktop SERP. HTTPS is already being displayed for secure sites. Bing & other Search Engines will surely follow.

• Eventually, non-secure websites may be considered unsafe to users and purged from SERP altogether.

• Browser support for HTTP/2 protocol is only for HTTPS websites. This protocol greatly speeds up page loads. If your site is not secure, you will not benefit.

*Possible scenarios, no one knows for sure.

[IanCP]

Interesting. Unfortunately given it appears a certainty both Google and Browsers will force sites to move to https, it does impose some burden upon "informational only" sites with traffic <100,000 a month. Informational sites upon which the internet was largely founded before big $$$$ changed the face of it.

Many of these sites do not receive any information from visitors [credit card/login/form filling], nor are they necessarily monetised. I've already seen conflicting advice on cheap/free SSL certificates adding to the confusion.

Across the informational forums of my genre, many are/were unaware of the potential problems ahead. Most consider it another pain in the backside. My main current host of 17 years had this to say:

In general... I would recommend using ssls.com for a cheap SSL cert. There's also Let's Encrypt, but those require renewal every 90 days still, which is a pain.

Once you install the SSL cert, you can add .htaccess file redirects to point everything to https and then ensure all your site pages request over https as well, to avoid the insecure content warnings.

For your site, what website content editor do you use to make the HTML pages?

Worst case, I can help and use SSH to globally (in all site files) search/replace

http://your-site.com/ to https://your-site/,

that should do it for the most part.

[robzilla]

I won't get into informational sites needing HTTPS again, but one of the best things about Let's Encrypt is actually that it's relatively easy to set up automatic renewals. So rather than renewing every year or so, which is still a pain, you set it up once and you never have to worry about your certificates expiring again. More and more tools are becoming available to make this easier.

[Libre]

For the ones who are on linux and want to change all the http urls to https urls you can use the follow command:

find /path/to/httpdocs/ -type f -exec sed -i 's/http:\/\/www.example.com/https:\/\/www.example.com/g' {} \;

That saves a lot of time!

[guggi2000]

@IanCP There seems to be a notion that the word "http" needs to be replaced with "https" in the internal linking structure.
Not true! https should rarely appear in your files.

Assume you need to use absolute links (relative are better if on the same domain), try to use // instead of https://
This way it will work on both protocols and you can change gradually.

Example, let's say you had a resource to an external static image like this:

<img src="http://staticfiles.example.com/myImage.jpg" >

change that to

<img src="//staticfiles.example.com/myImage.jpg" >

(It may be off topic but the advice your hosting company gave is a little risky, sorry... don't do auto-replace on that scale)

[IanCP]

<img src="//staticfiles.example.com/myImage.jpg" >

Thanks - my sites internal links were always done that way

A General Question for all

Somewhere in the back of my mind there was a general A - Z guide on these forums for switching from http to https. I haven't been able to find it again.

[IanCP]

Well the switch over to https occurred with minimum fuss and heartache - I just forgot about some scripts which has now been promptly remedied.

Thanks to keyplyer and others for their input.

The best part is the browsers IE, Firefox, Chrome, and Opera all show a secure website. The Edge doesn't show a secure lock, but it doesn't complain either.

I had to revise my AdSense ads - that was overdue anyway.

Thanks again all.

[guggi2000]

@IanCP when did you switch? Are all pages HTTPs in the serps?

[IanCP]

Switched in the last 24 hours. As for SERPS? We will see.

[keyplyr]

Edge does display its version of a secure lock. Probably need to refresh the page.

If it's the site in your profile, I'm getting a warning with Chrome 56 mobile for Android.

[guggi2000]

@IanCP You will only be able to tell in a few weeks regarding SERPs or SEO...

Glad the tech side went well 4 u

[IanCP]

@ keyplyer

I've fixed all my own scripts, also updated every AdSense ad etc.

Now using a useful tool called "Why No Padlock?" It identified a list of olden day scripts [Number of insecure items: 13] all going externally to facebook, amazon google analytics, google+ etc.

I'm working on updating/deleting them. Try and remember what and why stuff from well over a decade back?

[IanCP]

Update -

"All 47 items called securely!"

[keyplyr]

Good work IanCP :)

[IanCP]

Thanks for your contribution.

BTW: Comodo merely regard SSLS.com as nothing more than a "reseller" - so take your problems to them, not Comodo. Actually a person I had contact with at Comodo referred to them as "El Cheapo".

PS: A lot of the scripts I had to fix/update?

Probably weren't really working properly for a long time, denying me any potential benefit [if any] of having them. Google Site Search was one prime example.

[robzilla]

Actually a person I had contact with at Comodo referred to them as "El Cheapo".

Compared to Comodo's own prices, they (and other resellers) certainly are cheap. Or rather: Comodo is super expensive, 15x the price... for the same product.

[Lcurr]

My information site is still on http and I recently tried adding a discussion forum. Firefox warns off users who wants to register to post topics due to the site not being a secure site.

I'll need to make the switch, I think.

If anyone knows of the Guide for switching that @IanCP mentioned, please post the link!

[IanCP]

I couldn't find that link so I simply went ahead and Googled:

"steps to switch website to https"

You should hopefully get lots of guides from authoritative sites. Don't read just one, read many.

[Lcurr]

Thanks, Ian.

Okay, so I had a quick look at the one published by Search Engineland. I'd rather remove my forum, lol! In fact, I might look at building a community in FB rather than through my website.

Decisions, decisions...

[not2easy]

There are a couple of previous discussions for the change from http to https that have "Checklist" as part of the title:
[webmasterworld.com...]
[webmasterworld.com...]

Because they are a little dated I think there is more current and valid (today) information right in this thread.

[keyplyr]

- 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.

• Go through site, page by page & edit all file paths to relative (no protocol.) Test by accessing site using HTTPS and look for any browser alerts. Absolute paths need to be HTTPS.

• 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 a 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 & plugins.

• If you publish Adsense or other advertising, links in these scripts these 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. 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 should update on its own once Bingbot crawls new pages. Submitting updated sitemap.xml should speed up this process.

Again, your host may require a different set-up.

[edited by: keyplyr at 11:44 pm (utc) on Mar 17, 2017]

[Lcurr]

Thanks, @not2easy.

I had a look at the checklists. I'll have to figure out changing the whole site - mine's not yet mobile-friendly either so I need to do that as well. At least I don't have hundreds of thousands of pages to consider (...what kind of info site can have so many pages unless they have an army of writers?...).

Mine's got enough pages to make it a headache - especially since I'd like to preserve the status quo as the site has not been affected by the search algo updates and has been really steady for the past few years, and progressing well since I've been working on it again.

[Lcurr]

Oh, just saw your post, thanks, keyplyr. That list is really useful. I'll need to set time aside to look into this and contact my host as the first step. Good point.

[IanCP]

@ Lcurr

I'd rather remove my forum

Unrelated to https issues, my folks voted some time back to use Google gmail forums for my 20 years old forum.

Setting aside the forum issue, you also need to consider the very important ongoing negative impact a non-https site has with modern browsers.

I think the issue won't go away, it can only worsen with time. Browser security warnings will eventually kill off many sites which don't change.

[guggi2000]

Since @keyplyr already mentioned some htaccess code. Which one do you use for the redirect?

1.
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.example.com/$1 [R,L]

2.
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://www.example.com/$1 [R,L]

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

[edited by: phranque at 11:06 am (utc) on Mar 18, 2017]
[edit reason] unlinked substitution url for clarity [/edit]

[keyplyr]

They all do the same thing. Some server set-ups will require dommain name, others can use HOST. As mentioned above, refer to instructions at your host. Nobody here can tell you exactly what works best at your server except your host's admin team.

[phranque]

1. RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.example.com/$1 [R,L]

2. RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://www.example.com/$1 [R,L]

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

if you specify the R flag without specifying the status code for the RewriteRule, it will default to a 302 redirect.
in most cases of hostname canonicalization you want to use a 301 redirect.

whether you test the SERVER_PORT or HTTPS environment variable makes little difference, assuming your non-secure web traffic always comes through port 80. (which is fairly standard)
however, you probably want to make either of these a lexicographical string comparison rather than a regular expression comparison:

1. RewriteCond %{SERVER_PORT} =80

or...

2. RewriteCond %{HTTPS} =off

if your dns and web server are configured to accept requests for both example.com and www.example.com hostnames, then you don't want to just spit %{HTTP_HOST} back out in the RewriteRule substitution string since that environment variable value may not contain the name of the canonical hostname - it is the user agent-requested hostname.
in this case you want to specify the canonical hostname in the substitution string.

also if your dns and web server are configured to accept requests for both example.com and www.example.com hostnames, then you should probably want to add a non-canonical hostname test for your host canonicalization ruleset(s):

RewriteCond %{SERVER_PORT} =80 [OR]
RewriteCond %{HTTP_HOST} !^(www\.example\.com)?$
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

[TorontoBoy]

I asked A2 about the cost of switching to https:

Let's Encrypt SSL certificates are free of any charges, and can be applied to all of your domains. The only requirement is the domains do have to be pointing to our server before we can apply the SSL certificates.

There are no additional costs for adding free Let's Encrypt SSL certificates for https for any domains on your account.

So far I only have informational sites and see no need, but will continue to monitor. More complexity must be balanced by commensurate benefit.

Turning the internet to https will be like turning an oil tanker. The momentum is enormous and forcing sites to switch will not be easy. There must be a substantially tangible benefit for them.

[vivalasvegas]

I have just switched 2 of my websites to https using the free certificate offered by CPanel in partnership with Comodo. Very easy process. I'm surprised not many people mention this option.

Since the switch I have noticed an added latency to my pages' load time. However, I haven't read many complaints about it. Is everyone using a CDN and a server that supports http/2?
I have neither of the two, which according to this post [webmasterworld.com ] are good ways to improve speed.

[robzilla]

HTTPS over HTTP/1.1 is going to be a little slower than HTTP due to the extra handshakes required to set up a connection. If you can, it's a good idea to upgrade your web server to support HTTP/2. Further improvements to HTTPS are coming, like TLS 1.3. Run your site through the SSL Labs tool to see if everything is configured properly. There are lots of little optimizations for HTTPS [hpbn.co] but if all you have access to (or are comfortable with) is cPanel, it may be difficult to implement them. HTTP/2 will likely be your biggest win, so I'd start with that.

[keyplyr]

Sadly, many (most) shared hosting does not yet support HTTP/2 and since it's a big switch on their end (the way they explain it) the several I've asked have no plans to do so. This may become a significant selling point for hosting services.