Usability en URL's

[Johnny]

Je wilt URL's zo duidelijk mogelijk hebben voor zowel bezoekers als zoekmachines, maar wat is nou de beste manier om dit te doen? Je begint met een lelijke URl zoals deze:

http://website.tld/article.php?id=123

Met Apache kun je via mod_rewrite dit makkelijk omzetten naar iets wat makkelijker te lezen is, net als hier op Tweakers.net gebeurd, alle parameters scheiden met slashes:

http://website.tld/article/123

De browser denkt dan echter dat je in de directory /123 zit, om je relatieve links op je pagina nog goed te laten werken zul je dus met de <base> tag aan de slag moeten.

Als je de pagina wilt opslaan zal je browser de pagina standaard "123.html" noemen.

Daarnaast suggereert deze URL ook dat de map article/ bestaat terwijl dat niet zo is.

Ik denk dat dit daarom duidelijker is:

http://website.tld/article123

Maar als het een Nederlandstalige website is, kan het dan niet beter zoiets zijn?

http://website.tld/artikel123

Een helemaal andere manier is om de inhoud van de pagina te beschrijven in je URL:

http://website.tld/artike...e_lange_titel_bla_bla_bla

Zoekmachines zoals Google vinden dat helemaal geweldig, en ook als je een pagina wilt opslaan heb je meteen een beschrijvende naam. Een nadeel is dat de gebruiker moeilijker een patroon kan zien in de URL, en dat je de URL heel erg lang kan worden en je hem steeds voluit moet gaan schijven en dat je nooit twee artikelen met dezelfde titel kan hebben.

Nee, ik weet het verschil tussen URL's en URI's niet en ik ben die andere nieuwe afkorting vergeten maar er komt vast wel weer iemand met een linkje waar het wordt uitgelegd.

[Stewie!]

Johnny schreef op maandag 14 november 2005 @ 10:10:
Ik denk dat dit daarom duidelijker is:
http://website.tld/artikel123

Ik denk het niet, wat een ranzige oplossing is dat

http://website.tld/artike...e_lange_titel_bla_bla_bla

Zoekmachines zoals Google vinden dat helemaal geweldig, en ook als je een pagina wilt opslaan heb je meteen een beschrijvende naam. Een nadeel is dat de gebruiker moeilijker een patroon kan zien in de URL, en dat je de URL heel erg lang kan worden en je hem steeds voluit moet gaan schijven en dat je nooit twee artikelen met dezelfde titel kan hebben.

simpel: -2, -3, etc erachter. Overigens worden die html sites wél vaak echt als html opgeslagen omdat de site dan sneller is bij meerdere bezoekers. In de database blijft wel altijd nog een kopie om een nieuwe html cache te genereren bij wijzigingen in bijvoorbeeld de layout

Nee, ik weet het verschil tussen URL's en URI's niet en ik ben die andere nieuwe afkorting vergeten maar er komt vast wel weer iemand met een linkje waar het wordt uitgelegd.

Maar wat is de vraag van dit topic? Of je punt?

Voor beginners is dit stukje altijd handig: http://www.sitepoint.com/article/guide-url-rewriting
Heeft mij aantal jaar terug ook prima op weg geholpen

[ Voor 15% gewijzigd door Stewie! op 14-11-2005 10:18 ]

[BtM909]

Waarom zou je gebruikers moeten weten of iets een subdirectory of bestandsnaam is?

Je gebruikt userfriendly URL's voor verschillende redenen; voor gebruikers is dat user-friendly zijn

Verschil tussen URI en URL

[ Voor 8% gewijzigd door BtM909 op 14-11-2005 10:17 ]

[sjroorda]

Als je het over usability hebt voor wat de eindgebruiker betreft, is de laatste vorm het duidelijkst. Ik zit zelf ook wel eens met het probleem dat ik een URL heb gezien enige tijd terug, en als ik hem dan opnieuw wil vinden, tik ik de eerste letters van de URL in. Een cijfertje zegt me dan (meestal) niet zoveel, maar aan de hand van een duidelijke bestandsnaam kan ik de pagina makkelijker terugvinden.

Als je het over usability voor de ontwikkelaar hebt is een ?id=x het makkelijkst (even ervan uitgaand dat er een simpel CMS achterhangt).

Ultieme oplossing: relatie-tabel met ID en paginanaam, zodat je in je CMS a.h.v. ID's kan werken, en de gebruiker (en Google!) ziet duidelijke URL's! Misschien maar eens gaan ontwikkelen .

