A redirect is the process of forwarding a client from the requested URL to another URL. Redirects are normally used because the document has moved temporarily or permanently to another URL. Redirects can be an effective tool to ensure usability and SEO.
In this guide we discuss which kinds of redirects exist, how they are implemented and how to use them properly.
A redirect is an automatic forward from the requested URL to a destination URL. The redirect is complete, when the client is forwarded to the destination URL of the redirect.
Redirects can be triggered on server side as well as on the client side:
Server side redirects
Client side redirects
A server side redirect happens, when the HTTP request to a web server is answered with a server status code, which indicates the requested document has moved to another URL. The client will then request the destination URL and the user gets forwarded.
There are several kinds of HTTP status codes (RFC 7231) that indicate a redirect of a certain type. There are no good or bad redirect status codes. Each kind of redirect has a purpose and can be applied with positive effects.
If a search engine discovers a redirect, it has to decide how to handle it. From a SEO perspective, there is one central question: Should link juice or ranking signals be passed via the redirect?
To make this decision, search engines look at the status code used for the redirect and its technical details.
The following table shows the 30x status codes and their technical details relevant in this context.
|HTTP Status Code||HTTP Version||Temporary / Permanent||Cacheable*||Request method subsequent request|
GET / POST
|302||HTTP/1.0||Temporary||not by default||
GET / POST
|307||HTTP/1.1||Temporary||not by default||
GET / POST
may not change
GET / POST
may not change
*The cache-default for status code 301, 302, 307 and 308 can be overridden by the cacheability of the request method or by explicit cache controls. More information about this topic can be found in RFC 7234, Section 4.2.2.
Search engines might base their behaviour on the following questions:
The redirect status code can help answer these questions.
An important redirect from a SEO perspective is the 301 redirect "Moved Permanently". Google has confirmed in a video, the 301 redirect usually passes link juice with a slight loss and is the first choice for SEO tasks when the site structure changes. Other search engines might follow a different philosophy.
A 301 redirect is cacheable by default, if not indicated otherwise. The cache-default can be overridden by the cacheability of the request method or by explicit cache controls. More information about this topic can be found in RFC 7234, Section 4.2.2.
The request method may change for the subsequent request. Current browser technology usually uses the GET method for the request to the destination URL, even if the initial request was sent with the POST method.
The 301 redirect is the right choice to prevent dead ends and consolidate incoming links. Link juice and traffic can be preserved. Normally 301 redirects are used if you want search engines to apply all SEO value to the destination URL after the destination of a document has changed permanently.
Use cases for 301 redirects
The 301 redirect is the wrong choice for for all occasions in which cacheability can lead to unexpected negative behaviour.
The 301 is also wrong, if you want to apply a redirect that is not supposed to be of permanent nature.
The 302 status code indicates that the requested document has temporarily moved to another URL.
A 302 redirect is not cacheable by default. The cache-default can be overridden by the cacheability of the request method or by explicit cache controls. More information about this topic can be found in RFC 7234, Section 4.2.2.
The 302 redirect was first defined in HTTP/1.0 (RFC 1945) with the description phrase "Moved Temporarily". While it was specified, that the original request method should be used for the destination URL as well, browsers widely treated the 302 contradictory to the standard, always using a GET request for the destination URL.
In HTTP/1.1 (RFC 2616), the 302 was renamed to "Found" and the status codes 303 and 307 were added to offer a distinction between a temporary redirect that allows changing the request method and a temporary redirect that does not allow to change the request method.
The 302 status code is still by far the most commonly used temporary redirect status and it provides backwards compatibility for clients that do not support HTTP/1.1.
Because of the temporary nature of a 302 redirect, the behaviour can always change. This is why search engines usually don't pass PageRank or SEO value to the destination URL. This is also the reason why the 302 redirect is often regarded as a "bad" redirect by SEOs, which is a misconception. There are occasions in which the specific characteristics of the 302 redirect can be used with positive effects for SEO.
302 redirects are the right choice if you want to apply a temporary redirect that does not affect your sites presence in the search results. A temporary redirect is supposed to be a redirect with a limited life span. 302 redirects can also be used if you want to apply redirects that are not cacheable.
Use cases for 302 redirects
The 302 status code should not be used if you want to pass SEO value to a destination URL.
302 redirects should also not be used if the request method of the original request must be used for the request on the destination URL.
The status code 303 was specified in HTTP/1.1 and indicates a temporary redirect. The request method for the destination URL is always GET.
The 303 redirect is never cacheable.
Most clients treat the 303 status code exactly like they treat the 302 status code.
The 303 redirect can be used in a similar fashion to the 302 redirect. Due to being not cacheable under any circumstances, we suggest using the 303 over 302, when temporary redirects appear for undisclosed periods of time or fluctuating redirect destination targets. However, the request to the destination URL will always be requested using the GET method.
Use cases for 303 redirects
The 303 redirect can not be used, if the POST method must be used for the subsequent request. It is also not suggested to use 303 redirects for clients that do not support HTTP/1.1.
Like the 302 redirect, the 303 redirect can't be used for all scenarios that have a permanent nature.
The status code 307 has been defined in HTTP/1.1 to replace the status code 302 in occasions, where the request method must not be changed for the destination URL.
A 307 redirect is not cacheable by default. The cache-default can be overridden by the cacheability of the request method or by explicit cache controls. More information about this topic can be found in RFC 7234, Section 4.2.2.
The 307 redirect can be used if you need a temporary redirect, which forces the client to preserve the request method from the original request to the request on the destination URL.
Use Case for 307 redirects
307 redirects should not be used with the PRG-pattern. The 307 status code should also not be used if the redirect is of permanent nature.
The status code 308 is described in RFC 7538. It is a permanent counterpart to the 307 status code. Opposing to the 301 redirect the 308 redirect forces the request method of the subsequent request to be the same as of the original request.
A 308 redirect is cacheable by default, if not indicated otherwise. The cache-default can be overridden by the cacheability of the request method or by explicit cache controls. More information about this topic can be found in RFC 7234, Section 4.2.2.
The RFC 7538 restricts the usage of the 308 status code to "cases where the server has sufficient confidence in the client's understanding the new code or when a fallback to the semantics of status code 300 is not problematic".
The 308 redirect can be used if it is required to use the request method from the original request for the subsequent request, e.g. redirect of form action URLs using the POST method.
Use Case for 308 redirects
The 308 redirect is the wrong choice for for all occasions in which cacheability can lead to unexpected negative behaviour.
As shown above, there are a lot of different scenarios that require different technical specifications for the redirect used. The different status codes ensure that there is a perfect fit for each of these situations.
A client side redirect is a direct forward to a destination URL. The client side redirect is induced by the client, e.g. browser, directly.
While server side redirects are the desirable way to implement redirects, authors don't always have the opportunity to control server side redirects. For this case, client side redirects can be a choice to forward a user or have a document refreshed.
In HTML you can trigger a redirect using the following syntax within the HTML <head>:
<meta http-equiv="refresh" content="5; URL=http://www.example.com/">
The HTML meta tag offers the attribute "http-equiv", which can be used with the value "refresh" to indicate an automatic request to a target URL after a given time. The URL and the time has to be provided within the "content" attribute. The value for the content attribute contains the number of seconds until the redirect is triggered, followed by a semicolon and the URL to be called. The URL is optional. The meta element has to be within the HTML <head>.
This example would trigger a HTTP request with the GET method to http://www.example.com/ after 5 seconds. To trigger an immediate redirect use 0 seconds. There is no server side redirect status code involved in the process.
This technique has been widely used in the earlier days of SEO to create sneaky redirects for doorway pages. That's why search engines might misinterpret the intention of sites that use meta refresh. In addition, meta refresh with a delay other than zero seconds violate the Web Content Accessibility Guidelines.
We do not suggest to use meta refresh, because it might lead to problems with usability and with rankings in search engines. There are also better server side options for redirects.
location.href = "http://www.example.com/"; location.assign("http://www.example.com/"); location.replace("http://www.example.com");
From a SEO point of view, a server side redirect should always be prefered over a client side redirect. The major downside to client side redirects is the missing information about the reason for the redirect, making it harder for search engines to make a decision on how the redirect should be treated.
|Use Case||Temporary / Permanent||Cacheable||Possible Status Codes|
|Website Relaunch / Structure Changes||permanent||yes||301, 308|
|Geotargeting||temporary||no||303, 302, 307|
|Device Targeting||temporary||no||303, 302, 307|
|PPC / Affiliate campaign||temporary||depends on intention||303, 302, 307|
|URL Normalization||permanent||yes||301, 308|
If the structure of a website changes and no redirects are used, users will end up on 404 pages and SEO value as well as traffic might be lost. This often happens when websites are relaunched.
Redirects used to prevent this, should be
In order to prevent dead ends and conserve user flow as well as SEO value, we suggest using the 301 or 308 status code to redirect users from old to new URLs.
Note: The 308 can be the more accurate solution by specification, but clients might lack support for it.
If users are supposed to be forwarded to a localized version of a URL, there are certain requirements that need to be thought of when selecting a status code:
If a user changes its geographic location or browser language, the usage of a cacheable status code can lead to problems. The user might see the previously accessed localized content, resulting in a bounce or lower user engagement.
Without the vary header, search engines have no information about the changed behaviour of the redirect under different circumstances. Using the vary header usually leads to better targeting of multilingual sites in search results.
Because of the previously mentioned requirements, we suggest using 303, 302 or 307 redirects for geotargeting.
Webmasters can help search engines to understand international websites better, if the link attribute hreflang is properly used.
Using redirects for Pay per Click or affiliate marketing requires temporary redirects to prevent certain issues. The redirect targets can vary because of landing page testing or changes in the tracking infrastructure. To prevent problems the client's caching behaviour needs to be controlled.
As mentioned above, a Pay Per Click / affiliate campaign usually generates a lot of external references to the merchant's website. If permanent redirects are used and SEO value is passed on to the merchant's site, the site is basically buying links on a large scale. While search engines tend to be able to devalue affiliate links, in the worst case this can trigger link based filters like Google Penguin or even a manual action by search engines. The publisher's site can be penalized as well for selling links.
In most cases a non cacheable solution will fit, but as we are talking about paid traffic, it might be desirable to optimize loading speed by lowering the latency from redirects. Therefore it might be useful to utilize temporary redirects and allow them to be cached. This can be done using Cache-Control or Expire Headers with a low expiration time of for example 1 day. However, with proper client side caching, the tracking will only count the first access, because the redirect target is cached and called directly on recurring calls to the original URL.
Redirect requirements in Pay Per Click / affiliate campaigns:
The following table shows which status codes fit based on requirements.
|target URL can be called with GET||target URL can be called with POST|
client caches redirect
lower latency for recurring clicks
only first click counted in local tracking
|302, 307||302, 307|
client does not cache redirect
all clicks counted in local tracking
higher latency for recurring clicks
If users are supposed to be forwarded to a device specific version of a URL, there are certain requirements that need to be thought of when selecting a status code:
There are cases in which users do not want to use the device specific version of a website because they prefer to use the desktop version or the mobile version of a website. In this case, a cacheable redirect can lead to problems. The user might be unable to switch to the desired version once the cacheable redirect was received.
If the vary header is not sent, search engines have no information that the behaviour of the redirect changes under different circumstances. Using the vary header usually leads to better targeting of device specific sites in search results.
Because of the previously mentioned requirements, we suggest using 303 or 307 redirects for device targeting, depending on the required method for the request on the target URL.
We suggest using 303, 302 or 307 for redirects in device targeting.
Webmasters can help search engines to understand international websites better, if rel=alternate is properly used.
Many sites utilize the htaccess to do URL-corrections for host-, protocol- or other changes.
This usually includes but is not limited to
Redirects for URL-corrections should usually be permanent, cacheable and able to pass SEO value to consolidate user flow and link juice to the target URL.
Requirements for redirects in URL-corrections
We suggest using 301 or 308 redirects for URL-corrections.
Technically, redirects and rel=canonical are things that can hardly be compared. From SEO point of view, both can help to
Opposing to a redirect, the "canonical" is a HTML meta link element, which defines the prefered version of a document that is available on more than one URL. It can help to pass SEO value of an origin URL to the target URL, while the user can still access the duplicate document directly. However, the "Canonical Link Relation Specification" (RFC 6596) says if a canonical is used, the author should expect that applications such as search engines consolidate URL properties to the canonical URL. Applications are not required to use the canonical information to consolidate URL properties by specification. Search engines behaviour regarding passing of SEO value might therefore differ from expectations in individual cases.
Opposed to the vague nature of a canonical, a redirect is a specific solution with clearly defined application behaviour. Because of this, redirects should be prefered over canonicals, to consolidate URL properties and get rid off issues with duplicate content.
Over time, redirects can add up on a site and redirect chains might occur. A redirect chain is a number of redirects followed by each other.
This leads to
Redirect target status codes should be checked on a regular base to prevent redirect chains. Redirect chains can be detected with the Audisto crawler. Check out the hints about redirects for more information.
Each redirect generates a request to the server that needs to be processed and answered. This leads to higher latency for the user and may cause worse user engagement on a website.
|Number of requests||Time to process||Latency||Result|
|direct call||1||0.2s||0.2s||Page is shown|
|single redirect||2||0.2s x 2||0.4s||Page is shown|
|redirect chain||4||0.2s x 4||0.8s||Page is shown|
|maximum redirect chain||20||0.2s x 20||4s||Too many redirects error|
Different clients have a different number of requests before they throw a too many redirects error.
Redirects can add up quickly, for example if there is a chain of URL-corrections in place.
The following table shows an example redirect chain, that is caused by a number of URL-corrections, which are processed each in a separate step.
|Step||Reason||Redirect from||Redirect to|
|1||change the host||http://example.com/||http://www.example.com/|
|2||change the protocol||http://www.example.com/||https://www.example.com/|
|3||change to localized website version||https://www.example.com/||https://www.example.com/en-us/|
|4||change to mobile website||https://www.example.com/en-us/||https://m.example.com/en-us/|
From SEO point of view, redirect chains should be minimized whenever possible to optimize latency and improve user engagement on a website. Too many redirects might result in the waste of SEO value. Redirects for URL corrections should be implemented in a way that all corrections happen at once with a single redirect.
Search engines only crawl a small chunk of the web. A major challenge in this process is to use limited resources to find the highest possible number of relevant documents. In order to achieve this, each website gets assigned a crawl budget by the search engines, which determines the maximum number of requests a search engine will issue to a site within a certain time frame.
Each redirect causes the search engine to issue another request to find the requested document. So if redirects add up, this will affect your crawl budget usage. When crawl budget is consumed largely by redirects, more relevant parts of the site may get crawled less often or not at all. This can also lead to a longer time until a full crawl of the website is achieved, which results in lower index freshness.
More information on crawl budget optimization can be found in our guide about Crawl Budget and Crawl Rate Optimization.
URL highjacking happens, when the search engine unexpectedly shows the origin URL of a temporary redirect instead of the redirect target in search results.
If temporary redirects are used, search engines can't properly answer the question whether the original URL should be used for search results or if the target URL is the better choice. This can lead to unpredictable search engine behaviour.
The search engine might
Factors that might be taken into consideration by search engines, e.g.:
If you want to move content from one URL to another, make sure to use permanent redirects to avoid hijacking.
If your search engine rankings get hijacked by a third party, make sure to notify the search engine about this. All major search engines provide forms where webmasters can supply such information to straighten out highjacking problems.
If cacheable redirects are used temporarily to go back and forth between two URLs, this can lead to redirect loops.
If a user has discovered the site while the first redirect was active, the browser of the user will cache the redirect. When the user returns to the site, the client will see the new redirect back to the original URL and cache it as well. As a result, the client might end up in a loop between these two URLs.
Most clients work around this issue. Clients usually break the redirect loop by ignoring the internal cache and by verifying the cached information by a fresh request. However this behaviour should not be expected from all clients.
Pagination depth can vary, especially on sites with a highly dynamic number of content elements.
A pagination can contain a number of items in one moment and a smaller number of items in another moment. This results in a different number of pagination pages. A user might see a high pagination page in one moment and this pagination page can be inactive when the pagination page is accessed a moment later.
If you are using a permanent redirect status code in this case, it might get cached by the browser.
When the number of items changes again and the high pagination page can become active again. The user might access the page again and gets redirected to the previously cached redirect target URL.
We suggest using uncacheable temporary redirects for URL corrections in pagination.
You can find more information on pagination in our Ultimate Pagination Guide.