Multiviews und Suchmaschinen

[Cyx23]

Hallo,

wenn z.B. per Options +Multiviews die Möglichkeit besteht verschiedene Dateien unter der gleichen URI auszuliefern geschieht das ja nicht immer ganz transparent. Falls so eine html-Variante und eine gz(ip) angeboten werden, wird doch vmtl. im Falle von .gz der Client vom Server "gefragt", und ggf. dem IE die html geliefert. Wie sieht das z.B. für Googlebot aus?

Grüsse

Cyx23

[Cheatah]

Hi,

Wie sieht das z.B. für Googlebot aus?

der Googlebot ist ebenso Client wie der IE. Er bekommt vom Server nichts anderes.

Cheatah

[Michael Schröpl]

Hi Cyx23,

wenn z.B. per Options +Multiviews die Möglichkeit besteht verschiedene Dateien unter der gleichen URI auszuliefern geschieht das ja nicht immer ganz transparent. Falls so eine html-Variante und eine gz(ip) angeboten werden, wird doch vmtl. im Falle von .gz der Client vom Server "gefragt", und ggf. dem IE die html geliefert. Wie sieht das z.B. für Googlebot aus?

das kommt darauf an, welche Rahmenbedingungen der Googlebot als Grundlage der Verhandlung mitliefert.

Sendet er beispielsweise den HTTP-Header "Accept-Encoding: gzip", dann erklärt er sich damit bereit, gzip-komprimierte Daten zu empfangen (und zu dekomprimieren).
Die serverseitige Verhandlung sollte also genau vom Vorliegen dieses Headers abhängen (was sie etwa bei mod_gzip, mod_deflate bzw. gzip_cnc auch tut).

Tut er das nicht (was der aktuelle Stand zu sein scheint - ich habe es Google vor knapp einem Jahr vorgeschlagen, als ich mal einen ihrer Entwickler "an der Leitung hatte"; leider ist bisher offenbar nichts in dieser Hinsicht passiert ... was traurig ist, weil der Googlebot damit auf beiden Seiten Bandbreite verschwendet, statt HTTP im vollen Umfang zu unterstützen ... da sieht man, was es bedeutet, Quasi-Monopolist zu sein), dann will er die unkomprimierte Version haben.

Du kannst im M$IE diesen Header ein- und ausschalten (indem Du die Verwendung von HTTP/1.1 ein- bzw. ausschaltest) und damit ausprobieren, welche der beiden Dateien Dein Server in beiden Fällen auslieferst (das siehst Du an der Byte-Zahl im access_log).

Viele Grüße
      Michael

[Cyx23]

Hallo Michael,

besten Dank für die Ausführungen.

Die serverseitige Verhandlung sollte also genau vom Vorliegen dieses Head[...]

Der Client teilt schon bei der Anfrage die Fähigkeit mit, der Server findet als erstes die gzip und liefert abhängig von der Anfrage ggf. die nächste, unkomproinierte; etwas umständlich, aber wohl hinreichend zuverlässig hinsichtlich aller Clients, und dann wohl doch völlig transparent.

Tut er das nicht (was der aktuelle Stand zu sein scheint - ich habe es Google vor knapp einem Jahr vorgeschlagen, als ich mal einen ihrer Entwickler "an der Leitung hatte"; leider ist bisher offenbar nichts in dieser Hinsicht passiert ... was traurig ist, weil der Googlebot damit auf beiden Seiten Bandbreite verschwendet, statt HTTP im vollen Umfang zu unterstützen ... da sieht man, was es bedeutet, Quasi-Monopolist zu sein), dann will er die unkomprimierte Version haben.

Das ist allerdings jede Menge unnötiger Traffic.

Du kannst im M$IE diesen Header ein- und ausschalten (indem Du die Verwendung von HTTP/1.1 ein- bzw. ausschaltest) und damit ausprobieren, welche der beiden Dateien Dein Server in beiden Fällen auslieferst (das siehst Du an der Byte-Zahl im access_log).

Das scheint sauber zu laufen. Wenn da bei den Browsern defaultmäßig HTTP/1.1 deaktiviert ist ergibt das nochmals unnötigen Traffic.

Grüsse,

Cyx23

[Michael Schröpl]

Hi Cyx23,

Du kannst im M$IE diesen Header ein- und ausschalten (indem Du die Verwendung von HTTP/1.1 ein- bzw. ausschaltest) und damit ausprobieren, welche der beiden Dateien Dein Server in beiden Fällen auslieferst (das siehst Du an der Byte-Zahl im access_log).
Das scheint sauber zu laufen. Wenn da bei den Browsern defaultmäßig HTTP/1.1 deaktiviert ist ergibt das nochmals unnötigen Traffic.

was der Default ist, scheint von der jeweiligenm M$IE-Version abzuhängen (bei Mozilla und Opera muß man sich inzwischen ziemlich anstrengen, um die Kompromierung nicht zu wollen).

Meine eigenen Erfahrungen im Einsatz von gzip_cnc auf meiner Domain waren, daß die Quote derjenigen Browser, die gzip-Komprimierung unterstützen, in der Größenordnung von 40-50% lagen ... wobei sowohl viele M$IE als auch etliche Roboter-Zugriffe vorkamen. Immerhin eine Erkenntnis, die zur Existenz von http://www.schroepl.net/projekte/msie/ geführt hat ...

Viele Grüße
      Michael

[Cyx23]

Hallo Michael,

Meine eigenen Erfahrungen im Einsatz von gzip_cnc auf meiner Domain waren, daß die Quote derjenigen Browser, die gzip-Komprimierung unterstützen, in der Größenordnung von 40-50% lagen ... wobei sowohl viele M$IE als auch etliche Roboter-Zugriffe vorkamen. Immerhin eine Erkenntnis, die zur Existenz von http://www.schroepl.net/projekte/msie/ geführt hat ...

40-50%, das lohnt sich ja bereits auf jeden Fall, und Aufklärungsarbeit ist bei dem Thema sehr sinnvoll, zumal sinnvoller als die Desinformation die mir bei speziellen Kunden-logins entgegenpoppt.

Bei den IE stört mich gerade ein kleiner Schönheitsfehler, der wohl nicht direkt mit gzip zu tun hat. IE6 und IE5 merken offenbar nicht gleich wenn die Seite geladen ist und zeigen den Ladebalken unnötig lange an; ich möchte das doch irgendwie ändern, vielleicht hilft ja ein onload=selfocus()..

Grüsse

Cyx23

[Christian Seiler]

Hallo Cyx23,

Wie sieht das z.B. für Googlebot aus?

Da wir gerade dabei sind, etwas ähnliches hat mich immer mal interessiert: Wenn ich Content Negotiation für die Sprache verwende, dann liefere ich ja basierend auf dem Accept-Language-Header eine andere Sprache aus. Wenn nun eine Suchmaschine die Seite betritt, was passiert dann? Interpretiert eine Suchmaschine den "Vary"-Header? Schickt eine Suchmaschine überhaupt ein Accept-Language mit? Werden die verschiedenen Sprachversionen indiziert oder nur die eine, die die Suchmaschine bekommt? (Oder weigert sich eine Suchmaschine evtl. beim Auftauchen eines Vary-Headers?)

Viele Grüße,
Christian

[Cyx23]

Hallo Christian,

Wie sieht das z.B. für Googlebot aus?

Da wir gerade dabei sind, etwas ähnliches hat mich immer mal interessiert: Wenn ich Content Negotiation für die Sprache verwende, dann liefere ich ja basierend auf dem Accept-Language-Header eine andere Sprache aus. Wenn nun eine Suchmaschine die Seite betritt, was passiert dann? Interpretiert eine Suchmaschine den "Vary"-Header? Schickt eine Suchmaschine überhaupt ein Accept-Language mit? Werden die verschiedenen Sprachversionen indiziert oder nur die eine, die die Suchmaschine bekommt? (Oder weigert sich eine Suchmaschine evtl. beim Auftauchen eines Vary-Headers?)

m.E. müsste Google extra zusätzliche bots mit anderer Sprache schicken, wozu wohl erstmal kein Anlass bestehen dürfte.

Sprachkategorien sind ja dem Suchschema zufolge bei Google vorhanden. Ist wirklich die Frage ob Google ohne Accept-Language immer einen eindeutigen Default bekommt, und was wäre andererseits mit Accept-Language bei unterschiedlichen Inhalten gleicher URI zwischen google.fr und google.de?

Grüsse

Cyx23

[Michael Schröpl]

Hi Seiler,

Wenn nun eine Suchmaschine die Seite betritt, was passiert dann?
Interpretiert eine Suchmaschine den "Vary"-Header?

frage den Programmierer der Suchmaschine.

Schickt eine Suchmaschine überhaupt ein Accept-Language mit?

Konfiguriere Dein Apache-Log so, daß Du diesen Header siehst.
(%...{Foobar}i:  The contents of Foobar: header line(s) in the request sent to the server.)

Werden die verschiedenen Sprachversionen indiziert oder nur die eine, die die Suchmaschine bekommt?

Zunächst mal nur eine. Von der Interpretation des Vary:-Headers hängt ggf. ab, ob weitere (wobei dem Crawler leider die Information fehlt, welche weiteren Sprachen im Angebot sind).

(Oder weigert sich eine Suchmaschine evtl. beim Auftauchen eines Vary-Headers?)

Warum sollte sie?
Sie bekommt auch dann einen Vary:-Header, wenn sie keine komprimierte Übertragung unterstützt ...

Wenn jemand erzwingen will, daß sämtliche Sprachvarianten indexiert werden, dann bietet es sich an, eine HTML-Seite mit Links auf alle erreichbaren vollständigen URLs des eigenen Servers (inklusive der Sprach-Endung!) zu generieren. Wenn der Crawler dieses Dokument in die Finger bekommt, dann findet bei den nachfolgenden HTTP-Zugriffen keine Negotiation mehr statt.

Viele Grüße
      Michael