301 redirects: what they are, when to use them and how they affect SEO

A 301 redirect is the server's way of saying "this page has moved permanently, go here instead": the old URL answers with status code 301 and the new address, browsers load the new page automatically, and search engines move the old URL's rankings and links to it. Used well, a 301 costs you nothing in search. This guide is for anyone who renames pages, restructures a site or changes domain: it explains what a 301 does, when to use it instead of a 302 or a 404, what really hurts SEO, and how to check that your redirects work. Server configuration lives in a separate how-to, linked below.

Quick answer

• A 301 means "moved permanently". Use it whenever a URL changes for good: a renamed page, a new URL structure, http to https, a new domain.
• 301 redirects do not hurt SEO when they are done right. Google uses a permanent redirect as a strong signal that the new URL should replace the old one in search.
• Redirect to the closest equivalent, never everything to the home page. Google treats irrelevant redirects like missing pages.
• One hop only. Every old URL should reach its final page in a single redirect, with no chains and no loops.
• Use 302 or 307 only for temporary moves, and a 404 or 410 when a page is gone with no replacement.
• Keep redirects for at least a year, Google's guidance for site moves, and longer while old URLs still get visits or links.
• Test any URL with the free redirect checker, and write rules for a whole list with the redirect rule generator.

What is a 301 redirect?

HTTP status codes in the 300 range tell the client that the page it asked for is somewhere else. 301 "Moved Permanently" is the permanent version, defined in RFC 9110, the current HTTP standard. The server sends no page, only the status line and a Location header with the new address.

You can see it with curl in a terminal:

curl -sI https://example.com/old-page

HTTP/2 301
location: https://example.com/new-page/

That is all a 301 is. It is not a setting in Google, not a tag in the page and not a plugin feature: it is the answer your server, CDN or application gives for one address. Plugins and CDN dashboards are just different places to configure that answer.

"301 redirect" is also used loosely for any permanent redirect. The strict meaning matters when you debug: a <meta http-equiv="refresh"> tag or a JavaScript window.location is not a 301, because the server answers 200 OK and the page only moves afterwards in the browser.

How does a 301 redirect work?

Follow a single request through the chain of events:

1. The request. A visitor clicks an old link, or Googlebot recrawls an old URL from its index.
2. The answer. The server looks at the path, matches a redirect rule and answers 301 with the new URL in Location. This happens before any page is built, which is why a server rule is fast.
3. The second request. The browser requests the new URL and shows that page. The address bar shows the new URL. Each redirect costs a full round trip, often 100–300 ms on a mobile connection.
4. Caching. A 301 may be cached by browsers without an expiry date unless the server says otherwise, so a returning visitor often goes straight to the new URL without asking the old one. That is good for speed and bad when you made a mistake, because a wrong 301 can stick in browsers for a long time.
5. Indexing. Google follows the redirect and, according to its redirects documentation, uses a permanent redirect as a strong signal that the target should be canonical. Over the following days or weeks the new URL replaces the old one in results, with the old URL's links and signals attached.

Googlebot follows up to 10 redirect hops, and ignores any content the redirecting URL sends. It discovers each redirect only when it recrawls the old URL, which is why a big URL change takes weeks to settle even when every rule is correct.

301 vs 302, 307 and 308

There are four server-side redirect codes you will meet. They differ on two points: permanent or temporary, and whether the browser may change the request method.

For ordinary pages, 301 and 308 behave the same in search, and so do 302 and 307. The difference only matters for form submissions and APIs: with a 301 or 302, browsers are allowed to turn a POST into a GET, while 307 and 308 keep the method.

The expensive mistake is a 302 for a permanent move. Google then keeps the old URL in its index for longer, because you told it the move may be undone. Google has said a long-standing 302 can eventually be treated like a permanent one, but you lose weeks you did not need to lose. The cluster guide on 301 vs 302, 307 and 308 and one-hop redirects covers each code, when a temporary redirect really is right, and why http → https → www chains appear.

