Christoph's Blog

Rechtzeitig nach dem Ende der Fußballweltmeisterschaft mit dem Sieger der Herzen "Deutschland", hat Yahoo seinen Index erneuert und ein paar Schrauben neu eingestellt. Im Index sind alle Daten über eine Seite enthalten: Url, Titel, Inhalt, Cache-Version, Links (eingehend und ausgehend).

Bis im letzten Jahr hatte Google mit knapp 10 Mrd. Seiten den größten Index. Als Yahoo! auf einmal eine Zahl knapp der 20 Mrd. Grenze auf seine Seiten schrieb, entschied man sich nach kurzem Gerangel, eine Indexgröße komplett von den Seiten zu nehmen.

Im Allgemeinen sagt Google, dass sie alle 4 Wochen nahezu alle Seite im Index abgrasen und nach Änderungen überprüfen. Dass Yahoo! sein Index-Update im eigenen Weblog ankündigt kann nur bedeuten, dass eminente Änderungen entweder am Index, den Informationen oder dem Ausgabealgorithmus vollzogen wurden.

Yahoo! freut sich über Feedback und möchte wissen, was die Nutzer der Suchmaschine über die neusortierten Änderungen denken.

In other News:
Google hat heute morgen einen PageRank-Update vollzogen. Der PageRank ist eine Zahl von 0 - 10, welche Google jeder Seite zuweist. 10er PR-Seiten sind sehr selten. Nur Adobe.com, Google oder das ODP (Dmoz) und einige wenige mehr haben es in die heiligen Hallen der absoluten Vertrauenswürdigkeit geschafft. 0er PR-Seiten gibt es hingegen viele.
Über die Google Toolbar und viele weitere Erweiterungen kann die PR-Anzahl einer Domain angezeigt werden. Alle paar Monate werden diese Zahlen aktualisiert - so wie heute morgen.
Intern verrechnet Google übrigens mit aktuellen PR-Zahlen, jederzeit. Es würde nämlich keinen Sinn machen, eine so starre Technik zu verwenden, gerade wenn es Seiten gibt, die innerhalb kürzester Zeit viel Interesse anziehen. Doch ob eine Seite zwischen einem und dem nächsten Update an Relevanz gewonnen hat, sieht der User erst beim nächsten Update - so wie heute morgen...

P.S.:Jetzt hat Google doch wieder mehr Text bekommen.

Snippets sind die kleinen Zweizeiler auf den Suchergebnisseiten der Suchmaschinen. Die Snippets halten meist einen Link und einen kurzen Textausschnitt, der entweder aus der Meta-Description oder der Website genommen wird. Ein dritter Weg ist das "Borgen" einer Beschreibung für die Ergebnisseite vom Open-Directory-Project (ODP).
Lange Zeit galt es als SEO-Geheimtipp, in diesem Verzeichnis gelistet zu sein.
Falls die eigene Website in dem ODP eingetragen war, konnte man nicht beinflußen, ob Google in seinem Snippet die Informationen hieraus zieht.
Da jedoch Redakteure die Einträge dort erstellen, sind diese Beschreibungen nicht immer im Sinne des Webmasters oder oft veraltet. Der Wunsch nach Kontrolle wurde laut.


Hier wird für AOL nicht die Information aus der Seite genommen sondern vom ODP gezogen

Google stellt nun in seinem Blog eine Möglichkeit vor, wie man den Robotern mitteilt, dass man auf solche Methoden keine Lust hat:

To direct all search engines that support the meta tag not to use ODP information for the page's description, use the following:
<META NAME="ROBOTS" CONTENT="NOODP">
Note that not all search engines may support this meta tag, so check with each for more information.
To direct Google specifically from using this information to describe a page, use the following:
<META NAME="GOOGLEBOT" CONTENT="NOODP">

Durch den Einbau dieses Meta-Tags wird also nach dem nächsten Spider-Besuch nur noch die Information in das Snippet eingebaut, welche auch wirklich auf der Seite vorkommt.

Abwarten, ob das ein Schritt in die richtige Richtung ist. Immerhin waren gerade in den letzten Wochen viele ungenießbare Suchergebnisseiten aufgetaucht.

Nachtrag, 14.07.2006:
Der Tag hat laut SEORoundTable Einfluß auf sowohl den Title als auch das Snippet. Es werden keine Informationen mehr von DMOZ.org eingezogen.
Der Tag kann im Übrigen mit den anderen Anweisungen kombiniert werden. Z.b.:

"noodp, nofollow"

oder

"noarchive, noodp"

.

