Skip to main content

Get Your Store Ready for HTTPS

You probably received an email from Google announcing that starting in October of 2017, sites that cannot be accessed via HTTPS will be flagged in Chrome as not secure. This is part of Google's push to make the entire Internet secure. To answer this call, Yahoo is working hard on making HTTPS available to all stores and it should be available shortly; definitely well before the deadline set by Google. In some cases, stores will simply be able to flip a switch and make their site secure (conforming). However, other stores, most notably highly customized ones will need extra effort making sure they are ready for the switch.

What if your site is switched to HTTPS but it is not entirely secure?

If - when it becomes available - you switch your site over to HTTPS but not all parts of the site are secure, visitors to the site will still see a note informing them that the site is not secure. They may, and often will, also receive popups warning them of insecure content and asking if they want to continue - a sure way to turn the vast majority of visitors away.

What parts of the site can potentially be non-secure?

Once the switch is available, the main pages of the store will be secure. However, assets used inside the page also need to be secure. The product images - and indeed all images you upload into the editor will be taken care of. Other files linked from the "Files" area of the store editor will probably be secure, but that depends on how such files are linked into your site. If they use hard-coded non-secure (http:) links, then they will NOT be secure. Images used inside otherwise secure CSS and JS files may or may not be secure, again, depending on how those are referenced from within those files.
Also, forms used anywhere in the site (search, newsletter signup, etc.) all need to point to secure locations otherwise they will be flagged as non-secure. A notable example is the built in store search. If you are using the legacy yahoo store search you will have to upgrade to the newer version.
Finally, any third party scripts or tools your site might make use of, which are not secure, will have to be secured as well, but for those you'll most likely have to contact the vendor whose code it is. We will point those out to you if we find them in your store.

How can you find out what parts of the site will pose a problem?

You can start with third party tools such as customer reviews, customer account management systems, etc, by contacting the vendors those tools are from to make sure they can be upgraded to be secure. If you have the legacy Yahoo store search, upgrade it - or have it upgraded - to the new version. Don Cole of Your Store Wizards put together a testing tool that can alert you if your site is most likely to be ready or not for the switch. This tool is available here. But the most precise way to tell whether your site is ready to be secure or not is the yet-to-be-released HTTPS testing tool from Yahoo. This tool will temprorarily switch the store editor into secure mode so it will immediately show an expert what parts of the page or pages are not secure and, therefore, require attention.

What's next?

For your peace of mind, order our Secure Store Preparation Service now. We will process these in the order in which they are received, as soon as Yahoo Store's HTTPS testing tool is available. We will make sure all parts of the site are secure and ready for the switch, and we will identify any third party tool you may be using now that will need to be secured by the vendor who installed it (please note, we are not responsible for any charges third party vendors might assess for securing their own tools or add-ons.)

Comments

Popular posts from this blog

CPR for a Yahoo Store on Google's Supplemental Index

Recently a client of mine came to me and said that most of his store pages disappeared from Google, and he did not do anything to make this happen. I was a bit skeptical, so I went to Google, did a search on his store, and sure enough, there were only two pages indexed, his home page and his site map (ind.html) page. The rest were in the supplemental results, which means that Google thought the rest of the pages were not much different than these two pages. When I looked at the supplemental results, the little excerpts under each link were exactly the same, and I also noticed that what Google showed under each result was actually text from the ALT tags of the header image. I looked at some of these pages in my client's store, and they were actually different. This was a bit puzzling, but then I thought perhaps Google saw that the header and left navigation was the same throughout the site (which is pretty normal), but that the text that made each page different was too far down ins

What to expect when your redesign goes live

At Y-Times we roll out new designs, redesigns and other major upgrades to Yahoo stores on a fairly regular basis. Some of the main questions our clients ask are how to prepare for a roll-out and what to expect in terms of SEO and conversions when the changes go live? For any functional Yahoo store how well the site ranks and how well it converts are probably the two most important metrics. Since pretty much ANY change you make to any page can potentially alter either or both of these metrics, merchants may understandably feel nervous about far reaching alterations to their sites. However, when those functionality and design changes and additions are done right, there is really very little to fear. First off, what does it mean for a design or redesign to be "done right?" From the technical stand point, search engines look at the underlying structure of your site (the HTML, and increasingly also the CSS and JavaScript code) to try to extract information and meaning from i

Smaller is Better

You often hear the phrase "bigger is better". Sometimes it's true but not when it comes to JavaScript or CSS code in your Yahoo! Store pages. If you include JavaScript code or CSS either as linked files (the preferred method) or embedded inside your pages (obviously not preferred), making these files as small as possible should be your goal. Why? This is no rocket science: smaller files mean faster page loads = happy customers. Ok, so what bloats JavaScript code? In general, white space (tabs, carriage returns, non-used spaces), comments, and the actual code, such as variable and function names. You have control over all of these, however, if you don't use white spaces, carriage returns or comments, it will be immensely difficult to understand and modify your code. And not just for others, you too. There are many commercial JavaScript compression tools around, but I've been using this handy and free utility: http://www.andrewkesper.com/jscrush/ This little utilit