How To Handle Secure Files Being Indexed

At SMT we typically do a website audit for new clients. During these website audits we see a lot of the same mistakes from web developers and web designers that do not fully understand search engine optimization best practices. One of the issues we come across is the client's site starts to get indexed under the HTTPS version of their site. HTTPS is typically used to protect sensitive information such as credit card numbers, social security numbers, or personal information that is submitted from a form on the website.
 
Google provides an useful tool called site: command. The site: command enables you to see all of the indexed pages in the Google search engine for that particular site. To use this command you would enter in site:domain.com right into the Google search box. You will now see a list of pages that are indexed by Google. You can now scan these results and audit the page URLs to see if any secure pages using HTTPS are being indexed.
 
If there is a indexing issue with the secure pages, we typically see client's entire site show up with non-secure and secure pages in the result pages. Why is this bad? In short you end up competing against yourself with duplicate content. You also run the risk that if you have un-secured items on a page that is rendered with HTTPS it may throw up numerous error messages that may prevent the site visitor from continuing on and ultimately leave your site.
 
Usually the culprit is a link referencing the HTTPS version of page that should be referenced with HTTP. Once the search engines start crawling the site they carry the HTTPS and start to index non-secured pages with the HTTPS. Another scenario that we often see is that the search engine spiders crawl a site and ends up on a HTTPS page (such as a e-commerce check out page). Now the page should be using HTTPS, but what happens is that the way the website was set up the search engine spiders head back to the non-secure pages (i.e. product details page) and carry the HTTPS instead of being redirect back to the HTTP version for the non-secured page. Are your eyes crossed yet?
 
In the end, a good web developer would understand that you would need to add server directives to redirect HTTPS to HTTP when on a non-secured page. Understanding these issues is what sets apart an alright web developer from a good web developer that understands search engine optimization.

For more information, contact Sales & Marketing Technologies today.