Do 301 redirects hurt SEO?

No. A correct 301 passes the old URL's ranking signals to the new one. Google's Gary Illyes confirmed in 2016 that 30x redirects no longer lose PageRank, and Google's site move guidance is built on permanent server-side redirects for exactly that reason.

What people experience as "301s hurting SEO" almost always comes from one of these:

• Redirects to the wrong page. Sending a discontinued product to the home page, or a whole blog to one category. Google's site move documentation warns against redirecting many old URLs to one irrelevant destination such as the home page, and may treat those redirects as soft 404s, so the signals are dropped.
• Chains and loops. Old → older → new costs each visitor several round trips, and Google stops after 10 hops. A loop never reaches a page at all.
• Missing redirects. Old URLs that answer 404 after a relaunch lose their links and rankings.
• Removing redirects too early. Once the rule is gone, links from other sites point to a 404 again.
• The recrawl gap. Rankings can wobble for a few weeks after a large change while Google recrawls old URLs. That is the process, not a penalty, and it settles when every old URL has been fetched once.

Are 301 redirects bad for SEO in large numbers?

The number of redirects on a site is not a problem in itself. A shop that has renamed thousands of products over ten years can have thousands of exact-match 301 rules with no ranking effect. What matters is that each rule is one hop to a relevant page, and that your own site links to final URLs so visitors and crawlers rarely pass through a redirect at all.

When to use a 301 redirect, and when not to

Use a 301 when an address changes and the content, or a close equivalent, lives on:

• A page gets a new slug, or moves to a new folder.
• The site changes URL structure, such as /index.php?id=12 to /shoes/red-runner/.
• The site moves from http to https, or you settle on www or non-www.
• The site moves to a new domain, or merges with another site.
• Two pages on the same topic are merged into one.
• A product is replaced by a direct successor.

Do not use a 301 when:

• The page is gone with no equivalent. Let it answer 404 or 410. The guide on 404 vs 410 vs redirect for removed pages walks through the decision.
• The move is temporary. A seasonal page, maintenance or an A/B test belongs on a 302 or 307.
• Both pages must stay reachable. For near-duplicates that visitors still need, such as print versions or filtered lists, use a canonical tag instead. Canonical tags explained covers when a hint is better than a redirect.

Where 301 redirects are set up

The rule can live in four places. The closer to the edge, the faster it answers and the fewer systems it depends on.

The how-to guide on setting up 301 redirects on Apache, nginx, Cloudflare, WordPress, Netlify and Vercel has the exact rules for each, for one page, for hundreds and for a whole domain, plus the reasons a .htaccess redirect sometimes does nothing. For a list of old and new URLs, the generator writes the rules for you:

It runs in your browser, takes up to 10,000 rows, writes exact-match rules for Apache, nginx, Cloudflare Bulk Redirects, Netlify, Vercel or Caddy, and points chains in your list straight at their final page before a rule is written.

Redirects in WordPress

WordPress has three layers that can redirect: the server (.htaccess or nginx), redirect plugins such as Redirection or the redirect managers in Rank Math and Yoast SEO Premium, and WordPress itself, which redirects changed post slugs automatically and sends visitors to the canonical host set in Settings → General. Note the gap in core: pages are not covered by the automatic slug redirect, so a renamed page answers 404 until someone adds a rule.

Server rules answer before WordPress loads and keep working when a plugin is switched off; plugin rules are easier for editors and can log 404s. The common trouble is two layers doing the same job and creating a chain or a loop, so decide which layer owns which kind of redirect. The guide to WordPress redirects with a plugin or a server rule compares the plugins, shows where server rules go in .htaccess and gives a table of which layer should own https, www, renamed pages and migration lists.

Meta refresh and JavaScript redirects

When you cannot touch the server, for example on some hosted platforms, a meta refresh or a JavaScript redirect is the fallback. Google's documentation treats a meta refresh with a delay of 0 seconds as permanent and one with a delay as temporary. JavaScript redirects work only after Google renders the page, and Google says to use them only when server-side or meta refresh redirects are not possible. Link previews and many AI crawlers do not run JavaScript, so they never follow them.

