If you are a designer of some kind, you probably wince at the idea of checklists. You want to create attractive effective designs, and leave the technical details to someone else.
But if you’ve ever designed and launched a website, you know that is rarely an option. Launching a new site involves taking care of many individual tasks, and a checklist is simply the sanest way of making sure everything gets done.
Why Have A Site Launch Checklist?
- To spot issues before they become issues. By making a list of your necessary tasks, including common mistakes or errors, you minimise the chances of something going wrong. Checklists help you anticipate potential headaches and avoid them.
- Cover your back. As well as preventing costly or embarrassing errors, a detailed checklist can be used to prove to both yourself and the client which tasks were completed and when. Including records of client approval can prove useful in any future correspondence.
- Ensure everything works as it should. The internet is a funny beast, and change happens fast. That thing you assumed would always work fine can suddenly and unexpectedly break. Checklists force you to put aside assumptions and actually check. This kind of work can seem repetitive and pointless, but you are better safe than sorry.
Breaking Down Your Checklist
A checklist can seem a daunting prospect, given the multitude of factors at play in any given web project. Where do you begin? We like to use a simple formula for any site launch checklist:
- Pre-Launch Tasks
- The Launch Itself (checklist of process)
- Post-Launch Tasks
I’ll provide some examples of what you might include in each section below.
The pre-launch stage ensures that everything that can be done before the launch is done. Here we include factors like:
- Redirect Considerations. If we are launching a site re-design or moving domains – you will need to redirect old pages to their new counterparts. Have we got a list of the old pages? Have we prepared the Redirect data, ready for activation post-launch? You don’t want to have to try and figure this stuff out once the new site is live.
- Site Speed and Usability. Hopefully your staging site is on a comparable server setup to the final destination, so you can run through a series of tests to check page speed, best practices and standard usability checks. For example – how does the site perform on mobile? In different browsers?
- Analytics and Tracking. It may be difficult to fully test all elements of the analytic setup before going live, but many parts of the process can be checked pre-launch. Is your tracking code installed and/or ready to go? Are goals and other trackable events going to be easy to activate?
- SEO considerations. Checking for the standard SEO best practices. Titles, descriptions, header tags, the no-indexing of hidden pages and working sitemaps would all be good places to start.
- Interactions. Contact forms, newsletter sign ups, ecommerce sales – all such actions require testing pre-launch.
- Backups. Both before and after the site launch, you want to have recoverable backup files in the case of any problems. Get this lined up pre-launch with a plan in mind should anything go wrong.
- Client sign off. Don’t just take their word for it – get it in writing! Make a note of the date that the client signed off the staging site, and don’t begin the launch process until you have it.
Every ‘switch on’ process will be different, but you will usually need to consider the following:
- Hosting Setup. What steps do you need to take to setup the server for the new site? Do you need to create new DNS records, or simply edit a few nameservers? How long will the propagation process take?
- A Detailed Launch Process. Don’t take for granted that everyone knows and understand the required steps. Writing the process down will help other team members know what to do, including yourself. From importing databases to uploading files via ftp – each step should be clear in your head and clear on paper (or screen, probably).
- Email Addresses. Perhaps you are only dealing with the website – but what about email? Moving servers or domains will likely impact any email addresses associated with that domain – so prepare for this beforehand and make it part of your launch process. This may mean simply setting up a bunch of email redirects, but it could also require you to download and transfer old email messages to the new server.
The site is live! Is that the end of the story? If only. Now you need to check (and even re-check) things like…
- SEO again. Is the site indexable? Are redirects working as they should? Any 404s? What about sitemaps? There are no shortage of tools out there to help you check such things.
- Lingering Staging Files. If your launch process is comprehensive, hopefully this won’t be an issue, but you should still check. Is your new site referencing any files, images or content from the staging site? They may have been mistakenly hard-coded into template files…so perform a good sweep.
- Interactions again. They may have worked fine on the staging server, but now you’re live it’s time to double-check all of this. Is the client receiving contact form submissions? Is the newsletter sign up sending confirmation emails? Are ecommerce sales tracking in analytics?
- Client Sign Off. After a period of testing, you will probably want to let the client do some of their own investigation work. If you received an explicit sign off beforehand then this is unlikely to throw up any issues – but it can be helpful to get a fresh pair of eyes on the whole thing ‘in the wild’. Be sure to confirm the clients sign-off after launch.
Using such a model checklist will save you from a variety of nasty surprises. Defining the project ahead of time and knowing what steps to follow will make life easier for you and your team – and means the client is less likely to have any complaints after their new site goes live.