Creating your first Web site is easy — get the hosting, create the site, test it… and when you’re ready, start promoting the site. (Hah! Easy…)
But once you have a Web site, how do you create a new one? People are (hopefully) visiting your current site — browsing pages, clicking on services, sending emails. You need the current site to be fully functional for regular visitors while you are working on the new one.
Problem is, since your home page is defined by the Web server as a particular file name (usually index.html or default.htm), you can’t just replace it, or your whole site will break. What to do? There are several common ways to solve this, but one way is better than the others.
Bad Option 1: Intermingling
I’ve seen developers create the new site in the midst of the old one, using different file names to keep things unique. The new Home Page becomes index-new.html and the new subpages are given unique names. New images and scripts are jumbled in with old ones. Once the new pages are tested, the old Home Page file is renamed to index-old.html (or just deleted) and the new Home Page file is renamed index.html. Since the new site doesn’t link to any of the old site pages, they are orphaned and can be deleted, or converted to redirects to the new pages, or (sadly, most often) just left there.
For very small sites, this can work, but it’s messy and can be disastrous.
- During and after development of the new site, it is not immediately clear which pages are associated with which site.
- Since at least one of the filenames must change (the Home Page), that means that all links to that page must also change… right at the moment of launching the site. Most HTML tools help manage the change (for example, Dreamweaver fixes the links automatically), but it’s still an extra task.
- If the old site pages are deleted from the server after launch, there’s a risk of accidentally deleting the wrong ones, thus breaking links. If these files are left, any bookmarks to the old site will still work… to the old site. (I’ve seen this!)
Bad Option 2: Subfoldering
To avoid some of the problems above, people sometimes create a new subfolder inside the current site (e.g. /newsite/) and put all the new site files there. Then, when it’s time to launch, they collect all the old site files into an archive folder (/oldsite/ — or just delete them), then move all the new site files out of the subfolder into the site root. Voila, c’est vrais?
Non. It’s better, but now all the files have to move. All your links might have to change, or links on certain scripted pages might have to change. Even with a program like Dreamweaver helping, I’ve launched sites like this and then spent the next few days (weeks!) finding old links that still include the /newsite/ folder.
The Better Way: Subdomains
Many Web hosts allow you to set up a “subdomain,” which uses your base domain name and adds a prefix instead of the www. It acts like a separate domain name, but you don’t have to register another name. You just need the Web server configured correctly, and most hosting control panels make it easy to do now.
So you set up a subdomain like test.yoursitename.com, then do all the development there. You can browse to it, test the links, run scripts, access databases, and so on. Once you’re happy, you still have to move all the files, but all relative links should not require any changes.
That’s the way I do it.