If a client-side redirect really is your only option, make the old page carry every signal: a canonical tag to the new URL, an instant meta refresh, a location.replace() script and a plain link for everyone else. Meta refresh and JavaScript redirects has that page ready to copy, explains why timed "you will be redirected" pages fail accessibility guidance, and covers redirects in single-page apps. The JavaScript SEO guide explains the rendering side.

Redirect chains and loops

A chain is two or more redirects in a row before the page, such as http://example.com/shop → https://example.com/shop → https://www.example.com/shop → https://www.example.com/shop/. Each hop is another round trip for the visitor, and each one is another rule that can break. Chains build up naturally: every migration adds rules on top of the last one, and nobody updates the old ones.

The fix is always the same: point every old URL straight at the final address, and combine the http, www and trailing-slash rules into one. Redirect chains after a migration shows how to find every hop across an old URL list and flatten the rules on nginx, Apache and WordPress.

Your own links are the other half. Menus, content and templates that link to old URLs send every click through a redirect that you control and could avoid. The same guide shows how to fix internal links that redirect at the source while keeping the redirect for everyone else.

Redirect loops and ERR_TOO_MANY_REDIRECTS

A loop is a chain that never ends: A redirects to B, and B back to A. Browsers give up after about 20 redirects and show "ERR_TOO_MANY_REDIRECTS" in Chrome, or "The page isn't redirecting properly" in Firefox, and Googlebot gives up after 10 and reports a redirect error in Search Console.

A loop is almost always two layers that disagree: Cloudflare's Flexible SSL mode talking plain http to a server that forces https, a www rule at the host and the opposite one in WordPress, or a plugin undoing a server rule. The redirect checker shows the addresses that repeat. ERR_TOO_MANY_REDIRECTS: how to fix a redirect loop walks through the visitor fix, how to tell which layer sends each hop, and the fix for each pattern.

www, https and trailing slashes

Every page on your site can be reached at up to eight addresses: http or https, with or without www, with or without a trailing slash. Search engines see those as separate URLs. The site-wide redirects that fold them into one form are the most common 301s on the web, and the most common source of chains.

Pick one form, send the other seven to it with a single 301, and use that form in your canonical tags, sitemap and internal links. Trailing slashes, www and https: pick one has the configs and the order to do it in, with HSTS last.

Redirecting a whole domain

Moving to a new domain, merging a second domain into your main one or retiring an old brand all use the same pattern: redirect every path on the old domain to the same path on the new one, in one hop, and keep the old domain registered and redirecting. A catch-all to the new home page throws away the rankings of every deeper page.

For a domain move, also verify both domains in Google Search Console and use the Change of Address tool. Google's help page says the tool requires 301 redirects to be in place, that its signals last 180 days, and that you should keep the redirects for at least 180 days, longer if Google Search still sends traffic to the old URLs. How to redirect a domain to another domain has the setups for Cloudflare, Apache, nginx, cPanel and registrar forwarding, and the DNS and certificate steps people forget. The website migration guide covers the whole move, from redirect map to monitoring.

How to check a 301 redirect

Browsers are poor testers, because they cache 301s and may not ask the server again after the first visit. Use a tool that shows every hop:

Enter the old URL and the checker follows every redirect to the page that answers, with each status code, how much time Lighthouse measured the redirects costing, and the canonical tag on the final page. It also requests the http and the other www variant of the address to see whether they redirect permanently to the final host. You want one 301 or 308, then a 200 on a page whose canonical is its own address.

For a list of old URLs after a relaunch, paste them into the bulk URL checker, or paste old and new pairs into the migration redirect validator, which tells you for each pair whether it lands on the expected page in one permanent hop.

The full getReport report checks redirects on every run:

The fix pages on redirect chains and enforcing HTTPS have the short version of each fix.

