[OT] URL redirection

[Unknown W. Brackets]

1. Yes.  In both cases, they failed.  Biz is tacky, and 307 is poorly 
supported.  Oh, well...

2. A page can have "page rank" in Google's eyes.  If a popular page 
(let's say www.amazon.com's front page) linked to your page, it would 
greatly increase that page's page rank.

However, if someone links to a page that is a redirection, Google has 
two options:
	A. If the status code is a "302" or similar, the existing page gets the 
increase in page rank.  The actual destination page (which is indexed) 
has its own separate page rank.

	B. If the status code is a "301", the existing page gets nothing, and 
the destination gets all the glory.

It's better to have 1 page with a really high page rank, than 10 pages 
with low page rank.  As such, 301's are best when the redirect is, well, 
permanent... where the resulting page is really the desired one.

2b. Really?  That's crazy.  Google shouldn't cache that.  I meant 
browsers and proxies.  It's wrong to cache the result of the 301, just 
the fact that it redirects (the 301 itself.)

3. Well, Refresh uses a parameter, like this: "0; 
http://www.google.com/".  The "0" in this case is the number of seconds 
after the entire page has loaded (in most browsers, after the load event 
has been posted.)  On the other hand, a 301/Location combination happens 
as soon as the browser finishes reading the headers.

3b. There is a correct syntax.  In my experience, I have seen people use 
the incorrect syntax.  It's the age-old problem of IE (most of the time) 
accepting invalid code that shouldn't and doesn't work elsewhere.

5. Yeah, that's basically my point.  I've also been told (THIS IS A 
RUMOR) that Google penalizes you for JavaScript redirects.  Seems silly 
(esp. if you used a 301 on the same page) but everything in SEO is 
experience, guesswork, and rumor.

Also, take a look at Minefield.  It blocks many "automatic redirects" by 
default.  I've had it break many sites (although you can allow the 
redirect easily), actually.  I think it blocks both js and meta redrects 
not resulting from a POST or user click/etc.

-[Unknown]


Stewart Gordon wrote:
> "Unknown W. Brackets" <unknown at simplemachines.org> wrote in message 
> news:fu97a9$1lgv$1 at digitalmars.com...
>> You're pretty much right in everything you've said... but some 
>> clarifying points:
>>
>> 1. See the spec <http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html>.
>>
>> Here the important status codes are "302", "303" and "307". 
>> Essentially, 307 is 302... created because almost every client and 
>> server treats 302 as if it were 303.  You pretty much have to.
> 
> So effectively, the 307 code was created to supersede 302 because many 
> UAs were mishandling 302 as 303.  A bit like the way the .biz TLD was 
> created to attempt to sort the men from the boys (misusers of .com for 
> vanity sites and the like).
> 
>> 2. 301 is sometimes overused, because it will carry Google page rank 
>> while other 3xx codes will not.
> 
> What do you mean by "carry Google page rank"?
> 
>> 301 is also normally cached, unlike the others which normally aren't 
>> (even if cache headers say to, most clients and proxies ignore them.)
> 
> So that explains something.  In the days when I used a URL redirection 
> provider for my personal website, I would sometimes find Google 
> expanding my redirecting URL to its own cache of the redirect's 
> destination.  It just shows one of the problems with redirectors using 
> the wrong status code.
> 
>> 3. Refresh using <meta /> is essentially the worst case.  It provides 
>> a worse experience for the user (Refresh cannot happen until the 
>> source page finishes loading)
> 
> How do you work that out?
> 
> , it relies on HTML (so obviously cannot work for
>> images, RSS feeds and other content delivered over HTTP), there are 
>> syntaxes of <meta http-equiv="Refresh" /> which are not supported by 
>> all clients, etc., etc.
> 
> What are these syntaxes?  Are they ever necessary for such simple 
> redirection?
> 
>> 4. Note that the <meta http-requiv="" /> element/attribute pair exists 
>> to emulate an HTTP header in HTML.  Technically, one could send a 
>> Refresh header over HTTP (which would be ignored by many clients mind 
>> you) but no one would ever do that...
>>
>> 5. Your example is probably overdoing it.  If someone has a client 
>> that doesn't support/allow you to Refresh, it's unlikely JavaScript 
>> will do you any better.  It's probably a waste of bandwidth.  And, 
>> clearly, 301 is better in every case for this specific example...
> <snip top of upside-down reply>
> 
> That's half the reason I said "provide a means of disabling it".  I'm 
> not sure I've ever seen a client that doesn't support meta refresh at 
> all. Before I took over that website and undertook to clean it up, the 
> root URL was redirected using only JS, and anybody who has JS disabled 
> would just see a blank page.
> 
> But that said, if the user has disabled meta refresh, should I really 
> use JS to bypass it?  CTTAI if they hate meta refresh enough to want to 
> disable it, I guess they'd equally hate JS doing the same....
> 
> Stewart.