www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Reorg of D site

reply Walter Bright <newshound1 digitalmars.com> writes:
As some of you may have noticed, the D 2.0 stuff has all moved into 
digitalmars.com/d/2.0, instead of digitalmars.com/d. The original files 
have been replaced with redirects (phew, that was a lot of tedious work).

The benefit of this is that the searches are now targeted instead of 
picking up the whole digitalmars site. (It took about 24 hours for 
google to reindex the site.)
Jan 22 2008
next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Walter,

Again I just want to mention that Google assigns a number ("pagerank") 
to every page it indexes.  When a page is linked to by a reputable 
source, the number increases.

META Refresh redirects will get this page rank, but are useless, and 
will be badly indexed for phrases.  Also, people will not continue to 
link to these meta refresh pages.

So, you're splitting potential page rank (something you want to 
maximize) in pieces by using that sort of redirect.  If at all possible, 
I strongly suggest using a 301 redirect (which is a "permanent" redirect 
and tells Google to give the page rank to the resultant page.)

If you want, I can provide further documentation on this phenomenon from 
google.com.

That said, I'm glad to see this reorganization, and I'm sure it will 
help people searching the site.

-[Unknown]


Walter Bright wrote:
 As some of you may have noticed, the D 2.0 stuff has all moved into 
 digitalmars.com/d/2.0, instead of digitalmars.com/d. The original files 
 have been replaced with redirects (phew, that was a lot of tedious work).
 
 The benefit of this is that the searches are now targeted instead of 
 picking up the whole digitalmars site. (It took about 24 hours for 
 google to reindex the site.)

Jan 22 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Unknown W. Brackets wrote:
 Walter,
 
 Again I just want to mention that Google assigns a number ("pagerank") 
 to every page it indexes.  When a page is linked to by a reputable 
 source, the number increases.
 
 META Refresh redirects will get this page rank, but are useless, and 
 will be badly indexed for phrases.  Also, people will not continue to 
 link to these meta refresh pages.
 
 So, you're splitting potential page rank (something you want to 
 maximize) in pieces by using that sort of redirect.  If at all possible, 
 I strongly suggest using a 301 redirect (which is a "permanent" redirect 
 and tells Google to give the page rank to the resultant page.)
 
 If you want, I can provide further documentation on this phenomenon from 
 google.com.

Ok, sure! I didn't know this.
Jan 23 2008
next sibling parent "dominik" <aha aha.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:fn6v2q$1doq$1 digitalmars.com...
 Ok, sure! I didn't know this.

google will skip meta refreshes.. but you can build a sitemap, that would help ALOT - http://www.sitemaps.org/
Jan 23 2008
prev sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
Search for 301:

http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=34444
http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=79812
http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=66359

There's not as much directly from Google but you can find a lot on other 
sites just searching, e.g.:

http://www.seobook.com/archives/000297.shtml
http://www.bigoakinc.com/blog/when-to-use-a-301-vs-302-redirect/

That said, mileage will very in that kind of search, because most of 
people's knowledge about search engines is guided by guesswork and 
extrapolations from experience.  I used to have a link on Google's 
support that explained pagerank but can't find it now.

-[Unknown]


Walter Bright wrote:
 Ok, sure! I didn't know this.

Jan 23 2008
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Unknown W. Brackets Wrote:
 So, you're splitting potential page rank (something you want to 
 maximize) in pieces by using that sort of redirect.  If at all possible, 
 I strongly suggest using a 301 redirect (which is a "permanent" redirect 
 and tells Google to give the page rank to the resultant page.)

Will this also make browsers update the URL in the location bar? I don't like how (currently) typing in a url without /2.0/ or /1.0/ does not end up showing which page you ended up at
 
 If you want, I can provide further documentation on this phenomenon from 
 google.com.
 
 That said, I'm glad to see this reorganization, and I'm sure it will 
 help people searching the site.
 
 -[Unknown]
 
 
 Walter Bright wrote:
 As some of you may have noticed, the D 2.0 stuff has all moved into 
 digitalmars.com/d/2.0, instead of digitalmars.com/d. The original files 
 have been replaced with redirects (phew, that was a lot of tedious work).
 
 The benefit of this is that the searches are now targeted instead of 
 picking up the whole digitalmars site. (It took about 24 hours for 
 google to reindex the site.)


Jan 23 2008
parent reply Unknown W. Brackets <unknown simplemachines.org> writes:
Yes, a 301 should work like that (as would 302.)

-[Unknown]


Jason House Wrote:

 Unknown W. Brackets Wrote:
 So, you're splitting potential page rank (something you want to 
 maximize) in pieces by using that sort of redirect.  If at all possible, 
 I strongly suggest using a 301 redirect (which is a "permanent" redirect 
 and tells Google to give the page rank to the resultant page.)

Will this also make browsers update the URL in the location bar? I don't like how (currently) typing in a url without /2.0/ or /1.0/ does not end up showing which page you ended up at
 
 If you want, I can provide further documentation on this phenomenon from 
 google.com.
 
 That said, I'm glad to see this reorganization, and I'm sure it will 
 help people searching the site.
 
 -[Unknown]
 
 
 Walter Bright wrote:
 As some of you may have noticed, the D 2.0 stuff has all moved into 
 digitalmars.com/d/2.0, instead of digitalmars.com/d. The original files 
 have been replaced with redirects (phew, that was a lot of tedious work).
 
 The benefit of this is that the searches are now targeted instead of 
 picking up the whole digitalmars site. (It took about 24 hours for 
 google to reindex the site.)



Jan 23 2008
parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Unknown W. Brackets" <unknown simplemachines.org> wrote in message 
news:fn891s$1ncq$1 digitalmars.com...
 Yes, a 301 should work like that (as would 302.)

<snip top of upside-down reply> Yes, HTTP redirection using a status code in the 300s is the best way. But you should use the right code! In this instance, the correct code would indeed be 301 (moved permanently). 302 (found) would probably be the right one for redirecting the advertised URL of a site to the URL where it's actually hosted, but it seems a number of redirection providers wrongly use 301. (That said, I can't seem to make out by a quick read the difference between 302 and 307.) The trouble is that, depending on the hosting provider and server software, one may or may not have the means of setting up HTTP redirection. Meta refresh thus provides an alternative means. However, one should not use _only_ meta refresh! Some browsers provide a means of disabling it. This is yet another reason (besides search engines) that you should always have a plain HTML link as a fallback. view-source:http://www.lrca.org.uk/ or, if this doesn't work for you http://validator.w3.org/check?uri=http://www.lrca.org.uk/&ss=1 demonstrates a three-level approach to redirection: meta refresh, JavaScript and finally a link on the page. Stewart. -- My e-mail address is valid but not my primary mailbox. Please keep replies on the 'group where everybody may benefit.
Apr 17 2008
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
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.

2. 301 is sometimes overused, because it will carry Google page rank 
while other 3xx codes will not.  301 is also normally cached, unlike the 
others which normally aren't (even if cache headers say to, most clients 
  and proxies ignore them.)

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), 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.

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

-[Unknown]


Stewart Gordon wrote:
 "Unknown W. Brackets" <unknown simplemachines.org> wrote in message 
 news:fn891s$1ncq$1 digitalmars.com...
 Yes, a 301 should work like that (as would 302.)

<snip top of upside-down reply> Yes, HTTP redirection using a status code in the 300s is the best way. But you should use the right code! In this instance, the correct code would indeed be 301 (moved permanently). 302 (found) would probably be the right one for redirecting the advertised URL of a site to the URL where it's actually hosted, but it seems a number of redirection providers wrongly use 301. (That said, I can't seem to make out by a quick read the difference between 302 and 307.) The trouble is that, depending on the hosting provider and server software, one may or may not have the means of setting up HTTP redirection. Meta refresh thus provides an alternative means. However, one should not use _only_ meta refresh! Some browsers provide a means of disabling it. This is yet another reason (besides search engines) that you should always have a plain HTML link as a fallback. view-source:http://www.lrca.org.uk/ or, if this doesn't work for you http://validator.w3.org/check?uri=http://www.lrca.org.uk/&ss=1 demonstrates a three-level approach to redirection: meta refresh, JavaScript and finally a link on the page. Stewart.

Apr 17 2008
parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Unknown W. Brackets" <unknown simplemachines.org> wrote in message 
news:fu97a9$1lgv$1 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...

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.
Apr 18 2008
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
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 simplemachines.org> wrote in message 
 news:fu97a9$1lgv$1 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...

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.

Apr 18 2008
parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
I should note, I'm not actually entirely sure this is true in every 
browser.  In fact, it's been so long since I even used meta refreshes 
that this may not be true in any browsers anymore...

But obviously the browser has to parse the entire entity body and HTML 
(and usually render it) before redirecting.  This is because with a 
refresh (unlike a redirect) the entity body is understood to be a 
message about why they are being redirected.

The most correct place to use a refresh these days is in front of a 
search results page which is slow.  The refresh would be put on a page 
that says "your results are being loaded."  Even so, that's unpopular 
these days.

-[Unknown]


Unknown W. Brackets wrote:
 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.

Apr 18 2008
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 22 de enero a las 20:33 me escribiste:
 As some of you may have noticed, the D 2.0 stuff has all moved into
