Hallo zusammen,

ist ja ganz schön leer hier :eek: da muss man doch mal was ändern :)
ich bin seit einiger Zeit daran mir ein CMS und darauf ein Portal zu bauen und stehe jetzt vor der Entscheidung wie ich meine Links gestalte. Ich hab auch schon ein fertiges und so weit funktionierendes Konzept:

http://section.example.com/my/page/ident.language.htm
bzw.
http://section.example.com/my/page/ident.language.htm-parameter=bla
Wobei ich das mit den Parametern nur Sicherheitshalber ermögliche, benutzt wird das derzeit nicht.

Weiter habe ich ein Plugin-System im Aufbau das auch eine eigene (idr. sehr kleine) Navigation mit sich bringt. Und hier hab ich die größten bedenken bezüglich SEO. Unterseiten eines Plugins wären dann so verlinkt:

http://section.example.com/my/page/ident.language.htm/page/of/plugin
Und auch hier sind Sicherheitshalber Parameter gestattet (auch wenn sie vermutlich nie genutzt werden):
http://section.example.com/my/page/ident.language.htm-parameter=bla/page/of/plugin

Um noch mal halbwegs realistische Beispiele zu nennen:

#1: http://development.example.com/news.htm (Seite mit zugeordnetem Plugin)

#2: http://development.example.com/scripts.eng.htm-id=42/download (Seite mit zugeordnetem Plugin, Parameter und Unterseite)

#3: http://gaming.example.com/tetris.htm/history (Seite mit zugeordnetem Plugin und Unterseite)

#4: http://gaming.example.com/admin/user/edit.htm-id=42 ("Normale" Seite mit Parameter)
Ich strebe natürlich links im Stil von #1 an, würde aber zugunsten der Plugins auch gerne Links im Stil von #3 akzeptieren. Links nach Beispiel #2 werde ich komplett vermeiden (wenn auch nicht ausschließen) und #4 eben ausschließlich im Admin-Bereich wo SEO ohnehin unrelevant ist.

Für diejenigen die es Interessiert hier meine derzeitigen Rewrite-Rules:

# -----------------------------------------
# Admin page redirects
RewriteRule (^|^/)admin/?$ index.php?mode=admin&page=index

# Admin page redirects (with parameters)
RewriteRule (^|^/)(admin/[^\..]+)\.(.{3})\.html?(-(.*))?(/(.+)/?)?$ index.php?mode=admin&page=$2&lang=$3&plugin_page=$7&$5
RewriteRule (^|^/)(admin/[^\..]+)\.html?(-(.*))?(/(.+)/?)?$ index.php?mode=admin&page=$2&plugin_page=$6&$4


# -----------------------------------------
# Ajax page redirects
RewriteRule (^|^/)ajax/([^\..]+)\.(.{3})\.html?(-(.*))?(/(.+)/?)?$ index.php?mode=ajax&page=$2&lang=$3&plugin_page=$7&$5
RewriteRule (^|^/)ajax/([^\..]+)\.html?(-(.*))?(/(.+)/?)?$ index.php?mode=ajax&page=$2&plugin_page=$6&$4


# -----------------------------------------
# Public page redirects
RewriteRule ^/?$ index.php

# Public page redirects (with parameters)
RewriteRule (^|^/)([^\..]+)\.(.{3})\.html?(-(.*))?(/(.+)/?)?$ index.php?page=$2&lang=$3&plugin_page=$7&$5
RewriteRule (^|^/)([^\..]+)\.html?(-(.*))?(/(.+)/?)?$ index.php?page=$2&plugin_page=$6&$4


Für Verbesserungsvorschläge bin ich natürlich immer offen :)

MfG
Jens aka Forsaken

