301 redirects: how to use them effectively and handle edge cases

301 redirects are the most consequential one-line changes in technical SEO, and also the easiest to get quietly wrong. A single misconfigured rule can strand years of accumulated ranking signals, burn crawl budget, or send visitors in circles.

Done well, a 301 tells browsers and search engines that a URL has moved for good, and it carries the old page’s authority to the new one. Done carelessly, it leaks equity through chains, breaks on query strings, or fails silently for the crawlers you never see.

This guide covers how 301s actually work, when to reach for a different code, and how to handle the edge cases that trip up real migrations.

What is a 301 redirect?

A 301 redirect is an HTTP status code that tells a client a URL has moved permanently to a new location, instructing browsers and search engines to use the new URL from now on. When a server responds with 301 Moved Permanently, it includes a Location header pointing to the destination, and the client requests that URL instead.

The “permanent” signal is what makes a 301 different from a temporary redirect. It tells search engines to swap the old URL for the new one in their index, transfer the ranking signals, and stop crawling the original as a live destination.

Browsers cache 301s aggressively, often indefinitely. That is a feature and a trap: returning visitors skip the round trip, but if you set a 301 by mistake, their browser may keep following it long after you fix the server, because it never re-checks.

How a 301 redirect passes link equity

Link equity is the ranking value that flows through links, and a 301 is the standard way to move it from an old URL to a new one. Google has stated that PageRank passes through 301 redirects, and that its systems treat a 301 the same way they treat a 308.

Two caveats matter. First, equity transfer is not instant: Google has to recrawl the old URL, see the redirect, and reassociate the signals, which can take days or weeks. Second, topical relevance affects how much historical signal actually applies. Redirecting a discontinued running-shoe page to your homepage passes far less useful equity than redirecting it to a closely related product, because the destination has to make sense as a replacement.

With the mechanics clear, the next question is which redirect code to use in the first place.

301 vs 302 vs 307 vs 308: which redirect to use

The four common redirect codes differ on two axes: whether the move is permanent or temporary, and whether the original HTTP method is preserved. Getting this pairing right is the single most important redirect decision you make.

• 301 Moved Permanently is the workhorse for permanent URL changes: migrations, HTTPS upgrades, and restructures. Search engines swap the URL and transfer signals.
• 302 Found is a temporary redirect. Search engines keep the original URL indexed because you have told them the move is not permanent. Use it for genuinely short-lived redirects, like a seasonal promo or A/B test.
• 307 Temporary Redirect behaves like a 302 but explicitly preserves the HTTP method. A POST stays a POST. Use it for temporary redirects where the request method and body must survive, such as API endpoints and form submissions.
• 308 Permanent Redirect is the method-preserving version of a 301. Same permanence, but a POST is repeated as a POST rather than potentially downgraded to a GET.

Google has said it treats a 301 like a 308 and a 302 like a 307 for indexing purposes, so from a pure ranking-signal standpoint the permanent codes are interchangeable. The method distinction matters for functionality, not SEO. For everyday content moves you will almost always want a 301.

Code	Permanence	Method preserved	Typically cached	Passes link equity	Use it when
301	Permanent	No (POST may become GET)	Yes, often indefinitely	Yes	A page or site has moved for good
302	Temporary	No (POST may become GET)	No, by default	Original URL keeps ranking	A short-term move; original returns soon
307	Temporary	Yes	No	Original URL keeps ranking	Temporary move where POST/body must survive
308	Permanent	Yes	Yes	Yes	Permanent move where POST/body must survive

The wrong pairing has real costs: a 302 on a permanent move can leave the old URL competing in the index for months, while a method-losing 301 on a form endpoint can silently drop POST data. Once you have picked the code, you need to decide where the redirect runs.

Where redirects run: server, edge, meta refresh, and JavaScript

A redirect can be issued at several layers of the stack, and the layer you choose determines its speed, reliability, and whether non-JavaScript crawlers even see it. The four common options are server-side rules, edge/CDN rules, meta refresh tags, and JavaScript.

Server-side HTTP redirects are the default best practice. The web server (Apache, Nginx) or application returns a real 301 before any page renders, so it is fast, invisible to users, and unambiguous to every crawler. This is where the vast majority of redirects belong.

Edge or CDN redirects issue the same real HTTP status code, but at the CDN layer (Cloudflare, Fastly) before the request reaches your origin. This is increasingly the enterprise default because you can ship redirect rules without a code deploy, which sidesteps platform limits and dev queues. Functionally the crawler still receives a clean 301; the difference is operational.

Meta refresh and JavaScript redirects are last resorts:

• A meta refresh (<meta http-equiv="refresh">) fires in the HTML after the page loads. It is slower than an HTTP redirect, passes equity less reliably, and Google explicitly discourages it.
• A JavaScript redirect (window.location) only works if the client executes JavaScript. Google can render it, but most AI crawlers cannot, so a JS redirect can be completely invisible to them (more on that below).

