uxzentrisch erörtert:
Warum wir uns um URL-Weiterleitungen kümmern sollten. Ein Beispiel aus der Praxis.

Das Konzept »URL« ist einer der wesentlichen Bausteine, auf dem das Internet, wie wir es kennen, aufbaut. Höchste Zeit, dass wir uns mehr darum kümmern. Hier möchte ich gerne dafür sensibilisieren, dass eine URL ein sehr, sehr langes Leben führen kann – weit länger, als uns manchmal lieb ist. Und gleichzeitig ein bisschen über unsere Aufgaben sprechen, wenn wir als UX-Verantwortliche uns mit dem Thema befassen wollen.

»Cool URIs don’t change«

ist der Titel eines Artikels von Tim Berners-Lee. Mehr Wunsch als Wirklichkeit ist das. Das echte Leben ist bei weitem nicht so perfekt. Permanent zwingen uns technische Überarbeitungen von Websites, inhaltliche Aspekte, konzeptionelle Überlegungen, neue Content Management Systeme und viele andere Gründe, URLs von Ressourcen im Web zu verändern.

Manchmal ändern URLs sich eben. Ein Beispiel.

So haben wir beispielsweise bei unserem Kunden Kölner Weinkeller, einem Online-Weinhändler, im Zuge der Weiterentwicklung die alte Logik der Sortimentsnavigation und -suche komplett überarbeitet und in einem neuen Suchinterface vereint. Mit der logischen Veränderung haben sich notwendigerweise auch die URLs verändert, da Navigation und Suche vorher auf zwei verschiedenen Seiten verankert waren und nun zu einer zusammengefasst wurden. Hinzu kam, dass nicht alle Suchparameter der vorherigen Logik sich in der neuen Suche wiederfanden. Ein Beibehalten der alten URLs schied somit aus.

Das Resultat war, dass über 55.000 URLs von Sortiments- und Suchergebnisseiten, die Google bis dahin im Index hatte, von einem Moment auf den anderen ihre Gültigkeit verloren. Ebenso Bookmarks von Nutzern, Links von anderen Seiten und URLs in E-Mails.

Für Nutzer muss das kein Drama sein.

Für die Nutzer war das glücklicherweise weitgehend ohne Bedeutung, da wir mittels Rewrite-Regeln praktisch alle Aufrufe der alten URLs zu den neuen URLs weiterleiten ließen. (Die Liste der Rewrite-Regeln umfasst knapp 900 Einträge, da jede einzelne Shop-Kategorie darin individuell behandelt wird. Das erstellen dieser Regeln ist Arbeit, die man durchaus mit einplanen und automatisieren sollte.)

Beispiel einer Rewrite-Regel:

RewriteCond %{QUERY_STRING} id=114&cat=1866$ [OR]
RewriteCond %{QUERY_STRING} id=114&cat=1866&
RewriteRule ^index\.php http://www.koelner-weinkeller.de/index.php?id=sortiment&fq[]=fc_weingut:%22Bodegas+Dominio+Eguren%22 [R=301,L]

Von der Trägheit Googles

Heute, über 4 ½ Monate nach der Umstellung auf die neue Suchlogik, sind noch immer URLs der alten Sortiments- und Suchergebnisseiten im Google Index zu finden. Wir haben über entsprechende Suchabfragen (alte Seiten, neue Seiten) beobachtet, wie schnell (oder wie langsam) Google die neuen URLs in den Index aufgenommen und die alten verbannt hat.

Die Grafik zeigt die Anzahl der alten und neuen URLs über die Zeit, beginnend in der vierten Woche nach der Änderung, Woche für Woche.

Google hat in dem beschriebenen Fall pro Woche etwa 3.200 alte URLs augemistet und 3.800 neue URLs aufgenommen. In der Zwischenzeit haben Nutzer entweder einen alten Suchergebnistreffer (mit Weiterleitung dahinter) vorgefunden oder einen neuen. Die Geschwindigkeit, mit der alte gegen neue URLs ausgetauscht wurden, war offensichtlich die meiste Zeit annähernd gleichbleibend. Erst jetzt, wo noch knapp 1.000 alte URLs übrig bleiben, stagniert der Vorgang. Woran auch immer das liegt, wir warten gespannt darauf, wie lange Google diese letzten Einträge noch aufbewahren möchte.

Ist das wichtig?

Wenn URLs von Webseiten, wie hier bei einem Online-Shop, direkt zum Kauf von Produkten führen sollen, dann versteht sich von selbst, dass man einen gewissen Aufwand betreiben kann, um vernünftige Weiterleitungen einzurichten.

Aber auch wer nicht direkt den Absatz von Produkten über das Internet im Sinn hat, sondern lieber Informationen an den Mann bringen möchte, tut gut daran, sich Gedanken über URLs als langlebige Zugänge zum eigenen Angebot zu machen. Auch unter SEO-Gesichtspunkten ist es sinnvoll, eingehende Links auf eine tatsächlich existierende Seite umzuleiten, damit diese Links sich weiterhin positiv auf den PageRank der Site auswirken können.