Ich würde mir an deiner Stelle mal anschauen, wie der Zend Router (http://framework.zend.com/manual/de/zend.controller.router.html) das macht.

Ich strebe immer den Stil ohne Dateinamen an:

http://example.com/lang/section/page/?param=value (nur wenn's nicht anders geht)

Ich strebe immer den Stil ohne Dateinamen an:

http://example.com/lang/section/page/?param=value (nur wenn's nicht anders geht)

Demnach hast du die Sprache (sofern mehrere vorhanden) immer in der URL? Ich denk wieder viel zu kompliziert ^^
Die Sprache da irgendwie sauber rein zu bekommen ist nämlich im Moment mein größtest Problem. Als Subdomain will ich es nicht umsetzten (Cookies, Verwendung des CMS auf Subdomains).
Das Plugin-Problem konnte ich inzwischen lösen.

Demnach hast du die Sprache (sofern mehrere vorhanden) immer in der URL?

Ja, gleich als erstes. Diese Variante wird von den meisten mehrsprachigen Websites benutzt. Der leere Pfad (http://example.com/) geht auf ein PHP-Script welches den Accept-Language-Header parst und auf die passendste verfügbare Sprachversion umleitet. Darüber hinaus gibt es dann trotzdem noch die Flaggen zum manuellen Umschalten.

Wo ist denn das Problem dabei, wenn die Sprache in der URL steht?

Wo ist denn das Problem dabei, wenn die Sprache in der URL steht?
Prinzipell hab ich da kein Problem mit, ich kann nur scheinbar bei den Temperaturen nicht mehr klar denken ;)
Wie gesagt ich hab mal wieder viel zu kompliziert gedacht.

Und danke für den Tipp Amica :)

Persönliche Meinung, nicht wirklich SEO belegt oder nachgewisen;

Ich finde immer, dass Dateinamen in der URL wie "http://example.com/de/index.php/test/blub/3" absolut hässlich sind.

Erstens suggeriert eine Endung immer und bei jedem Benutzer, egal wie versiert er ist, dass es diese Datei in irgendeiner Form physikalisch gibt und sie auf dem Server existiert und zweitens ist es nicht benutzerfreundlich. Wenn schon SEO, dann richtig! Es gibt keinen nachvollziehbaren Fall, in dem eine URL mit einer Endung ".html" einer mit ".php" vorgezogen wurde, geschweigedenn einer ohne Endung überhaupt.

Daher vermeide ich soetwas wo es nur geht und habe nur Endungen in den URLs, wenn es die Dateien tatsächlich gibt...

Es gibt keinen nachvollziehbaren Fall, in dem eine URL mit einer Endung ".html" einer mit ".php" vorgezogen wurde, geschweigedenn einer ohne Endung überhaupt.

Das ist richtig, aber warum sollte man URLs andererseits mit Detailinformationen zumüllen, die weder für den Besucher noch für Suchmaschinen (sondern nur für potentielle Angreifer halbwegs) interessant sind? ;)

Ich finde immer, dass Dateinamen in der URL wie "http://example.com/de/index.php/test/blub/3" absolut hässlich sind.


Das index.php lässt sich ja auf einfache Weise wegmachen. Außerdem kann man statt des nichtssagenden "index" auch eine sinnvollere Bezeichnung wählen.


Erstens suggeriert eine Endung immer und bei jedem Benutzer, egal wie versiert er ist, dass es diese Datei in irgendeiner Form physikalisch gibt und sie auf dem Server existiert ...

Dann häng halt noch ein ".html" an:
"http://example.com/de/kaeseblatt.php/Seite-3.html"
Ist für Menschen les- und merkbar.

... und zweitens ist es nicht benutzerfreundlich. Wenn schon SEO, dann richtig! Es gibt keinen nachvollziehbaren Fall, in dem eine URL mit einer Endung ".html" einer mit ".php" vorgezogen wurde, geschweigedenn einer ohne Endung überhaupt.

Bei der Gestaltung einer vernünftigen URL-Struktur interessiert mich der Spanische Vogelschutzbund (http://de.wikipedia.org/wiki/Sociedad_Espa%C3%B1ola_de_Ornitolog%C3%ADa) herzlich wenig. Und Suchmaschinen juckt das ebensowenig.

Das ist richtig, aber warum sollte man URLs andererseits mit Detailinformationen zumüllen, die weder für den Besucher noch für Suchmaschinen (sondern nur für potentielle Angreifer halbwegs) interessant sind? ;)