Die Seite: Craigslist.org
Thema der Seite: Kleinanzeigen
Der Optimierer: Craigslist.org in Personalunion
Das Ergebnis: Plätze 1-500 (außer 2 und 3) zum Suchwort "Talent Gigs"

Die Story: Google sieht eine Subdomain als eigenständige "Seite" an. Somit werden x Subdomains einer Seite auch x-fach in den Suchergebnisseiten auftauchen, sofern der Anbieter alles richtig macht. Was wohl jeden Design-Freund nachts nicht schlafen läßt, läßt in den USA bei Craigslist.org alle Kassen klingeln: Die Seiten dieses Unternehmens werden zu abertausenden Keywordkombinationen sehr gut gefunden - mehfrach - hundertfach. Durch das Subdomain-Konzept und die wirklich sehr gute interne Linkstruktur ist der Index gut gefüttert mit Craigslist.org's Seiten (ca. 15.000.000 per heute).
Schon mal jemand überlegt, warum Craigslist so erfolgreich ist? Es ist quasi unmöglich, bei den Suchanfragen nicht auf ein Ergebnis des Kleinanzeigenanbieters zu klicken.

Always deliver more than expected.

Dieses Zitat scheint Google unter seinen Firmengrundsätzen dann vielleicht doch anders gemeint zu haben.

Dennoch tauchen immer wieder Ergebnisseiten auf Google auf, die dort eigentlich nichts zu suchen haben. Bekannte Beispielen waren https-Seiten, die z.B. bei Onlinebanking eingesetzt werden. Mit einem Mal waren Bestellkörbe, Kontenauszüge und geheime Firmendateien für jedermann sichtbar im Internet verlinkt. Und auch die schnellsten Webmaster kamen damals nicht gegen die Google-Cache Funktion an, die von jedem Dokument einen schönen Schnappschuß im wahrsten Sinne des Wortes verewigte.

Auch an die selbst auferlegten Regeln einer Robots.txt scheint sich der Branchenprimus nicht immer zu halten: Viele Webmaster beklagen, dass durch Robots.txt verbotene Seiten dennoch im Index zu finden sein.

Der letzte Schrei scheint jedoch zu sein, dass Google Seiten in seinen Index aufnimmt, die nicht einmal frei durch einen Link zu erreichen sind oder welche einen Login erfordern.

Fall 1)
Das Unternehmen X setzt ein CMS ein, welches auf den Seiten einen Link zum Editieren/Löschen des Artikels anbietet. Wird der Link geklickt, kommt man in die "Admin-Oberfläche". Hier wird dann auf Cookie-Ebene eine User-Identifikation durchgeführt. Leider hat das CMS nicht damit gerechnet, dass jemand auf die Seiten kommt, der überhaupt keine Cookies annehmen kann: Ein Suchmaschinen-Spider.
In diesem Fall behandelte das CMS den Besucher nämlich (leider) wie einen eingeloggten User. Hatte dieser eingeloggte User also den "Löschen"-Link geklickt, wurde folglich die gewünschte Aktion ausgeführt. Eine Nacht reichte für den aktiven Google-Spider aus, um sämtliche Seiten des Unternehmens nachhaltig vom Server des Betreibers zu löschen. Backup? Alt. Reaktion des Betreibers der Seite: "Wir werden den Löschen-Link von der Seite nehmen."

Fall 2)
Eine Schule in den USA war überrascht, als auf einmal sensible Schülerdaten aus dem "geschützten" Bereich im Web und in den Suchergebnissen von Google auftauchten. 619 Schüler konnten also ihren Namen, Sozialversicherungsnummern und Testergebnisse online auf Richtigkeit prüfen. Der Schulleiter war außer sich und wußte sich nicht anders zu helfen, als die Presse einzuschalten. Seiner Äußerung nach wurde nämlich von Seite des Suchmaschinenbetreibers Google nichts unternommen, diese Daten umgehend zu löschen.

