URL-Design
Ein paar unvollständige Gedanken zu besser auffindbaren Webseiten.
URL-Design: Suchmaschinen-freundlich ist gut. User-freundlich ist besser.
In Usability-Seminaren sind manche Teilnehmer ziemlich erstaunt, wenn sie den Begriff »URL-Design« hören. Oft glaubt man, dass URLs als Dateinamen gar nicht beeinflussbar seien, und wenn überhaupt, dass das doch ein Fall für die Suchmaschinen-Optimierer sei. Und was das denn mit dem Besucher zu tun habe – Hauptsache, der Browser zeigt den richtigen Inhalt an.
Sprechende Links
Suchmaschinenpräsenz ist in der Tat ein wichtiges Content-Usability-Kriterium. Viele Suchmaschinen mögen beispielsweise keine Session-IDs – man hat ihren Bots eingeimpft, weder Frage- noch Dollarzeichen von Fremden anzunehmen. Wenn beispielsweise ein CMS solche kryptischen URLs generiert, empfiehlt es sich, sie serverseitig umzuschreiben.
Nur den Suchmaschinen zuliebe? Suchmaschinen-freundliche URLs sind nämlich noch lange nicht benutzer-freundlich. Wenn wir den unleserlichen URL urlaub.com/index.php?74638&7xqr$1 umschreiben zu urlaub.com/index/74638/7xqr/, dann hilft das sicher einigen Suchmaschinen-Crawlern. Wir einfachen User hätten es jedoch mit dem Schema urlaub.com/fernreisen/malediven/ wesentlich einfacher. Es würde uns sogar stärker aktivieren, auf einen solchen Link zu klicken.
Ein »sprechender Link« löst in der Regel eine Erwartungshaltung aus: Man erwartet, den entsprechenden Inhalt aufzufinden. Die Aussicht auf Erfolg lässt uns sogar längere Wartezeiten in Kauf nehmen. Besser merken können wir uns solche Links obendrein. Und wenn dann der Seiteninhalt mit der Linkbezeichnung korrespondiert, womöglich auch in den ersten h1- und h2-Überschriften, dann freut das wiederum die Suchmaschine.
Absolute vs. relative Links
Deren Bots sind völlig merk- und intelligenzbefreit. Also sollte man das Bestmögliche tun, sie in ihrer Arbeit zu unterstützen; schließlich können sie nichts dafür. (Deshalb empfiehlt es sich übrigens, zuallererst an die robots.txt denken; man will ja nicht alles auffindbar machen.) Dabei hilft ganz fundamental die interne Verlinkung.
Relative Linkpfade (à la ../../../fernurlaub/malediven/) werden zu gern und zu schnell mal falsch gesetzt. Spätere Veränderungen in der Verzeichnisstruktur ziehen auch zwingend Anpassungen an den Pfaden nach sich. Und selbst wenn man alle Pfade richtig setzt: Irgendein Bot wird früher oder später irritiert ankommen und einfach gar nichts kapieren. Das müllt nicht nur die Error-Logs zu, sondern kann sich auf die Platzierung in den SERPs auswirken.
Absolut gesetzte (à la /fernurlaub/malediven/) anstelle von relativ gesetzten Links gehen nicht vom aktuellen Verzeichnis, sondern vom Root-Level (Wurzelverzeichnis) aus. So stellt man sicher, dass irgendwelche dahergelaufenen Crawler/Spider/Bots auch alles richtig indexieren. Und spätere Veränderungen fallen leichter, wenn beispielsweise die Dateien in ein höheres, niedrigeres oder anderes Verzeichnis verschoben werden. Auch das kann passieren – spätestens mit dem kommenden Redesign, dem neuen CMS oder einfach der neuen Projektleitung. Übrigens: Je weniger Verzeichnisebenen, umso besser. Denn mit jeder neuen bzw. tieferen Ebene zieren sich die Bots mehr, dort hinabzucrawlen.
Weiterleitungen
Wenn dies geschieht, steht man vor einer neuen Situation: Jetzt geht es nicht mehr darum, seine Seiten von den Suchmaschinen indexieren zu lassen, sondern darum, die hart erarbeiteten Positionen in den Suchmaschinen zu behalten, vielleicht sogar zu verbessern. Und außerdem sollen Bookmarks und alte Links keine frustrierende 404-Not-found-Fehlerseite ausspucken, sondern doch bitte gefälligst jetzt und sofort zur aktuellen Seite weiterleiten.
Cool URIs don't change, wünscht sich WWW-Erfinder Tim Berners-Lee. Recht hat er. Manchmal geht es jedoch nicht anders; vor allem, wenn es sich eben nicht um »cool URIs« handelt. Damit dies nicht zu einem Suchmaschinen-Desaster führt und auch die Website-Besucher nicht von einem Haufen Fehlermeldungen abgeschreckt werden, sollten permanente Weiterleitungen eingesetzt werden.
Hierzu gibt es verschiedene Möglichkeiten von Javascript über Metarefreshs bis hin zum PHP-Aufruf. Die beste aller Möglichkeiten ist ein serverseitiger Redirect, der sogenannte Redirect 301 beziehungsweise RedirectPermanent. Ein kleiner Eintrag in der .htaccess-Datei pro betreffendes Dokument ist alles:
RedirectPermanent /alte-datei/ http: //meine-domain.de/neue-datei.phpMan kann auch Redirect permanent oder Redirect 301 schreiben; das hat alles denselben Effekt: der Server weist auf Verlangen darauf hin, dass die abgerufene Seite für immer umgezogen ist, und zwar an den URL, den er umgehend ausliefert. Wenn es nicht für immer, sondern nur vorübergehend sein soll, ersetzt man das Permanent einfach durch ein simples Temp. Der Besucher selbst merkt davon nichts; nicht einmal eine Zeitverzögerng.
Wer keinen Zugriff auf seine .htaccess-Datei hat, kann in die alte Datei einen PHP-Aufruf setzen:
header("HTTP/1.1 301 Moved Permanently");
header("Location: http: //meine-domain.de/neue-datei.php");
exit();[Anmerkung: Das Leerzeichen vor den beiden Slashes // muss wieder rausgelöscht werden.] Kein Javascript, kein Meta-Refresh! Dafür sind selbst die gefräßigsten Bots nicht programmiert. Und das ist gut so.
Inhaltsverzeichnis
Wer eine sehr allgemeine oder nicht gerade web-affine Zielgruppe bedient, nennt seine Sitemap Inhalt oder Inhaltsverzeichnis. Sie bedient allerdings auch ausgehungerte Bots. Deshalb tut man gut daran, die Sitemap möglichst weit oben im Verzeichnislevel zu platzieren (z.B. meine-domain.de/inhalt.php). So ist es nur noch eine Frage der Zeit, bis auch Dummy-Bots die neuen Seiten gefressen haben. Zudem kann man in seinem Inhaltsverzeichnis schön und unbescholten seine Keywords platzieren. Achten sollte man darauf, dass die Linktexte erwartungskonform sind: Ein Link, der sich »Reisebericht Malediven« nennt, sollte nicht auf eine Seite führen, deren h1-Überschrift und Titel den Besucher mit »Willkommen auf der Partnerseite« begrüßen.
Eindeutig bringt mehr
Nicht nur die Sprache sollte also eindeutig sein, auch der jeweilige Dokumenten-Inhalt. Besonders Suchmaschinen-Nutzer legen ein auffälliges Verhalten an den Tag, was die Informationsverarbeitung betrifft. Sie haben ein klares Ziel, nämlich Informationen zu ihrem gerade eingegebenen Suchbegriff zu finden. In den SERPs erscheinen Links mit einer Kurzbeschreibung; je nach Suchmaschine findet der User vier bis sechs Ergebnisse direkt im Viewport seines Browsers vor. Mehr interessiert ihn erst einmal nicht; er klickt auf den vielversprechendsten Link.
Viele Faktoren lassen sich jetzt schön beobachten:
- Ist es ein sprechender Link? Wenn ja, sind die Chancen hoch, dass der User auch mal länger wartet als bei anderen Ergebnissen. Sogenannte Power-User klicken auch mal bei kryptischen URLs gleich in den Google-Cache.
- Wird ein Frame neugeladen, gelangt man gar auf einen Splash-Screen, findet eine sichtbare Weiterleitung statt? Oftmals sind solche Seiten schon zugeklickt, bevor sie überhaupt geladen sind.
- Korrespondiert die gefundene Seite mit den Suchbegriffen oder wenigstens mit der Beschreibung in den SERPs? Wenn ja, gut. Wenn nein, schlecht. Noch ist der User ungeduldig, weiß, dass noch viele andere, womöglich relevantere Suchergebnisse auf ihn warten. Also zurück und zum nächsten Ergebnis: Googlehupf! Das ist besonders schade, wenn der gesuchte Inhalt sich vielleicht auf der Website eine Seite weiter findet. Hier haben Texter und SEO (Suchmaschinen-Optimierer) geschludert: Sie sind nicht eindeutig gewesen.
Fazit: Suchmaschinen-User haben nicht nur ein sehr klares Ziel, sondern auch nervöse Finger. Den Zurück-Button und das Schließen-Kreuz finden sie mit geschlossenen Augen. In der Konsequenz bedeutet das, dass das, was draufsteht, auch drin sein sollte. Seitentitel, Überschriften und Inhalt sollten eindeutig miteinander korrespondieren. Ausnahmen bestätigen die Regel.
Eindeutiges, kanonisches URL-Schema
Durch Beate Palands Beitrag www is deprecated wurde ich überhaupt erst zu diesem Artikel inspiriert. Die Problematik ist ganz einfach: Viele Ressourcen verderben den Brei. Ein Inhalt, der sowohl über die Default-Datei (index.htm, index.php...), über das Verzeichnis, über eine Subdomain und über eine Weiterleitung erreichbar ist, hat ein Problem: Es gibt denselben Inhalt gleich mehrfach.
- http://meine-domain.de/
- http://meine-domain.de/index.php
- http://meine-domain.de/weblog/
- http://meine-domain.de/weblog/index.php
- http://www.meine-domain.de/
- http://www.meine-domain.de/index.php
- http://www.meine-domain.de/weblog/
- http://www.meine-domain.de/weblog/index.php
Alle diese Dateien zeigen auf einen einzigen Inhalt. Das ist nicht gut.
Je weniger Ressourcen auf einen Inhalt zeigen, umso besser für User und Suchmaschinen. Christoph Schneegans ist noch konsequenter und schreibt über Kanonische Adressen: »Verwenden Sie [...] eine URL für eine Ressource.«
Das ist gut für den Pagerank, für den User und für den Gedanken, dass jede Seite nur einmal vorhanden sein sollte. Wer im Nachhinein nur unter einer Adresse erreichbar sein will, informiert sich am besten zunächst darüber, mit welcher Adresse man in den wichtigen Suchmachinen am stärksten verzeichnet ist.
Da die großen Suchmaschinen zunächst nach der kanonischen Seitenversion suchen, sollte man auch nur auf diese verlinken und nicht auf die Default-Dateien. Ein href="/" ist also womöglich wesentlich sinnvoller als ein href="../index.php".
Darüber hinaus sind kurze URLs nicht nur ästhetischer, sie sind auch der E-Mail-Usability zuträglich. Viele Mail-Clients schneiden Zeilen nach 72 Zeichen ab; ganz schnell ist der versendete Link nicht mehr anklickbar. Dass man am Telefon kürzere Links schneller und fehlerfreier transportieren kann, sei hier nur am Rande erwähnt.
Kürzere URLs erreicht man auch durch das Abschneiden der Dateiendungen (via Content Negotiation oder über das Apache-Modul mod_rewrite). Das hat weniger was mit Ästhetik zu tun: Vielleicht bringt der nächste Relaunch oder das nächste CMS die Umstellung auf PHP, ASP, SSI oder was auch immer mit sich. Dann freut man sich über soviel Weitsicht.
Außerdem ist der URL ein Teil des Web-User-Interfaces, sagt Jakob Nielsen. Und weil das so ist, sollte eine Website nicht nur über einen einfach zu merkenden Domain-Namen verfügen, sondern auch über kurze URLs, die sich einfach tippen lassen und die Struktur der Website abbilden. Darüber hinaus sollten sie »hackable« sein, dem User also erlauben, sich durch Herauslöschen des Dateinamens im Browser-Adressfeld in die nächsthöhere Verzeichnisebene zu bewegen. Und außerdem fordert Nielsen P-URLs, persistente URLs, oder wie Berners-Lee viel einprägsamer ausdrückt: »Cool URIs don't change.« (P-URLs werden in der Blogosphäre Permalinks, permanente Links oder kurz Plinks genannt, was einprägsamer ist, die Sache allerdings nicht wirklich auf den Punkt bringt.)
Gutes URL-Design zeichnet also nicht nur eine intelligent verwaltete Site-Struktur ab, sondern legt gleichzeitig dem Website-Besucher ein nützliches Kommunikations- und Orientierungs-Tool in die Hand. Jesse James Garrett von Adaptive Path schreibt dazu in seinem Artikel User-Centered URL Design: »Recognizing that people really do read URLs – and, in turn, making those URLs easy for people to read – is really just an extension of the user-centered philosophy of design.«
Mehr lesen:
- w3.org, Choose URIs wisely
- Thomas A. Powell, Towards Next Generation URLs
- IBM, The Cranky User, Making URLs accessible
[via Sascha Carlin] - Fabian Wolf: PHP-basierte Alternative zu mod_rewrite
Trackbacks
Trackback-URI für diesen Eintrag:
http://www.web-blog.net/pingserver.php?p=tb&id=122
Trackbacks:
URL-Design
Nach längerer Blog-Abstinenz meldet sich Usability Inside in den letzten Tagen wieder häufiger zu Wort. Diesmal macht man sich dort Gedanken über sprechende Links der Form urlaub.com/fernreisen/mal...
Webmaster Blog (31.01.2004 | 23:05)
Content Management Systeme
Über dogfood bin ich auf einen interessanten Artikel gestoßen (aus Klaus Schallhorns exzellentem Suchmaschinen-Newsletters), in dem mal Tacheles über den Einsatz von CMSen geredet wird. Für den Großteil der Websites ist ein CMS einfach vollkommen überd...
hessis weblog (01.02.2004 | 23:00)
URL-Design und www.-Problematik
Marcus Völkel schrieb mal (31.01.04) über URL-Design:
In Usability-Seminaren sind manche Teilnehmer ziemlich erstaunt, wenn sie den Begriff »URL-Design« hören. Oft glaubt man, dass URLs als Dateinamen gar nicht beeinflussbar seien, und wenn ...
Michels Weblog. (10.06.2005 | 22:16)
Pingbacks
Kommentare
Hallo Marcus,
ich finde den Artikel sehr interessant und gut. Nur stellt sich mir die Frage ob es sich lohnt bei kleinen Sites (20-30 Seiten) extra Unterordner anzulegen? Oder ob es nicht reichen würde die einzelnen Seiten Usybility und Suchmaschinen freundlich zu benennen (z.B. fernurlaub_malediven.html).
gruß
Ferit Koc
Ferit, wenn die Inhalte bei kleinen Sites jeweils keine weiteren Unter-Inhalte bzw. Unterseiten haben, reicht das sicher. Ich persönlich finde Unterordner jedoch übersichtlicher und auch weitsichtiger. Es gibt einfach zuviele wirklich umfangreiche Websites, die einmal nur aus 20 bis 30 Seiten bestanden haben ;-)
Den Unterstrich im Dateinamen würde ich übrigens gegen einen Bindestrich austauschen. Offenbar wertet Google den Bindestrich tatsächlich als Trennung der beiden Schlüsselwörter.
Wieso so negativ den Suchmaschinenoptimierern gegenüber?
Viele würden die URLs sicher auch gerne dahingehend ändern so dass diese eine Nachricht transportieren, nur muss ein SEO bei solchen Belangen meist gegen einen Webmaster und/oder eine Agentur ankämpfen. Und da lässt man es meist lieber...
Ansonsten ein toller Artikel.
Negativ den SEOs gegenüber? Ich? Wo? Ähm, ich zähle mich immer zu denjenigen, die - ganz interdisziplinär - Texter und SEOs an einen Tisch bringen wollen. Habe ich mich irgendwo missverständlich ausgedrückt?
Bei mir entstand beim ersten Lesen der Eindruck, SEOs (Search Engine Optimization = Suchmaschinenoptimierung) seien zwar in der Lage aus urlaub.com/index.php?74638&7xqr$1 ein urlaub.com/index/74638/7xqr/ zu machen, aber keine sprechende URL ala urlaub.com/fernreisen/malediven/. Das mag in der Praxis zwar oft so sein, liegt dann aber eher am begrenzten Budget (und damit der vorhandenen Zeit) oder an der Unwilligkeit eines/r Verantwortlichen.
Mittlerweile bin ich den Part aber nochmals durchgegangen, ich scheine dich da wohl ein wenig missverstanden zu haben.
Okay, da hast du mich wirklich missverstanden. Ich hatte mich schon gewundert - schließlich ist der Großteil dieses Beitrags SEO-inspiriert. Das Time-/Budget-/PL-Problem ist mir leider auch bestens bekannt ;o)
Was mir noch aufgefallen ist, du benutzt den Begriff "Verzeichnisebenen":
Je weniger Verzeichnisebenen, umso besser. Denn mit jeder neuen bzw. tieferen Ebene zieren sich die Bots mehr, dort hinabzucrawlen.Sollte es hier nicht besser Linkebenen[1] heissen? Denn ein Bot hat (imho) grundsätzlich nichts gegen "unendlich" lange URLs, nur muss er meist jede Menge Links verfolgen um vom Hauptverzeichnis einer Webseite dort hin zu gelangen.
Ich weiss dass in vielen "Tutorials" und Checklisten für Suchmaschinenoptimierung von Ordner- oder Verzeichnisebenen die Sprache ist, nur wenn man mal darüber nachdenkt ist es nur logisch dass Suchmaschinen sich nach den Linkebenen richten, und nicht nach Verzeichnisebenen.
[1] Jeder Klick um schnellstmöglich von der Startseite zu der Unterseite zu kommen bedeutet in diesem Fall eine Ebene.
Sollte es hier nicht besser Linkebenen[1] heissen? [...] Jeder Klick um schnellstmöglich von der Startseite zu der Unterseite zu kommen bedeutet in diesem Fall eine Ebene.Klasse Gedanke, das ist ja interessant. Wenn man die Struktur einer Website aus der Sicht des Bots betrachtet, ist Linkebene wirklich am verständlichsten. Aber können wir denn diese Linkebenen nachvollziehen? Schließlich sind sie nicht eindeutig strukturiert, sondern beziehen sich relativ auf den Startpunkt des Bots. Wir verzeichnen also eine andere Ebene, wenn wir von der Startseite ausgehen, als wenn der Startpunkt die Sitemap ist. Drücke ich mich verständlich aus?
Aus der Sicht des Site-Admins ist der Begriff Verzeichnisebene allerdings ebenfalls irreführend. Ordnerebene finde ich tatsächlich am einleuchtendsten und eindeutigsten. Root ist die erste Ebene, jeder Ordner darin die zweite, jeder Unterordner die dritte, jeder Unterordner im Unterordner die vierte... und so weiter.
Oder meinen wir vielleicht etwas ganz anderes? Angenommen, ich habe auf der Startseite den Navigations-Menüpunkt Pressebereich. In deiner Terminologie bzw. aus Sicht des Bots führt der Link dorthin in die erste Linkebene. Aus der Sicht des Administrators der Website, der die Pressebereichs-Startseite im Ordner /company/presse/ liegen hat, führt der Link in die zweite Ordnerebene.
Wenn wir also darauf achten, dass wir tief verschachtelte Ordnerebenen über interne Verlinkung/Linkstruktur auf den ersten Linkebenen zugänglich machen, dann "unterstützen" wir also die Bots beim schnelleren Indexieren. Anders gesagt: Es ist völlig egal, wieviel Verzeichnis-/Ordnerebenen wir haben; wichtig ist es, relativ wenige Linkebenen zu haben. Korrekt?
Absolut korrekt. Treffender könnte man den Unterschied und die Bedeutung nicht formulieren.
Allerdings hast du ja auch schon das auftretende Problem benannt: Wo ist unser Ausgangspunkt? Die Sitemap, die Startseite, oder gar der am stärksten extern verlinkte Artikel?
Könnte man das mit Sicherheit sagen, wäre man in der Lage, die interne Linkstruktur danach auszurichten - ist man aber nicht und wäre aus Nutzersicht wohl auch leicht bescheuert.
Also bleibt als wichtigste Seite wieder nur die Startseite. Und das ist auch suchmaschinentechnisch absolut kein Problem weil sowieso jede Unterseite auf die Startseite linkt (bzw sollte...). Kommt also ein Spider auf eine Unterseite ist eine der Seiten die er im 2ten Durchgang holt sicherlich die Startseite. Und da die Spider ja nicht nur ein mal vorbeikommen, sondern mehrere Male mit verschiedenen Einstiegspunkten, wird die Startseite vermutlich auch als wichtigste Seite erkannt.
Ausserdem kann man vermuten, aber leider nicht beweisen, dass Suchmaschinen die Startseite sowieso als wichtigste Seite sehen...
Also fassen wir zusammen:
Suchmaschinenoptimierung legt nahe jede Unterseite von der Startseite aus durch möglichst wenige Klicks erreichbar zu machen.
Dies soll allerdings nicht dazu verleiten 250 Links auf die Startseite zu knallen wie es große Portale machen, aber dazu kann dann sicher Marcus wieder was sagen.
Übrigens: Durch intelligente Siteplanung ist es kein Problem mehrere 10.000 Seiten in 5 Ebenen unterzubringen. Funktioniert aber natürlich nicht bei jedem Thema.
> Usybility und Suchmaschinen freundlich zu benennen (z.B. fernurlaub_malediven.html).
wenn schon, dann bitte fernurlaub-malediven.html, denn google behandelt den unterstrich _ aehnlich wie einen buchstaben. Der Bindestrich waere als Trennzeichen also besser. und zur usability von _ oder -. lesetechnisch finde ich den bindestrich angenehmer, und er ist auch manchmal noch 2 pixel kuerzer ;-)
Hmm, also dass die Spider der Suchmaschinen Probleme mit relativen Referenzierugnen hätten, halte ich dann schon für etwas weit hergeholt. Zumindest im Entwicklungsprozess sind relative URIs zudem meist besser händelbar.
Sie hätten nicht, sie haben. So manche Error-Logs sprechen eine ziemlich deutliche Sprache ;) Zwei Links habe ich auf die Schnelle dazu gefunden:
Use Absolute Links for Google und Absolute Links Better for Google.
Vielen Dank für den Beitrag zu "user friendly urls".
Aus meinen gemachten Erfahrungen als Entwickler kann ich Dir nur beipflichten. Als Programmierer vermengt man zu gerne ein paar kryptische Zeichen in die url oder verliert sich in endloslangen query-strings.
Ich benutzte gerade in verschiedenen Projekten die Möglichkeit auch Datenbankinhalte mit normalen Dateinamen zu versehen indem ich auf dem Server für den Benutzer schnell die Umsetzung in die entsprechenden Querystring Parameter mache. Der Benutzer bekommt hiervon nichts mit, da dies serverseitig erfolgt, und auch google indexiert jetzt die Inhalte des CMS mit großer Begeisterung.
Auch ich bevorzuge wenn möglich den Bindestrichkonvention, da es bei der verbalen Weitergabe von Urls mit "Unterstrich" doch immer mal wieder Verwirrung gibt. Positiv scheint es sich dabei auch auszuwirken, wenn die H1 oder H2 der Seite einen ähnlichen Text hat wie der Dateiname.
Aber korrekter Markup und validierende Seiten sind noch einmal neues Thema.
Google guy sagt nur "just in case", also was solls. Eine Suchmaschine, die das nicht gebacken bekommt, wird wohl kaum dauerhaften Erfolg zeitigen können. Und Google Guy ist ein Mythos, ein paar Argumente wären auch nicht schlecht.
cheers
Und Google Guy ist ein MythosOh, das wusste ich nicht. Wie kommst du darauf? Meines Wissens ist der Mensch mit dem Pseudonym GoogleGuy ein verifizierter Google-Mitarbeiter. Mit einer überwältigenden Menge an Insider-Informationen, die sich ganz unzweifelhaft immer bewahrheitet haben.
Ich denke, seine wiederholten Aussagen in dieser Angelegenheit sind Argument genug. Und die Errors erst recht. Bevor wir beispielsweise unsere Website mit absoluten Pfaden bestückt haben, hatten wir täglich (teilweise immer dieselben) Fehlermeldungen, die ich den relativ gesetzten Links zuordne (ja, sie waren korrekt gesetzt ;-). Danach nicht mehr. Okay, dass Googlebot Errors produziert, war schon immer selten. Aber von Inktomi, Fast, Firefly und Konsorten hatte ich nicht wenige.
Ich kann nicht beweisen, dass die Fehlermeldungen mit den relativen Links zusammenhängen. Ich bin nur davon überzeugt. Aber mir deshalb ein »weit hergeholt« zu unterstellen, GoogleGuy als Mythos zu bezeichnen und dann »ein paar Argumente« einzufordern...? --> Den Zusammenhang habe ich schließlich mit nur einem einzigen Satz quasi nebenbei erwähnt! Vielleicht bin ich aber auch momentan einfach nur ein wenig sensibel, was gelungene und feinfühlige Kommunikation betrifft.
Ich möchte übrigens nicht so verstanden werden, dass ich relative Pfade für falsch oder schlecht halte. Das ist gar nicht mein Anliegen. Man sollte den Einsatz lediglich mal überdenken. Mein Hauptargument ist schließlich, dass man sie schnell mal falsch setzen kann bzw. später anpassen muss (z.B. bei Rewrite, Verschieben...). Natürlich gibt es auch Gegenargumente (z.B. offline, CD...) - aber das wäre ja schon wieder Stoff für einen separaten Artikel.
wenn auf jeder unterseite solche pfade stehen ./../../../../../format.css ist das irgendwo auch eine verschwendung. natuerlich laesst sich auch durch relative anwendung manchmal einfacher und platzsparender verlinken, aber in diesem fall ist eine absolute verlinkung sinniger.
und hier noch eine jugendsuende von einem bekannten online buchhaendler. da wurden derartig lange, mit riesigen session-ids verunstaltete links eingesetzt, dass ich mal den anteil der links am quellcode gemessen habe und nicht schlecht staunte. die links machten alleine ueber 18 Kbytes aus, und das bei einer gesamt seitengroesse des htmls von 80 KBytes. haette man die links und die session auf ein sinnvolles mass gestutzt, so haette man ca 16 KBytes sparen koennen. schon erschreckend was man alles anrichten kann, wenn man solche kleinigkeiten nicht genauer hinterfragt. dass google sich dieser seite nicht bemaechtigen wollte, das ist dann ein weiteres kapitel in der geschichte, und leider nicht mal das letzte.
Für wen machen wir denn Internetseiten? Für Leser und Besucher oder für Google?
Und es gibt auch durchaus dynamische CMS die sehr userfreundliche und sprechende Links anbieten (z.B. KONTENTOR, das ich verwende) und nicht diese schrecklichen Abfragen.
> Für wen machen wir denn Internetseiten? Für Leser und Besucher oder für Google?
für besucher, nur was nutzt die schönste seite, wenn keiner sie findet? der witz ist ja auch, dass viele änderungen oft beiden seiten dienen. yahoo hat links z.b. so weit verkürzt, dass es kürzer kaum geht, alles für die ladezeiten.
das erwähnte cms scheint von der warte aus ganz gut zu sein, mit dem design kann ich mich aber noch nicht so ganz anfreunden. und es gibt sicherlich nicht nur zufällig eine räumliche nähe zu der firma, oder ;-)
@ Gerald:
Dass das Design gut sein soll, habe ich ja nicht behauptet. Es wäre mal ein Redesign nötig.
Was meinst du mit räumlicher Näher zu der firma?
iuveno AG, D-85055 Ingolstadt
und dein whois-eintrag sagt mir ebenfalls ingolstadt.
und koennte ja sein, dass die applikation auch noch von iuveno gehostet wird. wenn dem so ist, dann ist das fuer mich ein gewisser ausdruck von naehe.
aber das cms macht schon den eindruck als ob es nicht schwer zu erlernen waere. und das automatische navigationsmenue scheint mir ebenfalls eine praktische sache.
@ gerald
Ja. Wir kommen beide aus Ingolstadt. Ich arbeite als freier Mitarbeiter für iuveno. Und habe an KONTENTOR mitentwickelt und so hoste ich auch bei iuveno.
In der Tat ein recht leistungsfähiges Tool auf das man auch Stolz sein darf. :-)
Etwas spät, aber: SUPER ARTIKEL!!!
Mein Lob!
feiner artikel, kompliment :-)
gutes URL-design fängt imho auch schon beim domain-namem der an. in diesem sinne ist web-blog.net auch etwas verwirrend, da *blog* ja die abkürzung von weblog ist, oder täusche ich mich da? ;-)
das erinnert mich ein wenig an autohersteller, die gerne das abs-system anpreisen ;-))
Ha ;) Typischer Fall von Altlast, die endlich ihrer Bestimmung zufällt. Mit ein wenig Fantasie kann man aus web-blog.net ja »das Blog übers Web« machen. Oder so.
web-blog.net finde ich gerade ein genialer Name - gerade weil es ein mittlerweile alltäglicher Begriff aufteilt, daas Web und Net, was auch irgendwie doppelt ist...
URL-Design fängt zwar auch beim URL selber an - aber man soll nie den fehler machen, ein unverwechselbarer Name dadurch abzulehen bzw. zu verpassen...
@marcus - urls kuerzen ist ne gute sache, aber bei deiner benachrichtigungsmail musst du nicht uebertreiben:
Jetzt lesen!
/comments?id=P122_0_1_0_826
ist mir dann doch etwas zu kurz geraten ;-)
Ich lach mich tot ;) - irgendwas ist immer! Das liegt wohl an dieser blöden pMachine. Danke für den Hinweis - darum werde ich mich heute abend kümmern. Und wenn ich viel Zeit hab, schau ich mir mal die Expression Engine an. Die kann sowas nämlich.
diese Expression Engine macht einen maechtig guten eindruck. mach mal, und wenn die wirklich so gut ist steig ich auch um :)
Okay, vorgestern habe ich sie mir installiert und bin bis jetzt sehr positiv angetan. Bevor ich mir jedoch die Finger wund tippe, hier ein Link zum pMblog von pMachine- und EE-Macher Rick Ellis über einen Vergleich der beiden Systeme: ExpressionEngine vs. pMachine Pro.
Um die Ecke bei Konstantin Klein, dessen Weblog auf der EE läuft, gibt's auch 'ne Menge zu lesen. Von ihm stammt übrigens die deutsche Übersetzung der Sprachmodule in pM und EE.
danke fuer den hinweis, und wie ich sehe klappt es mit dem link in der benachrichtigungsmail auch wieder :)
Ich würde was geben für ein bisschen Zeit, um mir die EE mal in Ruhe anzuschauen. Ich denke, das wird was für mich und auch für meine Kunden. Klingt zumindest so, als hätte die EE all die Features, die ich immer an pMachine vermisst habe.
Okay, hier was zum Zeitbedarf in Sachen EE ;)
- Download: 2 Minuten
- Entpacken und Upload auf den Server: etwas über 10 Minuten
- Installation: 2 Minuten
- Import aller pMachine-DB-Dateien, Artikel, Kommentare, Trackbacks: 2 Minuten
- Gewöhnung an das neue Interface: rasend schnell, sehr intuitiv, logischer als pMachine
Have fun!
Verstehe. Nachdem meine Arrays als Stühle eingelesen werden, guck ich noch mal. Hast Du die Demoversion oder gleich 99$ gezahlt?
Ich hab hier die Demoversion (Konstantins Sprachpaket ist wohl mittlerweile im Download integriert); soweit ich das überblicke, ist der Stand im Moment erst bei Public Beta. Das Teil ist seine 99 Euro sicher wert (steckt eine Menge richtig gute Arbeit hinter) - aber ich bin mir sehr unsicher, ob ich da zuschlagen werde. Mein Weblog braucht die EE jedenfalls nicht. Jetzt noch nicht.
Eine mögliche Alternativ-Lösung für all diejenigen, die keine Ahnung von Regular Expressions haben, oder bei denen es aus anderen Gründen mit dem mod_rewrite-Modul vom Apache Server nicht klappen würde, könnte folgender Artikel sein:
PHP-basierte Alternative zu mod_rewrite
cu, w0lf.
Ach ja, mein eins weiter oben angepriesener Lösungsansatz ist nun auch bei meinem Blog eingebaut und scheint bis dato problemlos zu funktionieren ;)
www.alltagsgrauen.de/index.php/directlink/20040313/
cu, w0lf.
Eigentlich sind doch die suchmaschinenfreundlichen URIs, wenn sie wirklich gut gemacht sind, ebenfalls auch die URIs, die diesen Grundsätzen von Usability entsprechen. Schließlich wird auch eine Seite mit http://thema.com/unterthema/ besser zum Unterthema indiziert, als wenn es ein http://thema.com/2832/ ist.
Also, da spricht eigentlich nichts gegeneinander sondern eher füreinander.
lg.
roland
So unvollständig nun auch wieder nicht ;-)
Genialer Artikel, wobei ich glaube, dass Userfreundliche und Suchmaschinenfreundliche Urls genau das gleiche sind. Bei deinem Beispiel ist urlaub.com/fernreisen/malediven/ sowohl für den User als auch für die Suchmaschine optimal, denn beide mögen sinnvolle Stichwörten in dem Domainnamen und eine nach Themen aufgeteilte Website. Ich rede immer von einer flache Hierarchie.
Ob in Unterordnern oder nicht, ist egal, aber es ist wirklich die Linkstruktur, die zählt, und meine Daumenregel ist "in 2-3 Links soll jede Seite erreichbar sein". Wo die Spider-Einstiegsseite ist, spielt derweil keine Rolle, denn ich setzte ja einen Link auf die Sitemap auf jede Seite.
"_" ist kein Delimiter und GoogleGuy ist ein Google Mitarbeiter. imho ;-)
So unvollständig nun auch wieder nicht ;-)
Genialer Artikel, wobei ich glaube, dass Userfreundliche und Suchmaschinenfreundliche Urls genau das gleiche sind. Bei deinem Beispiel ist urlaub.com/fernreisen/malediven/ sowohl für den User als auch für die Suchmaschine optimal, denn beide mögen sinnvolle Stichwörten in dem Domainnamen und eine nach Themen aufgeteilte Website. Ich rede immer von einer flache Hierarchie.
Ob in Unterordnern oder nicht, ist egal, aber es ist wirklich die Linkstruktur, die zählt, und meine Daumenregel ist "in 2-3 Links soll jede Seite erreichbar sein". Wo die Spider-Einstiegsseite ist, spielt derweil keine Rolle, denn ich setzte ja einen Link auf die Sitemap auf jede Seite.
"_" ist kein Delimiter und GoogleGuy ist ein Google Mitarbeiter. imho ;-)
Vielen Dank für einen SEHR nützlichen Artikel.
Was kann man da groß sagen - "ausdrucken, an die Wand hängen, sich an die Regeln halten". Vielen Dank!
Mit freundlichen Grüßen aus Saarbrücken,
Vitaly Friedman,
http://www.alvit.de/vf/
© M. Völkel 2003-2008, some rights reserved | PGP-Key | Impressum
XHTML 1.0 Strict, Valid CSS.