301 redirect best practices

1. Redirect page to page. Each old URL goes to its closest equivalent: the product to its successor, the article to its new address, the category to the new category.
2. One hop. Old URLs point to final URLs. When you add a new redirect, update the older ones that pointed at the page you are moving.
3. Redirect on the server or at the edge, not with JavaScript or meta refresh unless there is no other option.
4. Use 301 or 308 for permanent moves, 302 or 307 only when the old URL will come back.
5. Keep query strings in mind. Old URLs such as /index.php?page=contact need rules that match the query string; many simple rules ignore it.
6. Update your own links, canonical tags, hreflang annotations and the XML sitemap to the new URLs. Redirects are for everyone else.
7. Keep the redirects. Google's site move guidance says at least one year; there is little cost in keeping them for good.
8. Test before and after launch, from outside your browser cache, with every old URL you know of.
9. Log 404s after the change, in Search Console and your server logs, and add rules for old URLs you missed.

Common mistakes

• Redirecting everything to the home page. Visitors lose what they came for and Google treats the redirects as missing pages.
• Using a 302 because it was the default. Some plugins and frameworks default to temporary redirects. Check the status code, not just the destination.
• Testing in the browser that cached the old rule. Use curl -sI, a private window or the redirect checker.
• Stacking rules from every relaunch. Three migrations later, the oldest URLs take four hops. Rewrite old rules to point at final URLs.
• Two layers redirecting the same thing. A CDN rule and a server rule for https, or a plugin and .htaccess for www, create chains or loops.
• Deleting redirects during a clean-up. Links from other sites and bookmarks can point at old URLs for years.
• Redirecting instead of fixing links. An internal link that goes through a 301 works, but each click pays for the extra round trip.

Questions people ask

What does a 301 redirect mean?

A 301 redirect means the page has moved permanently to a new address. The server answers the old URL with status code 301 "Moved Permanently" and the new address in a Location header. Browsers load the new page automatically, and search engines replace the old URL with the new one in their results, passing its links and ranking signals along.

How does a 301 redirect work in the browser and in Google?

The server answers the old URL with a 301 and a Location header instead of a page. The browser then requests the new address, shows it and may cache the redirect for a long time. Googlebot follows it when it recrawls the old URL, up to 10 hops, and treats the permanent redirect as a strong signal to index the new URL in place of the old one.

Are 301 redirects bad for SEO?

No. A 301 to the right page passes the old URL's ranking signals to the new one, and Google recommends permanent redirects for any URL change. Problems come from how they are used: redirects to the home page or other unrelated pages, chains of several hops, loops, and redirects removed too early. Point each old URL at its closest equivalent in one hop.

Do 301 redirects pass all link equity?

Yes, as far as Google has said publicly. Google stated in 2016 that 30x redirects no longer lose PageRank, and it uses a permanent redirect as a strong signal that the target should be the canonical URL. The condition is relevance: a redirect to an unrelated page, such as the home page, may be treated as a soft 404 and pass nothing.

How do I undo a 301 redirect?

Remove or change the rule on the server, then expect a delay. Browsers that followed the 301 may have cached it and keep going to the new URL until their cache is cleared, because a 301 can be cached without an expiry date. Search engines update when they recrawl the old URL and find it answering 200 again. Test first next time with a 302, then switch to 301.

Can I delete old 301 redirects after a while?

Not for at least a year, according to Google's site move guidance, and not while old URLs still receive visits or links. Google's Change of Address help page asks for at least 180 days for domain moves. Keeping a redirect costs almost nothing, while removing it turns every old link and bookmark into a 404, so most sites should keep their redirects permanently.

Is a 308 redirect better than a 301 for SEO?

No, they are equal for search. Google treats 301 and 308 the same way, as a strong signal that the target should replace the old URL. The only difference is for forms and APIs: a 308 keeps the request method, so a POST stays a POST, while browsers may turn it into a GET after a 301. For ordinary pages, use whichever your server or platform sends.