Don’t Forget Your Redirects!

Share this article

I visited my online banking system today. This is what appeared:

	Not Found

It was a plain-text message — not even HTML. I’ve been using the same URL for at least ten years so was slightly alarmed. Luckily, I have some understanding of this web malarkey and soon located the correct page. How would less technical users cope?

I won’t name the company in question, but it’s one of the largest UK banks and it suffered during the credit crisis (admittedly, that doesn’t reduce the options by much). I suspect their helpline has been inundated by bemused and panicking customers unable to pay their bills. It need not have been that way and a little forward planning could have prevented hundreds of lost support hours.

Change is Inevitable

Good URLs should never change, but…

…it doesn’t matter how much thought or planning went into your page and URL structures — they will eventually change. Technology improvements will have an impact. New features will be implemented. Managers will indulge in flippant power struggles. SEO advisers will berate your keywords. New developers will decide your ideas were flawed. You’ll think of better ways.

The reasons don’t matter: your URLs will change.

Switching Strategy

Some clients presume users will only ever bookmark their home page. In reality, thousands of users may have bookmarked any of your pages. Two of those are the Google and Bing bots which attempt to index everything. If you haven’t budgeted to manage this issue, your site upgrade is not complete! Fortunately, the process is not difficult…

1. Detect your 404s
The first step: determine when a page can’t be found — never rely on your web server’s standard 404 pages.

This should be easy if you’re routing all requests through a single controller. If not, you can redirect to an error-handling page using an Apache .htaccess file or equivalent for your server, e.g

errordocument 404 /error.php

2. Redirect if possible
You now need to extract the page the user is attempting to access and map this to a new URL. How this is achieved will depend on the complexity and size of your site, e.g.

  1. In simple cases, it may be possible to use string replacements or regular expressions, e.g. /oldsite/* maps directly to /newsite/*.
  2. In large sites with radical URL changes, you may require a database table to store a one-to-one mapping of all old to new pages.

For most sites I’d suggest a reasonably easy compromise to detect the most important redirects using key terms in the URL, e.g. in PHP:

// requested URL

// redirects
$redir = array(
	'contact' => '/about/contact-us',
	'mail' => '/about/contact-us',
	'about' => '/about',
	'term', => '/terms-and-conditions',
	'service', => '/services'

// redirect if possible
foreach ($redir as $old => $new) {
	if (strpos($addr, $old) !== false) {
		header('HTTP/1.1 301 Moved Permanently');
		header('Location: ' . $new);

This can also be used to implement URL aliases, e.g. in the example above, a user entering would be directed to the contact information even though an ’email’ page was never created.

3. Log redirection failures
You’re likely to miss some old URLs when the new site goes live. 404 errors will normally be recorded in your server log files, but I recommend you log the requested URL to a separate text file or database for easier inspection. If you want to annoy someone, email all failures directly to them — they’ll soon demand a better redirect system.

4. Improve your error page
If all else fails, send a 404 header and display an easy-to-understand error page. Explain that the requested page is not available and may have moved elsewhere. Be helpful and display a sitemap and/or links to popular content.

I’d have hoped that, by 2013, most sites would put these simple policies into practice. Even a single redirect to a home page is preferable to seeing “Not Found”. I guess my bank never received the memo? Or perhaps they finally ran out of money? Excuse me while I withdraw my life savings…

Craig BucklerCraig Buckler
View Author

Craig is a freelance UK web consultant who built his first page for IE2.0 in 1995. Since that time he's been advocating standards, accessibility, and best-practice HTML5 techniques. He's created enterprise specifications, websites and online applications for companies and organisations including the UK Parliament, the European Parliament, the Department of Energy & Climate Change, Microsoft, and more. He's written more than 1,000 articles for SitePoint and you can find him @craigbuckler.

Share this article
Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week
Loading form