HTTPS Migration | Reflect Digital

HTTP to HTTPS Migration

Read our in-depth guide to a smooth HTTP to HTTPS website migration and download our handy checklist to make sure your migration goes without a hitch.

DOWNLOAD CHECKLIST

fishes-banner-min

Getting Started

The process of moving your website from HTTP to HTTPS is daunting. Scare stories of dramatic drops in rankings and plummeting search traffic abound, and many are quick to tell you the move is fraught with danger. Truthfully, there are many risks associated with any site migration but there are also a lot of precautions you can take to avoid these.

Get A Plan Together

First things first, get a plan together. Work out what you need to do, when, and how to check it’s worked. From there, it’s a matter of monitoring the move and ensuring you correct any issues as quickly as possible.

Set Up a Test Environment

Site migrations of any kind are never straightforward and as such the margin for error is high. It’s best to mitigate as much of the risk as possible by setting up a development site to test everything in before you move across to a live environment. Block search engines in the robots.txt, hide your development site behind a login and no-index everything. This prevents your site leaking out into the SERPs and diluting the effectiveness of your live site. This is good practice for any changes you’re making to your site, the last thing you want is a seemingly innocuous code change bringing your live site down!

Read Your CMS Migration Guides

There are a lot of complexities between different CMSs, some will handle parts of the migration for you, whereas others will not. If you have one of the more common CMS systems it is worth checking to see if they have a migration guide. If you have a bespoke CMS, talk to your website developer to see what assistance they can give.

Get Started Devices
Getting an SSL certificate

There are three types of commercial SSL certificates, choose one that fits the particular need of your business, one size does not fit all! Each gives different levels of security and also displays differently in the address bar.


  • Domain Validation

    The certificate authority issuing your certificate checks your right as the certificate purchaser to use the domain name. Your company identity is not vetted and only the encryption information within the Secure Site Seal is displayed. This validation is suitable for a single domain or subdomain, requires no paperwork and is usually issued quickly. It’s also the cheapest of the options. Address bar will display as a green padlock.

  • Business/Organisation Validation

    The certificate authority checks your right to use the domain name. The company identity is vetted, to an extent, and additional information about the company is displayed to customers when clicking on the Secure Site Seal. This validation is suitable for a single domain or subdomain and is usually issued within 1-3 days due to the extra need for business verification. Address bar will display as a green padlock.

  • Extended Validation

    The certificate authority thoroughly vets your company, including verifying your legal, physical and operational existence, that your name matches official records and that you have exclusive right to use the domain. Provides higher level of security and covers single domain or subdomain, usually issued within 2-7 days due to need for business verification. This one also comes with the green address bar for extra trust factor.


Perhaps also worth a note, is a fourth option, the self-signed SSL certificate. Although this too will encrypt data such as customers' login and other personal account details, most web servers will display a security alert because the certificate was not verified by a trusted certificate authority. When asking users to part with financial and personal details this might be a block to conversion.

Installing an SSL Certificate

The method for installing the SSL certificate will depend on both the type of certificate you have and the server you are using. A simple search for your particular combination is worth a punt but if you are stuck on how to proceed, contact the provider of your SSL certificate, they may have some guides already prepared.

Validate your SSL Certificate

Once your SSL is installed, validate it using online tools for confirmation that both the certificate is installed correctly and the server configured right.

Set a reminder to renew your SSL certificate

It’s not enough to install your SSL certificate and leave it. If you have a certificate that will expire after a year you will need to ensure you renew it annually. If the SSL is left to expire not only could this cause problems with your website but you may also need to go through the whole verification process again to get a new certificate. If possible, choose a certificate with a longer lifespan so you have to renew it less frequently or one that auto-renews if available.

Benchmark

If you want to know how well the move has gone you need to know the state of play before the migration. Take a crawl of your site, an in-depth 12 month report from your analytics programme and a keyword ranking snapshot. Understand the seasonality of your site so you can tell if any fluctuations in performance are due to the usual factors or an issue with the migration. In order to spot problems with the migration you need to know what normal looks like for your site.

Communicate with stakeholders

