I just transitioned my blog in two huge ways: (a) I reassigned it to a different domain name, and (b) I changed the blogging engine I was using, which incidentally used a file organization structure that is incompatible with my new engine.
Furthermore, I decided to import all of my old posts into my new blog rather than leave the old and start anew.
I do not regret any of the changes I've made, because I've laid a groundwork that I will be much happier with in the future. But these changes can wreak havoc on my site's perceived status, since any links to my pages and any stale search engine referals will now result in ugly 404 errors. Sure, we could set up a friendly 404 page that notifies the user of what has happened. However, why don't we eliminate the embarrassment of notifying the user at all and simply redirect them as best as possible?
An example scenario. In my case, I was moving my blog from the root of my site (http://www.nazin.com) to a subdomain (http://blog.nazin.com). Furthermore, I was migrating from Blogger.com, which publishes an HTML page for each post, to WordPress, which loads everything from index.php and uses the post slug in the query string to determine what post to display. For instance, one highly trafficked page was http://www.nazin.com/2004/08/airtunes-concerns-answered.htm, and my new site housed this post under http://blog.nazin.com/index.php/airtunes-concerns-answered/. Once all the old HTML files were removed from the old site, those pages would come up as 404 Page Not Found errors.
The technology behind the solution. To redirect the requests, assign a custom 404 page via the system administration for your site. This will naturally vary from one situation to the next, depending on your server situation (Do you have direct server access? Do you have shared hosting?). Most webservers will comunicate the error and the address in the CGI query string. We will use the original address the user attempted to navigate to as a means to redirect them to the post on the newly-migrated blog. As always, I'll do this with my server-side language of choice: ColdFusion!
Building the ColdFusion 404 Handler. Through the CGI structure, we can take a look at the input we are getting from the webserver for the error and address. Let's create a preliminary 404 handler page. Let's name it 404.cfm.
[cfoutput]#CGI.QUERY_STRING#[/cfoutput]
So if we were to implement this and attempt to browse to the scenario page above, we would get output similar to this:
404;http://www.nazin.com:80/2004/08/airtunes-concerns-answered.htm
To the human eye, it is immediately apparent how to take this output and create a redirect. At this point, it is simply a matter of text manipulation. Perhaps we might write some code like this:
[cfscript]
searchTerm=ListLast(CGI.QUERY_STRING,"/") ;
searchTerm=ListDeleteAt(searchTerm,ListLen(searchTerm,"."),".") ;
newURL="http://blog.nazin.com/index.php/" & searchTerm & "/" ;
[/cfscript]
[cflocation addtoken="no" url="#newURL#"]
Here, we are effectively telling ColdFusion: (1) Grab just the filename of the address (producing "airtunes-concerns-answered.htm"). (2) Delete the filename's extension (producing "airtunes-concerns-answered"). There are UDFs that have been written to perform this function as well, such as ripExt() at cflib.org. Finally, (3) Build the new URL and (4) Redirect the browser to that location.
Try browsing to the deleted page, and the redirection works like a charm! However, there is a serious issue lingering in our solution: What if your post slugs do not always match exactly from the old blog to the new blog, if you imported your old posts like I did?
Addressing mismatched slugs: A different approach. For my scenario page, the previous example worked perfectly. However, during the import process, WordPress did not always create post slugs with the exact same names as the HTML files generated by Blogger.com. Is it still possible to redirect the user?
Sure. Instead of attempting to redirect the user to the new post's address, try redirecting them to the more forgiving search page.
For the next example, let's use another high-traffic page that breaks the previous solution: http://www.nazin.com/2005/06/how-to-install-itunes-on-windows-xp.htm. On the new blog, this page is http://blog.nazin.com/index.php/how-to-install-itunes-on-windows-xp-sp2/; as you can see, the slug is slightly different because Blogger.com truncated it. This is not the only thing that could cause different slugs, however. Perhaps certain characters are treated differently in the different engines, or perhaps a customized slug was created. In any case, relying on the new blog's search engine will address the problem.
The code is actually simpler:
[cfscript]
searchTerm=ListLast(CGI.QUERY_STRING,"/") ;
searchTerm=ListDeleteAt(searchTerm,ListLen(searchTerm,"."),".") ;
searchTerm=Replace(searchTerm,"-","+","ALL") ;
newURL="http://blog.nazin.com/?s=" & searchTerm ;
[/cfscript]
[cflocation addtoken="no" url="#newURL#"]
The only difference with this approach is that it converts all the dashes (-) in the filename to pluses (+), which are used in the URL string to indicate spaces. Thus, the URL generated by this code (http://blog.nazin.com/?s=how+to+install+itunes+on+windows+xp) would be the equivalent of someone searching for "how to install itunes on windows xp" in the search box.
The user will thus be redirected to the new blog, with a link directly to the page desired.
Further enhancements. The final step you could take to really polish the process would be to modify the search results page on your blog to redirect the user to the search results page in the event that only a single record is returned. The code to accomplish this would vary from one engine to the next, but this would achieve the same effect as the previous solution, even when your post slugs differ.
Thanks for reading my solution to this situation. By all means, provide feedback if you know of a better way I could have handled this.
