website design

Website Design, SEO, SMO

If you’ve been paying attention then you already know that Google announced back in 2014 their intention to use HTTPS as a Ranking Signal.  So, this article is focused on how you can actually switch your site to HTTPS as smoothly as possible.

Example of a Chrome v38 visit to site with broken security certificate

SEO SSL

This is the biggest update that Google has done in years because it affects every single website evenly across the board. It’s not about links, or negative associations, SEO or even the quality of your content. It’s about paying your dues to get a Secure Certificate and taking the time to get it in place correctly. Google has just drawn a very clear line in the sand. Our Advice?…step over to this side of it with us and we’ll show you how you can migrate your site to HTTPS and stay in Google’s graces long term.

Migrating your Site to HTTPS

If you’re ready to dive in and convert your site, be sure to read through the following section – don’t skip over it as we’re going to review important things you need to be aware of.

TLS or SSL?

As you go through this process, you’re going to hear both mentioned often. Just be aware that SSL (Secure Sockets Layer) is now part of an overall security protocol known as TLS (Transport Layer Security).

Hosting Account Changes

The 1st step you’ll need to make in order to switch over to a secure server is to check with your Web host to see if they offer the secure server service and if you’ll need to update your account. Or, if you self host, you’ll need to talk with your IT team about this as well. Almost all hosting companies offer secure servers and in many cases will also assist you with setting up and/or sell you a secure server certificate. It’s very likely you will have to upgrade your account to a higher level as you will likely need to get a dedicated IP address if you don’t already have one, but these upgrades are often only a minimal fee.

Google also suggests using a web server that uses HTTP Strict Transport Security (HSTS) and it should be enabled. This would be a great idea when you have 100% HTTPS content on your site, but you would not want to use HSTS if there is a need for mixed secure and non-secure URLs on your site. HSTS tells the browser to request HTTPS by default even if someone enters in HTTP in the address bar. It also tells Google to use HTTPS URLs in the search results for your site.

Note that you don’t have to buy your Certificate from your web host, there are many purchasing options available with different pricing.

What you need to Know BEFORE Buying a Security Certificate

An important point to keep in mind with certificates, a £19 2048-bit certificate is very similar to a £199 2048-bit certificate. They both work exactly the same, but there are a few differences. For example, some are more compatible with mobile browsers than others. It’s up to you to choose how much you want to spend on this, just be aware there is no basic difference in how the certificates work.

Conversion wise, there may be some better brand recognition in regard to SSL logos that many like to display on their sites which could lead to conversion differences, but we don’t really have enough data to report factually on that possibility. The type (DV or EV) of SSL certificate really has more impact on conversions than the SSL logo you “might” display in the footer of your site. For this article, we’re referring primarily to DV certificates.

If you want to save money on the certificate, say you’re working on a charity site or something, there are free SSL certificates available from letsencrypt.org. Note: This option will likely require more technical expertise than most commercial certificates.

Domain Verification (DV) Certificate Options

  • Single Domain Certificates– Single name certificates cover one domain name, such as domain.com. Some single name certificates cover both www.domain.com and domain.com variations, some will not. Make sure to check on this before buying your certificate. Ideally you would want both variations covered if possible.
  • Multi-Domain Certificates– These certificates cover multiple domain names with the same certificate. This version works best for groups of subdomains that don’t change often, such as www.domain.com, cdn.domain.com, domain.com, mail.domain.com. There is a limit as to how many will be covered, for example up to 25 domains per certificate.
  • Wildcard Certificates– Wildcard (*.domain) SSL certificates cover your primary domain name plus any additional subdomains ( www.domain.com, mail.domain.com, domain.com, shop.domain.com, etc.). They will not cover multi-tier subdomains such as sub1.sub2.domain.com. You can get a wildcard option for DV, OV and EV types of certificates for an extra fee.
  • 2048 Bit Key– Google highly recommends getting a 2048 bit Key Certificate, which is the standard offered now. If you have an older certificate, you should upgrade to one that uses 2048 bit encryption.

 DV Certificate Installation

