Website migration best practices

Best Practise

2023-02-03T07:51:55-05:00

When should we consider developing on a test website?

To set this in context, let's first consider the reasons for using a separate test site when starting a new website project. Sometimes the test site is also known as a sandbox site.

The most common reason is that there is already an existing website, up and running and as a developer, you need to maintain a continuous service and migrate seamlessly from the old website to the new one. As a client of a web developer you need and expect a clean cutover. I'll look at some scenarios later and look at why there may be a period of transition that you need to think about how to manage your way through the migration.
Another reason may be that there may be some very good business reasons why you don't want your website to be found, whilst it is being built. For example, a web search on your name and your activity may take a user to your site and you may not be ready for that until you are ready to launch your business and have signed off on the design and content of the site being built.

The easiest and least risky scenario for a web developer to handle is to build a new site on its final hosting package, with its live domain name and add pages and functionality over a period of time, testing the new pages in place and maybe putting up an announcement saying 'new site being built' or words to that effect. However, for the reasons mentioned above, not all clients will want that, so here are some considerations for how to successfully migrate from a test site to a live site without damaging SEO in the process.

So let's assume that you are developing a new site for a client on a test site running on a server somewhere. Personally, I run 3 sandbox sites on my hosting and once one is finished with I back it up and delete the contents, ready for the next project to come along. It is very rare that I am trying to build more than three sites at once requiring a test sandbox site.

Considerations when developing on a separate test website

SEO on the sandbox site

I never add any SEO metadata on the sandbox site because it may conflict with the existing (old) website and, if the sandbox site is still running after launch, with the new site. I make sure that pages are not indexed by removing them from the sandbox sitemap. This can be done in Rapidweaver by unchecking the 'Show in Navigation' tag at the page level.

Of course, this generates more work during 'go live' as the metadata then needs to be added and pages need to be checked that they are included in the sitemap.

Another way to stop search engine robots from indexing your sandbox site is to use the robots.txt file to disallow all robots.

Migrating the CMS

The CMS contains all the text data, gallery images and blog posts that have been set up during testing. Migrating this to the new site is a simple matter of copying the CMS folder from the sandbox site and uploading it to the new site's hosting. If using the depot functionality to store PDFs for example then the links to these PDFs may need changing as they may have been specific to the sandbox domain.

Hardcoded links

Sometimes it is necessary to hardcode links within the website and these need to be checked, after migration to ensure that they are not pointing back to the sandbox site.

New hosting server considerations

Is the new hosting package compatible with the CMS? Is it running a currently supported version of PHP for example? This is something that I always try and find out before the migration as I don't want to put in a lot of effort getting a site migrated to a hosting package only to find that it doesn't work properly. Hopefully it will just be a matter of logging into the hosting package and upgrading the level of PHP.
Does the new hosting operate at an acceptable speed? There is no easy way to determine this in advance and probably only experience will tell whether 'XYZ' hosting is fast enough and reliable enough for the job. It is important to do speed checks using available tools to see if you are getting an acceptable performance after the migration.
Does a domain-specific email address work for the client on the hosting being migrated to. If the hosting is new to them then the client may have to set up the email account on each of their devices that they are going to use. Even if the email account is with the existing hosting then it is imperative to test the email functionality from any contact forms and get help from the hosting company to avoid any issues. Which also raises the question of how helpful are the support team at the hosting company?
Does the hosting being moved to run any sort of server-side caching? Server-side caching, sometimes called dynamic caching, consists of your hosting company keeping a snapshot of your site on the hosting server to deliver to the browser of anyone requesting to view your site. If you are building a site that is almost never going to change then this may be and ideal thing to have because you will definitely get some speed benefits and hence some SEO benefits of having a fast site. For the rest of us living in the real world of constantly changing websites with content that is updated regularly, server-side caching is a problem because what the customer sees is an old version of the site, unless you log onto the hosting package and purge the cache. A better way to deal with server-side caching is to find a way to disable it so it doesn't interfere with your or your client's ability to make updates to the site.

Change of hosting server location

