[Artemis]

Moin,

ich überlege gerade, welches URL-Format ich für eine Seite verwenden soll. Hier sind meine Überlegungen:

• xyz.de/name
• xyz.de/name/
• xyz.de/name.html

Welches würdet ihr als Benutzer bevorzugen, das heißt welches würdet ihr besser behalten? Wahrscheinlich /name oder /name/, oder?

Wisst ob ein Format Suchmaschinenfreundlicher ist, als ein anderes?

Grüße,
Artemis

[robo47]

das .html hintendran braucht man eigentlich nicht. zwischen /name und /name/ ist halt der unterschied, das eine ist ein verzeichnis normalerweise, das andere eine datei. bei /name/ kann es dir eher passieren, dass mal wenn man mit externen programmen offline-kopien einer seite macht, oder mit nem einfachen crawler ne sitemap erstellen will, der standardmäßig auf /name/index.html gehen will, ich habs eigentlich ohne / am ende, weil es eben dokumente sind und keine ordner.

suchmaschinenfreundlich sind alle 3 varianten, das .html dahinter macht da wohl auch nichts, ausser dass die urls länger sind.

mfg
robo47

mfg
robo47

[Jann Hendrik]

interessant ist es, wenn man in seinem CMS die Möglichkeit hat mit einer zentralen Einstellung zwischen den drei Formaten zu wechseln!

[Ben]

Ich denke für die Benutzerfreundlichkeit solltest du eher darauf achten, dass du "sprechende URLs" verwendest, also URLs, die dem Nutzer in Erinnerung bleiben können.
Beispiel:
-> http://www.example.com/ueber-mich/lebenslauf{/,.html}
-> http://www.example.com/interessen/laufsport{/,.html}

Grüße, Ben.

[schifti]

http://www.
ich bevorzuge persönlich ohne www. (muss doch nicht unbeding drann stehen, man erkennt das protokol doch schon an http )

[Lars]

www. is deprecated

[Ben]

Hat nur genau gar nichts mit dem Thema zu tun, wie ich finde.

[Artemis]

@Ben,
sprechende Namen will ich sowieso verwenden, weiß ja keiner was gemeint ist, mit http://xyz.de/section12/subsection43.

Werde wahrscheinlich die Methode http://xyz.de/bla/uhu verwenden.

Danke noch einmal an alle.

[xardias]

Ich habe letztens beim W3C was über den "stil" von URLs gelesen.

Es wird empfohlen die file extension weg zu lassen, immerhin kann es ja sein dass man von PHP auf statisches HTML oder auf ASP o.Ä. wechselt, dann sollten die URIs dennoch erreichbar sein.

Des weiteren würde ich auch die Variante ohne / am Ende verwenden. Wie schon gesagt wurde, es sind Dokumente keine Ordner. Da sollte man finde ich schon unterscheiden.

[Basti]

Zitat von Ben

http://www.example.com/ueber-mich/lebenslauf

Zitat von Artemis

http://xyz.de/bla/uhu

Bedenklich ist dabei, die Struktur der Daten (meine die "Sitemap" sozusagen) mit in den url zu zimmern. So ist bei Bens Beispiel "lebenslauf" eine Unterseite von "ueber-mich". Was, wenn der irgendwann verschoben wird. Hier also auch darauf achten, dass die urls möglichst viele Umstrukturierungen "ungebrochen" mitmachen.

Basti

[Ben]

Hm, joa. Haste schon Recht. Aber ich behaupte mal, dass das doch recht selten der Fall sein wird, oder?
Hör mir aber gerne Gegenargumente bzw. alternative Möglichkeiten der URL-Struktur an.

Danke.
Grüße, Ben.

[Basti]

Ich meine halt, dass es sinnig ist, die urls unabhängig von sowas ( = sich möglicherweise ändernde Voraussetzungen) zu machen. Ich hab jetzt gerade eine Site für einen Verband vieler Institutionen und Einrichtungen gemacht, bei der deren Mitarbeiter je ihre eigenen Einrichtungsseiten erstellen, berarbeiten, verschieben können. Da hab ich z.B. übersehen, dass ich hier den Einrichtungsnamen besser in den URL hätte dazupacken hätte sollen:

example.com/einrichtung_x/konzept

Im Moment müssen sie sich selbst einen ("Site-weit") eindeutigen Namen, wie z.B. "einrichtung_x_konzept", oder auch "unser_konzept" etc. geben und war keine so gute Entscheidung. Mal schauen, ob da noch was drinnen ist - die Site ist noch nicht online und es wurden erst ein paar Dutzend Seiten erstellt.

Der "Sitemap-Pfad" dieser Seite wäre aber im Moment z.B. folgender:

startseite/einrichtungen/einrichtung_x/konzept

Diesen Pfad als URL zu wählen wäre unsinnig - selbst ohne startseite, denn vieleicht erstellt ein Mitarbeiter von X mal eine Seite "Selbstdarstellung" und Packt das Konzept dann dort hinein. Das würde bedeuten, du brachst einen Mechanismus, Requests auf alte URLs umzuleiten, was ich im Moment nur für umbenannte Seiten tue und schon da lassen sich Konflikte nicht ganz ausschließen.