Auch, wenn man damit nicht gerade ein Wow-Erlebnis erzeugt, ist die langfristige URL-Pflege letztlich natürlich auch ein Dienst an der Zufriedenheit der Besucher. Wer beispielsweise den Link zu einer Pressemeldung von vor 10 Jahren weiterhin funktional hält, bereitet möglicherweise dem einen oder anderen Nutzer zuvorkommend den Einstieg in eine Entdeckung auch aktuellerer Themen.

Bestandsaufnahme

Wichtig genug sind URLs also, auch die alten. Wie aber pflegt man sie? Tatsächlich ist es gar keine so einfache Aufgabe, überhaupt in Erfahrung zu bringen, welche URLs von einer Site da draußen überhaupt existieren.

Im Fall der Sortimentsnavigation im Online-Shop war die Angelegenheit relativ einfach, da die URLs systematisch durch verschiedene Parameter aufgebaut werden. Sämtliche Parameter sind in diesem Fall bekannt, also sind auch die möglichen URLs bekannt. Wo es also beispielsweise um eine Datenbank mit News-Meldungen geht, könnte diese Systematik nützlich sein.

Aber nicht immer sind URLs systematisch aufgebaut. Hier helfen die Logfiles des Webservers ein gutes Stück weiter. Webserver Logfiles sind Textdateien, die üblicherweise für einen bestimmten Zeitraum zu jedem Aufruf des Servers einige Informationen enthalten, die entscheidend für unsere Aufgabe sind:

  • Pfad der abgefragten Ressource
    Z.B. »/« für die Startseite oder »/meine/unterseite« – also alles, was nach »http://meinesite.de« die URL ausmacht.
  • HTTP Status-Code der Anfrage
    Hier steht z.B. »200″ für einen normalen Aufruf und »404″ für den Fehler »Not Found«.
  • Herkunfts-URL der Anfrage
    Engl. »Referer«. Daran können wir sehen, woher der Besucher kam, falls er einem Link gefolgt ist.

Damit lässt sich schon mal die Frage, welche URLs der Site tatsächlich aufgerufen werden, beantworten. Je mehr Logdaten man hierbei einbezieht, also je größer der betrachtete Zeitraum, desto eher nähert man sich der Vollständigkeit an.

Anhand der Logdaten können wir als nächstes 404-Fehler auffinden und feststellen, ob sie durch Links von anderen Websites ausgelöst wurden. Hierbei handelt es sich recht wahrscheinlich um URLs, die früher einmal funktionierten, in selteneren Fällen handelt es sich um Schreibfehler. In beiden Fällen kann durch Weiterleitungen dafür gesorgt werden, dass Nutzer statt zu einer Fehlermeldung auf eine sinnvolle Seite geführt werden.

Logfiles müssen natürlich nicht zwingend mit dem bloßen Auge im Texteditor ausgewertet werden. Es gibt sicherlich eine Menge Tools, welche die oben beschriebenen Aufgaben erleichtern. (Ich kenne leider kein wirklich brauchbares. Wer Empfehlungen hat, ist herzlich eingeladen, diese als Kommentar beizusteuern.)

Alternativen (oder Ergänzungen) zur Logfile-Analyse sind die Google Webmaster Tools und Yahoo! Site Explorer. Die Webmaster Tools bieten zum Beispiel eine Auflistung von 404-Fehlern, auf die der Googlebot beim Indexieren gestoßen ist. Die verweisende Website wird mit angezeigt. Site Explorer listet je Site bis zu 1.000 URLs  auf, die der Crawler kennt und findet. Diese Liste ist augenscheinlich nach Relevanz sortiert und kann auch exportiert werden.

Richtig durchleiten

Sobald man weiß, auf welche URLs zugegriffen wird, kann man mit Hilfe von Weiterleitungen Nutzern sowie Suchmaschinen-Robots helfen, die gesuchten Inhalte zu finden. Nicht immer sind eins-zu-eins-Mappings möglich. In diesem Fall ist eine inhaltliche Entscheidung zu treffen, auf welche neue URL stattdessen zu leiten ist.

Zum Weiterleiten eines Nutzers auf eine bestimmte URL gibt es zahlreiche Möglichkeiten. Will man aber auch Suchmaschinen berücksichtigen, gibt es nur einen vernünftigen Weg: Die Weiterleitung mittels HTTP 301 Redirect. Diese im HTTP-Protokoll festgelegte Antwort teilt Browsern und Robots mit, dass eine Ressource nicht länger an der aufgerufenen Adresse gefunden werden kann, sondern permanent unter der neuen Adresse aufzufinden ist. Suchmaschinen werden dadurch veranlasst, ihren alten URL-Eintrag gegen den neuen zu ersetzen.

Eine Möglichkeit, solche Redirects zu erzeugen, wurde bereits genannt: Die Erstellung von Rewrite-Regeln. Wer Apache nutzt, aber nicht mod_rewrite nutzen kann oder will, kann möglicherweise auf die einfacheren Möglichkeiten des Moduls mod_alias zurückgreifen. (Auch hier lade ich gerne dazu ein, die Kommentare um Hinweise zu weiteren Methoden zu bereichern.)