If your marketing team is planning on a short term campaign days before the migration it is likely to skew your data and impact on your monitoring. Equally, if your IT department has no idea of the imminent changes they may not be on hand to lend assistance if something goes wrong. Talk to your team. Let them know the plan and how they can help you with a smooth transition.

Added complexities

Be aware that if you are using the move as an opportunity to update your website structure, CMS or content you will be adding in another layer of complexity. It might make it more difficult to diagnose migration issues as fluctuations and performance issues might be due to the other changes you have made or could be masking a deeper problem with the migration.

What to Move

What to Move Site
How much needs to be moved

If you have a small site you can move the entire domain to HTTPS at once without additional complexity. If your site is large, or has multiple sub-domains for instance, you may want to move it across to HTTPS in stages. To process a change from HTTP to HTTPS the search engine robots need to crawl a significant portion of the HTTP URLs and all of the HTTPS URLs. This allows them to realise the change has occurred and recalculate the ranking positions for the new HTTPS URLs. Many people assume that all the site will get crawled as soon as the search engine robots see t here is a protocol change. Unfortunately not, and this may result in a drop in rankings during the move.

For truly huge sites, you may choose to run both the HTTP and HTTPS sites concurrently. You would then need to use canonical tags to indicate to the search engines that the content has moved. But this takes a certain amount of trust that the search engines are respecting the canonicals. Redirects are usually a safer choice if possible.

Google has stated in the past that “when two URLs from the same domain appear to have the same content but are served over different protocol schemes, we’ll typically choose to index the HTTPS URL”, but this depends on a whole host of factors, including if the HTTPS pages have insecure dependencies such as images and videos. Don’t forget, Google has been dealing with issue of www. and non www. duplication for many years so they are likely able to handle HTTP and HTTPS duplication but it isn’t something you want to leave to chance.

Network Inspector
Listing your resources

It’s time to crawl your HTTP site. Look for all resources that are crawlable by search engines, including the robots.txt, fonts, Javascript and CSS files and any images. It is also a good idea to perform a site search in Google and Bing “site:yourdomain.com” to get a list of all URLs that have been indexed. This information will be needed once the migration has taken place to check all has gone as planned.

Preparing to Move

On-site

Duplicate all of the HTTP website content to the HTTPS version’s location. This will be the development site that you created. From here you can start updating the onsite elements of the website to the new HTTPS version.

  • Internal Links

    A common problem with moves to HTTPS is leaving internal links to the HTTP version on the site. This means the search engines are still able to navigate to the HTTP site from the HTTPS version. This will waste crawl budget as the search engines have to follow the HTTP to HTTPS redirect. Make sure you change all absolute URLs to the HTTPS version.

  • HTTP Headers

    Your HTTP headers are an efficient way of reducing code base overhead whilst communicating essential SEO signals to the search engines. This is likely where your canonical tags, hreflang tags and more are housed. Have a look to see that you have identified and corrected all of the tags. You may even discover some tags you weren’t aware of. Good practice for SEO is to have canonical tags on every page of the site, even if they are self-referencing. This can lower the risk of issues with duplicate content on your site. However, if your HTTP site has relative URLs change these to absolute canonicals with the HTTPS version of the URL referenced. If the HTTP site has absolute URLs, change them to reference the HTTPS version. Similar to canonical tags, make sure any hreflang tags on the site are referencing the absolute HTTPS version of the pages. Most CMSs will take care of this for you and your earlier investigation into your CMS’s migration guide should steer you here. But if you are in any doubt or yours is a bespoke CMS, speak to your website developer.

Header Inspector
  • Resource Hints

    If your site uses resource hints such as dns-prefetch, preconnect, prefetch, or prerender you will need to make sure these are using the HTTPS version of the URLs.

  • Open Graph tags

    Open Graph tags assist with telling social media platforms about the pages that are being shared. Make sure any OG tags containing the page’s URL are updated to the HTTPS version.

  • External scripts

    Make sure HTTPS is supported by any external scripts that are called

  • Structured Data

    Make sure you update any references to both your site’s and schema.org’s URLs to HTTPS

  • Internal site search & plugins are secure

    Make sure all your plugins, site searches and forms are updated to be secure and work with HTTPS.

  • Check for insecure content

    Use a crawling tool like Screaming Frog or DeepCrawl to export a list of any remaining insecure content. Fix where identified.

  • Update old redirects

    Using a crawler run a report of any URLs that are being redirected to. From there go back and update them to the HTTPS version. This will reduce the likelihood of redirect chains which will eat into your crawl budget.

