TRAFFIC
ALL YOU NEED TO KNOW
FOR MOVING TO HTTPS( PART 3)
Fili Wiese from SearchBrothers. com brings us the final instalment of his three-part guide for webmasters looking to make the transition to HTTPS, explaining how to troubleshoot problems arising from the move.
THE FIRST TWO PARTS OF THIS GUIDE described first, how to prepare for moving to HTTPS and second, how to perform the actual move on the server side and Google Search Console side. This final part goes into the completing the move to HTTPS and explains how to measure the impact and identify problems from the migration. It also discusses the next steps now that the website has been moved to HTTPS.
Finalising the move to HTTPS At this point, everything has been done for Google to prefer the HTTPS version 1 of the website and for Googlebot to best understand the move to HTTPS for the website. Depending on the size of the website crawled and the crawl budget available, it may take anytime from a few weeks to a few months for the switch to be visible on Google Search.
In addition, it is also important to monitor how the move to HTTPS progresses in Google Search, and whether any new issues arise.
Monitor server logs If something is not working as intended, fix it as soon as possible, make sure there is a notification system in place and monitor for any 50x or 404 requests being made to either the HTTP or HTTPS version of the website. A good place to find these errors is in the server log files. However, it is also possible to send a message by email or to a Slack channel at the moment they occur. Working together with the IT team will ensure there is manpower available to resolve any critical errors as soon as possible. Highlighted 404 errors may be a false alarm, but make sure these are not unexpected, and check why they are occurring and if they need fixing.
84.25.65.243-- [ 10 / Oct / 2016:13:55:36-0700 ]“ GET / favicon. icof HTTP / 1.1” 200 326“ http:// www. example. com / start. html”“ Mozilla / 4.08 [ en ]( Win98; I; Nav)” 2.5.45.7-- [ 10 / Oct / 2016:13:55:45-0700 ]“ GET / HTTP / 2” 200 2956“-”“ Mozilla / 5.0( iPad; U; CPU OS 3 _ 2 _ 1 like Mac OS X; en-us) AppleWebKit / 531.21.10( KHTML, like Gecko) Mobile / 7B405” 64.233.191.102-- [ 10 / Oct / 2016:13:55:49-0700 ]“ GET / home HTTP / 1.1” 200 43455“-”“ Mozilla / 5.0( compatible; Googlebot / 2.1; + http:// www. google. com / bot. html)”
Figure 1: Example of Screaming Frog Log Analyser with data
When possible, also use the system to keep track of which pages Googlebot is indexing, how fast and which status codes Googlebot is primarily crawling. As this data is best mined from the server log files, it may be useful to utilise an ELK stack 2 on a local server or a third party log analyser such as Botify 3, Screaming Frog Log Analyser 4 or Splunk 5( see Figure 1). Alternatively, load the server log files into Google BigQuery 6 and use the Google BigQuery interface or the 360 Data Studio 7 to analyse the data.
1 https:// webmasters. googleblog. com / 2015 / 12 / indexing-https-pages-by-default. html
2 https:// logz. io / learn / complete-guide-elk-stack /
3 https:// www. botify. com / log-analyzer /
4 https:// www. screamingfrog. co. uk / log-file-analyser /
5 https:// www. splunk. com /
6 https:// cloud. google. com / bigquery /
7 https:// www. google. com / analytics / data-studio /
20 iGB Affiliate Issue 63 JUN / JUL 2017