Before purchasing the certificate, you will need to generate a Certificate Signing Request (CSR). This is an encoded file that identifies your company and domain name plus it includes your public key. Your server host will most likely have a form for you to fill out to generate this file, so view their instructions or contact them for instructions for CSR file generation. Once you get the file, you’ll need to upload it to your server in a public location and send the location and/or the file itself to your Certificate Authority when purchasing your Certificate. Most hosting companies will have detailed instructions on how to do this as it may be unique to your host.

Once you get your certificate you will upload those .crt files and the CSR file to the server as well, then provide the file locations to your host or email the files to them for installation. There are a few more steps to the server setup process that are required, however most hosting companies will do those steps for you.

Update Your On-Site Links

If you’re switching to a totally secure server (all URLs), make ALL of your on-site URL references into relative URLs

Example: <a href=”page.html”> NOT <a href=”https://www.yourdomain.com
/page.html”>

Not only does this make all your onsite links protocol neutral (both https or http will work) but it will also allow you to work on your pages on your local machine without browser security warnings. There are some situations where you may want to use absolute URLs and that’s ok, but you do want to avoid using HTTP on-site links on your HTTPS site, that can be a source of errors and unnecessary redirects slowing page load time down.

This includes – image links, links to onsite resources such as Javascript, CSS files, PDF files, scripts, iframes, etc. Yes, it’s a lot to review!

Update Off-Site Links

You’ll also want to change any off-site links to be protocol neutral, which means removing the http (or https) part of the URLs.

Example: <a href=”//www.domain.com”> NOT <a href=”http://www.domain.com”>

This will prevent potential security warnings when people click an off-site link. We expect these browser warnings to be increasingly bothersome over time, taking this step now may help avoid issues down the road.

Is it time to Nuke the WWW?

If you’ve been thinking about dropping the “WWW” from your URL, this is an ideal time to make this switch. Since you’re going to have to redirect and update everything, this is an opportunity to shorten your URL in the process. The addition of WWW to domain names is actually pretty old, we did that in the past to differentiate between different services and ports, for example ftp.domain.com – yes, people actually used those.

Today it’s assumed any “domain.com” without the www, is going to be used for web browsers. Yes, you can drop it now if you want, people will not be confused, but it’s best to discuss this name change with your staff, client – whomever has a say in this before doing so! Some people will not want to change it…. If you do decide to make the change, you’ll have to include this with your 301 redirect methods that we’ll discuss next.

Redirecting HTTP to HTTPS

If you’re migrating from HTTP to HTTPS, you’re likely going to need to redirect your old inbound http links to https. On Apache servers, this will require modifications to your htaccess file. Of course this depends on if you’re doing a partial migration to https, or full, we’re assuming you would want to switch the entire site here in this discussion.

You need to carefully review any current redirects you have in place just as: redirecting from domain.com to www.domain.com, specific mod_rewrite instructions, and simple Redirect 301 instructions.

These all need to be updated to point to your new https URLs. For example, you may use something similar to the code we’ve included below – note we’ve added https to the rewriterule sections and we’ve added a site wide redirect from http to https at the bottom in yellow highlight.

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteBase /

RewriteCond %{HTTP_HOST} ^domain\.com$ [NC]

RewriteRule ^(.*)$ https://www.domain.com/$1 [R=301,L]

RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.html\ HTTP/

RewriteRule ^index\.html$ https://www.domain.com/ [R=301,L]

RewriteCond %{HTTPS}!=on

RewriteRule ^/?(.*) https://www.domain.com/$1 [R=301,L]

</IfModule>

For WordPress powered sites, we often add the commands in yelllow highlights below added to the standard WordPress .htaccess file, note these need to be placed right after the RewriteBase statement. Note: NGINX powered sites that often are used for WordPress will need to have the host implement the redirect for you, NGINX servers (unlike Apache) do not use htaccess files.

# BEGIN WordPress

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteBase /

RewriteCond %{SERVER_PORT} 80