SEO Screens
Technical Inspector
Technical
  • CDN

    Assets like Javascript, images and CSS files are needed to render most webpages. These are often loaded from a Content Distribution Network (CDN). All links to the assets loaded from the CDN need to be loaded from HTTPS. Update all CDN settings so they point to HTTPS versions, or remove the protocol entirely.

  • XML sitemaps

    Firstly, make sure there is an accessible XML sitemap on the HTTP version of the site. The XML sitemap should only contain the canonicals of indexable pages. These should be un-redirected, live URLs. If not, this confuses the indexed vs submission numbers when the sitemap is submitted to Google Search Console. Having your HTTP sitemap in Google Search Console will help with monitoring the indexation of the HTTPS pages.

    Next, crawl the HTTPS version of the site and compare it with the XML sitemap. If there are any pages on the HTTPS site that should be listed in the XML sitemap, but aren’t, make sure you update the HTTPS XML sitemap accordingly. Perform a sense check, all URLs in the XML sitemap should, of course, be the final HTTPS versions, and not the test site’s!

  • HTML sitemaps

    HTML sitemaps should be linking to the HTTPS versions of the pages. If they link to the HTTP version this will cause the search engines to have to crawl a redirect chain.

  • Robots.txt

    Often overlooked during a migration is the link to the XML sitemap that should be in the robots.txt. Make sure this is present and the location of the HTTPS sitemap is correct.

  • CSS & Javascript

    Your Javascript and CSS assets may load or import other assets such as images or fonts from either the same server, or elsewhere. These assets need to be available in HTTPS, which not all are. Test your assets with a find and replace of HTTP for HTTPS, if they are not available in the HTTPS version then you will need to find alternatives that are.

  • Feeds

    If your site regularly pulls in information from other sources, such as RSS news or third party product feeds, then you will need to ensure any links to the feeds and within the feeds are HTTPS.

  • AMP

    AMP has captivated the SEO industry with its ability to render content quickly. As such, more and more websites are becoming AMP enabled. If your site has AMP pages, the links to their URLs need to have the HTTPS protocol.

  • Cookies

    Cookies contain information, often sensitive in nature, such as authentication data. They need to be sent securely otherwise this information can be easily intercepted and read. As part of your migration to HTTPS it is crucial you update your server settings to ensure your cookies are secure.

Header Inspector

The Move

Redirects

One of the easiest ways to lose search traffic during any site migration is missing or botching redirects. Because of the importance of redirects in the move to HTTPS it isn’t a good idea to trust it to a redirect plugin, the best way to implement them is at a server level or via the .htaccess/web.config or equivalent file.

A catch-all redirect from HTTP to HTTPs will ensure the smoothest transition. Then creating the redirect rule it is wise to look at previous redirect rules to ensure there are no existing catch-all redirects in place that will lead to link chains. For instance, if your site automatically redirects to the trailing slash “/” version of a page, it is possible that the following chain could occur:

As previously noted, it is advisable to avoid redirect chains, especially on such as large scale, as they have the potential to eat into the crawl budget of the site and render some pages unreachable during a bot’s crawl.

It is also necessary to ensure you update your redirect rules for the hostname. For instance, if you have a redirect rule in place for all non-www. to redirect to the www. version this will need to be updated, i.e. from

Don’t panic

A crucial step in the HTTP to HTTPS migration is remaining calm once you’ve pulled the trigger. No matter how well you follow guides there will always be nuances for your particular site that could mean a step gets overlooked or executed incorrectly. A level head throughout the process and a keen eye on the metrics will mean you are able to spot and react to any issues as they arise.

After the Move

Allow the bots

If you have restricted access to the site in the robots.txt or through no-indexing, make sure you remove this so the search robots have access to the new version of the site. Too many times this step has been missed on a site migration and a beautiful new site remains inaccessible to the search engines.

Redirects

