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