3XX redirect HTTP website codes are a category of status codes in the Hypertext Transfer Protocol (HTTP) that indicate redirection. When a server responds with a 3XX status code, it informs the client (typically a web browser) that it needs to take additional action to fulfill the request. These status codes play a crucial role in dynamically redirecting web traffic to different URLs.
These status codes are essential for maintaining web functionality and user experience. They allow website administrators to update content, change URLs, or manage traffic distribution across multiple servers. By utilizing the appropriate 3XX redirect codes, website owners can ensure that users and search engines are directed to the correct resources and URLs.
Overall, 3XX redirect HTTP website codes enable efficient website management, URL redirection, and seamless user navigation by signaling the need for additional actions to fulfill requests.
3xx Status Codes Implications for SEO
3xx status codes have significant implications for SEO, influencing how search engines perceive and rank your website.
When a URL is redirected, Google keeps track of the original URL and the new URL (redirect target). One of these URLs becomes the canonical URL, determined by factors such as the type of redirect (temporary or permanent). The other URL becomes an alternate name for the canonical URL. These alternate names are different versions of the same content that users may recognize and trust more. In some cases, these alternate names might appear in search results, especially if a user’s query suggests a preference for the old URL.
For instance, when you migrate to a new domain, it’s common for Google to occasionally display the old URLs in search results, even though the new URLs have been indexed. This behavior is expected, and over time, as users become familiar with the new domain, the prominence of the alternate names will naturally diminish without any action required from you.
The most critical status code for SEO is the 301 (Moved Permanently). By implementing a 301 redirect, search engines understand that the original URL has permanently moved to a new location. This allows them to transfer the SEO value from the old URL to the new one, preserving rankings and traffic.
In order to monitor the correct redirection of your site’s content to new pages, you need to know the meaning of the server’s response codes. This will help you avoid loss of link equity and maintain and improve your page ranking.
Let’s discover what each 3xx Status Codes mean.
Overview of 3xx Status Codes
The 3xx category of HTTP status codes is primarily focused on redirection. These codes inform the client (most often a web browser) that it must take additional action to fulfill the request. This additional action is usually to send a new request to a different URL, provided in the response.
3xx Redirection:
| HTTP-status code | Name | How it works |
|---|---|---|
| 300 | Multiple Choices | Explanation of the code, including that it signifies multiple options for the resource that the client may follow. |
| 301 | Moved Permanently | Explain this indicates the URL of the requested resource has been changed permanently and where the new location is. |
| 302 | Found (Previously “Moved Temporarily”) | Explain this indicates that the URL of the requested resource has been changed temporarily. |
| 303 | See Other | Explaining its use for redirection, typically after form submission. |
| 304 | Not Modified | Discuss how this is used in conditional GET calls to reduce bandwidth. |
| 305 | Use Proxy | Describe how this means that the requested resource can only be accessed through a proxy. |
| 306 | (Unused) | Mention this was used in a previous version of the HTTP specification but is no longer used. |
| 307 | Temporary Redirect | Detail this code’s use for temporarily redirecting traffic. |
| 308 | Permanent Redirect | Discuss the use of this code to permanently redirect traffic. |
3xx status codes play an important role in making the web dynamic and user-friendly. For example, they allow web administrators to move content to new URLs without breaking existing links. When a user or a search engine requests the old URL, a 3xx response guides them to the new location. They are also used to load balance requests across multiple servers, enabling a smoother user experience.
These status codes do not represent an error but rather a change in the path to the requested resource. The resource has not been delivered yet, but it can be obtained by following the instructions provided in the status message. It’s also important to note that some 3xx codes imply that the content has moved permanently (e.g., 301), while others indicate a temporary change (e.g., 302, 307).
Understanding and correctly implementing 3xx HTTP status codes is crucial for any web developer or administrator. Doing so helps ensure seamless user experiences, efficient server operation, and proper indexing of web pages by search engines.
300 Status Code – Multiple Choices
When a server responds with a 300 status code, it indicates a unique scenario where the requested resource is associated with multiple potential endpoints, each characterized by a distinct location. The user, or the user agent, is thus required to discern the preferred choice and consequently redirect their request to that specific location to retrieve the intended resource. Notably, in certain sophisticated systems, an automated selection of the most optimal choice may be implemented, obviating the necessity for manual intervention. This exemplifies the dynamic nature of HTTP communication and the complexity it can occasionally introduce.
A user tries to access the URL "https://example.com/document".
The server realizes that there are multiple versions of "document" available in different languages, such as English, French, and Spanish.
The server returns a 300 Multiple Choices status codes, along with a list of the available versions of "document", each with its unique URL. This might look something like:
"https://example.com/document-en" for the English version
"https://example.com/document-fr" for the French version
"https://example.com/document-es" for the Spanish version
The user, or the user's browser, then selects the appropriate version based on the user's language preference and makes a new request to that URL.
The server responds with a 200 OK status code (assuming everything else is fine) and the requested document in the chosen language.
In some cases, a browser or automated client might be set up to make this choice automatically based on pre-configured criteria, such as the user's language settings.
301 – Moved Permanently
A 301 status code represents a permanent redirection from the initially requested URL to a new one. This implies that all future requests to the original URL should be directed to the new URL provided by the server.
This code is particularly useful when a website’s domain or URL structure changes. By using a 301 redirect, the website owner can ensure that users and search engines update their URL references to the new location, helping maintain the site’s SEO ranking.
The 301 Moved Permanently status code also implies that the method and the body of the original request will not be changed when the redirection is performed. That is, if a POST was made to the original URL, the redirect will also be done using a POST with the same body.
The business previously used "http://old-business.com", but they have rebranded and moved to a new domain: "http://new-business.com".
When a user or a search engine tries to access the old URL "http://old-business.com/about", the server has been configured to respond with a 301 status code and provides the new URL "http://new-business.com/about" in the HTTP response header's 'Location' field.
The user's web browser, or the search engine, recognizes the 301 status code, which means the resource has moved permanently. They will update their records and cache to use the new URL "http://new-business.com/about" for all future requests.
The user's browser is automatically redirected to "http://new-business.com/about", and the correct page loads.
This way, the 301 Moved Permanently status code ensures that traffic and SEO rankings are preserved when the site structure or domain changes. It informs both users' browsers and search engines that the old URL should not be used anymore, and all future requests should be directed to the new URL.
302 – Found (Moved Temporarily)
A 302 status code indicates that the requested resource has been temporarily moved to a new URL, and future requests should still use the original URL. Unlike the 301 status code, which tells the client that the move is permanent, a 302 status code signals a temporary change in location.
This status code is often used when content is moved temporarily, such as during website maintenance or A/B testing. When the client receives a 302 status code, it should follow the redirect for the current request, but continue to use the original URL for any future requests.
Importantly, the HTTP/1.0 specification referred to this status code as “Moved Temporarily,” but it was renamed to “Found” in HTTP/1.1. Despite this change in terminology, its function remains the same. However, note that the request method may be changed to GET from the original method in the case of the 302 status code. For example, if the original request was POST, the redirected request might be changed to GET.
The new URL for the resource is provided in the HTTP response header’s ‘Location’ field. The user’s web browser, or other HTTP client, should automatically handle the redirection to the new URL for the current request.
During a seasonal sale, they decide to replace the standard product page with a special sale page that includes additional discounts and bundles. The sale page is located at "http://store.com/product-sale".
When a customer tries to access the usual URL "http://store.com/product", the server responds with a 302 status code and provides the new URL "http://store.com/product-sale" in the 'Location' field of the HTTP response header.
The customer's browser recognizes the 302 status code and automatically redirects to "http://store.com/product-sale" for this specific request.
Once the sale period is over, the server stops issuing the 302 redirect, and the original URL "http://store.com/product" starts serving the standard product page again. Because the 302 status code indicates a temporary move, browsers and search engines continue to treat "http://store.com/product" as the primary URL throughout this process.
In this example, the 302 Found (Moved Temporarily) status code allows the store to temporarily alter the content they serve without changing the URL that customers and search engines use to access the product page.
303 – See Other
The 303 status code, titled “See Other”, signifies that the requested resource can be found at a different URL and should be retrieved using a GET method. This status code is used to redirect a client after a successful action has been performed, typically a form submission, to prevent the action from being duplicated if a user refreshes or navigates back to the page.
When a 303 status code is issued, the server includes the ‘Location’ field in the HTTP response header to specify the new URL where the client should direct the follow-up GET request. This differs from a 302 status code, where the client is expected to follow the redirection but use the original HTTP method.
In essence, the 303 See Other status code is a way for servers to ensure that a client retrieves the most current version of a resource while avoiding potential issues with form resubmissions or other actions that modify data.
It’s important to note that the 303 See Other status code was introduced in HTTP/1.1. It may not be fully supported by old clients that only implement HTTP/1.0. However, most modern clients and all modern browsers support HTTP/1.1 and understand the 303 See Other status code.
Once the form is filled out, the user hits the "Submit" button, and the browser sends a POST request to the server with the form data.
The server processes the form data successfully and needs to send a response back to the client. However, instead of sending the client back to the form page, the server wants to direct the client to a new "Success" page.
The server responds with a 303 status code and provides the new URL "http://website.com/success" in the 'Location' field of the HTTP response header.
The user's browser recognizes the 303 status code and automatically issues a GET request to "http://website.com/success", and the success page is displayed.
This way, the 303 See Other status code helps prevent the form from being resubmitted if the user hits the refresh button or navigates back using the browser buttons, as the last request the browser made was a GET request to the success page, not the form submission. This is also known as Post/Redirect/Get (PRG) pattern in web development.
304 – Not Modified
A 304 status code, also known as “Not Modified”, is used to indicate that the requested resource has not been altered since it was last requested. This status code is typically used for caching purposes and can significantly improve the performance of web applications by reducing server load and network traffic.
When a client has a cached copy of a resource, it can send a conditional GET request to the server with a ‘If-Modified-Since’ or ‘If-None-Match’ header. The server checks if the resource has changed since the last time specified by the client. If the resource hasn’t changed, the server will respond with a 304 Not Modified status code, and the client will load the resource from its cache instead of downloading it again from the server.
The server does not include a message body with a 304 response, and the resource’s headers in the response should be identical to those sent in the previous 200 OK response (except for some fields that might have different values, such as Date).
It’s important to note that the 304 status code is a feature of HTTP/1.1 and later. Older clients that only support HTTP/1.0 may not understand or correctly handle a 304 status code. However, all modern web browsers and most HTTP clients support HTTP/1.1 or later and should correctly handle a 304 Not Modified status code.
- The user first visits "http://news-website.com" at 9 AM. The server responds with a 200 OK status code, providing the latest news articles and setting the 'Last-Modified' header in the HTTP response to "Tue, 19 Jun 2023 09:00:00 GMT". The user's browser stores or "caches" the page content.
- The user visits "http://news-website.com" again at 10 AM. This time, the user's browser sends a GET request to the server with an 'If-Modified-Since' header set to the value it received earlier: "Tue, 19 Jun 2023 09:00:00 GMT".
- Assuming that no new articles have been published between 9 AM and 10 AM, the server responds with a 304 Not Modified status code. It does not include the page content in the response because it hasn't changed.
- Upon receiving the 304 response, the user's browser loads the cached version of the page, avoiding the need to download the page content again.
Through this mechanism, the 304 Not Modified status code allows browsers to load pages more quickly and reduce network traffic when the content hasn't changed. It's especially beneficial for users with slower internet connections or when dealing with larger, resource-intensive web pages.
305 – Use Proxy
The 305 status code is titled “Use Proxy” and indicates that the requested resource must be accessed through a proxy provided in the ‘Location’ header of the HTTP response. When a client receives this status code, it should repeat the request via the proxy location given.
However, it’s important to note that HTTP/1.1, the predominant version of HTTP in use today, has deprecated the 305 status code due to security concerns. Clients (including most web browsers) may refuse to handle responses with this status code, as doing so could expose the user’s credentials sent to the original host to the proxy. Consequently, the 305 status code is seldom seen or used in practice.
Instead of the 305 status code, other mechanisms are generally used for proxy services, such as PAC files (Proxy Auto-Configuration) or WPAD (Web Proxy Autodiscovery Protocol), both of which allow a client to determine the correct proxy to use for a given URL without the server having to explicitly tell the client to use a specific proxy.
However, for understanding, here's a hypothetical example:
A user tries to access a URL "http://example.com/resource".
The server, for whatever reason, wants the user to access this resource using a proxy. The server responds with a 305 status code and includes the proxy URL "http://proxy.com" in the 'Location' header of the HTTP response.
In an ideal scenario (if clients were to support the 305 status code), the client (or user's browser) would recognize the 305 status code, and then reissue the request for "http://example.com/resource" but via the proxy at "http://proxy.com".
However, as the 305 status code is not supported by most clients and browsers, this flow won't happen in actual scenarios. Instead, the client is likely to show an error or ignore the response.
In modern web practices, when a client needs to access resources via a proxy, it's generally configured at the client side (in client's or browser's network settings) or automatically configured using methods like PAC files or WPAD, and not directed by servers via HTTP responses.
306 – Switch Proxy
The 306 status code, titled “Switch Proxy,” was defined in a previous version of the HTTP specification, HTTP/1.0. It was used to signal the client that it should switch to a different proxy listed in the ‘Location’ header when making future requests.
However, this status code was deprecated in subsequent versions of the HTTP specification and is no longer in use. As of HTTP/1.1, the 306 status code is reserved and should not be used. Clients, including web browsers, do not recognize this status code, and its behavior is undefined.
As a result, you will not encounter this status code in a practical scenario, and it’s not used in modern web development. Similar to the 305 status code, the preferred method for handling proxies involves setting them up at the client level or using protocols like PAC or WPAD to auto-discover them rather than having the server instruct the client to switch proxies.
In theory, when it was still in use, the workflow would have been somewhat similar to this:
- A user tries to access a resource at "http://example.com/resource".
- The server, for some reason, would want the client to switch proxies for future requests. The server would respond with a 306 status code and include the new proxy URL "http://new-proxy.com" in the 'Location' field of the HTTP response header.
- The client (or user's browser), recognizing the 306 status code, would switch to the new proxy specified by the server in the 'Location' field for all future requests.
However, as this status code is now obsolete, this scenario will not occur in any current web environment. Modern web practices involve setting up proxies at the client level or using auto-discovery methods, rather than relying on server responses to switch proxies.
307 – Temporary Redirect
The 307 status code indicates that the requested resource is temporarily located at a different URI, as indicated by the ‘Location’ header in the response. Similar to a 302 status code, a 307 code implies a temporary redirection. The key difference lies in the way the two codes handle HTTP methods.
While a 302 status code might (depending on the client) change the HTTP method from POST to GET, a 307 status code does not allow the HTTP method to change. In other words, if the original request was POST, the redirected request will also be POST.
In the video by Google Search Central, you can see how a Googlebot interacts with HSTS /307s:
This status code is particularly useful in instances where a resource or a page’s location is temporarily changed and the client’s request needs to be repeated exactly (same method and body) at the new location. It is often used in situations where maintaining the original HTTP method is critical to the application’s functionality, such as form submission or API endpoints.
As with the other redirect status codes, the new URI should be provided in the ‘Location’ field of the HTTP response header. Clients, including web browsers, should automatically follow the redirect to the new location for the current request, but continue to use the original URI for future requests.
Note that the 307 status code is a part of HTTP/1.1 and is not defined in the older HTTP/1.0 specification. However, all modern clients and browsers support HTTP/1.1 and should correctly handle a 307 Temporary Redirect status code.
A user visits a page at "http://website.com/resource" to submit a form with some information. The browser sends a POST request to the server with the form data.
Due to some maintenance work or other temporary conditions, the server has moved the form processing script to a different location, say "http://website.com/temp-resource".
The server responds with a 307 Temporary Redirect status code and provides the new URL "http://website.com/temp-resource" in the 'Location' field of the HTTP response header.
The user's browser recognizes the 307 status code and automatically reissues the exact same POST request (with the same form data in the request body) to "http://website.com/temp-resource".
Once the temporary condition is resolved, the server stops issuing the 307 redirect, and the original URL "http://website.com/resource" starts handling the form submissions again.
This way, the 307 Temporary Redirect status code helps in maintaining the exact HTTP method and request body in a redirect situation, which can be crucial in certain scenarios, such as form submissions or RESTful API operations.
308 – Permanent Redirect
The 308 status code, also known as “Permanent Redirect”, is used to indicate that the requested resource has been permanently moved to a new location, and all future references should use a new URI with the same method. This status code is part of the HTTP/1.1 standard, added later in RFC 7538.
The 308 Permanent Redirect is similar to the 301 Moved Permanently status code, but with one crucial difference: while a 301 redirect can allow the HTTP method to change from POST to GET, a 308 status code does not permit this change. If the original request was POST, the redirected request should also be POST.
This status code is beneficial in instances where a resource’s location has been permanently changed, and the client’s request needs to be repeated exactly (same method and body) at the new location. It’s frequently used in situations where preserving the original HTTP method is essential to the application’s functionality, such as form submission or API endpoints.
The new URI should be provided in the ‘Location’ field of the HTTP response header. Clients, including web browsers, should automatically follow the redirect to the new location for the current request and use the new URI for all future requests.
While the 308 status code is a part of HTTP/1.1, keep in mind that not all clients may handle this status code correctly, as it was added later. However, all modern web browsers and HTTP clients should correctly handle a 308 Permanent Redirect status code.
An application sends a POST request to an API endpoint at "http://api.example.com/old-endpoint" with some JSON data in the request body.
The server has permanently moved this endpoint to "http://api.example.com/new-endpoint", so it responds with a 308 Permanent Redirect status code and provides the new URL in the 'Location' field of the HTTP response header.
The application, upon receiving the 308 status code, automatically reissues the exact same POST request (with the same JSON data in the request body) to "http://api.example.com/new-endpoint".
For all future requests, the application will use the new URL "http://api.example.com/new-endpoint", thanks to the 308 Permanent Redirect.
This way, the 308 Permanent Redirect status code helps in maintaining the exact HTTP method and request body when a resource has been permanently moved, which can be crucial for operations like API requests or form submissions.
Troubleshooting 3xx Status Codes
3xx status codes, also known as redirection status codes, generally don’t cause issues as modern web browsers and clients are typically able to handle these redirects automatically. However, certain situations may necessitate troubleshooting. Here are some general guidelines on how to handle and fix issues related to these status codes:
Check the Location Header
Ensure Correct Configuration of Redirects
Beware of Redirect Chains and Loops
Ensure Consistent Use of URL Formats
Consider the Impact on SEO
Test 307 and 308 Status Codes Thoroughly
Update Old Links
If you're still having trouble after following these guidelines, consider seeking help from a web development or SEO professional. They can use specialized tools to analyze HTTP traffic and identify the cause of any issues with 3xx status codes.
Redirect Checker for Detecting 3xx Status Codes
Redirect Checker is a robust online tool that provides an invaluable resource for diagnosing and addressing issues relating to 3xx status codes. With its ability to clearly distinguish between different 3xx status codes, such as 301 (Moved Permanently), 302 (Found), 307 (Temporary Redirect), and 308 (Permanent Redirect), you can gain crucial insights into how your server handles redirection.
Each code carries its own implications for SEO and client behavior, so being aware of the specific status code your server is returning is essential.
Another powerful feature of the Redirect Checker is its capability to identify redirect chains and loops. Redirect chains, where one URL redirects to another, then another, can slow down page load times and negatively impact SEO. Redirect loops, on the other hand, result in an endless cycle of redirections that prevent a page from loading, presenting a significant barrier to user experience.
The Redirect Checker also reveals the URL to which your server is redirecting the client. This feature is particularly useful if you encounter unexpected redirection behavior and need to pinpoint the source.
Finally, by measuring the time your server takes to return a redirect response, the tool provides insights into aspects of performance that directly impact user experience and page loading speeds. This makes Sitechecker Pro’s Redirect Checker a comprehensive solution for diagnosing and resolving 3xx status code issues.
Conclusion
3xx status codes have a significant impact on SEO and how search engines perceive and rank your website. The most critical code for SEO is the 301 (Moved Permanently), which transfers SEO value to the new URL. Temporary redirects like 302 (Found) and 307 (Temporary Redirect) may not transfer SEO value and should be used for temporary changes only. The 303 (See Other) code is primarily used for redirecting after form submission and doesn’t have specific SEO implications, but it improves user experience. The 308 (Permanent Redirect) is similar to 301 and signals a permanent move, positively affecting SEO.
To handle and fix issues related to 3xx status codes, check the ‘Location’ header, ensure correct redirects configuration, avoid redirect chains and loops, and consider the impact on SEO. Tools like Sitechecker Pro’s Redirect Checker can help diagnose and address these issues.
