Re-launching a site is no small task – there are many moving parts and usually lots of cooks in the kitchen. A poorly planned launch can cause enduring pain at a time that should be celebratory. In our experience, here are some of the most important parts of the process to consider to ensure success.
301 Redirects
When you move from the old version of your site to your new one, you will likely be introducing an entirely new URL architecture. While someone entering from the front page of your site will still be able to get to where they’re going, without a solid redirect strategy, all of those new URLs are going to confuse the heck out of Google, likely resulting in a precipitous drop in organic traffic results.
Setting up a list of 301 (permanent) redirects will move people and search engines from your old URLs to your new URLs. Using a 301 code tells Google that it can permanently update with your new URLs, rather than dropping large swaths of the site and rediscovering it.
You should use Google Analytics and Webmaster Tools to gather a list of currently-utilized URLs pre-launch, and determine what their analog is on your new site. These lists can grow to be hundreds of links long, so a database-driven redirect strategy may be helpful. Many CMSes have modules available to help a site administrator manage this list. Get this list in place prior to launch to ensure that everyone gets to their correct destinations after the site is re-launched.
DNS Considerations
DNS is the phonebook (remember those?) of the Internet. When you navigate to a website, your laptop, tablet, or phone will need to know the IP address of the website it’s trying to reach. In order to translate the named address (i.e. www.example.com) to the numeric IP (12.5.17.11), your device will query a DNS service.
Caching is central to the way that DNS works. Each translation from domain to IP comes with a recommendation for how long devices, caches, and other DNS servers should remember this information, so that they don’t have to constantly ask the authoritative servers. This is known as the “Time-To-Live” (TTL).
Simply put, if you are re-launching your site on a new IP address, you will want to reduce your TTL to something very low prior to launch – a few minutes if possible. This will ensure that, at launch time, the world will transition from seeing your old site to seeing your new site as quickly and seamlessly as possible. It also ensures that, if for some reason you need to revert back to the previous version of the site, it can be done quickly.
If you re-launch with a high TTL you subject yourself to a brackish period, during which some people will see your old site and some people will see your new site. This also makes switching back to the previous server take equally as long, with the same mixed site results.
You will also want to check with internal IT resources about whether there are any internal DNS servers or proxy servers that need to be updated or cleared around launch time. If these are overlooked, you may continue to see the old site inside your network, even after the rest of the world is seeing the new website.
Load / Traffic Planning
There is nothing worse than having a server crash on launch day. With a modicum of planning, you can sleep better knowing your architecture is built to withstand the traffic levels it will no doubt receive!
The first step is to take a look at your analytics and logs to get a sense of your baseline traffic levels. Looking at the current architecture and/or the architecture of similar sites with similar traffic levels can help you with a baseline setup. Consider putting your web servers behind a load balancer so that you can add additional servers to the mix without changing the IP address at a later time.
You should also consider caching options. Caching is probably the most effective way to reduce load on your servers while simultaneously speeding up load times. It can happen at many levels — query caching on the database, file-level template caching, in-memory caching using memcache or Redis, reverse proxies like Varnish Cache or Nginx, which will sit in front of your webserver, or CDN caches to serve your static assets are a few examples. Usually several of these are used simultaneously.
As important as the caching is, it must be accompanied with a good invalidation strategy (a set of rules that determine when to selectively clear caches if needed) so that site administrators understand when and how new content will be appearing after it’s been added.
Once you have a good setup, test it under some load! You can start with the lowly Apache Benchmark command-line utility, and scale up to using load testing services like blitz.io or Load Impact. Use them prior to launch to test various sections of the site. This will give you an idea of when your architecture will start to crumble under load and should let you effectively plan for how you can increase capacity when certain load and traffic thresholds are reached.
Monitor and Optimize
Immediately after launch, there is still much to do to ensure the launch’s success. For starters, you’ll want to get Google familiar with your site as quickly as possible. Ideally your 301 list is already doing its job of sending the spiders to the correct places, but you can get Google more rapidly and accurately acclimated by submitting an updated XML sitemap. This is an appropriately-formatted XML document that tells Google about all of the URLs that comprise your website. You can generate it via your CMS or by scanning your site externally, placing it somewhere public, and then submitting it to Google via their Webmaster Tools service.
If you run your own search engine, now is the time to update the search result URLs and re-index your site. Nothing says “unfinished launch” more than having your testing URL appear in your search results!
Finally, now is the time to watch things carefully for problems. Set up Google Analytics alarms to detect large spikes or dips in traffic. Set up service monitors to watch CPU, server load, network usage, memory usage, etc, and make sure they contact you if things start going off the rails. Use real user monitoring to observe how your new site loads for your actual users. Keep up on your page load times with services like Webpagetest and Google Insight as new content gets loaded onto the site and keep an eye out for small tweaks that can lead to big gains in performance.
There are a lot of other things that go into a successful launch, but giving at least these issues due consideration will put you well on the way to a trouble-free, relaxed site launch. Happy launch day!
