LinkGuard

301 vs 302 redirects

Both send visitors to a new address. The difference is what they promise: 301 says “moved for good”, 302 says “back soon”. Browsers, caches and search engines act on that promise.

The short answer

Use 301 (or 308) when a URL has changed permanently: a new slug, a merged article, http → https, a domain move. Use 302 (or 307) when the original URL will come back: a temporary sale page, A/B testing, maintenance, a geo or login bounce.

Google's documentation says both pass ranking signals, but they choose different canonical URLs: after a 301 Google indexes the destination; after a 302 it keeps indexing the original, at least for a while. A 302 left in place for months is eventually treated like a 301, but you give up control of the timing.

307 and 308

These are the strict twins. A 301 or 302 lets a browser turn a POST into a GET on the next hop (historically, they all did); 307 and 308 must repeat the same method and body. For page moves it makes no difference; for APIs and form endpoints, use 307/308.

Redirect simulator

/spring-sale redirects to /sale. Pick a code, then advance time.

Browser
Caches the redirect and may skip asking the server next time, even if you remove it.
Google indexes
/spring-sale (switching to /sale on next crawl)
Link signals
Passed to /sale (Google: all 30x redirects pass PageRank).
Form POST
Browsers may switch it to GET and drop the body.

Redirect chains and loops

A chain is a redirect that points to another redirect: http:// → https:// → www. → the new slug. Each hop costs a round trip (often 100–300 ms on mobile), and Google's crawler follows at most 10 before giving up. Point every old URL straight at the final one.

A loop is a chain that comes back to where it started. Browsers stop and show “ERR_TOO_MANY_REDIRECTS” (Chrome) or “The page isn't redirecting properly” (Firefox). The usual culprits:

  • the CDN connects to the origin over http while the origin forces https (the classic Cloudflare “Flexible SSL” loop);
  • a www rule on the server fighting a non-www rule in the CMS settings;
  • a trailing-slash rule in the framework undoing a no-slash rule at the host;
  • a login redirect that sends signed-out visitors to a page that itself requires login.

Paste the URL into the URL expander to see every hop and where it repeats, or check a batch in the dead link checker.

Build a loop, then break it

A site behind a CDN. Toggle the two settings and follow the request.

  1. Visitor → CDN: GET https://example.com/
  2. CDN → origin: GET http://example.com/
  3. Origin: 301 → https://example.com/
  4. Visitor → CDN: GET https://example.com/ (same URL again)
  5. CDN → origin over http … 301 … again ×20

ERR_TOO_MANY_REDIRECTS The origin keeps saying “use https”, the CDN keeps asking over http. Fix: set the CDN to Full (strict) SSL, or stop the origin redirect.

Questions people ask

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

301 means the page moved permanently; browsers may cache it and search engines index the new URL. 302 means the move is temporary; search engines keep the original URL indexed and browsers re-check each time.

Do 302 redirects pass link equity?

Yes. Google has confirmed that 30x redirects of either kind pass PageRank. The difference is which URL ends up indexed and shown in results.

Can I undo a 301 redirect?

On the server, yes. But browsers that already followed it may have cached it indefinitely, and those visitors keep being redirected until they clear their cache. Test with a 302 first if you are unsure.

How do I fix ERR_TOO_MANY_REDIRECTS?

Trace the URL to see which two addresses bounce between each other, then find the two rules responsible (commonly CDN vs origin https settings, or www vs non-www). Remove one so every URL reaches a final 200 in one hop.

How many redirects is too many?

Aim for one. Google follows up to 10 hops, but each costs load time and some crawlers and link checkers give up earlier.

Keep going