HTTP 301

On the World Wide Web, HTTP 301 is the HTTP response status code for 301 Moved Permanently. It is used for permanent redirecting, meaning that links or records returning this response should be updated. The new URL should be provided in the Location field, included with the response. The 301 redirect is considered a best practice for upgrading users from HTTP to HTTPS.

RFC 2616 states that:
 * If a client has link-editing capabilities, it should update all references to the Request URL.
 * The response is cacheable unless indicated otherwise.
 * Unless the request method was HEAD, the entity should contain a small hypertext note with a hyperlink to the new URL(s).
 * If the 301 status code is received in response to a request of any type other than GET or HEAD, the client must ask the user before redirecting.

Examples
Client request: Server response:

Using an .htaccess file
To fix problems with non-existing files or directories using a distributed .htaccess file:

Here is an example using a .htaccess file to redirect a non-secure URL to a secure address without the leading "www":

Static HTML
A custom directory redirect, using an index.html file:

Using programming languages
Here is an example using Perl CGI.pm: Here is an example using a PHP redirect:

Here is one way to redirect using Express.js:

Caching server
Equivalently simple for an nginx configuration:

Search engines
Both Bing and Google recommend using a 301 redirect to change the URL of a page as it is shown in search engine results, providing that URL will permanently change and is not due to be changed again any time soon.

Technical details
The HTTP 301 status code has several technical nuances that developers should be aware of when implementing and managing redirections:

Browser handling

 * Caching Behavior: Many web browsers cache 301 redirects. This means that once a user's browser encounters a 301 redirect, subsequent requests to the original URL will be automatically directed to the new URL without contacting the server.
 * Updating Bookmarks: Browsers may update bookmarks to reflect the new URL after encountering a 301 redirect.

Server side

 * Apache: Apache has mod_alias and mod_rewrite to handle 301 redirects. Using both often results in unpredictable behavior because modules do not respect other module rules.

Comparison with other status codes

 * 302 Found: Unlike a 301, a 302 status code indicates a temporary redirect. Search engines might not pass the SEO value to the new URL.
 * 307 Temporary Redirect: Like 302, but guarantees that the method and the body will not be changed when the redirected request is made.
 * 303 See Other: Used when the result of a POST or another non-idempotent request method is a resource that should be retrieved using a GET.

Location header

 * Mandatory Inclusion: The new URL should always be provided in the "Location" field when a 301 redirect is sent. Omitting the Location header will confuse browsers and may result in unexpected behavior.
 * Absolute URL Usage: While relative URLs might be accepted by some browsers, using absolute URLs in the Location header is the standard and ensures consistent behavior across all user agents.

Impact on SEO

 * Link Equity Transfer: Search engines typically transfer a majority of the link equity (or “link juice”) from the source URL to the target URL for 301 redirects.
 * Indexing Delays: There might be a lag before search engines recognize the redirect and update their indexes accordingly.

Common pitfalls

 * Multiple Redirects: Using multiple 301 redirects in succession (A to B, then B to C) can lead to increased page load times and may dilute SEO value.
 * Mixed Content Issues: When redirecting from HTTP to HTTPS, ensure that all resources (images, scripts, stylesheets) on the page are also loaded over HTTPS to prevent mixed content warnings.