Where Did Those Pages Go? Managed Redirects in the Context of Decoupled CMS Create a Fix for Missing Content
The redesign of a website creates a lot of small but important operational issues. One that often gets overlooked is what will happen when the old URLs for your site stop working. In most cases, as much traffic, if not more, comes in through pages other than your site’s homepage. The URLs of these pages inside the site often change when a new version of the site is launched, particularly when the relaunch involves a technology or platform change as well. When these URLs change the users who had bookmarked these pages or are coming to your site through outdated search indexes will first get to enjoy your brand new, well designed, 404 error page. Obviously, this is far from optimal.
Additionally, almost every site TBG (The Berndt Group) has built has had the need for “vanity URLs” for various pages inside the site. While 'http://www.yoursite.com/visit/events/2010/11/your-important-event.aspx' may work pretty well for the real the event page, it is often necessary to shorten that for marketing uses. The plethora of URL shortening services like bit.ly have made natural short addresses less important for sharing around the web, short and easy to remember URLs are still very important for many offline marketing activities.
The answer to both of these problems has traditionally been to setup virtual directories or redirections through the software serving the website (typically IIS or Apache). While this solution works, it always requires coordination between the team that is running the website’s content, and the team responsible for configuring and administering the server that the site lives on—spanning the sometimes strained I.T. and marketing divide. In our experience, these two teams are often separate and coordinating efforts between them for something such as this is often challenging.
TBG recently developed a technique, using a combination of one-time web server settings and content management system generated content that allows the team managing the website to create and manage these redirects just as they would any other content in CrownPeak’s Saas CMS.
Web Server Configuration
The first step in the process is configuring the web server itself to serve the pages using the old site’s file extension as a dynamic format of our choosing.
In our case, the old site used flat .html files for all of its content, meaning that the URL to the old site’s pages were like 'http://www.clientsite.com/section/subsection/index.html'. HTML files don’t have the ability to redirect users, so we need to configure the web server to process .html files with a server side scripting language.
In a recent case, we decided to use classic ASP for our redirects because it would keep them from interfering with the rest of the site, which was an ASP.NET application. This meant that we would need to tell IIS, the windows webserver application, to process .html files using the asp.dll. Our server was running IIS 6, so these instructions may vary for newer versions.
We needed to assign the ASP DLL to process .html files. We did this by editing the website properties for our site in the IIS management console, and then clicking the “Configuration” button on the “Home Directory” tab. This opened a list of all file extensions that will be processed by the server. We edited the entry for .asp files to get the file path of the ASP.DLL file, as this may vary from machine to machine. We then created an entry for the .html file extension and entered the ASP.DLL file’s path into the “Executable” field.
We then restarted IIS to make sure the setting took effect. A simple test is to create a sample classic ASP file that outputs “Hello World” and giving it the .asp file extension. If this works, you’re ready to go with the next step.
Redirects as Content
We were building this client’s site using CrownPeak’s Hosted CMS. CrownPeak’s product is a flexible decoupled CMS system, meaning that the CMS system outputs its content as files that get transferred to a stand-alone web server, which actually serves the content to users.
One of the great features of CrownPeak, which never gets talked about in sales demos, is the complete programmatic control of the paths and names of the files that get published as part of this process. It is this ability, however, that allows us to easily implement this redirect solution.
We created a template inside the CMS system for these redirects. This template contains fields for determining where the redirect will take the user and also a set of fields for determining where on the server the redirect will be published. Our template has two fields for this, one for the folder path, and one for the filename. If no filename is specified, the file gets named “default.asp”; otherwise the file is given the name specified. This allows users to specify paths only, and create the vanity URLs that they need. The file itself simply contains the ASP “Response.Redirect()” function, specifying the location of the content that the user should be sent to. As an added aide for creating these content pieces, we also included the ability for users to preview the content while working in the CMS system, to verify that the redirect will do what they need.
The result of this new type of content is that non-technical staff can easily create a custom web address that redirects to content in the new site structure. By looking at the old site’s web analytics, it is possible to get a sense of what popular pages may have been bookmarked by users. By using Google’s “links to” function, it is possible to get a nearly definitive list of inbound links from other websites. Then, it is possible for site managers to use these CMS-managed redirects to quickly and easily point the most important or strategic pages to the new, most similar pages.
A similar solution can also be created in any number of other decoupled CMS products, but in some cases this may require slightly more complex engineering using the specific CMS’s API to provide the needed access to the file name and path settings.
When the published file is accessed on the web server, the file behaves like an ASP file, because we told IIS to treat it as such, and redirects the user to the page specified. If published out to the same location on the server as a piece of content on the old site, the redirect is seamless, and instead of becoming acquainted with an error message, the user gets to see the content they were looking for on the shiny new redesigned site.
About the Author
Leave A Reply