Alle reden davon, wie ein Betreiber möglichst viele Seiten in den Google-Index rein bekommen und dort möglichst oben auf der Trefferliste positioniert sind. So auch bei uns, es heisst Suchmaschinenmarketing (SEO + SEM).

Heute mal das Gegenteil: Wie stelle ich sicher, dass meine Seiten nicht im Google-Index landen. So einfach wie es ist, sich selbst aus Google auszuschliessen, so sehr frage ich mich, weshalb Verleger klagen dass Google Inhalte klaue (sie können diese selbst sperren).

FAQ1: Meine Seiten kommen nicht in den Index, denn niemand kennt die Adresse. Meist falsch, da beispielsweise der Google Toolbar Seiten zurückmeldet und somit durchaus auch “unbekannte” URL gecrawled und indexiert werden.

FAQ2: Ist so was wichtig? Machen wir mal das folgende Spiel. Ich vermute bei jemandem Entwicklungssysteme oder will mich mal umschauen…

i) Suche in Google nach der Hauptdomäne bsp. mit der Query site:swisscom.com

ii) Nun beginnne ich Schritt für Schritt die Domänen auszuschliessen, die ich nicht sehen will mit -site. So lautet die zweite Query site:swisscom.com -site:www.swisscom.com und schon sehe ich interessante Kandidaten.. schauen sie selbst.

Also zurück zur Frage was ich für Möglichkeiten habe, dass Seiten nicht bei Google in Index landen.

> > Gruppe 1: Die Site / Seiten sollen öffentlich zugänglich sein

1) robots.txt Datei. Im Wurzelverzeichnis des Webserver kann ich mit der Datei robots.txt auf Stufe Verzeichnis festlegen, was der Suchmaschinencrawler besuchen soll. Der Grundsyntax (www.robotstxt.org) ist schon sehr lange stabil und lässt auch eine Differenzierung nach Suchmaschinen (User Agents) zu. Gewisse Suchmaschinen interpretieren auch einen erweiterten Syntax. Crawler die sich an die Regeln halten (alle “grossen”) erkennt man u.a. auch daran, dass sie die Datei zu Beginn einer Session anfordern (erzeugt einen Eintrag im Access-Log). Soll auf diesem Blog beispielsweise von keinem Crawler das Verzeichnis /mt/ nicht besucht werden, alle anderen aber schon, so lautet die Datei so:

User-Agent: *
Disallow: /mt/
Allow: /

Hier noch die Anleitungen bei Google, Yahoo und bei Microsoft.

2) META tags. Diese Tags gilt es auf Seitenbasis einzufügen und sie erlauben damit eine feinere Steuerung. Auch hier gibt es wieder einen von allen interpretierten Grundsyntax (www.robotstxt.org) sowie suchmaschinenspezifische Erweiterungen. In der Grundversion gibt es zwei Angaben i) soll die vorliegende Seite indexiert werden oder nicht (INDEX / NOINDEX) und ii) soll den Links in der Seite gefolgt werden (FOLLOW / NOFOLLOW). Somit sehen die Tags in etwas so aus:

<META name=”robots” content=”noindex, follow” />
<META name=”robots” content=”index, nofollow” />
<META name=”robots” content=”noindex, nofollow” />

3) X-Robots-Tag Header. Bei diesem Ansatz lieferte die angeforderte Seite in der HTTP Response den genannten Header. De Ansatz wurde von Google bekannt gemacht und unterstützt ihren erweiterten Befehlssatz. Zumindest Yahoo unterstützt den header auch. Die Befehle sind sehr ähnlich wie bei robots.txt also

X-Robots-Tag: noindex, follow
X-Robots-Tag: index, nofollow
X-Robots-Tag: noindex, nofollow

Grundsätzlich ist zu allen drei Ansätzen zu sagen, dass es effizienter ist den Crawler mit robots.txt grossflächig auszuschliessen, damit nicht alle Seiten ausgeliefert werden um festzustellen, ob diese indexiert werden sollen. Auf der anderen Seite ist META oder der Header zuverlässiger.

