What Is a 300 Status Code?

The target resource has more than one representation, each with its own more specific identifier, and information about the alternatives is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to one or more of those identifiers.

In other words, the server desires that the user agent engage in reactive negotiation to select the most appropriate representation(s) for its needs¹.

If the server has a preferred choice, the server SHOULD generate a Location header field containing a preferred choice’s URI reference. The user agent MAY use the Location field value for automatic redirection.

For request methods other than HEAD, the server SHOULD generate a payload in the 300 response containing a list of representation metadata and URI reference(s) from which the user or user agent can choose the one most preferred. The user agent MAY make a selection from that list automatically if it understands the provided media type. A specific format for automatic selection is not defined by this specification because HTTP tries to remain orthogonal to the definition of its payloads. In practice, the representation is provided in some easily parsed format believed to be acceptable to the user agent, as determined by shared design or content negotiation, or in some commonly accepted hypertext format.

A 300 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls².

Note: The original proposal for the 300 status code defined the URI header field as providing a list of alternative representations, such that it would be usable for 200, 300, and 406 responses and be transferred in responses to the HEAD method. However, lack of deployment and disagreement over syntax led to both URI and Alternates (a subsequent proposal) being dropped from this specification. It is possible to communicate the list using a set of Link header fields³, each with a relationship of “alternate”, though deployment is a chicken-and-egg problem.

• ¹ Content Negotiation RFC7231 Section 3.4
• ² Calculating Heuristic Freshness RFC7234 Section 4.2.2
• ³ Web Linking RFC5988
• Source: RFC7231 Section 6.4.1

300 CODE REFERENCES

Rails HTTP Status Symbol :multiple_choices

Go HTTP Status Constant http.StatusMultipleChoices

Symfony HTTP Status Constant Response::HTTP_MULTIPLE_CHOICES

Python2 HTTP Status Constant httplib.MULTIPLE_CHOICES

Python3+ HTTP Status Constant http.client.MULTIPLE_CHOICES

Python3.5+ HTTP Status Constant http.HTTPStatus.MULTIPLE_CHOICES

When is a 300 status code used?

A 300 status code is used when there are multiple options for the same resource that the client can choose from.

Without using 300 redirect status codes, users will visit your URL and would likely see content they don’t need. A 300 status code ensures your website visitors end up on the page they want and see content in a format they can access when they visit your URL.

Why are 300 redirects important?

So, what’s the big deal about 300 status codes, and why is it important to use them?

Let’s dive into two major reasons below:

They keep visitors engaged on your site

Using HTTP status code redirects helps you ensure that your website visitors find the information they are searching for.

If a user finds your old URL without a 300 redirect, they’ll be met with info they might not need. As a result, they’ll likely leave your website and seek out another instead.

Using HTTP 300 status codes gives your website visitors the information they need right away.

They increase your search engine rankings and traffic

When visitors leave your site without interacting with anything, it’s called a bounce. And your bounce rate can impact your website’s rankings in the search results.

With a 300 redirect, you can keep visitors on your site by giving them the information they need in the format they want, lowering your bounce rate.

This sends positive signals to Google that your website provides value to users, which helps you earn higher rankings in the search results.

What are the different redirect status codes and what do they mean?

Now that we’ve talked about why HTTP status code redirects are important, let’s explore the different types of codes and what they mean below and how they compare to 300 multiple choices codes!

• 300 multiple choices: 300 multiple choices redirects occur when a requested resource points to multiple destinations for the same requested document. The user can select the choice they desire.
• 301 moved permanently: Like the name suggests, 301 moved permanently redirects occur when one URL has been moved to another location. When a user visits the old URL, they will be automatically redirected to the new URL.
• 302 found: 302 redirects are used when a requested URL is temporarily at a new location.
• 303 see other: A 303 status code is used to direct the user to get the requested resource at another URL.
• 304 not modified: This status code is usually used for caching purposes. It tells the user that the response has not been modified, so they can continue to use the same cached version of the response.
• 305 use proxy: A 305 redirect lets the user know that a resource must be accessed through a proxy server.
• 307 temporary redirect: A 307 redirect is similar to the 302 status code but requires the same requested method to be used on the redirected URL.

Additional resources

• Learn about web development
• Learn about SEO
• Web development services from WebFX
• SEO services from WebFX
• MDN Web Docs
• W3Schools

Return to List of HTTP Status Codes