Website Go Live Check List for Launching a New Website

Here's a helpful Website Go Live Check List to help in the stressful time of a new website launch or a deployment of upgrades.

If you have ever launched or managed a website, you'll know how stressful it can be. Here's a helpful Website Go Live Check List to set you on your way, as well as a few things to check after deployment.

Launching new websites can be a stressful experience with technical glitches cropping up, data errors or inconsistency, unforeseen differences between production and development environments and so on. The list can be almost endless, but there are a few things you can do in advance to prepare and mitigate these risks.

Data

So, your developers have finished development, and the website has been through the QA process, everything should be working ok by now. If you're working on larger projects which require lots of data held in a database, such as product information or customer records then there are likely inconsistencies between what the developer set up on a local dev machine or test server, and what is actually on the live production system. Since replicating the live database to a development machine is a gross violation of privacy and GDPR, you cannot do a direct copy, but you can anonymize the data - especially in the customer records. Simply write a script that will replace the real customer data, such as names, addresses, telephone numbers etc. with dummy data. This new data can then be imported into the test system and you can test with almost real data. This is especially useful if you have a large number of foreign keys or lookups which can sometimes not join up.

Before You Go Live

Before you start the go-live process, make sure you have everyone on hand, or at least on standby, so that any problems can be fixed promptly. Do you have a dev on standby in case of a critical defect being found, do you have a network or server admin available in case of technical problems?

The Go-Live Process

I have lost count of the number of sites and projects I've put live over the years. There are various methods of transferring files to the production server, including fancy tools and bespoke scripts, but the method I use now is not only the quickest, but it is also the easiest to roll back should the need arise.

It may require you to change the directory structure on your web server's root directory, but in the long run, I think it will be worth it. This is the method I use to set up new servers and provide updates with as little downtime as possible.

Before I show you my method, let me explain a few of the alternatives I've seen and worked with in the past.

The first is the copy via FTP into the web folder, overwriting the existing content. If there are lots of files moved or deleted (only the developers know this) then delete the original contents and upload a fresh copy. This, of course, has the disadvantage of the website being unavailable during this time, and in one case, I witnessed a power cut in the office after deleting the old website files - two hours later we were able to start the upload process. Similar methods involve copying the files to a USB stick and then plugging this into the server. This is an option if you have a self-hosted server, but not an option for the vast majority.

Other options include using the Microsoft web publishing tool, which frequently crashes on larger sites, server switching, and yes server switching! One company I contracted for had a load-balanced server where they would break the load balance link, update one server to the new website, switch to the new server, take the other server down to update, then bring it back online and reactivate the failover software.

The best method I have found is a quick and simple method which has not let me down yet.

You need to structure your root web server directory differently (inetpub/wwwroot or htdocs depending on your server setup). Within this, a directory for each site, and within this a date-based folder structure. Simply create a folder for today's date, and upload all the web content into this folder, it doesn't matter how long it takes as the old files are still being served. When you are ready to go live, simply change the config in IIS or Apache to point to the new folder and apply the changes. Job done. Should you need to roll back, simply change the config back to the old folder, apply, job done.

SEO Checklist

Now the data and the web files have been tested, and verified and you know how to deploy them effortlessly and risk-free, have a check over the site to make sure nothing is going to break your SEO efforts.

Content

You should already have this covered during QA, but just to recap make sure that all web copywriting has been proofread. Spelling and grammar are correct. Paragraphs, headers, lists, and other formatting are correct. Copyright date (perhaps in the footer) includes the current year. Company contact details are accurate throughout the website. Generic content, such as lorem ipsum, has been properly removed and replaced. Images are in the correct places, formatted and working on all devices. Media content is in the correct places, formatted and working on all devices.

301 Redirects

If you make any changes to the files and folders in a website which mean that the location moves or is removed completely, you need to provide a 301 redirect so that any search engine traffic or organic links will point to new or relevant content instead of getting a 404 Not Found error.

Crawl the website using a tool such as Xenu Link Sleuth and use an Excel sheet to document not found errors where the old URL (Column A) will be getting mapped to on the new website (Column B) - all you've got to do now is put them in place before the website goes live. The methods for this vary between platforms, so check the documentation for your system.

Page Title and Descriptions

Search engines have long on a long way since we had to manually specify keywords for the page, and craft cunning meta descriptions and page titles stuffed with keywords the meta keywords aren't even required and often advised to leave it out altogether.

Enticing page titles are still very important, so check in the crawler that the page titles and meta descriptions describe what is on the page and are unique to each page on your website.

XML Sitemaps and Robots.txt

Accurate XML (and HTML) sitemaps are vitally important for search engines. They list all the pages on the site and allow the search engines to crawl more efficiently and intelligently. HTML sitemaps are human-readable lists which visitors can use to find content easier.

The robots exclusion standard, also known as the robots exclusion protocol or simply robots.txt, is a standard used by websites to communicate with web crawlers and other web robots. The standard specifies how to inform the web robot about which areas of the website should not be processed or scanned.

Also, check that there are no pages excluded in robots.txt or with the robots noindex tag which in fact should be indexed. Sometimes development sites are internet-facing and set to robots no-index to prevent listing in search engines.

Tracking and Analytics

Make sure your Google Tag Manager, Google Analytics and Bing Webmaster tools are set up and ready to go. Believe me, it's a right pain when you check the weekly stats only to find that the tracking codes haven't been added or updated. It also allows you to monitor your new changes and see the impact of your hard work.

Structured Data Mark Up

If you use Structured Data Markup on your site (such as reviews, recipes, events and so on) it's a good idea to check them in the Google Structured Data Markup checker  to make sure there are no errors introduced.

Minification and Packing

Many devs turn off minification and packing for debugging, so make sure that none of these changes has made their way onto the production environment and verify that you are serving compressed content, minified CSS and packed javascript content.

Server Config

TLS Certificates

You should be using TLS certificates to secure your site. After you launch, verify that each page is secure and that the certificate is valid.

Protected Pages

Check that any protected pages are inaccessible and require authentication and that these pages, if not the entire site, are served using HTTPS.

Backup System

Verify that any new web folders and data are added to your backup schedule and that they actually get backed up. In the past, I've seen people so confident that the new website was being backed up, but the backup tool did not have permission to the htdocs directory so nothing was actually getting backed up.

Things to Keep Your Eye On Post Launch

Traffic Loads

Keep an eye on server loads and traffic after launch. Sudden dips in traffic could indicate a problem either with the website or the indexing. Both need to be investigated to find the cause so it can be fixed.

Also, keep an eye on the server load. Has a new piece of code been written inefficiently and causing high CPU or memory usage, is a chunk of code getting called multiple times or crawled too frequently by spiders? These things will drag down your page load speeds and could harm your search engine rankings.

Testing

After a deployment, you should do an initial smoke test, and the following day do a more thorough test of all parts of the site to ensure that no area was unintentionally broken and that all the files and updates were deployed correctly.

Spread the Word

After the site has been deployed, and QA has verified that everything is working as expected, only then should you take to social media to let everyone know about your brand new website or major improvement works. Nothing is worse than all your social media followers publically finding bugs for you.

Have you any other tips for successfully go live? Have you any horror stories to share? Let us know in the comments below.