[Johnny]

DaMorpheus schreef op maandag 14 november 2005 @ 10:15:

Maar wat is de vraag van dit topic? Of je punt?

Wat is de beste manier om een URL weer te geven?

sjroorda schreef op maandag 14 november 2005 @ 10:17:
Als je het over usability hebt voor wat de eindgebruiker betreft, is de laatste vorm het duidelijkst. Ik zit zelf ook wel eens met het probleem dat ik een URL heb gezien enige tijd terug, en als ik hem dan opnieuw wil vinden, tik ik de eerste letters van de URL in. Een cijfertje zegt me dan (meestal) niet zoveel, maar aan de hand van een duidelijke bestandsnaam kan ik de pagina makkelijker terugvinden.

Waar zoek je dan precies? Want zowel in de history als het auto-complete-veld van je browser staat (als het goed is) de titel van de pagina.

Een website bevat vaak niet alleen artikelen, maar ook andere content, hoe combineer je die dan? Het zou zo kunnen, maar voor de bezoeker maakt het waarschijnlijk niets uit of tekst in een weblog of in artikel staat, maar dat het een foto is waarschijnlijk wel.

http://website.tld/artikel/titel_van_artikel
http://website.tld/foto/omschrijving_van_foto
http://website.tld/weblog/titel_van_bericht
http://website.tld/agenda/2005_11_10_omschrijving_agendapunt
http://website.tld/agenda/2005/11/10/omschrijving_agendapunt

Is het bijvoorbeeld handig om de datum in de URL te verwerken? Voor een artikel waarschijnlijk niet, maar in een online agenda misschien wel?

[disjfa]

Johnny schreef op maandag 14 november 2005 @ 10:59:
[...]
Wat is de beste manier om een URL weer te geven?

Is het bijvoorbeeld handig om de datum in de URL te verwerken? Voor een artikel waarschijnlijk niet, maar in een online agenda misschien wel?

Het grote punt van deze vragen is het punt van "Wat komt bij jouw situatie het beste over"

Ik bedoel er is echt geen echt antwoord op je vraag. Doe wat je zelf wilt. Google indexeert het gewoon aan de hand van gevonden linkjes binnen je site of van extern. Daar heeft de opmaak van je url helemaal niets mee te maken (we hebben het even over userfrienly urls).

Dus gewoon gebruiken wat voor jouw het makkelijkst werkt of overkomt.

[sjroorda]

Johnny schreef op maandag 14 november 2005 @ 10:59:
[...]

Waar zoek je dan precies? Want zowel in de history als het auto-complete-veld van je browser staat (als het goed is) de titel van de pagina.

offtopic:
En nu voel ik mee heel lullig en kruip ik ergens in een klein donker hoekje: ik gebruik Firefox al heel wat jaren, maar eigenlijk is mij bij de auto-complete nog nooit de titel opgevallen...

Een website bevat vaak niet alleen artikelen, maar ook andere content, hoe combineer je die dan? Het zou zo kunnen, maar voor de bezoeker maakt het waarschijnlijk niets uit of tekst in een weblog of in artikel staat, maar dat het een foto is waarschijnlijk wel.

http://website.tld/artikel/titel_van_artikel
http://website.tld/foto/omschrijving_van_foto
http://website.tld/weblog/titel_van_bericht
http://website.tld/agenda/2005_11_10_omschrijving_agendapunt
http://website.tld/agenda/2005/11/10/omschrijving_agendapunt

Is het bijvoorbeeld handig om de datum in de URL te verwerken? Voor een artikel waarschijnlijk niet, maar in een online agenda misschien wel?

Nu ga je wel erg ver. Je moet voor jezelf duidelijk krijgen wat je doel is met de betreffende onderdelen. Een agenda hoef je echt niet met Google te zoeken, dus om daar de datum in de URL te zetten... Lijkt me ook allesbehalve duidelijk. Eventueel in de bestandsnaam, maar niet in de URL.
Waar ligt je prioriteit? Gemak van beheren, of wil je echt alles eraan doen om gevonden te worden in zoekmachines? Dan is de URL slechts een (klein?) gedeelte van de strategie.

[Johnny]

sjroorda schreef op maandag 14 november 2005 @ 11:06:

