Introduction
In August 2014, Google announced that they would provide a ranking boost to websites using HTTPS (Hyper Text Transfer Protocol Secure).
In the years since, Google has further signalled their commitment to an HTTPS Everywhere web by gradually providing more prominent browser messages to users accessing HTTP web pages, noting that the pages are not secure.
In July 2018, during the release of the Chrome 68 browser, Google started to highlight all HTTP pages as “not secure” in the browser omnibox:
Google has said that eventually, all HTTP pages will be served to users with the following browser message. Note: The scary red text and warning triangle!
In March 2017, Firefox took this one step further by reminding users of when they were using insecure pages with a prompt on username and password fields.
We recommend migrating your site to HTTPS as soon as you can, whether you are undertaking a site migration or not, and below we’re providing an extension to our ULTIMATE SEO Website Migration Checklist with the steps to undertake when doing so.
Before we get started with our HTTPS migration checklist however, here’s all the background information that you need to know, including the pros and cons of migrating from HTTP to HTTPS.
The Key Difference Between HTTP & HTTPS
Both HTTP and HTTPS are client to server protocols that rely on a request from a browser or operating system and a response from a server.
The biggest difference is that during the request and response process, HTTP web pages will send information to a server as-is. Put simply, if a hacker was able to intercept an exchange between a HTTP web page and a server, they would be able to see the exact information that the user provided.
With HTTPS transfers, the information in this exchange is encrypted. The encryption replaces the plain text with a series of letters and numbers, known as ciphertext.
How HTTPS Works
An SSL (Secure Socket Layer) is key in making HTTPS work by encrypting the data in the server to browser exchange. This ensures that the data in the exchange is kept private and anonymised.
When a user accesses a secure HTTPS page, a session key is used to encrypt data between the browser and the server.
A browser will request the identity of the server, and the server identifies itself by sending an SSL Certificate in return.
The SSL certificate contains a public key and in HTTPS, this public key is required to unencrypt the data transferred to the server.
What is SSL & What are SSL Certificates?
A browser has to have confidence that a server is who it claims to be, and is able to confirm this through
something called an SSL Certificate.
A browser will request an SSL Certificate and check this information against something called a Certificate Authority. A Certificate Authority is the issuer of an SSL Certificate.
Major browsers, operating systems and mobile device companies work with Certificate Authorities to
maintain a list of trusted root certificates.
Types of SSL Certificates
There are three primary types of SSL Certificate; Domain Validation, Business Validation and Extended Validation.
Domain Validation:
This is the most common and can be issued within minutes. You’ll be able to secure these certificates at a low cost or even for free.
Business Validation:
These certificates can take a few days to be issued as they require you to provide more information to the Certificate Authority. You’ll have to pay, but not as much as for an Extended Validation certificate.
Extended Validation:
These can take up to a week to be issued and require the maximum amount of information from a Certificate Authority
You can see several examples of Domain, Business and Extended Validation certificates in use at the articles below from GlobalSign and ExpeditedSSL:
https://www.expeditedssl.com/pages/visual-securitybrowser-ssl-icons-and-design
https://www.globalsign.com/en/ssl-informationcenter/types-of-ssl-certificate/
ServerGuy also has an excellent in-depth write up on the differences between the certificate types that can help you choose the right type of certificate for your requirements.
You will need an SSL Certificate to switch to HTTPS.
Fortunately, most hosting companies can provide free or paid SSL Certificate options for you at the click of a button
Pros & Cons of Switching to HTTPS
Pros:
- Google has said that HTTPS pages receive a ranking
boost. - Prevent hackers or third-parties from intercepting
user data. - The level of trust it gives to users when they see that
their information is secure, i.e. the green padlock
and the extended validation green bar. This is
essential for any website that requests a lot of user
information, for example, an e-commerce website. - A level of trust is given to users when they see that you are who you claim to be. This is particularly important if you’re still in the process of building your brand.
- You may benefit from HTTP/2 if you’re using HTTPS.
- Continue to receive referral data in Google Analytics
(HTTPS referrals to HTTP websites are categorised within the ‘Direct’ traffic source and do not appear
in your referral sources). - Correct HTTPS implementation can result in faster page loading times.
Cons:
- Might require support from your development team
and hosting provider. - There is a cost for certain types of SSL Certificate.
- Different certificates have different lengths of
renewal. An expired certificate will invalidate your
HTTPS implementation. - You will need to dedicate some time and resource to
ensure the switch from HTTP goes smoothly. - There are opportunities for things to go wrong,
which can be a risk for sites that rely on organic
search traffic.
HTTP to HTTPS Guide & Checklist
Now you know how HTTPS works, and some the benefits, here are the steps you need to take to ensure a
smooth HTTPS migration.
Planning & Pre Migration
1: Plan your time
The time it takes to complete a HTTPS migration can vary depending on the size of your website, the resources you have available and the support levels of your host or development team.
If you’re responsible for a HTTPS switch, plan it for a time of low-seasonal activity. It’s also important that you have the time to oversee the migration, so plan it for a time where you know you’re going to be freed up and able to concentrate. For smaller sites or non-e-commerce sites with less than 5,000 pages, you might want to book out between 1 and 3 days in your diary. For websites with 5,000-10,000 pages or with e-commerce/ordering functionality, aim for 3-4 days. If you’re a large website with 10,000+ pages or have lots of third-party integrations or back-end functionality, you might want to have at least a week free to work through all of the necessary HTTPS processes.
Oh, and never plan a migration for a Friday. Just in case something goes wrong!
2: Communicate the planned migration to your team
Once you’ve decided on when you’re going to migrate, make sure this is communicated to any
team that works on the website.
Put the date in the calendars of your colleagues as well as your own. You’ll want to ensure sure that you’re making the switch at a time where there are no other planned website changes. Doing this will help to minimise the risk of any potential problems.
If something does go wrong, it’ll be easier to pinpoint the problem.
3: Benchmark
Check the tracking status of Google Analytics and Google Search Console. How will you know if your HTTPS migration has been successful?
The only way you’ll truly know is if you have data to compare it against. So check that your current Google Analytics and Google Search Console accounts are collecting accurate data, particularly for organic search. If they’re not, you should aim to collect at least a week’s worth of data in those accounts before making the switch.
In addition to this, crawl your current website using a tool like DeepCrawl or Screaming Frog so that you have a full HTTP dataset for post-migration comparisons.
4: Speak to your web hosting company or IT team
It’s highly likely that in the process of migrating to HTTPS you’ll need the support of your web hosting company, development team or IT team (Whoever is currently responsible for hosting your website and maintaining its performance and security). Even if you don’t think you’re going to need them, it’s useful to have them on board during a migration just in case you hit any snags.
For those that aren’t particularly comfortable with hosting environments, implementing redirects or working on staging environments, you’re most likely going to need support with steps 5 to 10. Be open with them and tell them where you think you’ll require most of their time and support.
Handling a website migration of any description alone can be very daunting, so don’t underestimate the
importance of getting your host or developers engaged in the project.
Some questions you might want to ask your web hosting company or development team include:
- Have you handled any HTTP to HTTPS migrations recently?
- What were the results?
- Were there any problems?
- Could they have been avoided?
- Were there any frustrations for you in this process?
- How long did it take?
You might even want to share this guide with them and ask them if they’re comfortable with everything that’s featured within. This sometimes the easiest way to identify any potential issues ahead of the migration happening!
5. Decide on Your SSL Certificate Type
Earlier in this guide, we detailed the different types of SSL Certificates that are available. You’ll need to make a decision based on the level of authentication you require, the budget you have available and the technical configuration of your hosting environment.
Another factor in deciding which certificate type to use can be whether or not you are using a CDN (Content Delivery Network). Though CDNs can help add an extra layer of security and simultaneously help to improve page performance through speedy delivery, they can make for a slightly more complex HTTPS migration. This is because certificates are needed for the secure transfer of information from your browser to your CDN and then your CDN to your server and vice-versa.
If you’re unsure, the best thing to do is speak to your development team or web hosting company. Web hosting companies will usually partner with both free and paid SSL Certificate providers and have simple cPanel (or alternative) functionality to make SSL Certificate activation and CDN configuration much easier than it might appear.
If you’re curious, leading CDN provider, Cloudflare has an excellent write up on CDN and TLS integration.
*Additional Tip*
You’ll also want to check that any SSL Certificates configured are set to auto-renew. SSL Certificates have expiry dates, and if they do not autorenew, you can lose your HTTPS status. Once the
certificates are set to auto-renew, you shouldn’t have any problems, but still, mark the renewal date in your diary and check the status of HTTPS on the date your certificate is set to renew.
6: Backup your website
Hopefully, you’ll already have a tool or process in place to manage routine backups of your website. But just in case you don’t, now is the time to back up your website before you make any changes!
…and maybe speak to your developers about getting some backup management after the migration.
7: Access your staging server
Unless you’re SUPER brave, you’re probably not going to want to make all of the changes below to your live website.
Instead, you should configure everything below on your staging server to test before ‘mirroring’ and merging with your production website.
8: Configure the HTTP to HTTPS rewrites
This is the stage where you “force” all requests for HTTP URLs to redirect to the new HTTPS variations.
The type of rewrite you use will be dependent on the web server software you use. Again, if you’re unsure, this is a good time to reach out and speak to your web hosting company for support.
*WordPress Users* Thankfully, forcing HTTP to HTTPS redirects is a little easier on WordPress than some other content management systems. Here are some handy guides from Kinsta and SererGuy on how to edit your .htaccess file and implement your HTTP to HTTPS redirects:
https://serverguy.com/servers/redirect-http-to-https/
https://kinsta.com/knowledgebase/redirect-http-to-https/
*MacOS Users* Struggling to find your .htaccess file? When viewing your directory files, you might find that macOS natively hides some files. To show all hidden files, follow this guide depending on the macOS version you’re using.
*Important* When configuring your HTTP to HTTPS rewrites, you should also ensure that any legacy redirects
are forced to the new HTTPS status.
9: Update all internal links, scripts and code references to HTTPS
Your development team should be able to update all internal links and references from HTTP to HTTPS using “find and replace” server database
functionality.
You will want to ensure you update the new HTTPS status for:
• All internal links
• Canonical tags
• Hreflang tags
• Open Graph tags
• Media assets (videos,
audio, images and files
should all be served via
HTTPS)
• Font files
• CSS and JavaScript files
In addition to requesting support from your developer, you should manually review and update the website for any hardcoded links in plugins or widgets you might be using within your CMS as these can sometimes escape a find and replace request
10: Crawl the website and fix issues on staging
Using the crawling tool of your choice, crawl the website and check that all URLs are served in HTTPS, check the points detailed in step 9 and address any issues with mixed content. Both DeepCrawl and Screaming Frog have insecure content discovery functionality within their tools.
What is mixed (or insecure) content? Glad you asked!
If a page is encrypted (served via HTTPS) but elements of that page are unencrypted, this is considered mixed or ‘insecure’ content.
It’s fairly common to find pages with insecure content when using content management systems with lots of third-party integrations such as plugins or widgets. Your job should be to try and eliminate as much mixed content as possible.
Using DeepCrawl and Screaming Frog will help you identify pages with insecure content, but if you’re working on a smaller website, you might want to use one of the many Chrome extensions, such as the HTTP Mixed Content Locator to help you find the mixed content on your site quickly.
Once you’ve identified the mixed content, you’ll need to see if a secure version of that content exists. If it does, you should update your internal references accordingly.
If you find there is insecure content without a secure version that’s outside of your control, you might want to consider finding an alternative widget or plugin to use that replicates the functionality you’re trying to achieve.
11: Pause or prepare paid ads and third-party tools
You might find that you’ll need to pause any paid advertising campaigns around the time of your migration to avoid any wasted ad spend.
It’s likely you’ll need to update any paid advertising platforms with the new HTTPS URLs, so give you (or your team) plenty of time to do this ahead of launch if it’s achievable.
On a similar note, you might find that third-party tools for CRO, analytics or any other integrations you use for your website might require configuration changes to reflect the website’s new HTTPS status.
This is a good time to take stock of what you can update before launch and make a note of any tools that you need to update on launch day.
12: Tell your users (and your customer support team)
A HTTPS migration can go wrong, and users might experience website issues or downtime that they’re not used to experiencing.
For that reason, when you have a HTTPS launch day confirmed, it’s worth communicating that to your users or customers and your customer support team (if you have them).
You don’t have to tell them all the gory HTTPS details (though, why not?), a simple explanation that server changes are being made that might impact user experience should suffice. Remember to tell both your users and your customer support teams where to report any issues if they arise.
Launch & Post Migration
13: Launch day!
Congratulations! But…don’t celebrate with tequila shots at your desk just yet, we’ve got some work to do.
It’s best to ensure that you have your entire launch day free as there are quite a few tasks best saved for this.
Starting with…
14: Manually check your website (and ask others to do so too)
A HTTPS migration can go wrong, and users might experience website issues or downtime that they’re not used to experiencing. For that reason, when you have a HTTPS launch day confirmed, it’s worth communicating that to your users or customers and your customer support team (if you have them).
You should sense check:
- What’s the browser omnibox showing in respect of
our HTTPS status? - What happens if you type in the original HTTP homepage variation? Does it redirect?
- Test a few other URLs, do they redirect as expected?
- Are media assets all appearing correctly?
- Are pages noticeably slower to load?
- Are Robots meta tags correct? Have you been careful to avoid the dreaded, accidental noindex?
- Is the robots.txt file in place? Does it link to your HTTPS sitemap?
- Can you submit a form, sign up for a newsletter and complete a transaction or conversion as normal?
Set up a bug reporting log (Trello, Google Sheets) for you and anyone else in your team that happens to spot anything unusual with your website after launch day.
You don’t have to worry about immediately fixing everything you find, but having an awareness of what might have gone wrong at this stage can help you prioritise your time when it comes to the rest of your post-migration tasks.
15: Create new HTTPS Google Search Console properties
HTTP and HTTPS website variations are seen as unique in the eyes of Google (duh, that’s kinda why we’re here!).
This means that on launch day you’ll need to configure your new Google Search Console Properties. Both the HTTPS-www and HTTPS non-www versions.
You’ll only fully configure your preferred HTTPS variation; the other is to have as a verified property that you can monitor to stay on top of any potential
www/non-www issues.
16: Create and submit your new HTTPS sitemap
Create or update your sitemap containing only HTTPS URLs and submit that to Google Search Console.
If you’ve referenced your sitemap in your robots.txt file, you should double-check that it includes your HTTPS sitemap URL.
17: Configure your HTTPS Google Search Console property
You’ll want to make sure that you configure your new HTTPS property so that it matches all of you previous HTTP configurations.
You’ll need to:
- Submit your HTTPS sitemap
- Upload any disavow files that were previously active on your HTTP Google Search Console property
- Run Fetch & Render Googlebot checks for desktop and mobile
- Configure any URL parameters
- Connect your Google Search Console property to your Google Analytics property (you can also make this connection in Google Analytics)
- Configure Google Search Console Site Settings
18: Crawl the website, again
You should now crawl your website again and compare the crawl data against any previous crawls.
The key things you’re looking for at this stage are:
- Any insecure/mixed content warnings
- Ensuring that HTTP to HTTPS redirects are
permanent 301 redirects and are going to the
correct URLs - Canonical and hreflang URLs are all HTTPS
- Ensuring that no HTTP URLs are discovered
19: Check the SSL configuration
Upon launch, you can also use one of the many handy SSL configuration checkers
- ssllabs.com
- sslshopper.com
- jitbit.com/sslcheck
…here’s one we made earlier @ ssllabs.com
20: Update Google Analytics
In Google Analytics you’ll need to update the Default URL in your property and Views.
To do this at a property level, go to Admin > Property Settings > Default URL > Save.
To do this at a View level, go to Admin > View Settings > Website’s URL > Save.
You’ll also need to connect your HTTPS Google Search Console property data with your Google Analytics property. To do this, go to Admin > property Settings > Search Console > Adjust Search Console.
Select the correct property and then save.
While you’re in Google Analytics, remember to annotate your HTTPS launch day!
21: Update your social media URLs
If you have social media URLs that link back to your website, update those URLs with the new HTTPS location.
This can be particularly important for YouTube where, if you’re part of the Partner Programme, you may now need to link to your new HTTPS Google Search Console property to continue to be able to utilise video features.
22: Monitor the results
At this point, we hope you have the hackers in tears, a website faster than a shooting star and a glowing green box mercilessly patrolling your browser’s omnibox..
But if you didn’t quite get there, fear not. The best thing to do if you come up against any issues is to go back through the steps in this checklist. Did you skip anything? Was there something you were a little unsure about the first time around? Go back over any uncertainties. Check, double-check and triple check.
Over time you should see Google start to propagate search results with new HTTPS URLs. Your indexed URLs should drop off in your old HTTP Google Search Console account and increase in your HTTPS Google Search Console account as this propagation takes place. The speed at which that happens can vary dependent on the size of your website.
You might see a ranking boost; you might not. You certainly shouldn’t expect it. This could be for a variety of reasons, but if you’re migrating now (in 2019) there’s a fair chance that a number of your search competitors have already upgraded and you might be playing catch up!
23: Consider HSTS implementation
Once you’re confident in your HTTPS implementation, you may want to continue to explore the option of utilising HSTS (HTTP Strict Transport Security) with your web host or development team.
HSTS is a further layer of security that can only be implemented if you’re using HTTPS. Google recommends sites using HTTPS also use HSTS, stating:
“We recommend that HTTPS sites support HSTS (HTTP Strict Transport Security). HSTS tells the browser to request HTTPS pages automatically, even if the user enters h t t p in the browser location bar. It also tells Google to serve secure URLs in the search results. All this minimizes the risk of serving unsecured content to your users”.
So there you have it, the Ultimate Guide to moving your site from HTTP to HTTPS. We’ve also got a FREE bonus checklist within our PDF of this post and you can download that below, ensuring you don’t miss a step!
If you’d like some support when undertaking your migration, please don’t hesitate to get in touch. You can call us on 01273 733433 or leave us a message via the form here.
Download our Free Website Migration Checklists below: