Bin-auf-Hawai-Status-Code: Evaluation

[Beat]

Yahoo hat vor längerer Zeit einen Geniestreich in der Hinsicht gehabt: Bereiche der Webseite mit der CSS-Klasse "robots-nocontent" werden nicht indiziert. Leider hatte Google zumindest 2008 kein Interesse, das zu unterstützen.

Hi Tim
Ich habe es irgendwann aufgegeben, auf proprietären Mutwillen zu setzen.
Ich habe Seit BdE-Online eine sehr einfache Policy:
Nimm an, dass ernstzunehmende Index-Bots als solche zu erkennen sind.
Der Aufwand, deren merkmale zu registrieren, ist bei den grossen drei sehr klein.
Nebst den Usertypen Admin, Submadmin, Member und Guest führe einen Typ Robot.
Blende alle Teile aus, die Robots nicht indexieren sollen.
Pflege statt dessen ein Set von permanenten Bookmarklinks ohne Query-Strings.

@all

Meine Frage nach dem Bin-Auf-Hawai-Statuscode ist nicht eine dringliche im Sinne eines "ich muss jetzt dringend etwas machen". Aber es interessiert mich konzeptionell für zukünftige Implementierungen.

Da sind verschiedene Ansätze mit bestehenden Statuscodes:

503
pro:  Erlaubt oder empfiehlt Message-Body (Danke für die Berichtigung)
      Bots indexieren diesen Body nicht, denn es ist eine Error-Page.
cons: Er ist in der Rubrik Server-Error.
      Das muss ich vielleicht nicht so heiss essen.
      Die Tatsache eines Retry-after bekräftigt
      ein vorgesehenes Verhalten des Servers.
quest:Wie reagieren Browser auf solchen Content?
      Stichworte: Bookmark, History, Re-Request?
      Retry-After findet hier wie Anwendung?

404 (von Texter vorgeschlagen)
pro:  Message Body erlaubt
      Bots indexieren nicht,
      ziehen aber auch keine negativen Schlüsse bezüglich späterer Versuche.
      Meine langjährige Erfahrung mit 404.
cons: Browser ziehen zwar keine negativen Schlüsse (anders als bei 410)
      bezüglich Re-Requests
      Bookmark: Ja ich kann eine 404 Seite bookmarken,
      denn ich bookmarke die Url. Stimmt das immer?
      Consistenz: Content in einer 404 Seite 90% identisch zur normalen Seite?

200 (Chris)
pro:  Für Clients optimal.
cons: Bots: Erfordert Veränderungen im Content.
      (Wiederherstellung des kanonischen Index-Contents)

302 oder 307
pro:  Bots indexieren die ursprüngliche Url nicht.
cons: Unnötiger zusätzlicher Request.
      Das Umleitungsziel muss auf einer alternativen URL ausgeliefert werden.
Ich will diesen Vorschlag schon mal streichen, weil er nur das Problem verlagert.

WebDAV Methode? Unterirdisch.

Mein Vorläufiger Entscheid.

Unter der Voraussetzung, dass der Server auf Bots alternativ reagiert
für Bots:    503 (kein verboser Content-Body notwendig)
             ein Retry-After header kann mitgesendet werden.
für Clients: 200.

mfg Beat