RewriteRule ^(.*)$ https://www.domain.com/$1 [R=301,L]

RewriteRule ^index\.php$ – [L]

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule . /index.php [L]

</IfModule>

# END WordPress

Avoid Redirect Chains!

You need to carefully test all of your redirects for errors AND to be sure you don’t get in a situation that chains one redirect to another!

Stacked redirects, which cause serious issues for both your site visitors and Googlebot, need to be avoided at all cost. We suggest using the Screaming Frog spider to review your redirects. If you’re on a Microsoft or other type of server, contact your host or IT department to request assistance on generating these redirects in your server configuration.

Pro Tip: When putting your redirects in place you want to be sure you are using 301 from http to https NOT 302. With a 302 redirect you’re just telling Google “hey, we are just testing out https”. We’re putting a lot of emphasis on this because, just like chained redirects, it’s a common mistake.

Check your Page Load Time

Test a sample of your pages that are now secure to see if your load time has been impacted. HTTPS connections do load slower due to more requests, so expect to see some slow down. If the site is dramatically slower you need to investigate further.

Update Inbound Links

While getting everyone that links to you to change their links from http to https might be difficult, it would certainly make sense to at the minimum to update any inbound links to your server that you control so they don’t have to be redirected to your site. Sites like your Facebook Page, Google My Business Page, Bing Business Page, Yahoo Local, directory listings, etc. all would be good to get updated so visitors aren’t redirected.

Social Media Buttons and Widgets

When you switch your site to a secure server, most likely you will lose all of your social counts aka “likes”. That’s because all your previous counts were tied to your URL, which was at the time HTTP, when we switch the site to HTTPS, that’s a new, unique URL. Unfortunately most social sites like Facebook reset the counter when you do this.

You CAN retain your previous URL in many situations, but you’ll have to make certain you specify the URL for the like button on each page of your site using your previous absolute URL. For an example, let’s say this is your pre-HTTPS Facebook like button code for a hypothetical URL such as http://domain.com/services.html looked like this. If so, do not update the URL to your new HTTPS version.

<!– Load Facebook SDK for JavaScript –>

<div id=”fb-root”></div>

<script>(function(d, s, id) {

var js, fjs = d.getElementsByTagName(s)[0];

if (d.getElementById(id)) return;

js = d.createElement(s); js.id = id;

js.src = “//connect.facebook.net/en_US/sdk.js#xfbml=1”;

fjs.parentNode.insertBefore(js, fjs);

}(document, ‘script’, ‘facebook-jssdk’));</script>

 

<!– Your like button code –>

         <div class=”fb-like”

                 data-href=”http://domain.com/services.html”

                 data-layout=”standard”

                 data-action=”like”

                 data-show-faces=”true”>

         </div>

 

Some social Javascript buttons are setup to dynamically insert the URL to count so the same code can be used on every page, for those you’ll need to switch over to code that specifies the URL on each page in order to retain your counts (using your old URL). Another example would be the LinkedIn Javascript button, you’ll need to specify the URL by adding data-url=”http://domain.com/services.html” to the script.

For WordPress Sites that want to use a plugin for their social buttons, we highly recommend the Social Warfare Plugin which is capable of retaining your previous HTTP URLs for your page likes, even though your server is setup for HTTPS. If retaining those “like” counts are important, this is one of the few plugin options available right now that can do it.

Update Other Media

While updating Print, Radio, TV and other forms of advertising won’t be quite as important (they will get redirected regardless) it might affect other inbound links. For example if you advertise in a magazine, that magazine may have links to your site that get included in web versions of the magazine. A review of all forms of traffic should be done, and updated as the situation dictates. This is just a reminder not to forget these other formats. Don’t forget your email signature files, customer correspondence such as sales confirmations, and all your other on-line communications methods.

Important Migration Tips

