Redirects

Having a firm grasp on redirects and the many different scenarios in which they are used is essential when it comes to technical SEO.

While the premise may sound relatively simple, there are several different types of redirects, each with their own use cases.

In this guide we outline the different types of redirects, when they should be used and how you can ensure you’re following best practises.

---

What Is a Redirect?

A redirect is a technique that allows you to direct both users and search engines to a different URL to what they originally requested.

There are multiple ways to implement redirects, and they can be either permanent or temporary.

---

Why Are Redirects Important?

It’s inevitable that you are, at some point, going to need to change or remove URLs on your website. Redirects allow you to communicate these changes to search engines, as well as helping to maintain a good user experience by preventing people from landing on an old or deleted page.

Further to this, any link equity that a page has accrued can be passed on to the new destination through a 30X redirect. This can help maintain rankings and prevents PageRank from external links being lost to a deleted or moved URL.

---

Use Cases

There are a number of common scenarios where a redirect is typically required, for example:

• Changing Domain
  • If you’re migrating from one domain to another, you’ll want to ensure visitors to your old domain are redirected to the new one, and that any link value is also passed.
• Merging Domains
  • If you own several variations of your domain (such as typos), or perhaps if you’ve acquired a competitor, you can redirect all of these to one correct destination.
• Site Restructures
  • If you’ve significantly changed your website’s structure, for example during a redesign, URLs may be changed or removed. Redirects help maintain a good user experience by avoiding broken pages.
• Avoiding Duplicate Content
  • If you are changing URLs from a non-trailing slash version to a trailing slash version, then a redirect will be needed.
• URL Changes
  • Anytime you change a URL, for example replacing an old product with a new one that has a different URL, a redirect should be put in place.

---

Types of Redirects

There are essentially two types of redirect: server-side and client-side.

True to its name, a server-side redirect results in the server responding to a request with a 30X server status code, indicating that the requested resource has moved to a different URI.

A client-side redirect is executed by the browser, and is defined within the code itself, instructing the user agent to retrieve content from elsewhere.

Further to this, redirects can be either permanent or temporary, allowing you to communicate changes to the search engines and signpost which page you want to show in the search results. As per Google’s official documentation on redirects:

• Permanent redirect: The new redirect destination will now be displayed in the search results.
• Temporary redirect: The source page of the redirect will continue to be displayed in the search results, but users will be redirected to the temporary destination.

---

Server-Side vs Client-Side

It’s almost always best to opt for a server-side redirect as opposed to client-side. In Google’s own words:

“If you need to change the URL of a page as it is shown in search engine results, we recommend that you use a server-side 301 redirect. This is the best way to ensure that users and search engines are directed to the correct page. The 301 status code means that a page has permanently moved to a new location.”

However, there are certain instances where a client-side redirect is acceptable to use. Again, this is noted within Google’s Quality Guidelines when talking about JavaScript Redirects, which is a type of client-side redirect (more on that later):

“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.”

Client-side redirects can also be useful when you do not have the ability to access server behaviour, such as not being able to edit the .htaccess file.

There are some additional drawbacks to using client-side redirects:

• Not all browsers support them, meaning the user would not be forwarded to the correct destination.
• Some search engines may not correctly interpret a client-side redirect, which may impact the passing of authority from the original page to its new destination. Google shouldn’t have a problem if it’s able to crawl and render the pages correctly.
• A client-side redirect breaks the browser back button, which may seem like a trivial issue but can be frustrating for the user.

Generally speaking, a client-side redirect is better than not redirecting at all, when it is not possible to implement server-side redirects.

---

Server-Side Redirects

There are several different types of server-side redirect, but it’s likely you only need to fully understand a handful of them from an SEO perspective.

Code	Text	Type
301	Moved Permanently	Permanent
302	Found	Temporary
303	See Other	Temporary
307	Temporary Redirect	Temporary
308	Permanent Redirect	Permanent

301 Redirect: Moved Permanently

The 301 redirect is one of the most important redirects. As mentioned previously, Google recommend the use of a server-side 301 redirect if you need to permanently change the URL of a page as it is shown in the search engine results.

It is the most effective way of communicating a permanent change to both users and search engines, and ensures that indexing and link signals are passed from the original URL to the new target URL.

A 301 redirect should be used if you are making a permanent change, such as:

• Migrating to a new domain.
• Changing the URL of a page, perhaps as a result of a site restructure.
• Preventing duplicate content issues, or if you want to consolidate similar pages/topics into a single page.

It’s important to understand that there can be serious implications to using a 301 redirect if you subsequently change your mind later on down the line. Firstly, it will take time for the original URL to be indexed again, and it’s unlikely that it will rank as well as it did prior to the redirect being implemented.

302 Redirect: Found