Using your earlier crawl of the HTTP site upload the comprehensive list of HTTP URLs into a crawler, such as Screaming Frog and check that all are 301 redirecting to the correct HTTPS URL.

Robots.txt

Update your robots.txt with the HTTPS version you’ve already created.

Iphone Robot
Folder Image
On-site

Once you’ve finished migrating it is crucial you check that everything has gone as you would expect. Check the following:

  • Internal links

    All pointing to the HTTPS version of the URLs.

  • Tags & structured data

    Check your canonical tags, hreflang tags, open graph tags, structured data references and resource hints have updated as you would expect.

  • Development site links

    If development links have been hardcoded on to the site during the migration, usually because the opportunity to update content has been taken, then these will need to be amended. The quickest way to identify development links on the site is by running it through a crawling tool and searching for part of your development domain.

Technical

It is important to check all the technical aspects of the website set-up are functioning correctly after the migration and are all pulling through secure content.

  • Check your CDN, CSS & Javascript

    Are your resources all HTTPS? If not, update. Now. You can be suffering from mixed content if the initial HTML loads as secure but other resources do not. It will compromise the overall security of your site and lead to warnings in the browser.

  • Check HTML sitemaps

    You may have updated your feeds and third party content but check that the migration has happened as you expected.

  • Check Feeds, AMP & Cookies

    You may have updated your feeds and third party content but check that the migration has happened as you expected.

  • Fix 404s

    If you are noticing high levels of 404s, or any that weren’t there before the migration, make sure you investigate and fix them. It could be an indicator of a larger issue with the migration.

Off-site

Like with moving house there will be a ream of people you need to notify of your website’s change of address.

  • Google My Business/Bing Places

    It’s imperative that your NAP (name, address and phone number) details on your GMB/Places accounts are consistent with your website, therefore, it is necessary to update the listings with the new HTTPS version of the address.

  • Citations

    As with Google My Business and Bing Places, any other citations you have, such as directory listings need to be amended or notified of the change.

  • Facebook/social media

    Update your social media channels with the new address, and whilst you’re at it, why not shout about the change to a secure browsing experience?

  • Google Analytics

    Make sure you remember to update your Google Analytics account. Go to Admin and your view settings. Change the settings from HTTP to HTTPS. This way you keep the history of your site and don’t have to start all over again!

Off-site Laptop
Make sure your search console and webmaster accounts are updated:
  • Add the HTTPS version of your domain. This is a crucial step if you want accurately monitor the migration and for ongoing website health checks. It is possible to group properties within Google Search Console to make for easier management. It is not necessary to use the change of address tool in Google Search Console for a migration to HTTPS.

  • You may also want to check all the settings for the HTTP version, such as crawl rate, geotargeting and URLs set for removal and replicate these in the HTTPS property.

  • Whilst you’re there, check for (and deal with!) any manual actions for the HTTP site.

  • Also, submit the HTTPS homepage to index. Verify that the homepage of the HTTPS version renders correctly, then click "Submit to Index" button and "Crawl this URL and its direct links".

  • Submit your new XML sitemap.

  • Update disavow file - If you have a disavow file for the HTTP version of the site, you may wish to upload it to the HTTPS’s Google Search Consol, especially if you have suffered from penalties in the past.

Off-site Laptop
Update Devices
  • Update your social share counts

    There are a lot of intricacies to updating your shares and other social media metrics following a protocol change. It is worth seeing if the social media sites have guides available for you to follow.

  • Update any pay per click, retargeting and banner adverts

    Update offsite advertising to point to the correct version of the site. Also ensure your email campaigns are configured to serve the HTTPS protocol.

  • Update other tools and tracking software

    If you are making use of other tools such as split testing software and keyword tracking, update these to use the HTTPS versions of the URLs.

  • Submit your site for HSTS prerendering

    HSTS (HTTP Strict Transport Security) allows a HTTPS website to submit their domain name to be preloaded into the browser. This means the website, if it operates solely on HTTPS, can be added to a list maintained by the browsers and once included on the list, benefit from faster loading. If a domain name that features in this list is typed into the address bar, instead of making a connection to the server, the browser will redirect the user to the HTTPS version using a 307 temporary redirect. This acts like a 301 permanent redirect generated by the browser and not the server. This causes the HTTPS website to load considerably faster in the browser than the HTTP version used to. This can be as much as reducing 100+ milliseconds to just a few milliseconds, which is a long time in website loading. It also means unnecessary HTTP redirects are avoided.


