Correctly Redirecting on the Web

There is a lot of confusion and misconceptions about "redirects" on the web. Many assume there are only two methods of redirects: a 301 and a 302 - but there are in fact 7 different ways to redirect from the server side, and of course the notorious client-side redirect methods such as JavaScript.

There are 3 main reasons to redirect to a new page:

• A page has moved, you need a permanent redirect
• A form has been submitted, you need to proceed to the next page
• Interaction on the client-side (after the page is loaded) requires you to load another page

The last item on that list (using JavaScript) is NOT redirection, and using it immediately on page load as a means of redirection is improper and should be avoided, especially in the case of SEO which makes the action look like black-hat SEO tactics.

Apache (most Linux servers) and IIS (Microsoft Windows server) will both assume a 302 redirect if you specify a location but not a status code along with it. This has created the immensely misused 302 status code, and forced the web standards consortium to create two new status codes to rectify the misuse of server-side redirects.

GET and POST

For those unaware of the different methods of loading a web-page, the two most common ways of asking for a page off a server are a GET and a POST request. A "GET" request normally means you want a normal page, and you're not telling the server anything special. A "POST" request normally means you are submitting information for the server to process.

The importance here is when you are redirecting, do you maintain a POST request or change it to a GET request?

Permanent Redirects

You've moved a page or an entire site. Without question, you are looking for the 301 status code. The correct name for this is a "301 Moved Permanently", often incorrectly titled "301 Found".

When using a 301 Redirect, the correct thing for the browser to do is to maintain the Request-URI (GET or POST) - however many browsers incorrectly turn this into a GET request. Proper use of status codes will help rectify this.

Form Redirects

When you submit a form on a page your server will then process it and return a new page to redirect to. A redirect here is important because if you deliver the thank-you page without redirecting, pressing back or refresh will force the form to be resubmitted. So it's important that your redirect should be executed with a GET request (so not to post the form information twice). This may be the cause of many browsers incorrectly using a GET request when performing a 301 redirect.

The correct way to redirect here is to use a 303 redirect. A "303 See Other" redirect instructs the browser to switch to a GET request and continue processing. It does not imply if the redirect is permanent or temporary, but the browser should NEVER cache a 303 response. This is important for proper script operation.

Temporary Redirects

So you just happen to actually want a temporary redirect. Using a 302 is ambiguous thanks to it's massive misuse, and you can't rely on search engines to react to it in the way you want. Instead the correct manner is to use a 307 redirect. The "307 Temporary Redirect" instructs browsers to maintain the Request-URI and cache the response IF the server says so. This allows you to offer temporary POST-friendly redirects.

Correct Status Code Names

When you send a status code back to the browser you also send a title along with it. These titles have been greatly mixed up, especially with different servers giving their own names (Largely IIS) but the correct names are:

• 301 - Moved Permanently
• 302 - Found
• 303 - See Other
• 307 - Temporary Redirect

The other 3xx codes that exist but are rarely if ever used include:

• 300 - Multiple Choices
• 304 - Not Modified
• 305 - Use Proxy

The 306 status code is no longer used and is now reserved.

Client-Side (JavaScript) Redirects

There is an odd misconception that a JavaScript or "Meta" redirect is a 302 redirect. This is not true, any "300" redirect code is sent from the server, thus called a server-side redirect. A JavaScript redirect originates from a script run in the browser itself, this is called a client-side redirect. A browser with JavaScript disabled will not execute the redirect. This form of redirect is NOT SEO-friendly and can be considered foul-play as far as a search engine is concerned and can lead to penalties in search engine results.

If you execute a JavaScript redirect as soon as the page is loaded, you're doing something wrong. Under no condition should this ever legitimately happen. The ability to load a new page using JavaScript should be reserved for scripted operations initiated by user action.