Unterm Strich

URL-Pflege ist wichtig und macht Arbeit. Wer sich damit näher beschäftigt hat, wird einiges tun, um sich einer besseren Welt anzunähern. Denn dort sind URLs cool. Und coole URLs ändern sich nicht. Aber darüber reden wir ein anderes mal.

14 Kommentare

Ingo vor 6 Jahren

Zur Google-Trägheit: Sendet ihr eine Sitemap an Google oder laßt ihr nur crawlen? Und dann ist da glaube ich ein Fehler im [OR] (2mal gleiche Bedingung).

Marian Steinbach Autor vor 6 Jahren

Der Weinkeller hat eine XML-Sitemap, darin sind aber die oben besagten Seiten nicht enthalten, sondern nur die Produkt-Detailseiten.

Die beiden RewriteCond-Zeilen unterscheiden sich in einem Zeichen, nämlich in $ vs. & am Ende des Ausdrucks. (Würde man nur id=114&cat=1866 suchen, würde der Ausdruck z.B. auch bei id=114&cat=18660 zutreffen.)

Ingo vor 6 Jahren

What about [$&] ? Schöner Artikel übrigens.

Marian Steinbach Autor vor 6 Jahren

Werde ich bei Gelegenheit ausprobieren. Wusste nicht, ob man das $ (für String-Ende) so mit klammern kann. Danke!

antwort42 - Daniel Rosner vor 6 Jahren

Marian, vielen Dank für den Artikel. Ich wusste bisher nicht richtig wie das Thema bei Kundenprojekten angehen. Dank Deines Artikel kann ich nun die hoffentlich richtigen Fragen stellen und passende Antworten finden.

Laufhannes vor 6 Jahren

URL-Umleitungen sind für solche Änderungen in der Struktur enorm wichtig. Nichts ist da ärgerlicher, als irgendwelchen Links oder Bookmarks zu folgen und dann zu sehen, es hat sich alles geändert und man landet nicht mehr dort, wo man landen wollte.

Die Weiterleitungs-Regeln habe ich bei meiner letzten Änderung allerdings lieber über PHP und Datenbank geregelt, 900 Einträge in der htaccess klingt für mich sehr umständlich.

PHP Gangsta vor 6 Jahren

Man kann auch mit Hilfe der Applikation das Rewriting machen falls man nicht mit mod_rewrite/mod_alias arbeiten möchte und dort 900 Einträge hinzufügen möchte.

Im Falle von PHP+Zend Framework kann man das relativ simpel mit Hilfe des »Zend_Controller_Router« machen und dann einen 301 Redirect erzeugen.
Ich kann es gerade nicht ausprobieren, aber das sieht dann ungefähr so aus:

$router->addRoute(
›oldUrls‹,
new Zend_Controller_Router_Route(‹id=114&cat=:cat‹,
array(‹controller‹ => ›rewriter‹,
›action‹ => ›rewrite‹))
);

public function rewrite()
{
$cat = $this->_getParam(‹cat‹);
$this->_redirect(‹/neueUrl/cat/‹.$cat, array(‹code‹ => 301));
}

Ich hoffe das ist halbwegs richtig.

Aber nach wie vor ist die zu bevorzugende Methode die Apache-Methode, dann braucht dafür nicht extra PHP angeworfen zu werden.

Marian Steinbach Autor vor 6 Jahren

Nett, da habt Ihr beide in die gleiche Kerbe gehauen. (Tut mir leid, aber PHP-Code in Kommentaren funktioniert aufgrund der Übersetzung von Anführungszeichen nicht so prima…)

Umständlich war das Erzeugen der Rewrite-Regeln nicht, weil wir es per Script (Ja, mit PHP :-) gemacht haben. Von Hand hätte ich das sicher nicht machen wollen.

Nicolay vor 6 Jahren

Sehr cooler Artikel, Danke Marian.
Aber Frage: Was ist mit dem ?

Marian Steinbach Autor vor 6 Jahren

Hallo Nicolay! Danke! Meinst Du mit Deiner Frage das Fragezeichen in der dritten Zeile der Rewrite-Regel? Das gehört ja zur neuen URL, als Trenner zwischen Dateiname »index.php« und dem folgenden Query String. Dort darf eigentlich auch kein Zeilenumbruch sein, das brechen die Browser nur ungünstig um. Mal sehen, ob ich unser CSS entsprechend otpimieren kann, so dass keine Umbrüche entstehen.

Nicolay vor 6 Jahren

Hi Marian,

nein, eigentlich ich meinte das Canonical Tag von Google und Co. Der kopierte Code-Schnipsel wurde aber anscheinend gelöscht und nur noch das Fragezeichen vom Blog-CMS stehen gelassen ;)

Lieben Gruß
Nicolay

Trackbacks und Pingbacks