The rule of thumb: use a server-side or edge 301 whenever you can, and only fall back to meta or JavaScript when you have no access to the server or the routing genuinely depends on client-side state. With the mechanics settled, here is when a 301 is the right tool.

When to use a 301 redirect

Reach for a 301 whenever a URL’s content has permanently moved and you want its accumulated authority to follow. The common scenarios share that permanence.

• Deleting a page that has a replacement. Redirect the old URL to the closest equivalent so its links and rankings are not wasted on a 404.
• Changing a URL slug or path. Renaming /blog/seo-tips-2023 to /blog/seo-tips, or moving /shop/ products to /store/, needs a 301 from every old URL to its new one.
• Migrating to a new domain. A rebrand from oldbrand.com to newbrand.com requires a one-to-one 301 map plus Google’s Change of Address tool.
• Consolidating duplicate or similar pages. Merging three thin articles into one authoritative guide and 301-ing the weaker two concentrates their signals.
• Canonicalizing protocol and host. Forcing HTTP to HTTPS, and www to non-www (or vice versa), so one canonical version serves every request.

The connecting principle is one-to-one relevance: each old URL should point to the single most equivalent new URL, not a generic catch-all. Redirecting 12,000 discontinued product pages to the homepage is technically a redirect but throws away nearly all the equity. Just as important is knowing when a 301 is the wrong answer.

When not to use a 301 redirect

Avoid a 301 when the move is not actually permanent, or when a redirect masks a problem a different fix should solve. Using a permanent redirect for a temporary situation confuses search engines about which URL to index.

• Temporary changes. For maintenance pages, limited promotions, or A/B tests, use a 302 or 307 so the original URL keeps its ranking.
• Genuinely dead content with no equivalent. If a page is gone and nothing replaces it, a 410 Gone (or a 404) is often the honest, correct signal. Do not force an irrelevant 301 just to avoid an error code.
• Redirecting large numbers of unrelated URLs to one page. Bulk redirects to the homepage are frequently treated as soft 404s by Google and pass little value.
• Fixing internal links you could simply update. A redirect is a patch; editing the link to point at the final URL is the real fix.

Choosing correctly here keeps your index clean and your crawl budget focused. When a 301 is right, implementation is straightforward.

How to set up a 301 redirect

Setting up a 301 means configuring your server, CMS, or CDN to return the 301 status with a Location header for the old URL. The exact method depends on your stack.

On Apache, add a rule to .htaccess:

Redirect 301 /old-page /new-page

On Nginx, add a rewrite inside the server block:

location = /old-page { return 301 /new-page; }

On a CMS, use a redirect plugin or the platform’s built-in redirect manager, which writes the rule for you without touching server config. On a CDN, add the rule in the dashboard’s redirect or rules engine.

Whichever method you use, follow the same discipline:

1. Map old URL to new URL one-to-one. Build a spreadsheet of source and destination before touching config.
2. Point at the final canonical URL, not another redirect, to avoid chains.
3. Test each rule before and after deploy. Confirm the status code is actually 301, not 302 or 200.
4. Update internal links, canonicals, and your XML sitemap to reference the new URLs directly.

That last discipline matters because the most common redirect failures are structural, starting with chains and loops.

Redirect chains and loops: the silent tax

A redirect chain is a sequence where one URL redirects to another that redirects again before reaching the final destination, and a loop is a chain that never resolves. Both waste crawl budget and bleed link equity, and both are extremely common after a few years of accumulated URL changes.

Chains stack up innocently: an HTTP-to-HTTPS rule, then a www rule, then an old-slug rule, and suddenly a single request passes through four hops. Each hop adds latency and risk. Analyses of large link graphs suggest chains of three or more hops can lose a meaningful share of the equity a clean single redirect would pass, and Google follows only about five hops per crawl attempt before giving up.

Loops are worse: URL A redirects to B, and B back to A, so no client ever reaches content. Browsers show a “too many redirects” error and crawlers abandon the request entirely.

The fix is to flatten every chain so the original URL points directly to the final destination in one hop. This is exactly the kind of issue that is hard to spot by eye because a chain still “works” for a human clicking through. Server-side traffic analytics that record the real status code per URL make chains visible: Lume’s Status Codes dashboard surfaces redirect chains and cases where crawlers hit a redirect or error, so you can catch multi-hop rules that are quietly taxing your crawl budget. Flattening chains is especially critical during a migration, when hundreds of rules land at once.

Site migrations: mapping and monitoring at scale

A site migration is any large-scale change to your URLs, domain, or platform, and 301 redirects are the mechanism that carries your rankings across the change. The bigger the migration, the more the redirect map is the project.

