- 9 min. read
William CraigCEO & Co-Founder
- President of WebFX. Bill has over 25 years of experience in the Internet marketing industry specializing in SEO, UX, information architecture, marketing automation and more. William’s background in scientific computing and education from Shippensburg and MIT provided the foundation for MarketingCloudFX and other key research and development projects at WebFX.
Something that is overlooked by a lot of web designers and developers is what is actually involved in the deployment of a website; the process when you’ve finished developing the site, tested to make sure it works, and are ready to push it to a live web server. In a lot of cases, you will be dealing with clients who are getting their website for the first time, and there is nothing for you to really consider apart from the hosting solution to set them up on. As time goes on, you will start getting larger clients that may have existing websites already, or who have more complicated needs.
You may find yourself in a scenario where the outcome could be a very unhappy client with data loss and a whole company’s worth of missing emails and site assets. Here are some basic steps that will ensure that you have covered all the bases for a smooth website deployment.
Step 1: Preparation
There are a few things to consider when you are finalizing a website, and they all depend on what type of deployment you will be completing. The three general scenarios of a website deployment is:
- The client has nothing (i.e. this is their first website)
- The client already has hosting and you will be deploying the site on their server
- The client already has hosting but you will be moving to a new server
The first scenario is the most desired because you are starting with a blank slate. Scenarios 2 and 3 are a bit trickier and involve a more thoughtful deployment process. Once you have worked out what your deployment scenario is, you will be able to better prepare yourself for everything you need to do in order to carry out a smooth transition from the old website to the new one.
If you are dealing with scenario 1, then all you need to do is register their domain name and purchase (or provide) web hosting. Simple and fast deployment. Scenarios 2 and 3 require some information gathering.
You need domain management credentials for the existing web host so that you can manage the DNS records (more on this in a bit). You will find that, in many cases, the client has no idea what these are or where to get them, so you will need to do as much as you can before you approach your client. So let’s gather information on our own.
We can use a tool like whois.domaintools.com to find out some information about the existing domain name. Type in the domain name and on the results page you will see the whois information. For those not familiar with the term, a whois (pronounced as “who is”) is a query of information regarding an Internet resource, such as a domain name.
For illustration purposes, here’s the whois information for Google. Take note of the various contact email addresses, especially the administrative and technical contact. If you know who they are, then you are all set because you will know who to talk to.
If you don’t, just write down their contact details and ask your point-of-contact for the project about them. Next, click on the Registration tab. You will see ICANN Registrar information (the first line), which you should take a note of.
Also, note down the Name Servers listed. The ICANN Registrar is the company that registered the domain name. GoDaddy, Network Solutions, and Namecheap.com are examples of ICANN registrars.
If you have contact with the person listed as the domain’s administration or technical contact, either request the ability to manage the domain name yourself or ask them to modify the DNS records for you when your site is ready to be deployed. If you don’t know the contact for the domain, then you will have to get your client to email or phone them for you. At the very least, if you mention the ICANN Registrar’s name (e.g.
“Hey, you registered your domain name on GoDaddy, does that ring a bell?”), then it might jog their memory and help them recall the information you need.
Step 2: Set Up DNS Records
If you are going to be setting up the website on a new host and you have access to the DNS management administration, then that’s great. Create yourself an A record (the address record that maps a domain name to the IP address of the server) or subdomain record for a live development site such as
dev.domainname.com. Point this subdomain to the IP address of the new server.
If you don’t have DNS access but wish to have full control, I recommend using ZoneEdit.com, which is a free and easy, web-based domain manager. Be warned! Make sure you know what you’re doing with this tool; read their DNS basics and FAQ.
If you don’t want to get this far into the technical side, you need access to their account on their domain name registration service, which will usually have GUIs to help you set up DNS records.
Step 3: Set Up a Live Testing Site
It’s now time to see if the site works on the live server environment. A practice I recommend doing is setting up a subdomain URL prior to officially deploying the site. Something like
dev.domainname.com which will eventually be on
Don’t create a subdomain on the host as this will set up a new directory and make local DNS changes. Set it so that
dev.domainname.com acts as a totally separate website. What you want to do is make
dev.domainname.com a domain alias (also known as a CNAME record).
So, for example, if you’ve set up an A record (the record that maps the IP address of the web server to the domain name) like so:
example.com. A 192.0.2.1
You would set an alias for
dev.example.com as such:
dev.example.com. CNAME example.com.
By doing this, you can set up the website in the same physical location that it will live.
You want to be as accurate as possible here so that you can do your final tests as if the site was truly deployed (which, technically, it is). You can set all folder permissions and other settings, and then run tests and benchmarks to see how the site performs on the server. If you’re hosting on the same server as the old website, the best you can do is upload to a directory named
dev and set up a subdomain DNS record for it while you test.
This allows the existing site to function normally, while still allowing you to test the web server environment. You will have to move this when it is time to deploy.
Step 4: Set Up Email Accounts
Developers deploying a website often overlook email, but it will be a priority to the client. Does your client have mail hosted on their old server?
Are you moving their email? If their email is currently in the same hosting account as the old website, then you will probably be moving mail to the new server. If so, collect all email account addresses and set up the exact same accounts on the new server.
In most cases, you then won’t need to change anything, it will just transition to the new mail server at the same time the website does. If the client has an internal mail server or third-party mail hosting, then you will need to make sure that the MX records (the DNS records that deal with mail) are all correct. If your client has no idea, then a quick test is to ping the mail server, and if it has a different IP address to the website, then it’s most likely hosted on a different server and you need to double-check the MX records and make sure whoever is managing the DNS is notified of what is happening.
MxToolbox will give you all the information you need about the domain; it will list information about a domain name’s MX records. The last thing you want to happen is for the client to lose email.
Step 5: Backup and Go Live
Even if you are hosting on a new server, take a full backup including any databases of the old website, as you never know when you might need something. OK, all set to go live.
If you have full control over DNS records then just change the A record for the domain name so that the IP address is set to the new web server and in about 20 minutes the new website will be live. If anything is not right, just change it back to the old website and do some testing. If you are changing Name Servers to point to the new host, then this can take anywhere up to 72 hours, so make sure you have the time to monitor and fix any errors as they happen on the new website.
Because this is a change in name servers, you can’t just change it back quickly, so be prepared and give yourself enough time. If you are hosting on the same server and removing the old website to make way for the new one, then do it at a time where you can monitor and fix anything live as it happens. Give yourself enough time and try to go live in the business hours of the companies that you will need to contact if anything goes wrong.
All done. If you follow these steps, you should have a 100% smooth deployment of your new website and a happy client to spread the word of your business.
Website Deployment Checklist
- Have access to DNS record management or know the people to contact
- Set up the DNS records and make sure that all the settings are correct
- Set up and test the website on the production server (where it will live)
- Set up email
- Back up the old site (if applicable) and deploy the new one
President of WebFX. Bill has over 25 years of experience in the Internet marketing industry specializing in SEO, UX, information architecture, marketing automation and more. William’s background in scientific computing and education from Shippensburg and MIT provided the foundation for MarketingCloudFX and other key research and development projects at WebFX.
WebFX is a full-service marketing agency with 1000+ client reviews and a 4.9-star rating on Clutch! Find out how our expert team and revenue-accelerating tech can drive results for you! Learn more