Imagine a customer only clicks on a product link and lands on a ‘404 Page Not Found’ error. They leave your website and you lose a sale. Redirects solve this problem by taking that customer to a different page, avoiding the 404 error. This is why redirects matter—not just for user experience, but also for SEO. In this guide, I’ll walk you through what redirects are, how you implement redirects correctly, and how you avoid common redirect problems.
What is a Redirect?
A redirect is a piece of code instructing the server to forward (or redirect) any requests made at one URL to a different URL. The URL you are redirecting from is called the redirect source (or redirect origin) and the URL you are redirecting to is called the redirect destination (or redirect target).
Types of Redirects
| Redirect Type | Processed By | Best For | SEO Friendliness |
|---|---|---|---|
| 301 Redirect | Server | Permanent URL changes (for example, to fix 404 errors or change URLs during a website redesign) | Best for SEO |
| 302 Redirect | Server | Temporary URL changes (for example, a product that is temporarily out of stock) | Can cause problems |
| JavaScript Redirect | Browser | Client-side redirects | Avoid when possible |
| Meta Refresh Redirect | Browser | Timed redirects | Use sparingly and only if necessary |
There are two different ways to implement a redirect: in client-side code or server-side code.
- Server-side redirects. Defined in server configuration files, these redirects are processed on the server (Apache, Nginx, Windows, etc.) before any content is sent to the browser. The server sends an HTTP response with the appropriate status code (e.g., 301, 302, 307) and the URL the browser should redirect to in the ‘Location’ header.
- Client-side redirects. There are two types of client-side redirects: meta refresh redirects and JavaScript redirects. These redirects are processed in the browser after the initial page containing the <meta> tag or the JavaScript code is loaded. This results in a less reliable redirect.
Benefits of Server-side Redirects
- Better for SEO. Search engines recognize 301 redirects as a permanent move, preserving rankings.
- Faster Performance. Processed by the server, minimizes HTTP requests, and does not load unnecessary scripts before redirecting.
- Reliable. Robots and browsers process them consistently. Users are unaware of the redirect.
Problems with Client-Side Redirects
- Worse for SEO. Search robots may be unable to execute the JavaScript or bugs prevent the meta redirect from processing.
- Slower Performance. Extra code must load first before the page is redirected, resulting in additional HTTP requests.
- Unreliable. JavaScript can break, preventing the redirect. Users may see the initial page load before the redirect.
Implementing Server-Side Redirects: Best Practices
On Apache systems, redirects are configured in the .htaccess file. On Windows, redirects are configured via a web.config file. There are also several other ways to handle redirects in a variety of programming languages. You can find out what kind of server you are on by using a tool like BuiltWith.
.htaccess 301 Redirect
An .htaccess file is a control file for Apache servers. The .htaccess file is located in the main directory (or root directory) of your website (make sure to view hidden files). In the .htaccess file, you can put many statements telling the server what to do, including statements about redirects.
Here are the steps to add a 301 redirect to the .htaccess file:
- To create the statement in the .htaccess file, you want to first state that you are making a redirect with the statement redirect.
- Next, you want to define the type of redirect. In this case, we want to permanently redirect the URL, so the redirect type is 301.
- Then you want to state the URL of the redirect source. To use the example above, let’s say we are fixing the broken link of “/login”. So, the redirect source URL to state in the .htaccess file code is /login. Note that, this URL shouldn’t include your website’s domain (this is called a relative URL).
- Finally, you want to state the redirect destination. In the example above, “/login.html” is the working version of the page and therefore, this is the URL we want to redirect to. We’ll state this by adding http://www.examplesite.com/login.html. For the redirect destination URL, it is best to include the domain name to make the redirect clearly stated (this is called an absolute URL).
Putting it all together, the line in your .htaccess file looks like this:
redirect 301 /login https://www.examplesite.com/login.htmlAfter saving the .htaccess file to your server, the next time you visit examplesite.com/login, you will be redirected to examplesite.com/login.html.
WordPress Redirects
For WordPress (and other CMS systems), some plugins will help with configuring and managing redirects. The plugin I’ve found works the best for clients and that I highly recommend using is called, simply, Redirection. Once installed, Redirection can be located under the “Tools” menu. From the main page, you can edit existing redirects or you can add a new redirect.

