Handling Errors and Duplication, 301 Redirection - Designed to be Found, Part 10

Written by Adam Stafford - 18 Aug 2009

301 redirection

That all things change is a universal truth. Because of this, plus the canonicalization issues, or the need to track some URLs with query strings, using server-side redirection to seamlessly move a visitor from a deprecated URL to the preferred version is a guaranteed necessity.

Where redirection is needed, one must correctly understand the difference between a temporary redirect (server code 302 response) and a permanent redirect (server response 301).

The temporary redirect (302) says to use the temporary URL, the redirect, for now, but to continue to come to the old URL in future. This is the default version of redirect that IIS-based servers tend to give.

The permanent redirect (301) is the one most favoured in SEO terms. It says to forget the old, deprecated URL and to instead index, bookmark or update to the new URL. This is the version you must use for canonicalization and duplicate content issues, because this is the only one that says not to index the deprecated version.

In cases where server-side redirection proves problematic for whatever reason, a META REFRESH is treated by search engines exactly as though it were a redirect.  A refresh with a time of 0-3 seconds is treated as if it were a 301 permanent redirect.  A longer delay on the refresh is treated as a temporary 302 redirect.


<meta http-equiv="refresh" content="0">


Checking that the correct server redirects are in place can be achieved with a variety of tools freely available online. I personally favour ‘Sam Spade’ from www.samspade.org but any other tool that can retrieve HTTP header information will suffice.

Look out for part 11 next week…