HTTPS as a ranking signal: moving to SSL without losing traffic

The announcement on the Webmaster Central blog was measured. HTTPS is a "very lightweight signal" today, carrying less weight than high-quality content. Google said it may decide to strengthen it, because it wants to encourage all site owners to switch and keep everyone safe on the web. The post also pointed to the HTTPS Everywhere session from I/O in June, which laid out the technical arguments.

Three things follow. Nobody will leap from page three to page one by buying a certificate. The direction of travel is clear, so the cost of being late will rise. And the security case stands on its own: encryption stops Wi-Fi snooping, protects form data and prevents ISPs and hotels from injecting ads into your pages.

Not every site needs to act at the same speed. A sensible decision rule:

• Move this quarter if you take payments, have customer logins, collect any personal data in forms, or operate in healthcare, finance or legal where trust is the product. Many of these sites already have SSL on checkout and only need to extend it sitewide.
• Move in the next two release cycles if you have a lead-generation site with contact forms, a content site with a newsletter signup, or a membership area.
• Plan it for your next redesign if you run a small brochure site with no forms and no logins. You will still want to do it, but the risk of a rushed migration outweighs a signal this light.

There are three validation levels and the differences matter less than resellers imply.

A few practical notes. Buy from a reseller rather than directly from the certificate authority; the same Comodo, GeoTrust or RapidSSL certificate is often a third of the price. If you run several subdomains (www, shop, blog, app) a wildcard certificate is cleaner than four separate ones. Use a 2048-bit key with SHA-256 signing; Google announced this month that it will start flagging SHA-1 certificates in Chrome from November, so do not accept an SHA-1 certificate from anyone. And check that your host supports SNI or gives you a dedicated IP, because shared hosting plans sometimes do neither and cannot serve your certificate at all.

Treat this as a site move with URL changes, because that is exactly how Google treats it. Every URL on your site is about to change from http:// to https://, and search engines need to be walked through that.

1. Install and test the certificate. Run the SSL Labs server test and aim for an A grade. Fix any chain issues before anyone links to the new URLs.
2. Make every internal reference protocol-relative or HTTPS. Images, scripts, stylesheets, fonts, iframes, embedded video. Search your templates and database for "http://" references to your own domain. Any one left behind creates a mixed-content warning and in some browsers a broken padlock, which undoes the trust you just paid for.
3. Check third-party resources. Ad tags, analytics snippets, chat widgets, social buttons and embedded maps all need HTTPS versions. Most major providers offer them in 2014, but older plugins and some smaller ad networks do not. Those are the ones that bite.
4. Set up 301 redirects from every HTTP URL to its HTTPS equivalent. Server-level rules, not page-level scripts.
5. Update canonical tags, sitemaps and robots.txt to reference HTTPS URLs. Submit the new sitemap.
6. Add the HTTPS version as a separate property in Google Webmaster Tools and Bing Webmaster Tools. Webmaster Tools treats http:// and https:// as different sites, and this is the step most people miss. Without it you lose visibility into crawl errors during the exact window you need it most.
7. Keep the Analytics property but change the default URL to HTTPS in the property settings, and verify referral data still arrives. HTTPS-to-HTTP referrals strip the referrer, so expect a small shift from "referral" to "direct" in your reports.
8. Update links you control. Social profiles, email signatures, directory listings, Google+ page, paid search destination URLs. AdWords ads pointing at HTTP will redirect and still work, but every extra hop slows the landing page.
9. Consider HSTS once everything is stable, which tells browsers to always use HTTPS for your domain. Add it a month after the migration, not on day one, because it is hard to undo if you find a problem.

Expect a dip. Even a perfect migration tends to show a few days of lower organic traffic while Google re-crawls and consolidates signals to the new URLs. Two to four weeks of mild noise is common; a well-executed move usually returns to baseline inside a month and some sites see a modest gain.

Here is what is not normal and what it means. A 30 to 50 percent drop that persists beyond two weeks usually points to redirect problems: the HTTP pages are returning 302s, or redirect loops, or the home page redirects but deep pages do not. A rise in crawl errors in Webmaster Tools often means robots.txt on the HTTPS version is blocking CSS and JavaScript, which Google began penalizing more directly this year. Broken padlocks across the site mean mixed content, and the browser console lists every offending URL.

For the first six weeks, check crawl errors on both Webmaster Tools properties daily and compare organic landing pages weekly against the same weeks last year.

Buying the certificate and stopping there. Having HTTPS available while the site still serves HTTP by default earns nothing. The signal rewards pages that are served over HTTPS, and that requires redirects.

Duplicate content from running both versions. If HTTP and HTTPS both return 200 with no canonical, you have doubled your site in Google's eyes and split your link equity between the halves.

Forgetting the CDN. If images or assets are served from a content delivery network, the CDN needs its own certificate or a shared one, and the asset URLs need updating. Several CDNs charge extra for custom SSL in 2014; budget for it.

Breaking the ad revenue. Publishers using AdSense are fine, but some third-party ad networks still cannot serve over HTTPS and will either go blank or trigger warnings. Audit your networks before you flip the switch.

We treat an HTTPS migration as a small infrastructure project with marketing consequences, and run it in four stages. In discover we crawl the site, inventory every third-party resource, review hosting and CDN capabilities, and pull a traffic baseline so the recovery can be measured honestly. In plan we choose the certificate type, set the migration date against the sales calendar, and write the redirect map and rollback plan. In build our web and infrastructure team installs and tests, fixes templates and content for mixed content, configures redirects and HSTS, and updates Webmaster Tools, Analytics and paid campaigns in the same release. In improve we monitor crawl errors and organic landing pages for six weeks and use the moment to fix the speed and crawl issues the audit surfaced.

The reason to run brand, growth, web and technology together on something this technical is simple: the migration touches ad tags, email templates, social profiles and conversion tracking at the same time as the server. When one team owns all of it, nothing falls between the cracks.

A representative engagement was a mid-sized online retailer that had SSL only on checkout and wanted it sitewide ahead of the holiday season. The work started with an inventory that found several dozen hard-coded HTTP image references in product descriptions and a review widget with no HTTPS version, which was swapped for one that had. The migration ran in a single early-morning release with server-level redirects, a new Webmaster Tools property, and updated AdWords destination URLs. Organic traffic dipped for about ten days and recovered within the month, and the padlock across the site gave the brand a cleaner story to tell in its own holiday messaging. You can read more about that kind of work in our e-commerce case study.