A 302 redirect is a temporary redirect, and essentially results in the same user experience as a 301 redirect. However, a 302 redirect tells search engines that this is a temporary change as opposed to a permanent one. This means Google will keep the old URL in its index, rather than the target URL.

Over the years there has been much discussion around how much PageRank a 302 redirect passes, but Google have been somewhat consistent with their messaging around this. In 2016, Googler Gary Illyes stated that 30x redirects don’t lose PageRank anymore. He later tweeted in 2017 that this was still the case.

Essentially, a 302 redirect will pass PageRank and it may eventually be treated as a 301 permanent redirect if it is left in place for a long period of time.

A 302 redirect should be used for temporary changes, where you intend for the old page to comeback at some point, for example:

• If you’re redesigning your website and want to send users to a specific page for a certain period of time.
• Running a seasonal promotion and want to temporarily redirect users to a special sales page.
• A/B split testing the updated design of a page, without impacting the original URL’s rankings.

303 Redirect: See Other

Like a 302, a 303 redirect is a temporary redirect that communicates to search engines that the requested resource can be found at another URI using a GET method. 303 redirects cannot be cached or refreshed, meaning they’re useful at preventing accidental resubmissions of forms by clicking the submit button, back button or refreshing the page.

As such, 303 redirects should be used for:

• Pages with a form submission
• Payment confirmation pages
• Upload progress pages

Essentially, any page that shouldn’t be refreshed, bookmarked or cached should potentially use a 303 redirect. In reality, it’s unlikely you’ll ever need to use a 303 redirect due to the way that most of the aforementioned examples are implemented these days.

307 Redirect: Temporary Redirect

A 307 redirect is very similar to a 302 redirect and was introduced to the HTTP standard in HTTP/1.1. Again, a 307 redirect is temporary, and it is easiest to explain with an analogy.

Imagine you’re shopping for groceries and want to go down aisle 23 but it’s closed due to a spillage, so you’re directed down aisle 24 instead. This diversion is temporary, and you categorically know that once the spillage has been cleaned up, aisle 23 will be open again.

This is essentially how 307 redirects are treated, and Google also have a great video on how Googlebot handles these.

307 redirects sound almost identical to 302 redirects on paper, and while they are both temporary, a 307 redirect precisely communicates that this is a temporary change, and that the original URL will be back. As mentioned previously, 302 redirects can be seen as a vague directive to the point where they can be treated as permanent after a certain point in time, whereas this would not happen with a 307 redirect.

Link equity is passed in a 307 redirect like a 302, but search engines will not update their index to include the destination URL. As such a 307 redirect should only be used when you are certain it is temporary, and that the original URL will return.

308 Redirect: Permanent Redirect

Similar to how the 307 redirect is a more strongly defined 302, the 308 redirect is essentially a stricter version of the 301 redirect. It indicates that the requested resource has definitively moved to a new destination and forces the request method and body to be the same as the original resource. Unlike a 301 redirect, a 308 does not allow changing the request method from POST to GET.

The 308 redirect is still relatively new; however, Google have stated that it will be treated the same as a 301 redirect. This means that link equity will be passed to the destination URL, and the ranking page may update in the index.

All of the aforementioned examples of when to use a 301 redirect apply to a 308 redirect, but if you’re not entirely sure you should always opt for a 301 redirect. A 308 redirect can be useful if a large, complicated site with lots of forms is migrating to a different domain.

---

Client-Side Redirects

There are only two types of client-side redirect: a meta refresh redirect and a JavaScript redirect. As mentioned previously, these redirects are executed by the client itself. While there may be legitimate use cases for a client-side redirect, you should generally always opt for a server-side redirect if you are concerned about SEO performance.

Meta Refresh Redirect

Meta refresh redirects are commonly seen on pages that have a countdown, for example:

“You will be redirected in 5 seconds. If you are not, please click here.”

They are often used when a server-side redirect is not possible, as the redirect is simply defined within the code of the page itself. As mentioned previously, there are several drawbacks to meta refresh redirects, and they can be confusing to the user if they are not expecting it.

As meta refresh redirects are implemented through the HTML code of a page, they cannot be used for images or other types of content such as a .pdf.

According to Google’s official documentation on redirects, a meta refresh with a 0 second delay would be treated as a permanent redirect, while any other meta refresh (>0 seconds) would be treated as temporary.

Unless you have a very specific use case for a meta refresh redirect, you should always opt for a server-side 30X redirect instead.

JavaScript Redirect

A JavaScript redirect is reliant on the client being able to interpret JavaScript, which as well as the other client-side drawbacks, is another reason why it’s often better to use a server-side redirect.

Unlike meta refresh redirects, a JavaScript redirect allows you to redirect clients based on logic, meaning you can define different destinations based on different conditions.