Say you are moving 12,000 product URLs from /shop/ to /store/ during a replatform. The plan looks like this:

1. Build a complete one-to-one redirect map from every old URL to its precise new equivalent. Crawl the live site first so no URL is missed.
2. Test on staging before launch, checking a large sample for correct status codes, no chains, and no loops.
3. Launch all 301s at once, then update internal links, canonical tags, and the XML sitemap to the new URLs.
4. Submit updated sitemaps in Search Console and Bing Webmaster Tools, and use the Change of Address tool for a domain move.
5. Keep the redirects live for at least a year. Google’s guidance is to leave migration redirects in place for at least a year so all signals fully transfer; for a domain move, keep them as long as reasonably possible.

Monitoring is the step teams skip. After launch you want to know that bots are actually receiving 301s (not 404s or 302s), that no legacy URL slipped through the map, and that crawlers are not hitting chains. Lume’s Pages report shows the real status code each URL returns, including 3xx, so you can verify redirects behave the same for bots as for humans and spot any old URL still throwing an error. Even a well-mapped migration will surface edge cases, and those are where redirects most often break.

Edge cases that break redirects

Most redirect failures live in the details: the query string, the protocol, the crawler that cannot run JavaScript. These are the cases worth handling explicitly.

Query strings and parameters. A rule that redirects /old-page may drop everything after the ?, stranding /old-page?utm_source=email or losing pagination and filter parameters. Decide deliberately whether to preserve, rewrite, or strip query strings, and test URLs that carry them. On Apache and Nginx this often means using rewrite rules with the query string appended rather than a bare Redirect.

HTTPS and www canonicalization. You want exactly one canonical host and protocol. The trap is stacking the HTTPS rule and the www rule so http://www. takes two hops to reach https:// non-www. Combine them into a single rule that jumps straight to the canonical version in one redirect.

Redirecting 404s. When you find old inbound links pointing at dead URLs, a 301 to the most relevant live page recovers that equity, but only if the destination is genuinely equivalent. If nothing fits, leave a clean 404 or 410 rather than dumping the link on the homepage, which Google may treat as a soft 404.

Hreflang and international. On multilingual sites, a redirect must respect the user’s and crawler’s language and region. Redirecting every visitor to a single geo-detected version can break hreflang and hide localized URLs from search engines. Keep language variants individually crawlable and reserve geo-redirects for cases where you have handled the hreflang implications.

AI crawlers and JavaScript. AI crawlers such as GPTBot, ClaudeBot, and PerplexityBot follow 301, 302, 307, and 308 status codes, but they operate under tighter constraints than Googlebot, so every extra hop raises the chance they abandon the request before reaching your content. Critically, most of them do not execute JavaScript, so a JS-based redirect that works fine for humans is invisible to them: the bot receives the shell and never reaches the destination. They may also blur the temporary-versus-permanent distinction, treating a 302 target as canonical. The safe move for anything you want AI systems to read is a single-hop, server-side 301.

Handling these cases up front is far cheaper than diagnosing them after rankings dip. The FAQs below cover the questions that come up most often.

Frequently asked questions

Do 301 redirects lose link equity?

Modern Google guidance is that a single, well-implemented 301 passes PageRank with negligible loss, and Google treats a 301 like a 308 for indexing. The real leakage comes from redirect chains and from redirecting to an irrelevant destination. Keep redirects to one hop and point at a genuinely equivalent page to preserve the most value.

How long should I keep a 301 redirect in place?

For a page move, keep it live for at least a year so search engines fully transfer the old URL’s signals to the new one; after that the transfer generally persists even if you remove the rule. For a full domain migration, keep the redirects for as long as reasonably possible, since inbound links to the old domain can persist for years.

What is the difference between a 301 and a 308 redirect?

Both are permanent redirects that pass ranking signals, and Google treats them the same for indexing. The difference is method preservation: a 301 may convert a POST into a GET, while a 308 repeats the exact request method and body. Use a 308 when the redirected request must stay a POST, such as an API or form endpoint; use a 301 for ordinary content moves.

Will a redirect chain hurt my SEO?

Yes, in two ways. Each additional hop bleeds a share of link equity and adds latency, and Google follows only around five hops before giving up, so a long chain can prevent indexing of the final URL entirely. AI crawlers are even less patient. Flatten every chain so the source URL redirects directly to the final destination.

How do I check that my redirects are working correctly?

Verify that each old URL returns an actual 301 status with the correct Location, not a 302, a 200, or a 404. You can spot-check individual URLs with browser dev tools or a header-checking utility, but at scale you want per-URL status-code reporting that includes bot traffic, so you can confirm crawlers receive the same redirect humans do and catch chains, loops, and stray errors across the whole site.