There are some conditions that need to be met before a site can be accepted for HSTS.

To check your site meets all the necessary conditions and to submit is for HSTS, visit https://hstspreload.org/

Once your site has been accepted for HSTS it is difficult to reverse. You can apply to the browsers to have your site removed but this can take months to process. It can also take years for users to update their browsers so you’re in for a long wait if you wish to go back to pre HSTS.

The Aftermath

This is the point where you hold your breath and watch the numbers. Unfortunately, you might be holding your breath for a while. Depending on how large your site is, and the method you chose for moving it, the HTTPS site might not be completely indexed for several months.

There are ways of tracking how well the indexing is progressing however, so whilst you are waiting on the fruits of your labour you can keep an eye out for potential issues.

Google Search Console

Google Search Console, for both your HTTP and HTTPS property, is key in seeing how well your new site is being indexed. Look at both the XML sitemaps submitted to the HTTPS property and the index status. You should be able to see an increase in the number of pages indexed as time goes by. Similarly, looking at the HTTP property’s index status should show a decline in pages indexed.

Server Logs

The server logs are possibly the best way to understand how the search engine bots are crawling your site and any errors they are encountering. Data from log files is not easy to interrupt by the untrained eye so it will be worth utilising a log analyser to help you out.

Aftermath screens
Keyword monitoring tools

It will hurt initially but you need to face the pain of fluctuating rankings and keep an eye on your keyword monitoring tools. It is not uncommon to experience a period of ranking tanking, but if it isn’t recovering in line with the indexing of your site you may need to look at supplementing the work you are doing with additional focus on keyword rankings.

Compare with your benchmarks

Using the benchmarking reports you made when preparing for the migration you should be able to spot if fluctuations are genuinely a result of the migration or if they are part of your industry’s seasonality.

It is important to remember that migrations are not simple. You will most likely see an impact in the months following a migration and it is to be expected. If you have made the move from HTTP to HTTPS and you are experiencing a decline in traffic or you have picked up on a high number of 5XX or 4XX requests being made to either HTTP or HTTPS version then retrace your steps. Go back through this guide and see if there is a step you missed or a complexity you overlooked. If you are really struggling to diagnose the issue or are unsure if what you are seeing is normal then it might be time to seek outside help. SEO agencies with a history of successful HTTPS migrations are a good source of reassurance or troubleshooting assistance.

Reflect’s Recommended Resources

We’ve even done the legwork and found the resources you’ll need for a successful migration. The licence fee costs are on you though.

Analysis Tools

Server Log Analysis: screamingfrog.co.uk/log-file-analyser/

Insecure content checker: www.jitbit.com/sslcheck/

HSTS Validity Checker: hstspreload.org/

Crawling tools

Screaming Frog: www.screamingfrog.co.uk/seo-spider/

DeepCrawl: www.deepcrawl.com/

DOWNLOAD CHECKLIST

Contact our experts

Lollipop in and say hello

Creative design agency based in Maidstone, Kent

Trusted digital agency

  • google_partner_logo-min
  • iso27001-16779-small-min
  • thedrumrecommends_logo-min
UK Search Awards - SEO Winner
Wirehive Best Use of Search 2018
Drum Search Awards SEO finalist 2018
UK Search Awards 2018 SEO Award
5-wirehive-performance-marketing-campaign-finalist-v2
6-wirehive-consumer-site-of-the-year-finalist-v3

Maidstone - Kent

7 James Whatman Court, Turkey Mill, Maidstone, Kent, ME14 5SS

Soho - London

2 Bourchier Street, Soho, London, W1D 4HZ

Cape Town - South Africa

16 Edison Way, 1st Floor, Block D, Edison Square, Century City, Cape Town, 7441 South Africa

Proud to be a Lab Logo agency

Reflect Digital is rated 4.95 out of 5, based on 22 reviews on Facebook & Google 5 Star reviews