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.
Technical point of view: What is a redirect
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
- 30x HTTP status codes
- Client side redirects
- Meta refresh
- Javascript redirects
Server 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 |
|---|---|---|---|---|
| 301 | HTTP/1.0 | Permanent | by default | GET / POST may change |
| 302 | HTTP/1.0 | Temporary | not by default | GET / POST may change |
| 303 | HTTP/1.1 | Temporary | never | GET always |
| 307 | HTTP/1.1 | Temporary | not by default | GET / POST may not change |
| 308 | HTTP/1.1 | Permanent | by default | 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:
- Is the redirection of temporary or permanent nature?
- Can the redirect origin URL be shown in search results?
- Is there any information about how long the redirect will be active?
The redirect status code can help answer these questions.
301 Redirect - "Moved Permanently"
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.
When to use 301 redirects
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
- Moving a domain permanently
- Moving a document permanently
- Changing the sites protocol permanently
- Changing a site's structure permanently
When not to use 301 Redirects
The 301 redirect is the wrong choice for for all occasions in which cacheability can lead to unexpected negative behaviour.
Examples
- Geotargeting
- Device targeting
- A/B testing
- Tracking (including pay per click- and affiliate campaigns)
The 301 is also wrong, if you want to apply a redirect that is not supposed to be of permanent nature.
Examples
- Seasonal products on ecommerce sites
- Temporary special offer landing pages on ecommerce sites
Analyze the structural impact of redirect malpractice with Audisto
Our software will analyze redirect chains or redirect loops with just a few clicks. Get easy insights how wrong usage of redirects harms your website and your performance.
Explore Redirect Features
302 Redirect - "Found" / "Moved Temporarily"
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 might not 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.
When to use 302 redirects
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
- Geotargeting
- Device targeting
- A/B Testing
- Tracking
- Recurring temporary content
- Redirect with no effect to presence in search results
Examples
- Seasonal products on ecommerce sites
- Temporary special offer landing pages on ecommerce sites
When not to use 302 redirects
The 302 status code should not be used if you want to pass SEO value to a destination URL.
Examples
- Moving a domain permanently
- Moving a document permanently
- Changing the sites protocol permanently
- Changing a site's structure permanently
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.
Examples
- Move the action URL from a form that uses the POST method temporary
303 - "See other"
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.
When to use 303 Redirects
The 303 redirect can be used in a similar fashion to the 302 redirect. Due to being not cacheable under any circ*mstances, 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
- All 302 use cases that work with GET requests for subsequent requests
- Geotargeting
- Device targeting
- A/B Testing
- Tracking
- Recurring temporary content
- Redirect with no effect to presence in search results
- PRG-Pattern (POST / Redirect / GET)
When not to use 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.
Examples
- Subsequent request requires POST method, e.g. moving a form action URL that requires the POST method
- Redirect is permanent
- SEO value is supposed to be passed on to the destination URL
307 Redirect - "Moved Temporarily"
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.
When to use 307 Redirects
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
- Subsequent re quest requires POST method, e.g. moving a form action URL that requires the POST method
When not to use 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.
308 Redirect - "Moved Permanently"
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".
When to use the 308 redirect
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
- Moving a very complex website with a lot of forms that use the POST method
- Subsequent request requires POST, e.g. moving a form action URL that requires the POST method
- All 301 use cases
- Moving a domain permanently
- Moving a document permanently
- Changing the sites protocol permanently
- Changing a site's structure permanently
When not to use the 308 redirect
The 308 redirect is the wrong choice for for all occasions in which cacheability can lead to unexpected negative behaviour.
Conclusion on Server Side Redirects
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.
Analyze the structural impact of redirect malpractice with Audisto
Our software will analyze redirect chains or redirect loops with just a few clicks. Get easy insights how wrong usage of redirects harms your website and your performance.
Explore Redirect Features
Client Side Redirects
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.
"Using JavaScript to redirect users can be a legitimate practice. For example, if you redirect users to an internal page once they're logged in, you can use JavaScript to do so. When examining JavaScript or other redirect methods to ensure your site adheres to our guidelines, consider the intent. Keep in mind that 301 redirects are best when moving your site, but you could use a JavaScript redirect for this purpose if you don't have access to your website's server." --- Google Search Console Help - Quality Guidelines
Meta Content Refresh
In HTML you can trigger a redirect using the following syntax within the HTML <head>:
<meta http-equiv="refresh" content="5; URL=https://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 an HTTP request with the GET method to https://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.
JavaScript Redirects
Javascript redirects are a client side alternative to the meta refresh. JavaScript redirects require a client to be able to interpret JavaScript.
Use cases
- Redirects based on user interaction
- Cross browser redirection
- Device targeting
For most use cases it is better to use server side redirects than JavaScript redirects. Even though search engines might be able to understand JavaScript redirects and do interpret them as intended, server side redirects should be prefered in any case because of their lower requirements on the client. If the client does not interpret JavaScript, the redirects will not work. Server Side redirects work in any case.
Compared to meta refresh, JavaScript redirects allow to redirect the client based on logic. This allows different redirect targets under different circ*mstances. This makes it a viable option, e.g. for client or device targeting to redirect to the device specific URL.
Because of the fact that much more client specific information is available in Javascript than in an HTTP request header, the Javascript redirect might be a better choice than a server side redirect in some situations.
Examples for JavaScript redirects
There is a wide range of ways to implement JavaScript redirect. JavaScript redirects can have different behaviour in terms of browser history, information about the referrer and can behave differently depending on the browser that is used.
Here are a couple of examples for different methods to implement JavaScript redirects.
location.href = "https://www.example.com/";location.assign("https://www.example.com/");location.replace("https://www.example.com");Conclusion on Client Side Redirects
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.
If no server side redirect is possible, javascript redirects can be used to do redirects for device-/browser- or geolocation targeting.
Common SEO Use Cases for Redirects
| 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 |
Redirects on Site Structure Changes
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
- Permanent
- Cacheable
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.
Read our detailed guide on how to do website structure optimization if you want to learn more about this topic.
Redirects for Geotargeting
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:
- Redirects need to be temporary
- Redirects need to be not cacheable
- A vary header should be supplied for search engines
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 circ*mstances. 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.
Redirects for Pay per Click / Affiliate Marketing
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:
- Temporary
- Non cacheable / cacheable depending on intend
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 | 303 | 302, 307 |
Redirects for Device Targeting
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:
- Redirects should be temporary
- Redirects should be not cacheable
- A vary header should be supplied for search engines
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 circ*mstances. 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.
Google supports both HTTP redirects as well as javascript redirects for device targeting, but suggests using 302 redirects along with rel=alternate definitions.
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.
Redirects for Host- and Protocol-Changes and other URL-Corrections
Many sites utilize the htaccess to do URL-corrections for host-, protocol- or other changes.
This usually includes but is not limited to
- Forcing www- vs. non-www version
- Forcing protocol HTTPS vs HTTP
- Adding trailing slash
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
- Permanent
- Cacheable
We suggest using 301 or 308 redirects for URL-corrections.
Redirect vs. Canonical in SEO
Technically, redirects and rel=canonical are things that can hardly be compared. From SEO point of view, both can help to
- Avoid problems with duplicate content
- Consolidate URL properties, e.g., link popularity
Opposing to a redirect, the "canonical" is an 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.
Common SEO Mistakes with Redirects
Redirect Chains
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
- Client warning "too many redirects"
- Higher latency
- Crawl budget waste
- SEO value waste
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.
Redirects as Latency Generators
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.
Example:
| 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.
Redirects as Crawl Budget Killers
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 due to Redirects
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
- use the original URL to show in search results
- use the redirect target URL to show in search results
Factors that might be taken into consideration by search engines, e.g.:
- Time the temporary redirect is active
- Incoming links to each URL
- Trust of the host
- Length of origin and target URL
- User signals in search results
- Internal or external redirect
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.
Redirect Loops due to cacheable Redirects
If cacheable redirects are used temporarily to go back and forth between two URLs, this can lead to redirect loops.
Example:
https://example.comis redirected tohttps://www.example.com. The redirect is cached.- The redirect gets reverted. Now
https://www.example.comredirects tohttps://example.com. The redirect is also cached.
If a user has discovered the site while the first redirect was active, the user's browser 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.
Analyze the structural impact of redirect malpractice with Audisto
Our software will analyze redirect chains or redirect loops with just a few clicks. Get easy insights how wrong usage of redirects harms your website and your performance.
Explore Redirect Features
Wrong Redirect in Pagination
Pagination depth can vary, especially on sites with a highly dynamic number of content elements.
Example:
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.
How we help - Redirect Analysis
The Audisto Crawler offers a number of hints to help identify issues with redirects. If you need personal assistance analyzing your website, just contact us. We will be happy to help.