Nu ga je wel erg ver. Je moet voor jezelf duidelijk krijgen wat je doel is met de betreffende onderdelen. Een agenda hoef je echt niet met Google te zoeken, dus om daar de datum in de URL te zetten... Lijkt me ook allesbehalve duidelijk.

Waarom niet? Op een bepaalde datum zijn er verschillende agendapunten, als je dan de URL doorgeeft aan iemand weet die persoon dat het een agendapunt is, op welke datum en waar het over gaat.

Het doel van Google is om uiteindelijk alle informatie te indexeren en doorzoekbaar te maken, en voor sommige publieke agenda's kan het weldegelijk handig zijn dat ze makkelijk kunnen worden gevonden.

Eventueel in de bestandsnaam, maar niet in de URL.

De bestandsnaam is toch een onderdeel van de URL?

Waar ligt je prioriteit? Gemak van beheren, of wil je echt alles eraan doen om gevonden te worden in zoekmachines? Dan is de URL slechts een (klein?) gedeelte van de strategie.

Geen van beide; bij de bezoekers.

[Garyu]

Ik vind het eigenlijk helemaal geen issue. Of je nu A of B gebruikt, 99% van je gebruikers bookmarken zo'n pagina of komen gewoon terug door nog een keer hetzelfde pad te volgen. Op zijn hoogst zijn er enkele tweakerts die echt zo'n url overtypen / opnieuw intypen om direct bij je pagina te komen.

Voor de tijdsinvestering die het bedenken en schrijven van al je mod_rewrites e.d. kosten kan je beter je tijd besteden aan de algemene usability van je site-navigatie dan je druk te maken om de URL. Dat is wel het minst belangrijke aspect van de gebruiksvriendelijkheid.

Ik vind het altijd net en aardig als ik een url kan lezen, maar ik ga een site er niet minder om gebruiken als er IDs in voorkomen in plaats van mooie leesbare woorden.

[mees]

Ik gebruik zelf altijd de slash i.c.m. tilde
slash ( / ) om variabelen te scheiden, en de tilde ( ~ ) ipv het 'is-teken' (=).

www.voorbeeld.nl/artikel~154/zoeken~zoekwoord

Het voordeel ervan? google indexeert sneller alle links op de pagina. Veel mensen verklaren het tot onzin, maar het is echt zo. Ik heb op dezelfde dag 2 websites online gezet. Dit was in september dit jaar. Google heeft de url's met ~ en / nu volledig geindexeerd, terwijl de andere website die nog met ?, & en = werkt, nog steeds niet geindexeerd is. Waarom is mij een raadsel, maar ik blijf bij de slashes en tildes!
Daarnaast ben ik nog wel bezig met een page-alias systeem te maken voor mijn cms. Je geeft aan elk artikel op je website een page-alias mee, deze kan opgeroepen worden door bijvoorbeeld www.voorbeeld.nl/page,keywoord. De komma is ook geen enkel probleem voor google, en gebruikers hebben een duidelijke url in beeld. Daarnaast zullen dezelfde pagina's ook op de oude manier te benaderen zijn.

Dat is denk ik het balngrijkste van het hele verhaal, zorgen dat meerdere manieren tegelijk mogelijk zijn.

[ Voor 41% gewijzigd door mees op 14-11-2005 14:55 ]

[LuCarD]

mees schreef op maandag 14 november 2005 @ 14:35:
Ik gebruik zelf altijd de slash i.c.m. tilde
slash ( / ) om variabelen te scheiden, en de tilde ( ~ ) ipv het 'is-teken' (=).

www.voorbeeld.nl/artikel~154/zoeken~zoekwoord

Het voordeel ervan? google indexeert sneller alle links op de pagina. Veel mensen verklaren het tot onzin, maar het is echt zo. Ik heb op dezelfde dag 2 websites online gezet. Dit was op 14 september dit jaar. Google heeft de url's met ~ en / nu volledig geindexeerd, terwijl de andere website die nog met ?, & en = werkt, nog steeds niet geindexeerd is. Waarom is mij een raadsel, maar ik blijf bij de slashes en tildes!
Daarnaast ben ik nog wel bezig met een page-alias systeem te maken voor mijn cms. Je geeft aan elk artikel op je website een page-alias mee, deze kan opgeroepen worden door bijvoorbeeld www.voorbeeld.nl/page,keywoord. De komma is ook geen enkel probleem voor google, en gebruikers hebben een duidelijke url in beeld.

Indexering werkt aan de hand van de inbound links. Dus hoe meer pagina's naar jouw linken hoe vaker de bot van google langs komt.

