Over the last few months at work, I have been involved with more and more clients who are looking to either rebuild their site from scratch or just re-design their existing templates. This conversation is a very difficult one to handle, because most people believe once the design is done, or the managers have signed off on the test site, at 10pm on a Friday night you throw up the new files, and on Monday morning you have one fresh new website to show off.
For my own sanity and for the benefit of all web developers around the world, below is IDH Solutions Step-by-Step Guide on how to Rebuild & Relaunch a Website.
Step 1: The Reason for the Change
One of the first things I ask every client I deal with is why do they want to change the site in the first place? Is it because they feel the look is dated? Maybe they had a static site and now they want to move to a CMS? Or possibly they have decided to take their website seriously.
Either way, if there is no purpose or logic for the change, it is very likely in 6-12months the client will be back to where they started with a website that is not performing or living up to their expectations of what the website should be doing for the business. Clear goals and outcomes need to be set before you even talk to developers and graphic designers.
Step 2: Backing Up & Current Hosting
Once you have set your goals and have consulted with various web professionals, the next step is to be taking backups of everything relating to your website and business. This includes such things as template files, email newsletters, client/user details, and database tables. Whilst every IT professional preaches backing up, you would be surprised how few people do not take this advice and wind up in a particular messy situation.
I have also found in most cases, a client will still have a few months or so left with their current hosting provider. I normally recommend that they do not cancel this service early, but rather leave it up until whenever the hosting expires. Ideally, you would place a robots.txt file in that hosting space to stop the search engines coming past. Once again, this is just due to my paranoia that I recommend this, but it has saved me once or twice when dealing with new hosting.
Step 3: Make Sure the Testing/Dev Environment isn’t Getting Indexed
Once again, a seemingly minor issue to some, but I feel it is a very important one to keep in mind. Some web developers with limited search engine knowledge would not see the benefit, but it is imperative that the test environment has either a robots.txt file or a meta no-cache tag to keep the bots at bay. I had an issue recently the dev environment got within top 30 ranking results for a particular key phrase because the web developers weren’t communicating effectively. In another more amusing situation, another website’s development was outsourced to Asian developers and they had pornographic pictures in place of the clients images temporarily, and those test and dev images were ranking for brand specific terms.
Basically, just make sure proper measures have been taken to stop the test site getting indexed by both parties, and do not take their word on it, check it out to be sure.
Step 4: Making Sure Redirects Have Been Put in Place
There is a fairly good chance that some URLs across a site will change over any period of re-design or rebuilding. The last thing you want your users and the search engines to see once the new website has gone live is a bunch of 404 error pages. This task might take a bit of time, especially if going down the re-build option, but I feel its one of the most important. There is no point having a bunch of great new pages and content and so forth, only for them not to be found by users because of bugs in the navigation, or by search engines who cannot discover the new page, or all the websites out there that are linking and recommending you to others.
So make sure you discuss with the web programmer or designer about implementing the correct forms of redirection for the new pages.
Step 5: Be Prepared for some Downtime
Whilst everyone involved plans to make sure the move goes successfully, it’s unreasonable to expect everything to go smoothly. In fact, I can probably count on my hand the total number of website rebuilds that have gone successfully without any hiccups. Some points to keep in mind:
- Do not make the move during business hours. Don’t laugh - that request happens more often than it should.
- If changing URLs, allow time for DNS propogation.
- Give the site a thorough analysis once live to make sure all internal links are functioning correctly.
Step 6: Monitor & Evaluate the Changes
So assuming everything went smoothly and the changes have been pushed live, make sure you monitor the effectiveness of the changes against the goals and objectives that were set in the beginning. This step isn’t a one time process, 3-6months after it has been done. It is good practice to continually monitor the website and analysing what is working and what is not.
From this analysis, the points and issues raised become the goals and objectives for the next time you go to make changes to the website. This way you can be guaranteed that the website is doing exactly what it needs to do to help your business.
If you are a web developer, please feel free to leave some comments or thoughts on what you do when you are involved in this situation.