Was ich damit sagen will:
Es hängt einfach davon ab, was tauglich ist. Die Konzept-Seite der Einrichtung X über einrichtung_x/konzept verfügbar zu machen ist sinnvoll, da sich niemals etwas daran ändern wird, dass dort eben das Konzept der Einrichtung X zu lesen ist - wie man sich dann auch immer zu dieser Seite durchklicken kann.

Basti

[kampfgnom]

mal ne allgemeine frage..
wie kann ich das denn einstellen?
Also mit dem bespiel.de/ordner/ das is ja nich schwer
aber nur beispiel.de/topic
kann ich noch nich
danke fürs helfen
kampfgnom

[Chr!s]

Einfaches Beispiel für z.b.
domain.de/section

RewriteRule ^([a-zA-Z0-9_-]+)/?$ /index.php?section=$1 [NC,L]

Über die index.php mit der superglobalen $_GET kannst du dann 'section' abfragen..

[kampfgnom]

Zitat von Chr!s

RewriteRule ^([a-zA-Z0-9_-]+)/?$ /index.php?section=$1 [NC,L]

und das schreibt man einfach mit in den php code mit rein oder muss das in eine gesonderte datei/dateiform?!

grüße
kampfgnom

[WarrenFaith]

Nein das muss in die .htaccess Datei rein.
Stichwörter zum Googlen: RewriteRule, htaccess

[Ben]

Hallo,
ich belebe diesen Thread nochmals, da ich gerade mal wieder über die richtige Struktur von URLs nachdenke.

Chris Shiflett hat kürzlich einen interessanten Beitrag geschrieben und auch die Diskussion in den Kommentaren ist sehr interessant.

Dort wird z.B. auf http://www.w3.org/Provider/Style/URI verwiesen. Eine zu empfehlende Lektüre!

Nun gut.
Ich bin mir nicht ganz sicher, wie man es am besten realisiert.

Situation: Ein Nachrichtenüberblick, also kein privater Weblog.

Mögliche Formen, die für mich derzeit in Frage kommen würden, wären also

http://example.com/news/123,a-sample-news-title - /news/{id},{title}
http://example.com/news/2007/january...a-sample-title - /news/{year}/{month}/{title}


Erklärung:

• Domain/Kategorie/ID,Titel
  Abtrennung von ID und Titel, aufgrund der Tatsache, dass meinem Verständnis nach ein Slash eine neue Rubrik o.Ä. einleitet. Das Komma erweitert aber nur die Identifikation des Datensatze, demnach sind Titel und ID auf einer Ebene und nicht in unterschiedlichen!
  
  
• Domain/Kategorie/Jahr/Monat(/eventuell Tag)/Titel
  Hm, Vorteil wäre eine leichte Archivierung, da man so sehr leicht und anwenderfreundlich navigieren kann. Vor allem, wenn man sowieso ein "Archiv" anbieten will.
  Nachteil ist offensichtlich. Der URL wird "unnötig" lang. Sehr lang.
  Weiterhin wäre so etwas hier eventuell verwirrend news/2007/05/01/test
  Ist nun der 1.5 oder der 5.1 gemeint?

Heise.de geht z.B. einen anderen Weg. Dort wird nur die ID verwendet. Das fällt bei mir raus, ist auch nicht diskutabel.


In den Kommentaren schreibt Darryl Patterson

I agree, descriptive URLs are all good. In the case of blogs, I'd say using a date in there is relevant, as thoughts and opinions change over time. Year/month is plenty granular enough.

In Blogs also mit Angabe des "Datums"!?

Interessant ist auch der Beitrag von Nate Klaiber
http://www.nateklaiber.com/2006/08/1...ing-your-urls/

und sein entsprechender Kommentar in der Diskussion zum Beitrag von C.Shiflett:

Nate K writes:

Chris,
I previously wrote about this topic as well. I consider myself very particular when it comes to URL structure. I want to be able to accommodate friendly and descriptive links - but I also want to keep them short and to the point (easy to repeat to a friend). This is why I usually allow several different structures for my URL - but make the URL friendly link the main link. My new site will house this structure better than other sites I have done.

Personally, I don't think it is any slower because I index the post slug (unique key) in the database. If you build your database structure accordingly then it will still be quick to respond.

I work for a book publisher and I use multiple URLs in several ways. I want our books to have a friendly url, but I also want our bookstores and customers to be able to find a book by an ISBN. So, I have both URLs available to them, they can type in http://www.barbourbooks.com/book/detail/{ISBN}/ which will then apply a 301 redirect to the SEF url. Having one central location is key to maintaining a nice index (as well as avoiding looking to serve up duplicate content on 2 urls). This just gives your visitors multiple doors into your website - short and sweet URLs.

I think the key is to have the proper database structure, map out the possible doors to the website, decide on a 'main' page that will be the end landing page, and then understand your HTTP codes to send the proper code with the proper request (301, 302, etc).

Meinungen? Kommentare?
Alles gerne gesehen.

[robo47]