[mees]

LuCarD schreef op maandag 14 november 2005 @ 14:40:
[...]
Indexering werkt aan de hand van de inbound links. Dus hoe meer pagina's naar jouw linken hoe vaker de bot van google langs komt.

Dat verhaal is me wel duidelijk ja. Maar beide websites hebben 14 pagina's die naar hen linken. (volgens google). En de ene website is al volledig doorlopen, en de andere website is alleen nog maar de index van bekend. Verklaar dat maar eens.

[Not Pingu]

mees schreef op maandag 14 november 2005 @ 14:43:
[...]

Dat verhaal is me wel duidelijk ja. Maar beide websites hebben 14 pagina's die naar hen linken. (volgens google). En de ene website is al volledig doorlopen, en de andere website is alleen nog maar de index van bekend. Verklaar dat maar eens.

Als jouw bewering waar is, dan zouden alle sites die de querystring gebruiken voor het identificeren van resources, problemen moeten hebben met indexering en zou alleen maar de indexpagina geindexeerd moeten zijn. Ik kan je verzekeren dat dat niet het geval is.

De verklaring voor het verschil in indexering tussen je twee sites zou ik dus eerder zoeken in de pagina's die ernaar linken, de relevantie van de content en de sitestructuur. Want hoe controleer je welke pagina's zijn geindexeerd? dat ze niet in een google search naar voren komen wil niet zeggen dat google ze niet gevonden heeft.

[ Voor 22% gewijzigd door Not Pingu op 14-11-2005 14:49 ]

[Stewie!]

mees schreef op maandag 14 november 2005 @ 14:43:
[...]

Dat verhaal is me wel duidelijk ja. Maar beide websites hebben 14 pagina's die naar hen linken. (volgens google). En de ene website is al volledig doorlopen, en de andere website is alleen nog maar de index van bekend. Verklaar dat maar eens.

Een conclusie op basis van de indexering van 2 websites?

[mees]

zegt " site:www.url.com" in google jou iets?
Daarmee meet ik het aantal links. En ik beweer niet dat iedereen met die querystring problemen heeft, maar dat het in mijn geval beduidend trager gaat dan anders. En daarbij zien slashes en tilders er leuker uit dan vraagtekens en ampersands..

DaMorpheus schreef op maandag 14 november 2005 @ 14:53:
[...]

Een conclusie op basis van de indexering van 2 websites?

Nee hoor, ik heb het vaker meegemaakt. Maar ik wilde het nu gewoon eens testen, dus heb 2 websites online gezet met dezelfde inhoud, alleen andere URL opbouw.

Van google.nl zelf:

quote: http://www.google.nl/intl/nl/webmasters/guidelines.html

Richtlijnen voor webmasters
Door deze richtlijnen te volgen helpt u Google om uw site te vinden, te indexeren en te rangschikken. (...)
Als u kiest voor het gebruik van dynamische pagina’s (bijvoorbeeld pagina’s waarin het karakter '?' in de URL voorkomt), bedenk dan dat veel zoekmachines makkelijker overweg kunnen met statische dan met dynamische pagina’s. Het helpt als u met korte parameters werkt en als u het aantal parameters beperkt.
(...)

En nou wil het dus net, dat google de ~ niet ziet als een parameter, maar als deel van een map/bestands-naam. Denk maar aan de home.provider.nl/~uwnaam websites

[ Voor 83% gewijzigd door mees op 14-11-2005 15:23 ]

[Rickets]

Ik zou zelf voor de laatste optie gaan, maar ik vind de titel te lang. Die moet je wat beknopter zien te houden; niet de hele titel van het document hoeft er in vermeldt te worden. Als iemand die URL dan ergens ziet staan, heeft hij meteen een indruk waar dat document over gaat.

Karakters als ~ vind ik ook geen aanrader. Ten eerste typt het onhandig. Je kan je hierbij afvragen hoeveel mensen de URL intypen (hoevaak staat je URL op papier bv.), maar het blijven toch rare tekens voor mensen. Ten tweede kan het mensen een onveilig gevoel geven. Al die rare tekens in de URL zouden (in hun ogen) best eens van een virus kunnen komen, en voor je het weet is je creditcardnummer gestolen Houd je URL simpel.
Ook underscores en dashes zijn niet echt handig, het is niet altijd even duidelijk of er een dash of een underscore staat, maar soms heb je wel een scheidingsteken nodig.