Was ist in den beiden Fällen passiert?
Natürlich liegt es nah, die Schuld bei demjenigen zu suchen, der die Daten letztlich auf seinen Ergebnisseiten präsentiert hat: Google. Denen liegt jedoch nicht wirklich viel daran, Informationen zu verbreiten, die nicht dafür gedacht sind.
Die Lösung ist in der Methodik der Spider zu suchen: Sie nehmen keine Cookies an, sie verfolgen Links. Da Googles Spider einer der aktivsten ist, ist es klar, dass solche Daten zuerst hier auftauchen. Von der Technik her wären jedoch auch andere Suchmaschinen irgendwann an diese Daten gekommen.
An erster Stelle scheint also der Schutz der Daten vernachläßigt worden sein. Webmaster sollten sich zunehmend darüber Gedanken machen, wie Zugänge zu Admin-Seiten zu programmieren sind. Sollte das Abschalten von Cookies (In jedem Browser möglich) der einzige Schutzmechanismus sein, lohnt sich weitere Mühe. Das Auslagern von Sicherheitsüberprüfung ist generell zu überdenken...
Auch im zweiten Fall ist Google nicht unbedingt ein Vorwurf zu machen:
Wahrscheinlich hat ein Mitarbeiter der Schule beim Verlassen der Admin-Pages einen externen Link geklickt. Das Tracking-System der externen Website hat den Referrer getrackt. Dieser könnte so ausgesehen haben:

http://www.catawba.k12.nc.us/admin/edit-data.php?user=admin&pass=wisdom

Viele Seiten benutzen Online-Statistiken wie z.B Webalizer. Unter domainame.tl/webalizer findet man bei Google tausende solcher Statistik-Seiten.
Diese zeigen auch die Verweise/Referrer in ihren Statistiken als Link an.

Findet Google also so eine Statistik und verfolgt alle dortigen Links, dann ist es nur eine Frage der Zeit, bis der Googlebot sich durch den schlecht geschützten Admin-Bereich eines Webangebots spidert und natürlich alle Angaben auch in den Index bringt....

Mehr zum Thema Referrer-Spam demnächst

Google bezieht seine Informationen aus den HTML-Webseiten im Internet. Dazu werden die HTML-Seiten von seinem Spider angefordert und analysiert. Bisher hat Googlebot im HTML-Code referenzierte Stylesheets, Javascripts usw. nicht geladen und nicht in die Analyse einer Seite einbezogen (Ausnahmen bestätigen die Regel).

Heute fällt mir jedoch bei meiner Log-Analyse jedoch folgendes auf:

66.249.66.203 - - [23/Jun/2006:03:23:44 +0200] "GET /blog/serendipity.css HTTP/1.1" 200 6574 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Im Klartext: Der Googlebot findet die Stylesheet-Datei aus meinem Blog im HTML-Code und ist schlau genug, diese auch für die Bewertung meiner Seite einzubeziehen.

Warum sollte Google sich .css-Files angucken?
Zunächst einmal bietet eine CSS-Datei doch nur Styleangaben. Wird jetzt etwa geguckt, wie gut eine Seite aussieht oder was will Google damit?
Ganz einfach. Im Wettrüsten zwischen Suchmaschinenoptimierern und Suchmaschinenbetreibern gibt es diverse Tricks, die Seiten im Index nach oben pushen, die da nur zweifelhaft hingehören.

Eine immernoch beliebte und effektive Möglichkeit ist das Verstecken von Text.
Schreibe ich 1000 Mal mein gewünschtes Keyword in weißer Schrift auf weißem Hintergrund, so hat mich das früher an Spitzenpositionen zum Keyword gebracht. Heute funktioniert das nicht mehr....sagt man.

Jedoch ist auch die Web-Technologie ein wenig weiter forgeschritten.
Per CSS-Stylesheet sind die Positionen, Farben, Sichtbarkeiten von Elementen (z.B. DIV-Ebenen) nach Belieben veränderbar. So kann ich meinen "Faketext" in eine Ebene schreiben und diese dann an Position x: 2000 Pixel, y: 4000 Pixel verschieben, wo sie weit aus dem sichtbaren Bereich ist. Auch die Angabe "unsichtbar" ist möglich und für die Suchmaschinenmanipulation hilfreich.

So wurde der Wunsch an Google immer lauter, doch auch die Styleangaben in die Bewertung und Analyse mit einzubringen.

Diesem Wunsch wird nun vielleicht (in einem Versuch) versucht Rechnung zu tragen. Ob es die Spamseiten zu vielen Suchbegriffen aus dem Index drückt, die da aktuell noch zu finden sind, bleibt abzuwarten.

Auch Javascript wird vereinzelt mal von Google angefordert - allein wirklich damit umzugehen scheint der Suchmaschinenführer noch nicht zu können. Viele Weiterleitungen per Brückenseiten (Doorwaypages) in den Suchergebnissen belegen dies.

PS: Hoffentlich wissen die Blackhat SEO nicht, dass man das Spidern eines Files ganz einfach per robots.txt-Datei ausschließen kann und somit noch ein paar Monate mit gefakten Suchergebnissen Urlaubsgeld verdienen kann...

User-agent: *
Disallow: /css/meine-spam-css.css