Over the last few years we’ve learned a few things when migrating sites to secure servers. Here are the tips we found most important for you to be aware of.

  • Make use of a test server and/or site if possible to catch potential problems before making migration on your main site. Specifically testing extensive redirects needed can be problematic and create a ton of duplicate content if you’re not careful.
  • With the addition of https to a site, there can be massive duplication issues. Content can and will be indexed as both https and http unless you utilize 301 redirects to the secure version. Google may, or may not detect which version it wants to use. This is where you need to be sure that you’re telling Google, via a 301 redirect and/or rel=canonicaltags which content you want indexed.
  • Certificate misconfiguration problems ( Wrong IP address, www vs. non-www, subdomain, etc. ) can cause significant issues, make sure and test your certificates before going live!
  • Google Analytics works on HTTPS/Secure Servers. If you switch your site, you should update your configuration in GA, go to Admin > Property Settings > Default URL. You’ll see a drop down there for either http, or https. This would primarily apply if your implementing https site wide.
  • No Changes needed to Google Analytics Tracking Code, it already uses https.
  • Feedburner does not currently support https URLs.
  • Even though Google has stated there will be no link loss switching from HTTP to HTTPS, there is the potential that you may see some ranking changes.
  • Implement your 301 redirects quickly, Ideally at the same time you update to HTTPS. Do not let pages that you have changed URLs on to go 404, then decide to fix the broken links later. There is a theory, which we believe to be sound, that Google maybe discounting the link power over time for links that have went 404, then later redirected.
  • Don’t forget to update special landing pages, form and sales confirmation pages, and other URLs that are not part of the normal menu structure of the site.
  • Google Plus will follow the change from http to https so your Plus One’s should transfer.
  • HTTPS requires 2 additional browser handshakes to make the connection. This increases latency for your users.
  • It’s possible sites with AdSense Ads will see an income drop IF they switch to HTTPS – see Moving site from HTTP to HTTPS results in much lower earnings(Google Product Forums). This can be due to the requirement that the AdSense ads be SSL compliant, and they may not have the inventory to serve on your site.
  • Make sure that all ad networks you have on your site are HTTPS capable beforemaking the switch to HTTPS. Many ad networks are being very slow at updating to HTTPS.
  • Google suggests using self-referencing Rel=Canonical tag pointing to HTTPS version of the page. It’s also a good idea to check any rel=canonicals you’re using to make sure they point to the new secure URL. This is URL specific, if you have mixed secure and non-secure content, your rel=canonical tags should reflect this as well.
  • Use relative URLs for resources that reside on the same secure domain
    <a href=”page.html”>, not <a href=”https://www.domain.com/page.html”>. This will be very helpful when working with HTML files on your local machine and lower the chance of errors linking to a non-secure version.
  • Use protocol neutral links for off site links such as <a href=”//www.domain.com”>, not <a href=”http://www.domain.com”>to avoid browser warnings when users click through to non-secure sites. You can also use protocol neutral, but absolute links on site if you wish (we do here at SEN).
  • Be aware that all elements of your page must be HTTPS or Browsers may generate warnings. For example, embedding an image or Javascript from a HTTP site will generate a browser warning on secure pages. A good example is the Facebook news feed, it’s typically mixed https/http content and generates the lock with triangle error in Chrome.
  • Make sure to review your site’s Robots.txt if you blocked HTTPS URLs in the past.
  • HTTPS Ranking Signal is real time (doesn’t require a refresh).
  • HTTPS Ranking Signal is URL specific (not site wide). Technically you can switch incrementally.
  • HTTPS Ranking is calculated separately and is unrelated to Panda or Penguin, or other algorithms.
  • Google News is HTTPS compatible.
  • Google’s Change of Address tool in Google Search Console does not support HTTPS migration (yet). Google says 301 is sufficient.
  • If Googlebot sees a broken certificate on HTTPS, they will likely index the HTTP version instead (if available) for indexing. That can’t happen if you’re 301 redirecting HTTP URLs to HTTPS however.
  • Google uses the canonical URLs that are indexed, so if you’re serving the site on both (HTTP/HTTPS), but selecting HTTP as the canonical, then we wouldn’t see that as being indexed using HTTPS. This is across all Web searches, globally per John Mueller-Google
Copy