Number of redirect steps in website migration

[optimierung]

The owner of the old site is only doing 302-redirects (strange but irrevocable) in form of http://example.tld...... so we have the chance to non-www 301-redirect to www.

So bad so far: What kind of disadvantages (except the unnecessary redirect) there will be for us e.g. G* and link reputation transfer, etc.

Any help will be much appreciated.

Thank you.

[edited by: tedster at 2:20 pm (utc) on Oct 17, 2012]
[edit reason] defeat the auto-linking [/edit]

[tedster]

Here's what we heard from Matt Cutts last year. Each redirect step means any link equity loses about 10% to 15% of its power. If you chain too many redirects together, that can really add up! Also somewhere in the area of about 5 redirects, googlebot may just stop following them.

Given that, you can make a judgment call about how best to apply your resources. I'd say convincing the "powers that be" to go to a 301 redirect is clearly the ideal, but I gather you already know this.

[g1smd]

request for the old site (both www and non-www?) --302-> example.com --301-> www.example.com

Looks like a disaster.

[lucy24]

So you've got a choice between duplicate content (www.example.com and example.com) and a multiple-link chain?

If someone had a few spare domains lying around, that could be a darn useful experiment. But not if it's anyone's livelihood at stake.

Does the original 302 redirect keep the existing www configuration (with or without) or does it all go to the same format? It's less disastrous if any one request goes

EITHER (old name, any format)
(www.)?example.org >> 302 >> www.example.com

OR (new name, wrong format)
example.com >> 301 >> www.example.com

If all the 302 redirects point to the same form of the domain name, you'll have to stick with that form even if you don't like it.

[optimierung]

@tedster: thanks for the comment of MC which sounds quite reasonable

@g1smd & lucy24: the source website is a very large one, still in operation, the new website was earlier implemented as a directory, nobody feels fully responsible, therefore this website is in a chaotic status, a mixture of www and non-www urls, sometimes canonicalized, a lot of 404s, special CMS....

I only know definitively that they will use 302 redirects because of their strange understanding of "302 = temporary move" (I hope they will not mix the target url format!).

Therefore I have the choice between pest and cholera.

I would prefer the choice of the one additional redirect because DC seems to me to have more disadvantages. What do you think?

[phranque]

the site owner is providing the strongest signal so he needs to get it right.
a 302 status code response does not actually mean "moved" - it means Found:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3

therefore google will index the originally requested url using the content from the Location: header url.
all of the link equity will go the the original url.

[optimierung]

@phranque

Thank you for your comment. We are working hard to convince the site owner to send the right signal but we are not sure to be successful because it is a chaotic company.

[g1smd]

They either sort this out or Google will eventually flag the site for "low technical quality".

[optimierung]

@phranque

302 Found or 302 Moved Temporarily
Checking websites with a spider tool we see (for the same website, for different urls) the status code 302 with FOUND resp. MOVED TEMPORARILY
Checking these urls with another tool we get the identical status messages:

302 Redirecting to the same host: Status MOVED TEMPORARILY
302 Redirecting to another host: Status FOUND

Are the search engines using the same convention?

Thank you

[g1smd]

The words are immaterial. It's the status code number that is important.

The server could return

"302 the sky is blue"

and it would make no difference whatsoever.

[phranque]

the text doesn't matter as much as the status code.
the search engines don't care what it says.
technically "Found" is the correct meaning, but "Moved Temporarily" a better description of the effect.

HTTP/1.1: Status Code Definitions - 302 Found:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3

[vincevincevince]

Yes; convince them to use the right status code. On the http://X formats, if most lack the www. then standardize the site for canonical use without any www.
.

[edited by: Robert_Charlton at 7:43 am (utc) on Nov 9, 2012]
[edit reason] delinked sample url [/edit]

[optimierung]

Thank you for your answers!

#1 we know:
the results are dependant from the client (the programmers of the user agent)

#2 we read:
302 found is http 1.1 and moved temporarily is http 1.0

#3 we test: using Webbug
#A URLA: HTTP/1.1 302 Moved Temporarily > the same url > we receive HTTP/1.1 404 Not Found (clicking HTTP 1.0)
#B URLB: HTTP/1.1 302 Found > the same url > we receive HTTP/1.1 302 Found (clicking HTTP 1.0)

#4 we are confused especially for the case #3#A 404 Not Found

[smithaa02]

Tedster, any chance you post a link referencing where Cutts says you lose 10-15% per redirect?

[tedster]

The original comment was in an interview by Eric Enge - [webmasterworld.com...]

Eric Enge: Let's say you move from one domain to another... is there some loss in PageRank that can take place simply because the user who originally implemented a link to the site didn't link to it on the new domain?

Matt Cutts: I am not 100 percent sure whether the crawling and indexing team has implemented that sort of natural PageRank decay, so I will have to go and check on that specific case. (Note: in a follow on email, Matt confirmed that this is in fact the case. There is some loss of PR through a 301). [my emphasis]

[stonetemple.com...]

As I remember, the 10% to 15% number came in a video that was published slightly later. Because video content is hard to research I haven't come up with that one so far - will post it if I can find it.

[phranque]

302 found is http 1.1 and moved temporarily is http 1.0

that's interesting!
i never noticed before.

302 Moved Temporarily:
http://www.w3.org/Protocols/HTTP/1.0/spec.html#Code302

