As already mentioned a content management system like ours allows non-technical website content creators to add content directly into a site without coding. This process is pretty straightforward, especially when dealing with text. But unlike off-line content, web content commonly consists of images, links and other documents such as PDFs, Word, and Excel files. Under the hood, these elements require file references that tell a web page where the picture, file or link lives. When a site is in development, or when content is being entered from an existing website, these kinds of elements often need to have their file names and/or locations adjusted for the new site. If such details are overlooked, when the site goes live, broken images and broken links can occur. This actually happens quite often, especially in redesigns. That's because content entered from an original site, which contain images and file links, will still function--while the existing site is still live. But once the new site takes its place, the images and links that had been working during development and pre-launch testing no longer work because they're no longer in the same place.

Suddenly, a site launch celebration turns to a frantic effort of fixing broken images and links before too many people see them. For example, there are hundreds of pages on the new Newfangled site and I missed a case just like this. On the whitescreening page I had originally copied the content from the old page including an image of the whitescreen screen. When the site went live and the old site was archived, including that particular image, the image stopped displaying. I actually consider this one oversight--among so many pages and images--a real content entry success. Such instances are common and mistakes happen even when great diligence is applied. So, even after checking over a site thoroughly before launch, it's always necessary to check it again after launch.

This particular problem is less common when building a new site, however it can still happen. This usually results from images or links being referred to by using what is technically called an absolute URL rather than a relative URL. Don't be confused by the jargon. A URL (Uniform Resource Location) is simply the place where a file lives. For example, website images are often placed in a website "images" folder. So the URL of a particular jpeg might be "www.newfangled.com/images/myjpeg.jpeg." An absolute URL just means that under the hood, the reference to this file uses the complete URL including the website's domain (www.newfangled.com for this example). A relative URL, on the other hand, refers to a file or link without using the domain part--which typically is the right way to do it. But a problem can occur if an image or link uses an absolute URL during the development of the site. That's because the development site's URL has to be different from the final live site's URL--something like siteindevelopmet.site.com. If this complete URL is used to refer to images or links, the reverse problem occurs. When the site goes live and the images and pages now live under the final website address, the old development URL doesn't work, since the images and links are not there anymore. The new site will contain broken elements. Again, care when doing content entry and checking the site after launch are important to successful "go live" experiences.   next >