Here's the old discussion...
Avoid meta-refresh and JS redirects - Google's JohnMu http://www.webmasterworld.com/google/4160708.htm [webmasterworld.com]
Looking at meta refresh redirects another way... I'm thinking that desired behavior with meta refresh, if it could be implemented, would be...
a) when you are unable to do a real 301, to let visitors know that there's been an address change, and also to pass linking credit from the old url to the new. This suggests it would be desirable to have a longer refresh act as a 301.
b) on shorter redirects, it would be desirable to eliminate the effectiveness of, say, keyword-heavy doorway pages (this is one of the reasons that meta-refresh pages had once been penalized).
c) on shorter redirects, it would also be desirable to prevent cross-domain hijacking.
From the reported tests, it sounds like the long refresh does act, at least in part, as a 301. Was any transfer of anchor text credit observed with the long meta refresh? I'm assuming that since the inbound anchor text would be interacting with the text on the target page, not the pointer page, this might be something that's hard to test and evaluate (at least in one pass, if it's practical to test at all).
The 302 means that the target's content is attributed to the pointer url i.e. url A has 'hijacked' url B's content.
Attributing the target content to the pointer url would accomplish (b)... ie, eliminate the effect of keywords on the url A pointer page.
From the test report, I'm not sure where "hijacking" stands now. I'd thought that Google and Yahoo, at least, had solved it, but now I'm not sure. Hijacking usually only happened when there were big inequalities in PageRank between the pointer and target page... but I thought the engines had fixed it even in that situation.