#3 we test: using Webbug
#A URLA: HTTP/1.1 302 Moved Temporarily > the same url > we receive HTTP/1.1 404 Not Found (clicking HTTP 1.0)
#B URLB: HTTP/1.1 302 Found > the same url > we receive HTTP/1.1 302 Found (clicking HTTP 1.0)

are URLA and URLB on the same server?
is "the same url" on the same hostname/subdomain?

[g1smd]

302 Found is HTTP/1.1 and 302 Moved Temporarily is HTTP/1.0

I knew that :) but had long ago forgotten it. :(

[lucy24]

#2 we read: <snip>

#3 we test: <snip>

#4 we are confused

How I wish we could stop right there :)

http://www.w3.org/Protocols/HTTP/1.0/spec.html#Code302
vs.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3

I kinda suspect that in real life it has less to do with the formal protocols and more to do with elapsed time (1996 vs. 1999 vs. 2012).

[optimierung]

@tedster thank you for the original comment

# Sure the subject is a little bit formal and of academic interest.

# But we trust on the results of tools, e. g. Webbug, so let me repeat one test result:

- URLA: Result > HTTP/1.1 302 Moved Temporarily (Webbug clicking HTTP 1.1)
- URLA: (the same url) Result > HTTP/1.1 404 Not Found (Webbug clicking HTTP 1.0)

The result is crazy: 404 Not found

[phranque]

perhaps something is looking for HTTP_HOST which isn"t supplied by HTTP/1.0 and responds with 404 when it's missing

[moxie]

This all makes me wonder if link equity loses power when it comes to a mobile redirect.

[TheMadScientist]

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.

[tedster]

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'.

Absolutely - and a very important observation for many areas of Google before anyone spends significant resources fixing a "problem" which is merely academic today and not really affecting search traffic.

I've recently looked at a couple sites where hundreds of thousands of CMS driven redirects were 302 that "should have been" 301. By strict rules, these sites should have created all kinds of trouble within Google, but Google compensated for the CMS mis-configuration and the sites are not having troubles because of their poor status code choice.

[Robert Charlton]

No one's mentioned site speed. Going back to the question in the title regarding the number of redirect steps, I'm thinking that the chaotic setup described could also slow down a site quite a bit.

[optimierung]

@TheMadScientist, tedster: thank you for your very interesting comments

1. We have to use any kind of tool to see what kind of redirection(s) is going on, independent of the handling of the search engines. Our result 404 Not found is strange! Is it the same for SEs?

2. All about 301 or 302: In our case of the 302's we see the duplicate content! This is not academic! Or I am totally wrong reading SE guidelines?

[TheMadScientist]

The biggest technical difference, even according to protocol, between 301s and 302s is where the page is initially requested from.

A user agent should continue to request a 302 initially from the original source since the redirect is 'temporary' or 'undefined' (or insert another word of your choice for 'not permanent') and then follow the redirect if it's still present.

A 301 should be requested from the new source initially by user agents since the redirect is permanent. (<-- Google does not necessarily do this ... If they did, they would never know if a redirect has been removed or changed to a different location, so they don't even handle 301s according to strict protocol, but the people who 'tout protocol' as the 'be all end all' conveniently 'forget' to tell you that part for some reason.)

Since the 302 'bug' years ago, the handling (transfer of link weight, age, other associated data) to the best of my knowledge is very similar to a 301 (actually, afaik, it's exactly the same over time, but there's so many hair splitters here I don't want to say that directly, because I don't feel like arguing with them any more than I have to already, so I always 'qualify' my statement about the handling to appease them.)

I would guess you will see a longer 'lag' between the redirect being discovered and 'full trust' with the receiving URL replacing the redirected URL in the results using a 302, but eventually it will, and I would suspect what you are seeing as 'duplicate content' in the results is where the URL receiving the redirect (meaning yours) has already replaced the URL being redirected.

Even with a 301 there's an up to 3 week 'lag' in the redirect being fully trusted and URLs for differing results are not always replaced at the same time. I've had some cases where a 301 is used and a search for 'blue widgets' will show the URL I've redirected, but a search for 'widgets that are blue' will show the new URL. That's not 'duplicate content' it's simply that the change hasn't made it all the way through the system yet.

As far as tools go, ignore the HTTP/1.0 headers and go with HTTP/1.1. GBot (and all modern browsers) is an HTTP/1.1 bot and as noted earlier in this thread, HTTP/1.0 headers sent to the server are not the same as HTTP/1.1, so it could be either the server settings on the redirecting end or the server on your end or the antique request method (HTTP/1.0) that's beyond obsolete not being updated in the tool you're using since no one uses it these days.

The 'short version' of checking is:
If your browser is redirected, so is GoogleBot. If you want to know the exact status code of the redirect, just use the header check in the control panel here or something like FireFox live headers if you want to make sure there's not a chain. They're both reliable and nothing else is needed.

[edited by: TheMadScientist at 5:37 pm (utc) on Nov 11, 2012]

[TheMadScientist]

I should also note:

If you're seeing both URLs in the results for the same query, just wait ... As the redirect develops 'more trust' it will begin to change over time and since visitors who click on either will end up on the same page (yours) I definitely wouldn't complain about the double listing, because you get twice as many chance at clicks, which makes it a bit unfortunate for you they will eventually figure it out and only list one URL if this is why you're thinking there's duplicate content.