On the “Add New Redirect” screen, the “Source URL” is the URL you are redirecting from (the redirect source or origin), and the “Target URL” is the URL you are redirecting to (the redirect target or destination). The Redirection plugin also allows you to handle redirects with regular expressions and also lets you group redirects for better organization. By default, Redirection will set the redirect as a 301 but if you want to change that, you can click the gear icon for more options and set the redirect to a different response code.
Common Redirect Questions
How long should I keep redirects?
The length of time for Google to adjust will vary with some reports saying Google recognized redirects within a matter of hours and other reports suggesting it can take months. For more, see my article about how long to keep redirects.
How do you use 301 Redirects to fix 404 Errors?
One way to fix not-found errors on your website is by adding redirects. Let’s say, for example, that /login is a 404 not-found error on your website. To fix that error, and prevent people from encountering the error, you can add a redirect /login (the 404-error page) to /login.html (a working page on that website). That way, if anybody attempts to access /login, they will instead be taken to /login.html and avoid the redirect.
You can also add preventative redirects if there is a good chance a URL might be typed incorrectly. This is especially important for URLs used in offline advertising. For example, a brochure might tell people to visit yoursite.com/sale. Some people might forget the “e” at the end of the word, so it would make sense to redirect yoursite.com/sal to yoursite.com/sale before the brochure is distributed so that all customers can access the page.
How do you use redirects to avoid 404 Errors during a redevelopment?
When you are updating your website, as part of a redesign, redevelopment, or some other type of major overhaul, you will occasionally need to change the URL of a few pages. When you change the URL, anybody attempting to access the old URL will receive an error message saying that URL can no longer be found. Instead, you want to redirect visitors and robots who attempt to access the old URL to the new version of the URL to prevent a 404 error from ever occurring.
In some cases, every URL (or almost every URL) will change as part of the redesign or redevelopment. One of the most common reasons for this is when you are moving your website to a new platform. The platforms may generate different URLs (e.g. page.aspx instead of page.php) or the new platform might force a directory structure (e.g. all blog posts must be in a /blog/ directory). This is an area to evaluate when selecting new platforms; a platform that requires no (or only a few) changes to URL structure is preferable since it reduces the need for redirects and lessens the chances of losing traffic with a redesign.
When transitioning a website with only a few pages with changed URLs, redirecting each page is easy. But if you have lots of pages with changed URLs (for example, thousands of product pages all have changed URLs) sometimes it is more practical to only select the “best” pages to redirect. This may include redirecting pages with several external links, high traffic volume, a high number of social shares, a higher conversion rate, or some combination of those factors.
What are the different types of redirects?
When the server processes this redirect, an HTTP response status code is returned to the browser to indicate that a redirect has occurred and clarify the type of redirect. There are different types of redirects, including:
- Permanent redirect: A permanent redirect returns a 301 or 308 response code. JavaScript redirects do not return a status code but are typically treated as permanent. Meta refresh redirects are considered permanent if they are instant (0 second processing time).
- Temporary redirect: A temporary redirect returns a 302 or 307 response code. Meta refresh redirects do not return a status code but are typically treated as temporary if it is a delayed refresh (the processing time is greater than 0 seconds).
There is some anecdotal evidence that Google might treat 302 redirects as 301 redirects in some cases but, even still, a 301 is a clearer signal to send.
Why use a 302 temporary redirect?
If the redirect is truly temporary, then a 302 response code on the redirect is the right solution. For example, if you are temporarily shutting down a promotion page on an e-commerce website but will re-open that promotion page in a few days, a 302 would be appropriate. A 302 can also be appropriate when redirecting to new URLs if there is a chance of reverting to old URLs during a limited test phase.
What are 307 and 308 redirects?
A 307 or 308 response status are status codes available in HTTP 1.1. A 307 response indicates a temporary redirect and a 308 indicates a permanent redirect. The 308 code is supported by Google and treats a redirect returning a 308 status like a 301 redirect. As both status codes are supported, you do not need to change your current 301 redirects to a different status code.
A 307 response code on a redirect is most often seen within testing tools, including Google Chrome, when testing redirects between non-secure and secure websites. The 307 response status is returned in the browser even though the server may not be configured to return a 307 redirect. That’s because browsers are redirecting to https using an internal redirect and internal redirects return a 307 status. Internal redirects are not seen by Googlebot because this type of redirect isn’t a “real” redirect returned from the server. If you see a 307 response status in the browser, you’ll need to check what status code the server is returning as that will be the status code seen by robots (including Googlebot).
What are Redirect Chains?
A redirect chain is where several URLs redirect from one to the next to the next. Each step in the chain is a redirect hop. Example:
asite.com/A -> asite.com/B
asite.com/B -> asite.com/C
asite.com/C -> asite.com/DIn this example, the redirect source is asite.com/A and the final redirect destination is asite.com/D. However, the redirect takes three hops to arrive at that destination, creating a redirect chain. Note that the URL asite.com/B redirects to asite.com/D in two hops.
Robots waste resources crawling through these redirect chains and may simply stop following the chain after a certain number of hops, meaning the robots may not locate the final destination of the redirect chain. Chains can also lead to slower speeds (learn more about how redirects slow down a website).
As much as possible, chains should be avoided. In the above example, the redirects from asite.com/A and asite.com/B should both be updated to redirect to asite.com/D in one hop. If a chain cannot be avoided completely, chains should be reduced to as few hops as possible.
What are Redirect Loops?
A redirect chain that circles back onto itself is called a redirect loop. No destination can be arrived at by following redirects in a loop; visitors will be unable to access any pages within the redirect loop. Robots will waste crawl budgets when encountering loops. Human visitors and robots will both encounter error messages due to redirect loops.
Here is an example of a redirect loop. This starts at asite.com/A and redirects through a chain back to asite.com/A.
asite.com/A -> asite.com/B
asite.com/B -> asite.com/C
asite.com/C -> asite.com/AHow do redirects impact traffic?
Even when adding a redirect correctly, you will often see a dip in traffic from Google and potentially a dip in rankings in Google search results as Google learns about the redirect and the new URL. This can be especially problematic during a website redesign, though redirects can be a key part of recovery.
What page should you redirect to?
Deciding where some URLs should redirect to is easy, especially for updated pages. For example, a page about an old product might have been removed from the website, but there is a new version of that product. In this example, the URL of the removed page should redirect to the URL of the new page.
What about pages that do not have a new version? In these cases, the removed page’s URL should redirect visitors to a page that meets similar expectations as the removed page. For example, an old product page was removed and there is no new version of the product, but a redirect could route visitors to a category page that lists products similar to the product that was removed.
It is important to avoid redirecting visitors to a page that isn’t something people wouldn’t expect as this is frustrating and confusing. Let’s say, a visitor is trying to find a product you no longer carry but that old URL redirects me to your website’s about page—the about page has nothing to do with the product the visitor was interested in. One common example of this is the home page. The home page is broadly focused, so the chance the home page will be similar enough to the removed page visitors wanted to find is unlikely.
If there is no relevant page to redirect to, it might be better to not add a redirect at all and, instead, let the removed page return a not-found error. When reaching an error message, especially a well-crafted error message, visitors know the page they were hoping to access is no longer available instead of being confused after being redirected to an irrelevant page.
Testing Redirects
Google Search Console
To check that a URL redirects in Google Search Console, you can use the URL Inspection tool by entering a URL in the search box at the top of the screen.

Google Search Console will then return the results indicating what they know about the URL. If Google’s bots have previously crawled the URL, you will see a note that this URL is a “Page with redirect”, which is what we’d expect to see for a correctly implemented redirect. Note that a page with a redirect will not be indexed. Learn more about Google’s Page Indexing reports and why these pages are not indexed.

Other Methods of Testing Redirects
Another way of testing a redirect is to use a tool like WhereGoes. In WhereGoes, you can enter a URL, confirm that the proper response is returned when it is redirected, and confirm the URL redirects to the right location. Begin by entering the URL on WhereGoes’s main screen and then click “Trace URL”.

The result will then be returned. In this example, you can see that /tech-seo/controlling-search-robots/ on my website redirects with a 301 response to the /noindex-vs-nofollow-vs-disallow/ article.

Get Help With Your Redirects
Need help auditing redirects or correcting redirect problems? Contact me today.
More Articles
Schema Entity Mapping
Learn how to build an entity map, connect entities with schema markup and @id, and decide which information to repeat across your website.
Read Schema Entity Mapping →Schema: Find, Fix & Prevent Problems
Find and fix common schema markup problems, from invalid code to rendering issues. Learn how to audit and test schema with crawlers and validation tools.
Read Schema: Find, Fix & Prevent Problems →