SSL (https) Protocol for SEO Tips

When doing on-site search engine optimization techniques, implementing SSL (secure sockets layer) is often tricky, and if not correctly implemented can result in ranking and duplicate content issues. This tutorial will walk you through the correct implementation of SSL on your website to ensure the best SEO results.

Implementing the secure sockets layer protocol on your website is one of the best ways to protect the privacy and communication of sensitive information between you and your customer. This method encrypts the packets as they travel between your server and the client’s browser, preventing any possibility of third parties sniffing that information.

As a requirement (although the concepts in this article can be applied to any type of server and CMS software), more emphasis will be given to the implementation of SSL on a LAMPP server configuration (Linux/Apache/MySQL and PHP) because Apache commands an almost 60% share of the world wide web (source: http://royal.pingdom.com/2011/01/04/apache-web-server-hit-a-home-run-in-2010/).

Check to See if SSL is Really Necessary

As you may already know, SSL carries an additional cost when operating a website. It is useful to know if you actually need it for your site. Here are some general guidelines to help you decide:

  1. Your website accepts sensitive information such as credit card or social security  numbers.
  2. You are in the business of contracts, where client privacy is very important. For example, if you are a lawyer planning to have a website and you accept client inquiries by email or your web form, it is important to secure this information via the use of SSL.
  3. Your business is in the financial sector. Common examples include banks or gateway payment services such as PayPal.
  4. You have logins on your website where security and privacy is a priority. Common examples include a customer or email login; you may have noticed that Gmail and Yahoo email login use SSL.
  5. Your website contains sensitive information only available to a select group of visitors or recipients.

Is You SSL Installation Fully Working?

Okay, so you decide that your website needs an SSL implementation and you have purchased an SSL certificate from a reputable vendor – now you need to install it on your website. Some web hosting makes this process very easy for their customers; after purchasing certificates, your web host will configure it for you.

Bear in mind that configuration can cause a slight downtime, so make sure you are prepared for this event and have informed your customers in advance that your website will be undergoing important maintenance.

The easiest way to check if your SSL is working is to use the https version of your website. For example, if you enter this URL in the browser address bar: https://www.example.com/  and it loads without any errors (loading the same content as http://www.example.com/) then your SSL is working. Once you have a fully working SSL, the default implementation will be site wide, so any document can be accessed in secure protocol.

An exception to this rule is when your domain has a sub-domain. The extent of the normal/common issued certificate can only be applied to a single version of your registered domain (www or non www) such as www.example.com and not to your other sub-domains (such as subdomain.example.com). If you really need to secure your sub-domain; you need a wild card certificate which is more expensive than a normal certificate. Or you can purchase a separate certificate for your other sub-domain.

You can also check if the https version is working by checking to see if it returns a 200 OK header status using this checker: http://www.seoconsultants.com/tools/check-server-headers-tool/



When you have a fully working SSL installation on your website, the default behavior is that any content or post URL can be accessed  in one of two ways. The first and most common is using the http version (e.g. http://www.example.com/); the other is the https version: https://www.example.com/. This will extend not only to the homepage, but to all of the pages on your website.

As you might imagine, having your content accessible by more than a single URL is a problem in search engine optimization due to duplicate content issues.

This is often caused by:

  1. Inconsistent internal linking- some of your internal links are linking to the https version of your content that results in search engine crawlers indexing the https version.
  2. Using https version in inbound links – some of your inbound links are pointing to the https version rather than the http version of the URL.

You only need to present one official URL (per content piece) to search engines. This can be tricky since SSL implementation is site wide. There are several common solutions to this problem that are beneficial to your site’s SEO:

  1. Blocking the https version in htaccess or robots.txt – if the secure page is blocked in robots.txt, there is no way it can cause duplicate content issues with the http version. However, this is not advisable since if your https version earns an inbound link, it will not contribute to the rankings of your overall domain. There might also be some content that you need to strictly present in the https version and you need it to be crawled by search engines.
  2. Putting noindex tags on the https version – a noindex page will be dropped in the search engine indexes, so it can prevent canonical issues. However, as with robots.txt, it will be a wasted link baiting opportunity if a user links to the https version.
  3. Adding rel=nofollow attributes to all links pointing to the https page. This is not recommended because there are still a lot of ways a search engine bot can end up indexing the secure page. For example, links from other domains pointing to your secure pages.

Secure Page Canonical Issues Recommended Solution

Deciding on the best solution depends on how you are going to use the SSL version of your URLs. If you need both versions to exist (which most websites are doing); decide on a “single” canonical version. Most of the time, you would stick to the original version, which is the http version. You cannot do a 301 redirect since it will combine two URLs into one and either the https or http version is no longer accessible.

The most recommended solution is to use a link rel canonical tag on the https URL version pointing to the equivalent http version. Suppose a search engine crawler visits https://www.example.org/yourpost.php; in the <head> tag, they should find a link rel canonical pointing to the http:// version of the URL, which is:

<head>
<link rel="canonical" href="http://www.example.org/yourpost.php"/>
</head>
<body>
<!– The rest of the html code here–>

In this way, even though the content is still accessible in both the http and https version, search engines will only see and respect the http:// as the canonical version of your website. This will prevent any possible duplicate content issues.

Below is an example of how to do this using PHP:

<html>
<head>
<title>This will output rel canonical tags pointing to http version</title>
<?php
$currenturl= $_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];

//Check if it is using the secure https port which is 443
if ($_SERVER["SERVER_PORT"] == "443") {

//connected to secure port, formulate the http canonical version
$canonicalversion="http://".$currenturl;

//echo the canonical version to the HTML as link rel canonical tag

echo ‘<link rel="canonical" href="’.$canonicalversion.’"/>’;
}
?>
</head>
<body>
This will output in secure and non-secure page but shows the canonical tag to search engine bots.
</body>
</html>

To test the above script, copy it to a text file and save it as test.php, then upload it to your server with the SSL installation. Test it by accessing the page in both the http and https versions and view the source code to observe the link rel canonical tag behavior. It will only output the link rel canonical tag if the page is accessed using https.

To implement the above code, copy and paste this code into the <head> tag of your PHP template:

<?php
$currenturl= $_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
if ($_SERVER["SERVER_PORT"] == "443") {
$canonicalversion="http://".$currenturl;
echo ‘<link rel="canonical" href="’.$canonicalversion.’"/>’;
}
?>

Disclaimer: Server configuration and CMS software varies, so it is your responsibility to fully test the outcome of this script.



This section will be very helpful if you need to use the https version throughout your domain. A popular website that use the https version as the canonical version is PayPal: www.paypal.com.

In this case, this is how the implementation works: if there is a request to the server which is a non-secure page (http version) the server will 301 redirect this URL to its secure version (https version). But if the request is already for a secure page, it will immediately provide the user a 200 OK status and there is no need to redirect.

To do this on Apache servers using .htaccess:

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

How to Implement the Above .htaccess Code:

  1. Download your existing .htaccess, located in the root directory of your website.
  2. Open .htaccess and paste the above htaccess code before any code in the .htaccess file.
  3. Save and upload it back to your server.
  4. Now test if all non-secure pages 301 redirect to the secure version. For example, if the URL is : http://www.example.com/test.php, it should 301 redirect to https://www.example.com/test.php. You can also use this checker: http://www.seoconsultants.com/tools/check-server-headers-tool/

Now what if you need to exclude the https implementation in some of your website folders? You just need to add additional conditions in the .htaccess. Supposing you need to exclude the following folders in the https implementation:

  1. xyz
  2. abc

This is the revised .htaccess code:

RewriteCond %{HTTPS} !=on
RewriteCond %{REQUEST_URI} !^/xyz
RewriteCond %{REQUEST_URI} !^/abc

RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

Google+ Comments

Google+ Comments