Genau! Und deswegen mag ich keine Sprachenkürzel in Pfadangaben, es sei denn, sie sind Teil der Navigation (wie bspw. in einem Wörterbuch). Aber in welcher Sprache ich eine Web-Seite am liebsten serviert haben möchte, soll bitte der Webserver bei meinem Browser erfragen. Der käme sich sonst veräppelt vor, weil er bei jeder HTTP-Anfrage extra entsprechende Header mitschickt. ;)

Ich würde versuchen die Slashes zu minieren.. benutz einfach andere Trennzeichen (Unterstrich z.B.)

Kenne dein Projekt nicht, aber vllt solltest du generell mal die Struktur überdenken, das scheinen mir nämlich schon arg viele Paramter zu sein ;)

Und deswegen mag ich keine Sprachenkürzel in Pfadangaben,
Was allerdings dazu führt, dass SUMAs evtl. nur eine Sprache finden, da sie selten Cookies unterstützen. Oder gar wechselnde Inhalte unter der Selben URL.

Ich sach nur: Problematisch!

Ja - auch die Möglichkeit, gezielt Links auf andere Sprachversionen zu verschicken/bei Social Bookmarking-Diensten einzutragen etc. verschenkst du, wenn die Sprache nicht Bestandteil des URLs ist.

Was allerdings dazu führt, dass SUMAs evtl. nur eine Sprache finden, da sie selten Cookies unterstützen.
Wer sprach von Cookies? "Accept-Language" heißt der Header der Wahl ...

Oder gar wechselnde Inhalte unter der Selben URL.
Das verstehe ich jetzt nicht ...
Ich denke mal, dass ein Suchmaschinenrobot selten einen Accept-Language-Header mitschickt. Wenn doch, dann sollte die Suchmaschinendatenbank auch mit den dahintersteckenden Konzepten vertraut sein. Im Normalfall wird aber die Default-Seite ausgeliefert. Das dürfte wohl meist die in englischer Sprache sein. Das kann natürlich ein Problem für den Web-Seitenbetreiber darstellen. Deswegen schrob ich ja auch: ... deswegen MAG ICH keine Sprachenkürzel in Pfadangaben, es sei denn ...
Es wird sich nicht jeder nach mir richten, aber ich finde es in den meisten Fällen eine bessere Lösung, als auf irgendwelchen (oft unpassenden) Landesflaggen rumzuklicken ...

Ein Problem ist auch, dass die meisten Browser das Einstellen der Sprache kompliziert machen und die entsprechenden Konfigurationsdialoge gerne verstecken.

Ja - auch die Möglichkeit, gezielt Links auf andere Sprachversionen zu verschicken ...

Das ist auch nicht nötig, wenn Browser und Server die Sprache aushandeln. Schicke ich den Link einer Person, die eine andere Sprache als ich spricht, wird diese die Web-Seite in ihrer gewünschten Sprache ansehen können.

... /bei Social Bookmarking-Diensten einzutragen etc. ...
Wer braucht'n so'n Kram? ;) Nee, im Ernst: Da gilt doch das Gleiche: Eine URL, und die Sprache wird bei deren Aufruf ausgehandelt.

Das ist auch nicht nötig, wenn Browser und Server die Sprache aushandeln. Schicke ich den Link einer Person, die eine andere Sprache als ich spricht, wird diese die Web-Seite in ihrer gewünschten Sprache ansehen können.
Du weißt selber, dass nicht immer alle Sprachversionen gleiche Qualität haben müssen - Paradebeispiel: PHP-Manual.


Sprachversion gehört für mich definitiv mit in die Adresse.
Besucher, die über die Indexseite einsteigen, kannst du ja trotzdem per Content Negotiation auf die am besten zur gemeldeten Vorliebe passenden Version weiterleiten.

Und für den Fall, dass explizit per Adresse angeforderte Sprachversion und Accept-Language nicht übereinstimmen, kann man auch gerne den Hinweis auf die anderen Sprachen noch mal gesondert hervorheben.

Wer sprach von Cookies? "Accept-Language" heißt der Header der Wahl ...

1. Ich möchte mal bezweifeln, dass Sumas hunderte von Requests absetzen, welche sich nur im Accept-Language Header unterscheiden.
2. Wie willst du dem User einen Sprachen Schalter anbieten?