While search engines can interpret JavaScript redirects, it’s almost always better to use a server-side redirect if possible. This is because search engines need to render the page in order to interpret the redirect, and thus they are slower to execute than a server-side redirect.

In 2020, Googler Gary Illyes also tweeted saying that JavaScript redirects are probably not a good idea. However, Googler John Mueller confirmed in a 2019 video that Google “support JavaScript redirects of different types and follow them similar to how we’d follow server-side redirects.”

If you have no other means in which to implement a server-side redirect, and a meta refresh doesn’t suit your needs, then a JavaScript redirect is a good fall-back option when compared to no redirect at all.

A Note on Canonical Link Elements

The rel=”canonical” element is similar to a redirect in that it helps specify a single preferred version of a page when it’s available via multiple URLs. It’s a hint to the search engines to help prevent duplicate content, by consolidating indexing and link signals to a single URL to use in ranking.

It’s considered best practise for every page to include a self-referential canonical tag as it makes it easy for search engines to determine which version of a page you want indexed, while consolidating ranking signals.

As such it’s also worth considering the use of a rel=”canonical” element in the event that you are not able to implement server-side redirects.

---

Crypto Redirects

If you can’t implement any of the aforementioned methods Google advises that, at the very least, you should let users know that the page or content has moved to a different destination. They recommend doing this by a simple explanation accompanied by a link to the new page or content, for example:

“Please note, this page has now moved and can be found here.”

While still not as effective as a server or client-side redirect, this offers a better user experience and may be interpreted as a crypto redirect by Google.

---

Redirect Best Practices

Outside of the above recommendations and use cases, there are some common best practises that should be followed when implementing a redirect.

• Relevancy is key
  • URLs should only be redirected to a relevant alternative. If a redirect points to a non-relevant page, it’s unlikely to carry much weight and may even be treated as a soft 404.
• Keep them in place
  • Google recommend that redirects are kept in place for at least 1 year. However, from a user experience perspective it’s important to keep them in place indefinitely if you’re not able to update links to point to the end destination.
• Prioritise
  • Keep on top of your most visited and most linked to pages and redirect them to relevant alternatives if you need to remove them.
• Changing URLs
  • It’s generally best to avoid changing and subsequently redirecting URLs unless absolutely necessary.
• Internal linking
  • Try not to link internally to redirecting URLs, instead link to their destination. Linking to a redirecting URL wastes crawl budget and causes latency.
• Server-side vs client side
  • As mentioned previously, it’s almost always better to use a server-redirect over a client-side redirect.
• Redirect chains
  • Avoid redirects that point to other redirects, which is known as a redirect chain. As per Google’s documentation, it states that Googlebot will follow up to 10 redirect hops. This number is dependent on user agent e.g. Googlebot Smartphone may follow a different number of hops than Googlebot Image.
• General redirects
  • There are many common redirects that apply to almost all sites. These include:
    • Www. Or non www. – from an SEO perspective there’s no difference between using www. and non www. However, be sure to use a 301 redirect from your non-canonical URLs to their canonical equivalent.
    • HTTP to HTTPS – Google have been very open about the fact that they consider HTTPS a ranking factor, and it’s likely that your site is already secure. As well as being secure, you should enforce HTTPS through the use of HSTS, forcing all communication between a website and a client to be sent over secure HTTPS connections. A site wide HTTP -> HTTPS permanent redirect is still needed, however. This is because the Strict-Transport-Security header is ignored unless it’s sent over HTTPS, meaning that if the first visit to your site is not via HTTPS, you still need that initial redirect to HTTPS to deliver the Strict-Transport-Security header.
    • Slash or non-trailing slash – if pages on your site with or without a trailing slash are the same, these are treated as separate URLs. This raises concerns around duplicate content, and while Google are good at determining a canonical version of a page, you can enforce a permanent 301 redirect to your preferred version.
    • Uppercase to lowercase – upper case and lowercase versions of URLs are treated as separate, which again can cause issues from a duplicate content perspective. It’s generally recommended that lowercase URLs should be used consistently across a site, and you can implement permanent redirects from uppercase URLs to their lowercase equivalents.

---

How to Audit Redirects

The Screaming Frog SEO Spider can help to check and audit your redirects at scale, either by crawling your site or by uploading a list of URLs in bulk. The tool makes it easy to identify what redirects are being used and their destination, as well as highlighting and following redirect chains.

Take a look at our in-depth guide on how to bulk check redirects.

If you’re changing your URL structure or moving to a new domain, we also have a guide on how to audit redirects in a site migration.

---

Final Thoughts

Implementing and maintaining redirects across your site can become complicated, especially at scale. However, it is important to routinely keep on top of them and follow best practises, to ensure you’re making things as easy to understand as possible in the eyes of the search engines.