digitalmars.com/d/2.0, instead of digitalmars.com/d. The original files have
been replaced 
 with redirects (phew, that was a lot of tedious work).
 
 The benefit of this is that the searches are now targeted instead of picking
up the whole digitalmars site. (It took about 24 hours for google to reindex
the 
 site.)

Thanks. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- 3 people die every year, testing if a 9 volts battery works on their tongue
Jan 23 2008
prev sibling next sibling parent reply Alexander Panek <alexander.panek brainsware.org> writes:
On Tue, 22 Jan 2008 20:33:22 -0800
Walter Bright <newshound1 digitalmars.com> wrote:

 As some of you may have noticed, the D 2.0 stuff has all moved into 
 digitalmars.com/d/2.0, instead of digitalmars.com/d. The original
 files have been replaced with redirects (phew, that was a lot of
 tedious work).

First an foremost: why didn't you put 1.0 showing up as default on digitalmars.com/d ? I still don't see a point in presenting an instable and experimental branch on the front page. With Konqueror, on the specification part of the site, there seems to be something wrong with the encoding. Additionally, there's a minor margin/width difference of the menu between the start page and the specification.
 The benefit of this is that the searches are now targeted instead of 
 picking up the whole digitalmars site. (It took about 24 hours for 
 google to reindex the site.)

May I suggest using some sort of content management system? Working 24 hours on a rather small task like that sounds kind of wrong. -- Alexander Panek <alexander.panek brainsware.org>
Jan 25 2008
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Alexander Panek wrote:
 On Tue, 22 Jan 2008 20:33:22 -0800
 Walter Bright <newshound1 digitalmars.com> wrote:
 
 As some of you may have noticed, the D 2.0 stuff has all moved into 
 digitalmars.com/d/2.0, instead of digitalmars.com/d. The original
 files have been replaced with redirects (phew, that was a lot of
 tedious work).

First an foremost: why didn't you put 1.0 showing up as default on digitalmars.com/d ? I still don't see a point in presenting an instable and experimental branch on the front page. With Konqueror, on the specification part of the site, there seems to be something wrong with the encoding. Additionally, there's a minor margin/width difference of the menu between the start page and the specification.
 The benefit of this is that the searches are now targeted instead of 
 picking up the whole digitalmars site. (It took about 24 hours for 
 google to reindex the site.)

May I suggest using some sort of content management system? Working 24 hours on a rather small task like that sounds kind of wrong.

Google worked on it for 24 hrs, not Walter. --bb
Jan 25 2008
prev sibling next sibling parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Alexander Panek wrote:
 First an foremost: why didn't you put 1.0 showing up as default on
 digitalmars.com/d ? I still don't see a point in presenting an instable
 and experimental branch on the front page.

agreed; -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Jan 25 2008
parent Peter Modzelewski <peter.modzelewski gmail.com> writes:
Tom S wrote:
 Alexander Panek wrote:
 First an foremost: why didn't you put 1.0 showing up as default on
 digitalmars.com/d ? I still don't see a point in presenting an instable
 and experimental branch on the front page.

agreed;

agreed ;) there is too much confusion among newcomers.
Jan 25 2008
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Alexander Panek wrote:
 On Tue, 22 Jan 2008 20:33:22 -0800
 Walter Bright <newshound1 digitalmars.com> wrote:
 
 As some of you may have noticed, the D 2.0 stuff has all moved into 
 digitalmars.com/d/2.0, instead of digitalmars.com/d. The original
 files have been replaced with redirects (phew, that was a lot of
 tedious work).

First an foremost: why didn't you put 1.0 showing up as default on digitalmars.com/d ? I still don't see a point in presenting an instable and experimental branch on the front page.

Or at least put 1.0 and 2.0 links side by side, with a note saying that 1.0 is stable and 2.0 is under active development.
Jan 25 2008
prev sibling parent Alexander Panek <alexander.panek brainsware.org> writes:
On Fri, 25 Jan 2008 21:35:18 +0900
Bill Baxter <dnewsgroup billbaxter.com> wrote:

 Alexander Panek wrote:
 On Tue, 22 Jan 2008 20:33:22 -0800
 Walter Bright <newshound1 digitalmars.com> wrote:
 The benefit of this is that the searches are now targeted instead
 of picking up the whole digitalmars site. (It took about 24 hours
 for google to reindex the site.)

May I suggest using some sort of content management system? Working 24 hours on a rather small task like that sounds kind of wrong.

Google worked on it for 24 hrs, not Walter.

Yes. I've figured that right after posting it. :\ -- Alexander Panek <alexander.panek brainsware.org>
Jan 25 2008