TheMadScientist - 1:46 am on Nov 9, 2012 (gmt 0)

Since the 302 bug of years ago, the handling of 302 redirects by Google is not strictly by protocol, which isn't cool for protocol freaks, but is for those on the receiving end of 302 redirects, because they're treated much closer to 301 'permanent' redirects than they were 'back in the day'.

I wouldn't rely on the tools to tell you how search engines will handle them, because the tools give you the status code and associated text according to protocol, not how search engines will handle the redirects.

Obviously, 301s would be ideal, but if they are not changed on the sending side, I would just canonicalize to whatever version of the domain they are sending the redirects to. If they are sending them to both www and non-www, then I would pick the version of the domain with the most inbound links and canonicalize to that one. So, if non-www has 50 inbound links and www only has 10 I would redirect www to non-www in an effort to lose the least link weight through the double redirect.

I'm not 100% sure on Google's transferring of weight these days, but I'm fairly sure it passes via 302 redirect, and I'm almost positive when Yahoo! did their own search they said they treat 302s as if they are 301s even though that's not protocol, and Google also has a delay before they trust 301s (something like 3 weeks if I remember correctly), and ... blah ... lol

The bottom line is: Go dig around and see what the search engines say, because I'm fairly certain you'll find they do not follow protocol WRT handling redirect status codes, because it opens the door for too many issues, and I don't feel like digging through history right now to find a source, but I do remember reading (hearing in a video? idk somewhere along the way) Google treats 302s almost exactly the same as 301s these days since 302s, being the default status when a status code is not specified, are so prevalent and handling them correctly according to protocol caused huge issues for hijacking in the past.