On a few occasions, I have found on investigation that I need to point an existing domain name to a new location, usually because a previous developer has moved the site to different hosting. The domain name and the hosting can be set up separately with different hosting companies. Many hosting companies offer attractive rates for domain names in order to encourage business in the hope that they will then also get to host the website which is the more lucrative side of their business so often I find a situation where a domain at company A is actually hosted at company B. This is usually achieved by updating something called the nameservers. Every domain has a set of name servers which tell browsers where to go to get to the actual site and sometimes during a migration exercise I will need to change those name servers to point to the required hosting.

This process can take several days to complete, although often one can see the new site through a particular browser after a few hours. I have four browsers on my Mac and sometimes I see the new site within a couple of hours on one of my browsers but the other three still show the old site.

The name server change has to be propagated across thousands of name server locations around the globe and it is luck of the draw for any given page view, which name servers your request for a page is being routed through. So during this type of migration you may sometimes see the new site and you may sometimes see the old site. This instability may have other odd effects so it is best not to plan to make changes to content through the CMS for example whilst this change is being propagated around the globe.

For the client this is also a consideration as incoming queries and bookings may get interrupted. It may be best in this scenario to close any routes to making a booking for example for a couple of days so timing of the switchover may be business critical.

Website Monitoring tools

Once I have gone through this sort of website migration from a test site to the live site I will always run tools against the live website to check that the site is working as expected. The tools I use are:

Using Lighthouse to monitor sites

1. Google Lighthouse which runs from Chrome/Developer Tools.

Lighthouse reports on Performance, Accessibilty, Best Practices and SEO. Scores above 90% are generally deemed to be good.

Using Web Site Auditor to monitor my site

2. Website Auditor

This is a tool I regularly use to check on website performance and SEO optimisation for particular pages against specific keywords.

It serves as a good way to check whether all the necessary steps have been taken during a website migration exercise.

3. Having submitted the migrated site to Google and Bing, I will then go back after a few days and check whether the Google Search Console and the Bing Webmaster Tools screens are showing any errors that I should be worried about.

Go live checklist

This is my own personal checklist for me to ensure I haven’t missed any important items:

Publish a new version of the RW project file to the live hosting server.
Migrate CMS files. My method is to copy the sandbox site to my Mac using FileZilla (although any FTP app will do). This also serves as a backup of the working test site. I then copy the cms-data folder to the live hosting server. Again I use FileZilla.
Once the CMS data for any blogs are copied over I will re establish the link from the Blog List page to the Blog Post page by using Rapidweaver preview on the Blog Post page and confirming the change in linkage in the pop up panel.
Check htaccess contents are correct on the live site. Test the page notfound condition works properly. Test that non WWW to WWW works. Also use code to disable dynamic caching in htaccess.
Set force HTTPS at server level
Add new TCMS licence code for the live site, register the licence, re-publish and test changes in Admin pages work correctly.
Check any forms set up and test them in live.
Add SEO tags using SEO Basics for the live site and also add structured data stacks (local business). I never set up SEO stacks until I am working with the live site.
Make sure that the Generate Social Tags box is unchecked in General settings in Rapidweaver. Viewers can't share to Facebook otherwise.
Test rich data using https://search.google.com/test/rich-results
Either use the real favicon generator website to create favicons and FTP to the new server, or use the RW icon set (create a 180 square png image in Logoist with a coloured background)
Run website auditor and check each page for optimisation score
Add Google analytics (if required), cookie jar and Data Privacy Policy section. I usually don’t add these to the Sandbox test site.
Add the website to the Google Search Console
Add Sitemaps in the Google Search Console. N.B. Set all pages requiring indexing to appear on the Sitemap as 'Show in Navigation' in RW
Add to Bing Webmaster Tools. I let Bing get its data from Google Search Console
Add a link from the Gallery page on websitesyork

Different developers may want to do things in a different way from me but my best advice for any migration is to have a checklist of activities to follow and for tests to check the results of those tasks. Develop your own checklist and add to it over time as you discover new things and ways of working.

If you would like to know more about web design then I would be happy to talk to you so please get in touch.