We are sometimes called upon to launch sites that were developed by other agencies or to launch sites to ensure the site is put live in accordance with a set of security and performance standards. Launching a website isn’t as simple as pushing a button. There are a lot of steps that have to happen before a scheduled launch to ensure that a website is performing as it should be. Just like a rocket launch, every detail needs to be triple checked, and every department needs to be on the same page well before the countdown starts.
There are two main ingredients for a successful launch:
Without thorough testing, you can’t be sure that your plan will work the way it’s supposed to. And without a clear plan of action, you can’t know what you need to test for.
Before we launch a website we develop a series of internal QA milestones to be carried out. These are usually divided into four broad categories:
Each of these categories encompasses a series of individual audits for specific elements of the website.
When we start the pre-launch process, we tend to have a launch date in mind, but typically the planned launch date will be far enough in the future that we have lots of extra time to resolve any issues. Having a planned launch date helps to focus the development process and keep everyone on-task, but it’s equally important to give yourself plenty of leeway to avoid unnecessary panic and allow for adjustments when needed.
The design is usually the first thing to be tested. In the design review stage, the original web designer goes over the site to confirm that what the developer has built matches the specifications of the design, whether that design was developed internally or by a third party. This is primarily a visual audit, with the designer taking a thorough look at each page of the site to ensure that content and widgets are aligned, colours are accurate, and images and graphics are sharp and correctly sized.
When it comes to development, we utilize a variety of different auditing techniques to drill down to the smallest and most obscure details of a website’s function. We take the time to go through every element of the website that to ensure that the back-end has been set up and organized according to our standards.
We spend time reviewing how the site looks and functions in native versions of all the modern browsers. We also test contact forms and email submission forms (often with the help of internal IT personnel) to make sure that the submitted data is arriving at its destination. Finally, to test responsiveness, we’ll view the site on a bunch of different screen sizes and device formats to make sure it’s presenting well across the board. A website might look fine on the particular browser and device that you’re using, but if it becomes stretched, compressed, or non-functional on another user’s device, then it’s not ready for launch.
The goal of all these tests is to simulate the broad array of conditions by which customers or users might access and interact with the website. The idea is to try out every possible website activity or interaction to make sure that your users aren’t going to encounter anything unexpected.
Once we’ve confirmed that the site looks and functions exactly as planned, then we look at the content. All of the text in the website — whether that’s blog posts, product descriptions, “about us” statements, or landing pages — undergoes a thorough proofreading. We use a specialized app to help confirm that the spelling and grammar is correct.
As part of the content testing, we’ll also perform a link audit. We review all of the links in the site to confirm that they’re all functional and correctly with no broken links. You absolutely don’t want users coming to your site on launch day and clicking a link to an important product page or whitepaper only to get a 404 error.
Last but certainly not least, we sometimes have an SEO specialist take a look at the site to ensure that all the in-site ranking factors are properly implemented. A good website development process includes mapping out all of this ahead of time and handing it off to the development team to deploy. So, this check is typically a confirmation that the meta data and other rankings factors have been properly implemented (vs writing meta data and optimizing keywords during the launch process). This can mean things like keyword usage and frequency, header tags, alt tags, meta data and 301 redirects.
A 301 redirect tells Google that a page on a website has been moved from one URL to another. For example, if your old site had a contact page at the URL oldwesbite.com/contact-us/ and the new website has a contact page at newwebsite.com/contact/, then you need to redirect /contact-us/ to /contact/. If you don’t do that, everyone going to your old contact page will get a big 404 error message (page not found). Google will experience the same thing. If you have a lot of these kinds of errors, Google will know instantly that you have a low-quality website with a lot of dead-ends. Google doesn’t want to send users to low-quality websites, so your site’s rankings will drop, making it a lot harder to find.
The reason we’re drawing attention to this specifically is because it is a factor that often gets overlooked by cheap or inexperienced web developers. We’ve seen it many times: a client will opt to have a website built by a friend or family member who has experience with web design but not development, and when the site launches, the business’ Google rankings plummet. Beautiful code is just as important as a beautiful design.
Once the different departments have confirmed that everything is as it should be, the project manager will perform a final review. This final review tends to be fairly high-level, but it’s important to get another pair of eyes on the project as a whole — when you’re working on a single piece, it’s easy to get lost in the weeds and fail to see how small details might affect the bigger picture. The length of the entire pre-launch process depends on the complexity of the website. A very large and complex site will, naturally, take longer to review. The final review generally takes place about a week prior to launch.
Once the project manager has had a chance to review, the entire team will meet to discuss the results of their individual audits. It’s important to ensure that everyone’s audit findings line up, and that no issues were found during an individual audit that might call into question the functionality of another website component. Having everyone in the same room helps to confirm that quality is consistent across every aspect of the website.
By now, you’re probably getting a feel for just how thorough our pre-launch process is. And that’s how it should be. Double and triple-checking every element of the website can be time-consuming, but it’s absolutely worth it in return for confidence that your website reflects the quality of your products and services.
Many website owners have the idea that the second their website is launched, it will be flooded with new visitors. In reality, it can take Google a few days or weeks to index a new site, or for traffic from an existing website to be rerouted to a new domain. If you’re prepared, you can take advantage of this by using a soft-launch approach. This is what we usually recommend.
Basically, a soft launch just means going live with your website prior to making any big announcements about it. In rare cases, an error or issue will arise that’s only visible to us once the site is live. A soft-launch strategy, in which the site goes live quietly and without too much fanfare, can keep visitor traffic to a relative minimum so we can confirm 100 percent that the site is functional — or, if need be, make final tweaks to fix a post-launch issue. Thus, we’ll often recommend that clients hold off on making a new website announcement until the Monday following the launch. This gives us a few days to monitor for any problems, and prevents panic.
Specifically, what’s happening with the registrar, the DNS, the web host, and the CDN? All these things should be decided and agreed upon prior to even setting a launch date. Have you made decisions that are driven by your needs? Is the hosting environment going to be robust enough to create a good user experience? Have you made a choice about a CDN? Are you going to rely on the server alone, or is the site going to live on a distributed network?
At WordZite, we only launch sites on our servers. So we know what the hosting environment will be like and we have a lot of confidence in it. Regardless of where your site is hosted, you want to have the utmost confidence in the hosting environment before you launch. An experienced web expert can make recommendations for web hosting and DNS hosting that will adequately support your website.
Have you gone through those audits and QA milestones and made sure that everything is working? It helps to have a detailed pre-launch checklist to cover every item, no matter how small. Give yourself and your team plenty of time to go through the list and make sure absolutely every aspect of your website is accounted for. If even one item remains unchecked, you’re not ready for launch.
Have you tested all the logins to make sure they work? The last thing you need is to realize you don’t have access to your website at this crucial time. Good web security starts before launch — make sure you know exactly who needs and has access to your website, and make sure everyone who can access your site has been trained on the proper login behaviour.
Usually we launch in the evening because that tends to be when traffic is at its lowest, but if your site targets users in a drastically different timezone, peak traffic times could be in the middle of the day in North America. If you have an existing website, check the analytics and determine the time of day where traffic is generally at a lull. Our goal is always to minimize disruptions to your business, and positioning predicted downtime for when traffic is the slowest helps us achieve that goal.
It’s also important to consider any typical website actions for your users that might be affected by a DNS switch or new host. For example, if your site supports ecommerce, you should plan to temporarily disable orders during launch. If a user were to submit an order or a registration form during the period of time that your site goes down, specific information could go missing without anyone’s knowledge.
And if so, do you have a schedule or plan for that?
We always recommend launching well in advance of any specific event for which you want your website live. For example if you have a big convention or a big marketing push coming up, we don’t recommend trying to launch your site on the day, or even the day before. Give yourself a few days at least in between launch and the start of your campaign, so you can be confident that your site is up and running without issue.
We have had sites in the past that have needed to be reviewed for legal reasons. Finance companies, for example, may have compliance departments that need to give the site a once-over before they are legally allowed to go live. If this is the case, make sure you’re keeping your legal person in the loop about your planned launch date, and make sure they have enough time and notice to review and approve everything before you go live.
We always hope that a website launch will go off without a hitch, but with so many moving parts there’s always a small possibility of an issue. It’s important to be prepared with a clear backup plan in case something does go wrong and we can’t launch your site at the planned time.
The most common backup plan, and the one we would generally recommend, is to make sure you have a functional backup of your old site, and the ability to revert back to the old site until issues with the new site are resolved. This strategy, in combination with a soft launch, will keep everything functioning normally (with your customers none the wiser) until any problems are fixed and your new site is ready to go.
Launching a new website should be an exciting milestone for you and your business. A little planning and forethought will help you keep it exciting, rather than stressful.
To find out what happens next, check out Part 2: Launch, and Part 3: Post-Launch.