Article Image
read

There are a lot of things to take into account, when you're finished with website development and planning to go live with a new (version of a) website.

Here's a basic list of what needs to be taken into account.

What should have already been done
AKA Don't bring these up during release

  • Design changes to how things look
  • Functionality changes to how things work

Any changes to the visual and functional aspects of the site should be done before launch testing. If you find something you don't like this late into the project, think hard whether you can live with it for a while. More often than not, the best thing to do is write it down, but don't bring it up until after the launch. Even small changes can create problems everyone wants to avoid.

Pre-launch checklist

Technical side of things

  • Make sure live server configuration is good to go
    • If you're automating server provisioning, your live server is already identical to any staging/dev environments you're using.
    • If there's any doubt, double-check.
  • Lower DNS TTL
    • A low TTL during launch ensures that the launch happens quickly, and that you can react to any changes without long waits. You should change the TTL days ahead of the planned launch date.
  • Enable production cache settings
    • Usually you don't want cache in the way of development, so these settings are off during the testing phase. Whatever your CMS, make sure caching is enabled and configured.
    • Things to note:
      • Javascript, CSS and SVG are minimized and combined, where possible
      • Images are optimized
      • If you're using a CMS like Drupal or Wordpress, disable any unused modules/plugins
  • Security
    • Check that admin passwords are secure (no qwerty or other placeholders)
    • If using a CMS, upgrade to latest version
    • Enable SPAM filters, where applicable
    • Check file and user permissions
  • Final test barrage with live environment

You'll want to emulate the end-result as closely as possible. The easiest way to do this is to use the live server environment, and add its ip address to your local hosts file. Test also without being logged in to the site.

  • At the least, make sure to test for these:
    • Browser test with supported browsers
    • Mobile device browser testing
    • Form input test (search, subscription, contact forms, etc)
    • Load testing?
    • Favicon
    • HTML/CSS Validation (W3C Validation)
    • Javascript errors
    • Broken links (for example using W3C Link Checker)

Final browser testing should be a formality, and not something you need to stress. Many popular automated testing tools, such as CrossBrowserTesting allow you to run the tests using your own connection, so you can even use a local hosts file.

  • Enable Analytics
    • If you're using an analytics software (and you should be), make sure that you're running the live configuration, and that it's working.
      • Check analytics code
      • Check analytics configuration (funnels, goals, custom variables)
      • Exclude relevant ip addresses and/or user groups from analytics
  • Backups and Monitoring
    • Whether you're using a server-level solution (not just RAID), or site-specific backups, make sure they're up and running.
    • You'll also want to set up a monitoring solution, that let's you know when there are problems. UptimeRobot is a simple tool to get started.
    • Instead of a backup solution, you should really focus on a recovery solution. How would you completely restore the production environment from backups, and how long would it take?

Content and SEO

  • Proof read content
    • Make sure to correct any factual errors, spelling and punctuation, and test that links are working.
    • Pay especial attention to the following:
      • Contact information
      • No leftover test content (search for Lorem ipsum)
      • No absolute links to test/staging server urls
  • Migrating content? Write redirects
    • It's important that search engines and users following old links are able to find your content. You should map old urls to new ones with 301 redirects, to automate the progress.
    • You can complement this by using a dynamic error page, when content is not found, and push the users in the right direction.
  • SEO Checklist
    • Thought-out title tags (70 characters or less)
    • Relevant meta tags (description 156 characters or less)
    • Test social media shares
    • Canonical URLs
    • Hierarchical and readable url structure
    • Automatically generated sitemap
    • Alt tags in images

During launch

This should be the easiest part of the launch. Change the dns (or server config) to point to the new site, and monitor the results.


After launch

  • Revert back to regular DNS TTL
    • When you're sure your new website is up and running, you can reduce the amount of requests to your dns servers by increasing the TTL back to whatever you're regularly using.
  • Double check documentation
    • Server and site documentation should be checked for validity. Things might have changed during the project.
    • Make sure that all passwords and documented login details are up-to-date

Most importantly: Reflect on what you could do even better. Any surprises you had should be added to your own launch checklist.

Blog Logo

Juhani Naskali

The not-so-famous IT-specialist from Finland


Published

Image

Juhani Naskali

The not-so-famous IT-specialist from Finland.

Back to Overview