Technically speaking, a redirect is a HTTP response code, beginning with a 3 (3xx), that is sent from a server indicating the need for a browser to display a different page than was requested.
Practically speaking, a redirect is intended as a way to send both users and search engines to a different URL from the one they originally requested. A URL redirect is a technique created to make a web page available under more than one URL, or to control where users arrive if they attempt to visit a nonexistent or incorrect URL. When you set up a redirect in cPanel, Plesk, IIS, or whatever your method of choice, a user arriving at the server for the requested URL will be told to go elsewhere. Depending on the type of redirect, you can also control whether that redirect is seen as permanent or temporary.
Most commonly, URL redirection is used to shorten site URLS, redirect users to the secure https:// version of a site, or to allow multiple domain names to point to a single website. Redirects are usually configured on the server where that domain’s website is hosted, but some limited redirect functionality can also often be configured at the registrar.
There are currently eight types of redirects, or more accurately eight 3xx HTTP response codes, with some being commonly used and some rarely used or even discontinued. To make these details more relevant, we will categorize list these codes based on how common they are today.
Of the eight active 3xx status codes, the most commonly used two are 301 and 302 redirects. For assistance with configuring a redirect of one of these two types, the following companion articles provide instructions specific to several different control panels and hosting environments. If these instructions do not meet your specific needs, please reach out to customer support and we will be happy to assist you further:
- Adding a URL Redirect with cPanel
- Adding a URL Redirect with Plesk (coming soon)
- Adding a URL Redirect with Apache (coming soon)
- Adding a URL Redirect with IIS (coming soon)
If you need assistance creating any other type of redirect, or any HTTP response code for that matter, please feel free to reach out to our support department for further assistance.
Commonly Used 3xx Response Codes
301 (Moved Permanently)
The HTTP response status code 301 Moved Permanently is used for permanent URL redirection. 301 redirects send site visitors and search engines to a different URL than the one they originally typed into their browser, selected from a search engine results page, or that was associated with a link or bookmark you followed. If your browser allows caching it will remember the redirect and will go directly to the new URL in the future.
Note: It is important to know that a user agent is capable of changing the request method from POST to GET for the redirected request. This is a technical possibility that should never be allowed as it could either lose, or even potentially expose the data payload from the original POST request. A new 308 (Permanent Redirect) method that disallows this change has been proposed, and is included in our list below.
The 302 Redirect was formerly known as “Moved Temporarily” to be used in conjunction with the 301 status “Moved Permanently.”
The functionality of a 302 “Temporary” redirect is for the most part Identical to the 301 redirect. Meaning a URL is typed in, or a link is followed, and you are redirected to a new URL. The difference with a 302 is that it tells browsers that allow caching that the original URL has been found and the redirection is only temporary. In theory the browser will attempt to go to the URL again if it is reentered. Temporary redirects tell browsers not to cache the redirect.
Note: It is important to know that a user agent is capable of changing the request method from POST to GET for the redirected request. This is a technical possibility that should never be allowed as it could either lose, or even potentially expose the data payload from the original POST request. Unfortunately a number of web browsers ignored this specification, and implemented this code in the manner just described. For this reason, HTTP/1.1 renamed the 302 status and added two new status codes to explicitly define the intended behaviors, and remove this ambiguity:
- A new 303 (See other) method that mandates the redirect execute over GET, whether it starts as GET or POST
- A new 307 (Temporary Redirect) method that maintains the original request method, keeping GET requests as GET, and POST requests as POST
304 (Not Modified)
This is an interesting redirect as it directs your browser to re-use the existing cached content previously retrieved from the requested URL, instead of redirecting you to a different URL. Because of this, some people argue that this shouldn’t count as a redirect, because the URL and request method do not change. But if you consider that the request is being redirected back to your browser’s cache, it makes sense. This is a handy redirect, if implemented properly, to reduce bandwidth requirements and decrease page load time. An example of where this could be used would be an automatically refreshing set of metrics or products for sale, where the data displayed has to be calculated or generated upon request. If there is a system in place to check for data changes, not only does the back-end system not have to regenerate that content, but neither does the browser need to re-download what it already has.
Newer 3xx Response Codes
For many years, 301 and 302 redirects were the only option available for redirecting from one page specifically to another. Unfortunately, these methods were only practical to use with GET requests, since redirecting POST to another URL with either a 301 or a 302 would change the method to GET, potentially losing or exposing the data payload. Thankfully, the 307 and 308 redirects have been proposed and adopted by most major browsers to resolve this issue.
Note: These are still fairly recent additions to the RFC and therefore older browsers may not support these status codes, or may not support them fully.
307 (Temporary Redirect)
One of two Pseudo replacements for 302 (Found), this redirect maintains the original request method (GET or POST) through to the redirect URL.
Like the HTTP response status code 302 (Found), the 307 Temporary Redirect is used for temporary URL redirection. 307 redirects send site visitors and search engines to the new URL, but your browser is requested not to cache the redirection and to check each time that the old URL is requested in case the redirect is removed or changes. Unlike the 302 redirect, whatever method that was used for the initial request (GET or POST) cannot be changed by the user agent, and will be maintained through the redirect. This means that form submissions and other POST requests can continue on safely as POST through the redirection.
A functional example of this type of redirect would be if you are performing a site redesign and needed to redirect visitors temporarily. If a visitor was in the middle of submitting a form via POST when you initiated the 307 redirect, their submission would continue on as POST and you would not need to worry about their sensitive data being lost, or potentially compromised (depending on server configuration).
308 (Permanent Redirect)
Pseudo replacement for 301 (Moved Permanently), this redirect maintains the original request method (GET or POST) through to the redirect URL.
Like the HTTP response status code 301 (Moved Permanently), the 308 Permanent Redirect is used for permanent URL redirection. 308 redirects send site visitors and search engines to the new URL, and assuming your browser allows caching, it will remember the redirect and will go directly to the new URL in the future. Unlike the 301 redirect, whatever method that was used for the initial request (GET or POST) cannot be changed by the user agent, and will be maintained through the redirect. This means that form submissions and other POST requests can continue on safely as POST through the redirection.
A practical use case for this type of redirect is if you need to replace a script that receives from a submission form, but you want to allow any straggling submissions that may occur from still-open visitor’s browsers to make it through. Another common use would be to pass on form data to a notification script in case “normal” form submission failed for an unknown reason.
Rarely Used 3xx Response Codes
300 (Multiple Choices)
The 300 (Multiple Choices) redirect method indicates that more than one possible resource are available from the requested URL, and the client should be prompted with the option to choose. For example, if a website offers multiple language options, it may be appropriate to redirect to a list of choices on the visitor’s first visit and store their selection as a cookie before then redirecting them to their desired content. Another option could be to offer multiple media types when an image, video, or audio selection is made and there is no predefined preference.
Understandably, since there is no predefined standard way of actually prompting and allowing a visitor to choose one of these responses, this response code is not widely used. Most sites would rather assume one “default” option, to present content to their visitors faster, and for possible SEO purposes of course, and then allow selection of alternatives if one is desired.
303 (See Other)
One of two Pseudo replacements for 302 (Found), this redirect explicitly changes the request method to GET upon completing the redirect.
This redirect is intended to be a type of protection from accidentally misusing a page that holds one-time only data. It’s most common use is to redirect you away from the URL you were at previously in a way that prevents refreshing from re-submitting a form, or re-triggering an action that was performed before the redirect. A good example would be a web form requesting credit card information to process an order. After submitting your credit card number, you wouldn’t want to be able to hit refresh and accidentally submit it again, causing duplicate charges, right? So the response from submitting that credit card information could include a 303 redirect to a “Thank you” page, where refreshing the page would presumably do no harm.
305 (Use Proxy)
This status code is intended to indicate that there is a restriction on the requested URL that requires the use of a proxy, the address for which is included in the response. Technically speaking, the URL provided in the response doesn’t actually have to be a proxy, but this was the intended use of this response header. An example of this in practice would be if you had a load balanced system, and instead of accessing the “front end”, someone attempted to access one of the workers in the “back end”. This response code could then be used to indicate “I know what you’re looking for, but you should be looking for it here”.
Note: Since its introduction, there have been several concerns as to the practical use of this redirect, and of how to implement it safely. For this reason, it is often considered insecure or potentially malicious, and thus generally not recommended.
Additional Note: There used to be an additional status code 306 (Switch Proxy) that was intended to be used in conjunction with the 305, but like the 305 the 306 code was met with security concerns and ultimately dropped from the RFC completely. The 306 code remains unused and reserved for potential future use, but should not be used for any purpose at this time.