301 Redirect

A 301 redirect is a server-side redirect with the HTTP status code 301 (“Moved Permanently”), which informs browsers and search engines that a URL has been permanently moved to a new address. The status code is defined in the HTTP standard RFC 9110 and is one of the most important tools in technical search engine optimisation: it ensures that users, crawlers and a page’s ranking signals – built up over many years – are directed to the new location rather than ending up on an error page.

In practice, 301 redirects are encountered wherever URLs change: when relaunching a website, when migrating an online shop to a new platform, when changing the domain, when merging categories, or simply when switching from http to https. Anyone who handles these situations without proper redirects will lose visibility – not because Google imposes a penalty, but because the old URL, along with its history, drops out of the index and the new URL starts from scratch.

How a 301 redirect works technically

When a browser or crawler accesses a URL, the web server responds with a status code. If the page is successfully served, the code is 200 (“OK”); if the page does not exist, it is 404 (“Not Found”). With a 301 redirect, the server does not return any page content, but instead returns the status code 301 plus a Location header containing the new destination address. The client automatically follows this instruction and accesses the new URL – for the user, this happens in milliseconds and usually goes unnoticed.

The process between browser, server and crawler

The difference between humans and machines lies in what happens to the ‘permanently moved’ information. A browser is permitted to cache the redirect: the next time the page is accessed, it jumps directly to the new address without querying the server again. This is precisely why you should only set a 301 if the move is truly permanent – a permanent redirect set by mistake cannot be easily removed from visitors’ caches.

For Googlebot, the 301 is a strong canonicalisation signal. Google interprets the redirect as stating “this page now has a different name”, transfers the signals collected from the old URL to the new one, and gradually replaces the old URL in the index. The Google documentation on redirects and Google Search explicitly states that server-side redirects are the most reliable method of communicating a site move. Important to note: this process takes time. Google must first crawl the old URL again to detect the redirect – for rarely visited pages, this can take weeks.

301, 302, 307 and 308: a comparison of status codes

The 301 is not the only redirect code. The HTTP standard RFC 9110 defines several 3xx codes, which differ in two respects: Is the move permanent or temporary? And is the client permitted to change the HTTP method when following the redirect?

For search engine optimisation, the distinction between permanent and temporary redirects is particularly crucial. A 302 tells Google: “The old URL will return; keep it in the index.” Anyone who redirects a permanently moved page using a 302 is therefore sending the wrong signal. Although Google often recognises from the context that a ‘temporary’ redirect is actually intended to be permanent, and treats it as a 301 after a while, you shouldn’t rely on this. If you’re serious about the move, say so.

Why 301 redirects are crucial for SEO

A URL that has been ranking for years carries an invisible legacy: inbound links from other websites, user signals, and a crawl and indexing history. All of this is tied to the exact address. If the URL disappears without replacement, this legacy is lost. The 301 redirect is the mechanism that transfers it to the successor URL.

For a long time, it was assumed that every redirect cost a small fraction of PageRank – a notion derived from earlier statements by Google employees regarding the so-called ‘damping factor’. Google explicitly abandoned this position in 2016: Gary Illyes publicly stated that 3xx redirects no longer lose PageRank. Since then, the quality of the destination has been more important than the code itself. A redirect only fully transfers relevance if the content of the destination page matches that of the old page. Anyone who redirects a hundred deleted product pages en masse to the homepage does not transfer any signals, but instead generates soft 404 errors: Google recognises the pattern and treats the redirects as deleted pages.

Three practical rules have been distilled from Google’s documentation and the experience gained from countless migration projects:

• Go straight to the destination: Avoid redirect chains. Googlebot follows a maximum of ten steps; three is the recommended limit – and each step adds to the loading time. After several relaunches, it is worth redirecting old redirects to the current final destination.
• Keep them active for long enough: Google recommends keeping redirects in place for at least a year. For URLs with valuable backlinks, there is no reason ever to disable the redirect – ‘cleaning up’ old redirects is usually self-sabotage from an SEO perspective.
• One-to-one rather than blanket: Each old URL is assigned the new destination that best matches its content. Category for category, product for product, guide for guide.

Implementing 301 redirects in practice

Where the redirect is configured depends on the stack. On an Apache server, a single line in the .htaccess file (Redirect 301 /old-page /new-page) is sufficient; with nginx, a return 301 in the server block is required. Content delivery networks such as Cloudflare offer their own redirect rules, which take effect before the request even reaches the origin server – with large numbers of redirects, this is also a performance consideration. E-commerce platforms and CMSs usually come with their own management tools, ranging from redirect plugins in WordPress to native modules.

