Why should I create a Ping profile when it’s sequestered in an app, offline, and impossible to link to or share via email?

Derek Powazek alias @fraying via Twitter. Gefunden im Artikel Social Design Lessons From Apple's Ping von Luke Wroblewski.

Mehr Worte braucht es nicht um zu hinterfragen, warum Apple die Anstrengung unternimmt, Applikationen wie Ping und z.B. den iTunes Store als geschlossene Systeme zu betreiben.

Zusammengefasst geht es darum, dass wir überlange (SEO optimierte) und bisweilen kryptische (garnicht optimierte) URLs, die sich keiner merken kann, mittlerweile dank bit.ly, ow.ly, tinyurl.com und anderen URL-Verkürzungsservices überwunden haben. Praktisch für Twitter, E-Mails und tatsächlich auch die mündliche Übermittlung.

Doch bei den Short-URL-Diensten sind wir eigentlich in eine User-Experience-Sackgasse gefahren. Denn langfristig kann es so nicht funktionieren.

Wir haben die Sicherheit die »echte« URL hinter einem Link direkt angezeigt bekommen, gegen eine gewisse Bequemlichkeit im Handling getauscht. Und die neueren URL-Verkürzer wie ow.ly, die die Originalseite nur noch in einem iFrame laden, machen die Sache noch schlimmer, da man die »echte« URL eigentlich garnicht mehr zu Gesicht bekommt. Gewiss, wir brauchen diese Sicherheit nicht immer, dass wir die Quelle verifizieren können. Aber wie es schon Jürgen Schmidt schreibt:

»Am schlimmsten daran finde ich jedoch, dass wir durch diese Trennung von URL und Inhalt leichtfertig die Arbeit von Jahren aufs Spiel setzen, in denen wir versucht haben, Anwendern zu erklären: ›Achtet darauf, was in der Adressleiste steht‹.«

Und da hat er vollkommen recht. Viele unserer begehrten Internetuser verstehen nicht wirklich was sie tun, sondern lernen Nutzungsmuster auswendig und spulen diese immer wieder ab. Die Macht der Gewohnheit. Deswegen sind ja auch Phishing-Attacken in der Vergangenheit so erfolgreich gewesen. Aber endlich haben viele (schmerzhaft) gelernt, eben nicht blind überall draufzuklicken, sondern vorsichtig zu sein und zu prüfen. Gerade bei kritischen Geschäften wie Online Banking, eBay, etc.

Doch nun kommen die URL-Verkürzer und machen diesen mühsam gelernten kritischen Blick schwierig bis unmöglich. Das kann man eigentlich nicht wollen. Ein erstes Artefakt, dass die URL-Verkürzer durchaus geignet sind schaden anzurichten, habe ich leider gelöscht.

Ich habe vor kurzem meine erste Phishing-Mail erhalten, die bat die angegebene Kurz-URL aufzurufen. Erklärt wurde die Verwendung einer Kurz-URL mit technischem Pseudo-Gewäsch, das auf den ersten Blick recht schlüssig klang. Jetzt könnte man sagen: Selber schuld, wer klickt schon auf Links in E-Mails fragwürdiger Herkunft. Da kann auch der URL-Verkürzer nichts für. Sicherlich richtig, aber der echte Anschein der verkürzten URL, macht es eben doch noch ein wenig schwieriger

Noch schwieriger wird es bei Browser-Exploits, bei denen der Besuch einer präparierten Website schon genügt, um den Schaden zu haben. Hier verhindern die URL-Verkürzer jede Vorprüfung. Da hilft nur nicht klicken. Und von nun an, sicherheitshalber einfach auf garkeine Short-URLs klicken? Das kann wohl kaum die Lösung sein. Was also tun, wenn wir weiter die Bequemlichkeit kurzer URLs haben wollen? Und das sicher und für viele User?

Über die Langlebigkeit einer Kurz-URL brauchen wir hier garnicht reden. Man erinnere sich an das mittlerweile Rückgängig gemachte verscheiden von tr.im. Mehr als schnelllebige Kommunikation ist nicht verlässlich zu bewerkstelligen. Ich warte auf den Tag, wo bit.ly, Hoflieferant der Twitter-Community, den Dienst einstellt und das Geschrei groß sein wird. Ein wenig mehr Verlässlichkeit braucht es schon, denn »Cool URIs don’t change«, und mit den Kurz-URLs verdoppeln wir das Problem einfach mal.

Eine brauchbare Lösung für diese Schwierigkeiten zeigt Jürgen Schmidt bzw. heise.de auch gleich auf:

Nicht zuletzt, um dieser Entwicklung etwas entgegen zu setzen, haben wir übrigens für Heise-Artikel eigene Kurz-URLs eingeführt. […] Und wenn es noch kürzer sein muss, funktioniert alternativ auch http://ct.de/-90345.

Die Quelle ist verlässlich, die URLs werden hoffentlich so lange bestehen, wie das Angebot unter der derselben Domain und werden sie genauso wünschenswerterweise auch nicht ändern.

Warum also nicht zukünftig bei der Konzeption von Websites, bei denen die Nutzung von Kurz-URLs für die sekundären Kommunikation höchstwahrscheinlich ist, dieses Feature gleich mit berücksichtigen und direkt Short-URLs zum Weiterbenutzen anbieten? Technisch kein größeres Problem, und die meisten Domains sind doch auch kurz und knackig.

Also, Kurz-URLs, wie wir sie heute kennen, sind eine Sackgasse – sie sind potentiell gefährlich oder sorgen für Verwirrung oder enden früher oder später im Nirwana. Doch der Bedarf an verlässlichen Kurz-URLs ist mit ein wenig Fantasie bei vielen Internetnutzern zu sehen. Die Idee, dass jeder Anbieter direkt Kurz-URLs anbietet ist da garnicht so schlecht – die dürfen dann auch gerne ab den »/« frei formulierbar sein, damit es bloß »social« und »user-generated« bleibt, wenn es denn sein muss.

Dieser Artikel ist unter dem Permalink http://uxzentrisch.de/sackgasse zu erreichen. Diese URL ist nicht ge-SEO-ed, aber das ist ein anderes Thema und vielleicht mein nächstes.

»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.