Suchmaschinen und die Technik
Autor: Markus Fettke | Kategorie: Internet
Cloaking
Ein Problem bei der Optimierung von Seiten für Suchmaschinen ist, dass optimierte Seiten optisch oft nicht sehr anspruchsvoll sind. Ein guter Text sollte Wiederholungen möglichst vermeiden, für ein gutes Ranking kann aber die mehrfache Wiederholung der Stichwörter hilfreich sein. Oder es müssen aus Marketinggründen auf den Webseiten viele zusätzliche Informationen untergebracht werden, die eine Seite inhaltlich überladen und so Suchmaschinenplatzierungen kosten.
Daher setzen Suchmaschinen-Optimierer schon lange eine technische Möglichkeit ein, dem menschlichen Besucher die optisch schön gestaltete Seite zu präsentieren, während der Robot der Suchmaschinen die Seite “zu sehen” bekommt, die für ein gutes Ranking sorgt. Diese als Cloaking bezeichnete Vorgehensweise ist einfach, und auch die Umsetzung fällt nicht allzu schwer. Der Teufel aber steckt im Detail – und in der Gefahr, dass die so optimierte Website aus dem Index der Suchmaschinen gebannt wird.
Wie kann ich aber nun einer Suchmaschine andere Inhalte präsentieren als einem menschlichen Besucher? Der einfachste Weg ist die CGI-Umgebungsvariable HTTP_USER_AGENT abzufragen – darin ist der User-Agent des Clients (Browser oder Robot) gespeichert, der die Seite aufgerufen hat.
Beispiele:
Mozilla/4.0 (compatible; MSIE 5.0; Windows 95; DigExt)
Mozilla/4.6 [de]C-CCK-MCD QXW03200 (Win98; I)
Scooter/1.0
Slurp/2.0e (slurp@inktomi.com; http://www.inktomisearch.com/)
Die ersten beiden Beispiele zeigen User Agents eines Internet Explorers bzw. eines Netscape Navigators. Die Beispiele drei und vier sind User-Agents von Robots. So kann also eine angeforderte Seite erkennen, welcher Client die Anforderung abgesetzt hat. Für normale Browser liefert der Webserver die “schöne” Seite, für Robots die optimierte.
Dieser Weg ist nicht ganz perfekt – niemand garantiert Ihnen, daß die Suchmaschinen Robots ihren eigenen User-Agent bei der Abfrage der Seiten angeben. Und tatsächlich tarnen sich inzwischen Robots mit Kennungen, wie sie auch von Browsern benutzt werden. Sicherer wird es, wenn Sie zudem noch die IP-Adresse abfragen und vergleichen – allerdings müssen Sie hier immer eine aktuelle Liste von Suchmaschinen-IP-Adressen pflegen. Und auch dann ist noch nicht ganz sicher, dass Sie Suchmaschinen-Robots auch als solche erkennen können, denn um Cloaking aufzuspüren, nutzen Suchmaschinen inzwischen auch IP-Adressen von normalen Einwahlprovidern.
Sollten Sie beim Cloaking erwischt werden, wird Ihre Site komplett von der Suchmaschine, die Sie beim Tricksen erwischt hat, gelöscht werden; als Ausweg bleibt dann oft nur die Nutzung einer neuen Domain. Diese Gefahr steht in keinem Verhältnis zu den geringen Vorteilen, die Cloaking bieten kann; deshalb sollten Sie auf diese Art der “Optimierung” verzichten.
Frames
Mit Frames lassen sich mehrere HTML-Dokumente innerhalb eines Browserfensters darstellen. Frames werden oft benutzt, um das Inhaltsverzeichnis einer Site oder Werbung darzustellen. Zwar sind Frames nicht von Haus aus schlecht für die Suchmaschinen-Optimierung, aber man handelt sich mit ihnen deutlich mehr Probleme ein als wenn man von auf dieses Hilfskonstrukt verzichtet.
Für den Suchmaschineneintrag sind Frames schon lange kein Hinderungsgrund mehr. Alle Suchmaschinen sind in der Lage, die Unterseiten eines Framesets zu erkennen und auch in den Index aufzunehmen. Allerdings beginnen hier bereits die Probleme. Denn Suchmaschinen nehmen, anders als dies oft der Vorstellung der Nutzer entspricht, nicht Webseiten auf, sondern URLs. Im Falle von Frames gibt es nun eine URL, die auf den Frameset verweist und mit dem Inhalt dieser Framesetseite aufgenommen wird. Doch hat ein Frameset gar keinen Inhalt, der aufgenommen werden könnte, sondern nur “Links” auf die Unterseiten. Entsprechend wenig aussagekräftig sehen solche Ergebnisse dann in Suchmaschinen aus.
Dabei gibt es durchaus Möglichkeiten, auch in der Frameset-Datei Inhalte unterzubringen: Dazu bietet sich der title-Tag ebenso an wie der noframes-Tag. Wenn Sie in diesen beiden Bereichen sinnvolle Inhalte angeben, haben Sie bereit eine wesentliche Frames-Klippe umschifft.
Es gibt aber noch eine weitere Falle. Was passiert, wenn eine Unterseite eines Framesets über Suchmaschinen gefunden wird? Dann klickt der Nutzer auf den Treffer in der Ergebnisliste der Suchmaschine und kommt unmittelbar auf die Unterseite – aber ohne Navigations- oder Titelframe. Wenn Sie Pech haben, sieht Ihr Besucher so zwar den Inhalt Ihrer Seite, aber keine Navigationselemente und er weiß nicht, wo er hier gelandet ist. Deshalb müssen Sie unbedingt auf jeder Unterseite eines Framesets Links zur Homepage und, wenn möglich, zu den wichtigsten Rubriken angeben. Denn so kann auch ein verirrter Quereinsteiger Ihre Frame-bestückte Website sinnvoll nutzen.
Für Quereinsteiger erbringt übrigens JavaScript nützliche Dienste. Wenn Sie auf jede HTML-Seite, die innerhalb eines Framesets dargestellt werden soll, das folgende kleine Script stellen, so wird beim Aufruf der Unterseite das Frameset nachgeladen:
Da aber nicht alle Nutzer in ihren Browsern JavaScript einschalten, sollten Sie trotz dieses Scripts meinen obigen Rat mit den wichtigsten Links auf jeder Unterseite beherzigen.
JavaScript-Weiterleitungen
Um den Inhalt dieses Artikels besser verstehen zu können, sollten Sie bereits grundlegende Kenntisse über HTTP-Weiterleitungen und JavaScript besitzen.
Der Einsatz von JavaScript zur Darstellung von Inhalten auf einer Webseite führt dazu, dass diese Inhalte für Suchmaschinen unsichtbar bleiben. In den meisten Fällen ist das nicht erwünscht, denn Suchmaschinen sollen ja möglichst viele Informationen aufnehmen, damit die zu optimierende Website gut gefunden wird.
Es gibt allerdings auch Einsatzzwecke, für die man die JavaScript-Blindheit der Suchmaschinen gezielt ausnutzt. Dies gilt vor allem beim Einsatz von Weiterleitungen auf speziell für Suchmaschinen optimierten Webseiten, den sogenannten Doorway-Pages. Eine Suchmaschine erkennt in einem solchen Fall die Weiterleitung nicht und nimmt den Inhalt der Doorway-Page auf; ein üblicher Browser (mit aktiviertem JavaScript) bemerkt die Weiterleitung und führt sie aus – und den menschlichen Betrachter sofort weiter auf die beworbene Webseite.
Realisierung einer JavaScript-Weiterleitung
JavaScript-Weiterleitungen können auf verschiedene Arten ausgeführt werden:
- location.href = ‘/neue-seite.htm’;
Mit dieser Vorgehensweise wird dem Objekt location.href ein neuer Inhalt, im obigen Beispiel ‘/neue-seite.htm’ zugewiesen. Diese Zuweisung führt dazu, dass der Browser diese neue Adresse lädt und darstellt. - location.replace(‘/neue-seite.htm’);
Weist den Browser an, die aktuelle Seite durch die angegebene neue Adresse zu ersetzen. Der wesentliche Unterschied zur obigen Methode ist, dass die URL der Adresse, auf der sich diese Weiterleitung befindet, dabei aus der Browser-History gelöscht wird. Damit funktioniert der Zurück-Knopf im Browser wie bei einem normalen Link.
An dieser Stelle sei ein wichtiger Hinweis angebracht: Suchmaschinen versuchen zunehmend JavaScript-Weiterleitungen zu erkennen. Sie sollten also diese Weiterleitungen auf keinen Fall für unsaubere Zwecke, sprich für Spamming, einsetzen.
robots.txt
Nicht immer sollen alle Bereiche einer Website von Suchmaschinen durchsucht werden können. Verzeichnisse mit Logfiles oder anderen halb-geheimen Dateien sollten nicht unbedingt in den Datenbanken der Suchmaschinen auftauchen. Um dies gewährleisten zu können, wurde der Robots Exclusion Standard vereinbart, an den sich die meisten Robots auch halten. Im übrigen wird er auch von vielen der “hausgemachten” Crawler beachtet, da die üblichen Libraries (etwa die Perl LWP Bibliothek), mit denen Robots sehr einfach zu schreiben sind, diesen Standard von sich aus berücksichtigen.
Entsprechend dem Robots Exclusion Standard liest ein Robot beim Besuch einer neuen Website (genauer: eines neuen Hosts) zunächst die Datei robots.txt im obersten Verzeichnis Ihres Webservers ein: http://www.ihredomain.de/robots.txt
Diese Datei ist eine einfache Textdatei, die zeilenweise aufgebaut ist. Hier sehen Sie ein
Beispiel:
# /robots.txt file for http://webcrawler.com/
# mail webmaster@webcrawler.com for constructive criticism
User-agent: webcrawler
Disallow:
User-agent: lycra
User-agent: omega
Disallow: /
User-agent: *
Disallow: /tmp
Disallow: /logs
Die Zeilen mit einem # am Beginn stellen Kommentare dar. Mit User-Agent sprechen Sie bestimmte Robots mit Ihrem Namen an. Es reicht dabei aus, einen Teilstring des tatsächlichen User-Agents des gewünschten Robots anzugeben; Groß/Kleinschreibung wird nicht berücksichtigt. Es können ein oder mehrere User-Agent-Einträge untereinander stehen.
Mit dem folgenden Disallow wird diesem Robot mitgeteilt, welche Bereiche tabu sind. Dabei werden alle URLs auf diesem Server ausgeschlossen, die mit den hinter Disallow angegebenen Zeichen beginnen. Im obigen Beispiel ist für den Robot webcrawler nichts verboten, also kann er die ganze Site indexieren. Für die Robots lycra und omega hingegen sind alle URLs gesperrt, die mit “/” beginnen – also die komplette Site. Der User-Agent * schließlich spricht alle bisher noch nicht genannten Robots an und verbietet diesen die Ordner /tmp und /logs mit allen Unterordnern. Eine Notierung der Art /tmp/* ist übrigens nicht zulässig. Eine Disallow-Angabe gilt immer für den zuletzt angegebenen User-Agent.
Wollen Sie allen Robots den Zugang zu Ihrer kompletten Site gewähren, so benötigen Sie keine robots.txt-Datei. Allerdings führt dies bei jedem Robot-Besuch zu einem 404-Fehler in Ihren Logfiles. Wenn Sie das stört, stellen Sie einfach eine leere robots.txt Datei auf Ihren Webserver.
Bitte beachten Sie, dass der Robots Exclusion Standard lediglich eine unverbindliche Empfehlung ist. Ein Robot muss sich nicht unbedingt daran halten. Die robots.txt-Datei bietet keinerlei Schutz für geheime Daten! Sie sollten also nicht auf die Idee kommen, eine Datei mit Passwörtern auf Ihren Webserver zu legen und das entsprechende Verzeichnis per robots.txt zu “schützen”.
Scriptsprachen (ASP, PHP, JSP) und Suchmaschinen
Anders als bei Javascript wird bei dynamischen Seiten mit ASP, PHP, JavaServlets, JSP oder ServerSideIncludes (SSI) der Programmcode vom Webserver ausgeführt – der Client, egal ob Browser oder Suchmaschinen-Robot, erhält gewöhnlichen HTML-Code ohne Programmanweisungen zurückgeliefert.
Während manche Suchmaschinen in den Anfangstagen des Web – wir sprechen also von den neunziger Jahren – nur Seiten aufnahmen, die auf .htm oder .html endeten, ist die Endung heute bei allen wichtigen Suchmaschinen bedeutungslos. Nun gut, Sie sollten Ihren HTML-Seiten nicht unbedingt Endungen geben, die typischerweise für Bilder (.jpg, .gif oder .png) oder ausführbare Dateien (.exe) verwendet werden; aber an Dateinamen, die auf .php oder .aspx enden, stößt sich heute keine wichtige Suchmaschine mehr.
Schwieriger aber wird es, wenn man wirklich dynamische Seiten einsetzen will – Seiten also, die ihre Inhalte aus einer Datenbank extrahieren. Denn Suchmaschinen sind oftmals recht zurückhaltend, wenn es darum geht URLs mit einem Fragezeichen aufzunehmen.
Die Angst ist verständlich, man stelle sich nur folgendes Szenario vor: Der Robot einer Suchmaschine findet einen Link, der auf eine Suchmaschine verweist und dort eine Suche auslöst. (ein fiktives Beispiel:
http://www.suchmaschine.com/search.cgi?search=computer) Würde der Robot diesem Link folgen, kommt er auf die erste Ergebnisseite der Suchmaschine und liest diese Datenbank-generierte Seite ein. Auf dieser Seite finden sich dann wiederum Links zu den nächsten zehn Ergebnisse, die er wiederum verfolgen würde. Auf diese Weise würde der Robot zigtausende Seiten der Datenbank auslesen, ein Vorgehen, das offensichtlich wenig Sinn ergibt.
PHP und Co. übergangen
Es gibt aber Websites, deren kompletter Inhalt in einer Datenbank abgelegt ist. Man denke nur an ein Online-Magazin, das alle Artikel in einer Datenbank speichert und keine statischen Seiten hat. Online-Shops und Blogs sind weitere Beispiele für Websites, die meistens aus einer Datenbank gespeist werden.
Der Königsweg, um solche Seiten problemlos in die Suchmaschinen zu bekommen, ist relativ einfach: Überlegen Sie sich ein statisches Adressformat, das keine Fragezeichen enthält, sondern die hinter dem Fragezeichen übergebenen Parameter im Dateinamen “versteckt”. Sollte also die Adresse Ihrer Website in etwa so lauten: /show.php?id=1234&cat=3, dann könnte ein mögliches statisches Adressformat diese Form haben: /artikel_1234_3.htm.
Noch haben Sie nichts gewonnen, denn es ist nur selten sinnvoll, für alle möglichen Werte von id und cat die entsprechenden Dateien tatsächlich auf dem Webserver abzulegen. Denn bei jeder Änderung an einem Artikel in der Datenbank müssten Sie dafür sorgen, dass die statischen Dateien ebenfalls aktualisiert werden. Wenn Sie aber das Modul mod_rewrite benutzen, nimmt Ihnen der Webserver (zumindest, falls Sie Apache benutzen) die ganze Arbeit ab. Wie das geht, ist im verlinkten Lexikon-Artikel erklärt.
Nun müssen Sie nur noch dafür sorgen, dass alle Links auf die neue Version der Art artikel_123_3.htm verweisen und das lästige Fragezeichen-Problem ist für Sie gelöst.
Weiterleitung per Meta-Refresh-Tag
Weiterleitungen werden üblicherweise per HTTP gesteuert. Da aber der Autor einer Webseite nicht immer Zugriff auf die Serverkonfiguration hat, gibt es eine HTML-Anweisung, die trotzdem eine Weiterleitung möglich macht.
Der Code für diesen sogenannten Meta-Refresh-Tag sieht so aus und ist im -Bereich der HTML-Seite anzugeben:
Die Zahl vor dem Strichpunkt gibt an, wie viele Sekunden der Browser nach dem Laden einer Seite warten soll, bis er die neue URL lädt, bis er also die Weiterleitung ausführt. Diese Art der Weiterleitung wird von Suchmaschinen heute problemlos erkannt. Eine Seite, auf der eine solche Weiterleitung angegeben ist, wird nur dann aufgenommen, wenn die Wartezeit bei mindestens fünf bis zehn Sekunden liegt.
Falls Sie Zugriff auf die Webserverkonfiguration haben, sollten Sie statt des Meta-Refresh-Tags eine “richtige” HTTP-Weiterleitung einsetzen. Diese erfüllen den gleichen Zweck und entsprechen der HTTP-Definition.
Weiterleitungen
Weiterleitungen sind eine praktische Einrichtung, etwa wenn sich die Struktur einer Website ändert und so neue Ordner- und/oder Dateinamen fällig werden. Wobei sich ändernde URLs recht nervig sein können – und weder Ihre Nutzer noch Suchmaschinen wirklich erfreuen.
Der Web-”Erfinder” Tim Berners-Lee hat diese Thematik bereits 1998 in einem wunderschönen Artikel mit dem noch schöneren Titel Cool URIs don’t change dargelegt. Theoretisch, so sagt Berners-Lee, gibt es keinen Grund, dass sich die URLs eines Dokuments ändern muss. Denn der Eigentümer einer Domain kann unterhalb seiner Domain den Namensraum (also die Order- und Dateinamen) beliebig festlegen und nutzen. Typische Gründe, die für einen URL-Wechsel angegeben werden, sind fast immer Gründe, die Berners-Lee zufolge leicht umgangen werden können. Oder hätten vermieden werden können, wenn der Webmaster zu Beginn etwas Verstand in die Struktur seiner URLs gesteckt hätte. (siehe auch: URI vs. URL.)
Da Sie hier immer noch lesen, gehören Sie wohl zur Mehrheit der Webmaster, die hin und wieder uncoole URLs verwenden und um Weiterleitungen nicht rumkommen. (Oder Sie möchten Weiterleitungen zum Zwecke der Suchmaschinen-Optimierung einsetzen, dann sind Sie hier natürlich auch richtig.)
Es gibt prinzipiell zwei Arten von Weiterleitungen:
- HTTP-Weiterleitungen
Das sind Weiterleitungen, die im HTTP-Protokoll definiert wurden und somit von jedem HTTP-Client (egal ob ein moderner Browser oder ein Suchmaschinen-Robot) verstanden werden. Diese Art von Weiterleitungen werden manchmal auch Server-Weiterleitungen genannt, da sie durch einen Header in der Antwort des Webservers gesteuert werden. - Client-Weiterleitungen
Diese Art der Weiterleitung funktioniert nur, wenn der Client in der Lage ist, die Weiterleitungsanweisung zu interpretieren. Da es sich dabei nicht um eine Eigenschaft handelt, die im HTTP-Protokoll definiert wurde, führen auch nicht alle Clients diese Weiterleitung aus. So fallen etwa JavaScript-Weiterleitungen in diese Kategorie; solche Weiterleitungen führt ein Client nur dann aus, wenn er JavaScript interpretieren kann – und wenn die JavaScript-Funktionalität auch eingeschaltet ist.
HTTP-Weiterleitungen richtig einsetzen
An dieser Stelle soll der Blick auf HTTP-Weiterleitungen gerichtet werden. Zu den beiden wichtigsten Arten der Client-Weiterleitung sei auf die entsprechenden Artikel verwiesen: JavaScript-Weiterleitungen und Weiterleitung per Meta-Refresh-Tag.
Wenn Sie also Weiterleitungen zu sinnvollen Zwecken, etwa nach einem Website-Relaunch, einsetzen möchten, so sind HTTP-Weiterleitungen der korrekte Weg. Da diese Weiterleitungen von jedem HTTP-fähigen Client erkannt werden, sind natürlich auch Suchmaschinen-Crawler in der Lage, solche Weiterleitungen zu erkennen. Haben Sie also die Pfade in Ihrer Website neu organisiert, so sollten Sie von den alten Adressen, die in vielen Suchmaschinen noch verzeichnet sind und manchmal auch von fremden Websites verlinkt sind, eine Weiterleitung auf die neue, nun korrekte Adresse setzen. Das hilft Ihnen, keine Nutzer zu verlieren und signalisiert gleichzeitig den Suchmaschinen, dass sich die URL der Webseite geändert hat. Damit wird in den meisten Fällen die neue Adresse nicht nur schneller aufgenommen, sondern Suchmaschinen berücksichtigen auch die Links, die auf die alte URL zeigen, für die Bewertung der neuen Adresse.
301 oder 302
Allerdings kommt es hier auf ein kleines Detail an. Es gibt zwei verschiedene Arten der HTTP-Weiterleitung, die sich im übergebenen Statuscode unterscheiden. Während der Code 301 für Moved Permanently steht, bedeutet 302 Moved Temporarily. 301 signalisert also dem Client, dass die angeforderte URL veraltet ist und künftig immer die neue angefordert werden soll; 302 hingegen heißt, dass die alte URL durchaus weiterhin gültig ist und nur derzeit die gewünschte Webseite unter einer anderen Adresse aufgefunden werden kann.
Während für einen menschlichen Nutzer diese Unterscheidung nicht so bedeutend ist, kann sie für die Auffindbarkeit einer Website in Suchmaschinen entscheidend sein. Denn Suchmaschinen nutzen diesen Statuscode um zu ermitteln, ob die weiterleitende URL im Datenbestand verbleiben soll oder dort gelöscht wird. Ein Code 302 sagt nun der Suchmaschine: “Lass’ die Adresse bitte in deiner Datenbank, denn sie wird irgendwann wieder benutzt werden.” Das führt nun aber dazu, dass die Suchmaschine die alte und die neue Adresse parallel weiterführt – und somit zwei URLs mit demselben Inhalt enthält. Diese Art der Spiegelung, im Fachjargon duplicate content genannt, kann sogar zum Ausschluss aus dem Google-Index führen. Sie sollten deshalb bei Änderungen an Ihrer Website, die Weiterleitungen erfordern, diese Weiterleitungen mit dem Statuscode 301 ausführen.
Wie aber lassen sich Weiterleitungen einfach realisieren? Das hängt in erster Linie vom eingesetzten Webserver und dessen Konfiguration ab. Wenn Sie einen Apache in der üblichen Konfiguration nutzen, und die Marktanteile besagen, dass Sie das mit ziemlicher Wahrscheinlichkeit tun, lässt sich eine Weiterleitung am einfachsten über eine .htaccess-Datei erledigen. Diese Dateien ermöglichen Konfigurationseinstellungen für einzelne Domains oder gar nur einzelne Unterordner vorzunehmen und können sehr einfach für Weiterleitungen eingesetzt werden. Hier sehen Sie ein Beispiel:
Redirect 301 /aktuelles/ http://www.suchmaschinentricks.de/aktuelles/news/
Wichtig ist, dass das Weiterleitungsziel als absolute URL mit führendem http:// anzugeben ist. Viele Clients akzeptieren zwar auch eine relative URL als Zielangabe, allerdings entspricht dies nicht der HTTP-Definition.
Wenn Sie Ihre Weiterleitung auf diese Art ausführen, sollte Google schnell bemerken, dass Sie Ihre Website umgebaut haben und die neuen Adressen in seine Datenbank aufnehmen.
Quelle: suchmaschinentricks.de
Tags: Cloaking, SEM, SEO, Suchmaschine