Also ich bin irgendwie kein Freund vom datum in der URL, einziges was ich sinnvoll halte ist ne ID, ermöglicht eben auch nach änderung des titles ein einfaches umsetzen eines 301er auf die neue URL, so wie ich das in diesem Thread beschrieben habe anhand meines systems, auch wenn man URLS nicht ändern soll, kann es ja immer mal vorkommen, dass es sein muss, ohne dass man den artikel verändert, erinnere mich da an nen Fall wo irgendeins unserer deutschen Ämter gegen nen Blog klagen wollte, der hatte blablablaamt-ortsname in nem title + url drinhatte und dadurch bei sumas um ein vielfaches besser gelistet war, ich glaub er hat es zwar dann freiwillig geändert, aber man weis ja nie.

[Ben]

Gut, gehen wir doch einfach mal auf den Beitrag ein, den ich geschrieben hab. Der Thread, den du verlinkst hast, ist mir durchaus bekannt.

Deine Ausnahme da gehört wohl hier rein

Do you really feel that the old URIs cannot be kept running? If so, you chose them very badly. Think of your new ones so that you will be able to keep then running after the next redesign.

Quelle: Sollte klar sein!


Ich tendiere auch zu news/123,sample-title wollte mich aber vorher noch mal in einer Diskussion auf alternative Möglichkeiten ... hinweisen lassen.
Wie dort steht .. es muss einfach gut geplant sein, weil ich ja dann nicht vorhabe, die URL-Struktur nochmals zu ändern.

[Basti]

Hi.

Vielleicht ganz gut, über folgende Fragen an das Thema zu gehen (sicherlich erweiterbar

• Welchen Informationsgehalt außerhalb der Serveranwendung soll der URL bekommen?
• Kann ein URL geändert werden und, wenn ja, wie kann ich rekonstruieren, welche Inhalte gemeint waren, wenn der URL geändert wurde?
• Wie kann ich über den URL/URI Anweisungen transportieren, um das Softwaresystem auf dem Server zu steuern, also vor allem Steuerbefehle von IDs von Inhalten unterscheiden?
• In welchem Kontext/Namensraum müssen die IDs von bestimmtn Inhalten eindeutig sein?

Informationsgehalt:
Damit die Webanwendung die Anfrage verstehen kann, brauchts im Minimalfall einfach nur ein numerische ID oder sowas. Daraus ergib sich also die Frage, für wen noch weitere Informationen in den URL gepackt werden müssen.

Ob ein URL ein Datum enthalten soll, ein Thema, ein paar Worte zum Inhalt, ein kryptische Zeichenkette oder den Namen des Autors, das ist eine fachliche Anforderung. Zu Berücksichtigen insbesondere hier folgende technischen Zusammenhänge und Grenzen:

- erlaubte Zeichen bzw. Verfälschung der Information durch eine mögliche Umkodierung von Zeichen
- Akzeptierte Maximallängen (bzw. Verfälschung durch Kürzung)

Allgemein: Wie verarbeitet der Empfänger die (kodierte) Information? (Menschen, Suchmaschinen)

Zuordnung:
Es ist z.B. auch kein Problem, einen Verweis von einem geänderten Titel auf einen neuen Titel in die Datenbank zu schreiben und damit dann einen 301er zu schicken. Lediglich, wenn ein neuer Artikel mit dem geänderten Titel entsteht, geht diese Verküpfung natürlich flöten. Letztlich kann man jeden URI auf einen anderen Umleiten, solange der alte nicht wieder mit einer neuen Bedeutung als eben genau dieser belegt wird.

Wichtiger ist die Frage, in wieweit die Information im URL noch gültig/sinnig ist, wenn man welce Inhalte (etc.) ändert. Siehe den Absatz "What to leave out" im von Ben verlinkten W3C-Artikel.

Anweisungen:
Hier ist halt wichtig, syntaktisch klar zu trennen. Ich benutze z.B. gerade example.com/controller.action, um eine bestimmte Anweisung durchzuführen und verbiete den Punkt in Seitennamen, um eine klare Trennung zu erreichen. Aber man kann ja auch beides kombinieren oder sonstwas zur Unterscheidung heranziehen.

Kontext:
Ein URL /2007/01/16/bla beschänkt den ANwender, am gleichen Tag nochmal einen Artikel mit dem "Titel" bla zu veröffentlichen. Ein URL /315,bla bei dem 315 eine fortlaufende Nummer ist, hat diese Einschränkung nicht. Nimmt man nur /bla, darf es nie wieder einen "Titel" bla geben etc.

...und noch der hier aus dem Link von Ben:

This approach also lets me offer /blog/2007/jan as an interface for browsing posts from January 2007 (full posts) and /blog/2007 as an interface for browsing posts from all of 2007 (abstracts). I hate URLs that you can't ascend.

http://shiflett.org/archive/289

Ach ja, und:
Wie kommt der URL zustande? Wer er eingetippt und ist das sehr bedienfreundlich? Oder wird er z.B. vom Seitentitel abgeleitet und muss dann nicht doch vielleicht noch eine Zahl angehängt werden, um Konflikte zu vermeiden? ...

Basti