> > Gruppe 2: Die Site / Seiten ist nur für eine Gruppe von Leuten zugänglich (z.B. Entwicklungssysteme)

Auch ein häufiger Fall ist es, dass ich ein System vor dem Live-Gang für eine Testgruppe zugänglich machen möchte. Die Ansätze oben sind grundsätzlich möglich, aber zu unzuverlässig und auch aufwändig bei der Umstellung vor dem Livegang. Das allerbeste hier ist also ein Passwort und zwar sehr früh. Also nicht erst auf einer Formularseite (sonst wird diese indexiert) aber bereits mit einer HTTP Basic Authentication (also einem Login Windows des Browsers).

Vor ziemlich genau fünf Jahren bin ich zum ersten Mal mit Spring (damals noch Interface21 auch in den Packagenamen) in Kontakt gekommen. Damals noch ein ziemlich unbeschriebenes Blatt hatte Spring in Kunden-evaluationen /-situationen kaum eine Chance gegen Struts. Da musste man schon fast einen Liebhaber von “progressiven” Neuerungen auf der Gegenseite haben, um von Struts wegzukommen. Wie auch Struts war Spring damals vorallem auf die serverseitige Webprogrammierung ausgerichtet – um einiges besser schon damals als Struts aber auch um einiges unbekannter… :-)
Während bei Struts das “Benzin” ausging und seid damals keine wirklich nennenswerte Neuentwicklung mehr zustande kam, ging bei Spring so richtig die Post ab. Die drei Standbeine “dependency injection” mit Bean-Container, “portable service abstraction” für die Abstraktion der diversen Java-API’s und Unterstützung von aspektorientierter Programmierung wurden schnell ziemlich gut ausgebaut und in den neuesten Versionen mit Möglichkeiten von AspectJ und Annotationen ergänzt. Damit hat sich Spring serverseitig im Markt behaupten können, erleichtert täglich dem Entwickler vieles und ist heute Quasi-Standard im Enterprise Java-Markt.

… und alles wurde gut… wohlgemerkt, serverseitig… wenn da nicht der Client wäre… :-)

Ich habe mich ehrlicherweise bislang nie so richtig wohl gefühlt im Html-, CSS- und JavaScript-Dschungel… zu unstrukturiert und launisch war mir diese Welt. Die unterschiedlichen Browser und ihre Eigenheiten haben das ihrige dazu beigetragen. Seid 2005 und der “neuen alten” Technologie AJAX und dem Buzzword Web 2.0 hat sich jedoch einiges verändert. Der Client ist nicht mehr als reine Anzeigemaschinerie da sondern erhält – je nach Gewichtung – immer wie mehr Logik (Stichwort hier RIA). Und ein neuer riesiger Zoo von AJAX-Frameworks war die Folge. Ich mag sie gar nicht erwähnen, so viele sind es mittlerweile (auch sehr gute, keine Frage).

Glücklicherweise hat dies auch Springsource erkannt und hat ihr altbewährtes “portable service abstraction”-Prinzip nun bis auf den Client ausgebreitet. Was bedeutet das? Nun, ganz einfach. Ich erhalte als Entwickler ein einheitliches clientseitiges Prgrammiermodel mit dem ich arbeiten kann. Ich muss mich nicht mit Dojo oder JQuery Eigenheiten auskennen sondern es reicht, wenn ich das SpringJS-API kenne. Schematisch sieht das folgendermassen aus:

Als erste Bridge und Implementierung wird Dojo unterstützt. Als weitere Bridge geplant ist zudem JQuery. Damit sind sicher die aktuell am meist verbreiteten JavaScript-Libraries unterstützt.
Mit SpringJS wird die HTML-Seite mit “progressivem” JavaScript ergänzt… was heisst, die Funktionalität ist auch dann gewährleistet, wenn der Client JavaScript ausgeschaltet hat. Das fühlt sich dann ungefähr so an:

Die HTML-Elemente werden mit sogenannten Dekorationen (siehe Decoration-Pattern) erweitert. Im Beispiel wird einfach ein OnClick-Handler dem Html-Element findFormUrl “hinzugefügt”.

So einfach… oder? Und das ganze portabel… hoffentlich… :-)