Und weiter geht es mit Artikeln aus der WEBeLINE – erschienen in der Juniausgabe 2009.
Unternehmen und Angebote verändern sich – die zugehörigen Internetauftritte meist auch. Doch der so genannte Relaunch birgt neben einer Vielzahl von technischen Herausforderungen auch aus der Sicht der Suchmaschinenoptimierung eine Vielzahl von Tücken und Stolpersteinen. Insbesondere bereits bestehende Suchmaschinenrankings können sich nachhaltig verschlechtern oder gar ganz verschwinden, wenn nicht die richtige Strategie gewählt wird.
Die Wahl des richtigen CMS
Die häufigsten Probleme bringt meist der Wechsel des Content-Management-Systems (CMS) mit sich. Hier empfiehlt es sich, vorab zu prüfen, ob das CMS auch grundlegende Anforderungen für eine Suchmaschinenoptimierung erfüllen kann:
- URL Struktur
- Sind „sprechende“, frei definierbare URLs möglich?
- Werden die URLs ohne Session IDs abgebildet?
- Accessibility
- Ist es grundsätzlich möglich, die Seite ohne das „zwingende“ Annehmen eines Cookies zu betreten?
- Generiert das CMS „sauberes“ HTML Mark-up, basierend auf den offiziellen Standards des W3C?
- Verzichtet das CMS bei der Einbindung wichtiger Elemente – wie z.B. der Navigation – auf Flash und JavaScript (oder wird eine alternative Version für Crawler generiert)?
- Meta Tags & Seitentitel
- Ist es möglich, den Seitentitel pro URL frei zu definieren?
- Können Meta Description (und Keywords) sowie das Robots Meta Tag pro Seite verwendet werden?
Migration von bestehenden URLs
Im Regelfall verändert sich bei einem Relaunch meist auch die URL-Struktur der Website und dies kann die Suchmaschinen vor große Probleme stellen. Optimal wäre es aus Sicht der Suchmaschinen, wenn sich eine URL niemals ändert, denn sie dient für Suchmaschinen als eindeutiges Identifikationsmerkmal im WWW – mit ihr sind direkt Rankings sowie auch Verlinkungen verknüpft.
Ändert sich eine URL, ist es also erforderlich, die Suchmaschinen hier zu unterstützen. Grundsätzlich empfiehlt es sich, alle alten URLs mittels eines HTTP 301-Redirects auf das jeweilige, neue Pendant umzuleiten. Dies kann z.B. mittels „mod_rewrite“ (Apache Webserver) oder „ISAPI Rewrite“ (Microsoft IIS Webserver) realisiert werden. Ein Beispiel:
RewriteEngine on
RewriteRule ^/alte/produkte/([0-9]+)/?$ /produkte/$1 [R=301]
Der Apache Webserver würde in diesem Fall alle Anfragen der Form http://domain.de/alte/produkte/1234/ auf http://domain.de/produkte/1234/ umleiten.
Dieses Vorgehen empfiehlt sich für alle bekannten und aktiv auf der Seite verwendeten URL Muster. Wenn Sie nicht sicher sind, welche URLs Ihrer Website Google bereits bekannt sind, empfiehlt sich auf jeden Fall ein Blick in die Google Webmaster Tools (dort könnten Sie z.B. die extern verlinken URLs verwenden) oder in den Yahoo! Site Explorer.
Außerdem hilft auch Google selbst. Eine Suchanfrage der Form „site:domain.de“ verrät Ihnen, welche Seiten Ihrer Website Google kennt – werden dort mehr als 1.000 Ergebnisse angezeigt, sind weitere Einschränkungen bzw. Verfeinerungen z.B. mittels Kombination von zusätzlichen Suchparametern möglich: „site:domain.de inurl:pfad“, etc.
Trifft der Webcrawler nun nach dem Relaunch auf eine solche URL-Weiterleitung, wird die URL im Suchindex aktualisiert – gleiches gilt für die Meta Description sowie auch den Seitentitel. Bitte beachten Sie: Die Redirects jetzt dennoch keinesfalls abschalten! Warum fragen Sie? Externe Verlinkungen werden mittels der Redirects an die neue Seite weitervererbt – sie profitieren also nach wie vor von der externen Verlinkung. Auch Dinge, wie z.B. der Google PageRank werden mittels des Redirects weitervererbt.
404 Error Handling
Insbesondere bei einem Relaunch empfiehlt sich die Verwendung einer eigenen 404-Fehlerseite, denn oftmals passiert es auch, das URLs bei der Umstellung z.B. vergessen werden und die Rewrite-Regeln nicht auf alle gewünschten Muster passt. Aus diesem Grund ist es erforderlich, die Fehlerseite mit dem Tracking Code Ihrer Web-Analytics Software zu versehen, um bei häufigen Fehlern schnell reagieren zu können. Dazu empfiehlt sich die folgende Vorgehensweise:
- Erstellen einer neuen HTML Seite, welche einen entsprechenden Hinweis beinhaltet, dass die gewünschte Seite nicht gefunden wurde
- Die HTML Seite wird mit einem Robots Meta Tag versehen, um die Indizierung zu verhindern: <meta content=”noindex,follow” />
- Das Tracking wird auf der Fehlerseite angepasst, um auch Informationen wie Ursprungs-URL sowie Referer zu speichern
Verwenden Sie z.B. Google Analytics, so muss die Funktion pageTracker._trackPageview(); entsprechend modifiziert werden:
pageTracker._trackPageview("/error/404.html?page=" + document.location.pathname + document.location.search + "&from=" + document.referrer);
Mehr dazu bei Google in der Hilfe. Vergessen Sie am Ende nicht, per .htaccess oder direkt in der Apache-Konfiguration die Fehlerseite zu definieren:
ErrorDocument 404 http://domain.de/error/404.html
Aktualisieren der Sitemap
Eine weitere Hilfe, um die Neu-Indizierung zu beschleunigen, sind die so genannten XML-Sitemaps. Innerhalb dieser Sitemap(s) werden die einzelnen URLs einer Website in maschinenlesbarer Form aufgelistet. Es empfiehlt sich, einige Tage vor dem Relaunch die vorhandene XML-Sitemap offline zu nehmen (löschen Sie diese auch aus den Google Webmaster Tools) und übermitteln sie direkt nach dem eigentlichen Relaunch eine neue Sitemap an Google und die anderen Suchmaschinen. Die Crawler besuchen dann oftmals in relativ kurzer Zeit weitaus mehr neue URLs, wo hingegen der normale Crawling-Vorgang meist deutlich länger dauert, da die Suchmaschinen die neuen URLs ja erst einmal finden müssen.
Die Live-Schaltung
Abschließend noch einige Worte zur eigentlichen Live-Schaltung bzw. dem Parallelbetrieb einer Test Version („Pre-Release“): In den meisten Fällen, ist es gängige Praxis, dass die neue Seite bereits vor dem eigentlichen Start unter einer anderen (Sub-) Domain im WWW verfügbar ist. Grundsätzlich ist das völlig unproblematisch – allerdings sind Suchmaschinen sehr „neugierig“ und selbst wenn diese Pre-Release Domain nicht verlinkt ist, kommt es vor, dass die Inhalte ab und an ungewollt in den Suchmaschinen auftauchen und damit Duplicate Content Probleme verursachen.
Nutzen Sie also entweder einen Passwortschutz auf der Testdomain oder sperren Sie die Seite mittels einer eigenen robots.txt Datei („Disallow: /“) für die Indizierung durch die Webcrawler.