Example: Shopware 6

Shopware 6 demonstrates how a platform resolves this issue at a system level: if the SEO URL of a product or category changes – for example, because the product name has been updated or a product has been moved to a different category – the system automatically creates a 301 redirect from the old URL to the new one. This ensures that the old URLs remain permanently accessible without anyone having to manually maintain a redirect table. However, this only covers changes within the current system. When switching platforms – for example, from Magento to Shopware – the new system does not recognise the old URLs; in this case, the redirect mapping must be developed as a separate project and implemented via server configuration or a redirect plugin. It is precisely at this stage that it is determined whether a shop migration will cost organic traffic or not.

Common mistakes with 301 redirects

The mechanism is simple, and so are the mistakes – yet they still happen regularly. The most common ones are:

• Bulk redirects to the homepage: Anything without an obvious destination ends up on the homepage. Google treats this as a soft 404, and the signals are lost.
• Redirect chains and loops: The old page redirects to the older one, which redirects to the new one – or, in the worst case, goes round in circles. Chains waste crawl budget; loops make content completely inaccessible.
• 302 instead of 301: Using a temporary status code for a permanent move delays indexing.
• Redirects removed too soon: If you ‘tidy up’ after three months, you’ll cut off backlinks and signals that haven’t yet been processed.
• Internal links not updated: After the move, internal links should point directly to the new URLs, rather than sending every navigation path through a redirect.
• Forgotten capitalised or parameterised variants: A complete URL inventory before the move prevents ranking parameter and pagination URLs from falling through the cracks.

Distinguishing between: 301 redirects, canonical tags and meta refresh

The 301 redirect is often confused with two related techniques that, at first glance, appear to do similar things. The canonical tag (rel="canonical") is not a redirect, but an indication in the HTML source code: ‘Of several similar URLs, this one is the authoritative one.’ Both URLs remain accessible; the user is not redirected. Furthermore, the canonical tag is merely a suggestion that Google may ignore – the 301, on the other hand, is an instruction that every client follows. Rule of thumb: if the old URL is to remain active (such as a filtered version of a category page), the canonical tag is appropriate. If it is to be removed, a 301 redirect should be set.

The meta refresh, on the other hand, is a client-side redirection via an HTML tag or JavaScript, which only takes effect after the page has loaded. Although Google can interpret immediate meta-refreshes, it explicitly classifies them as a weaker signal than server-side redirects – and for users, they feel like a hiccup during loading. As a permanent solution for relocated content, they have no place on a professionally run website; their legitimate use is limited to environments where one has no access to the server configuration.

A third point of confusion concerns status code 410 (“Gone”): it is the opposite of a redirect. The server uses this to indicate that a page has been deliberately removed without replacement. For content with no suitable replacement destination, a 410 is the more honest response than a forced redirect to an inappropriate page – Google will then quickly remove the URL from its index, without any soft 404 detours.

Frequently asked questions about 301 redirects

Does a 301 redirect lose link equity?

According to an official Google statement from 2016: no. 3xx redirects do not lose PageRank. The prerequisite is that the content of the destination matches that of the old URL – a redirect to a page on a different topic or, across the board, to the home page is treated as a soft 404 and effectively passes on nothing.

How long must a 301 redirect remain active?

Google recommends at least twelve months to ensure that all signals are passed on and all old URLs are reprocessed. For URLs with inbound links, the best approach is to keep them permanent. The maintenance effort involved in an existing redirect rule is minimal, whilst the damage caused by removing it is very real.

What is the difference between 301 and 308?

Both signal a permanent move. The difference lies in the HTTP method: with a 301, a client may convert a POST request to a GET when following the redirect; with a 308, the method must be preserved. For normal page views in search results, Google treats both the same; the 308 becomes relevant for forms and API endpoints.

How do I check whether a redirect is working correctly?

A crawler such as Screaming Frog can be used to test a complete list of URLs: Every old URL should be redirected directly to the correct destination using exactly one 301. Individual URLs can be checked via curl -I on the command line or using the URL inspection tool in Google Search Console, which also shows how Google has processed the redirect.

Can I undo a 301 redirect?

On the server side, yes – the rule can be removed or reversed at any time. In practice, however, the code has had an impact: browsers have cached the redirect, Google has passed on signals and may have removed the old URL from the index. Reversing the redirect therefore takes significantly longer than setting it up in the first place. A 301 is a decision, not an experiment.