Webrichtlijn 27 t/m 33: URL's
Produceer unieke, onveranderende URL's (R-pd.4.1) Dynamisch gegenereerde URL's dienen nog steeds naar dezelfde inhoud te verwijzen als inhoud wordt gewijzigd of toegevoegd. (R-pd.4.2) Vermijd het gebruik van sessies in URL's. (R-pd.4.3) Zorg voor doorverwijzing naar de nieuwe locatie bij het verplaatsen van informatie. (R-pd.4.4) Automatische doorverwijzing dient, indien mogelijk, uitgevoerd te worden door de server. (R-pd.4.5) Gebruik vriendelijke URL's, die leesbaar en herkenbaar zijn. (R-pd.4.6) Zet een leesbare, uitbreidbare directory-structuur op. (R-pd.4.7)
Helaas zitten vrijwel al deze punten niet binnen het bereik van een front-ender, en zijn we hierbij afhankelijk van het te gebruiken CMS, framework of back-end taal. Het enige wat wij kunnen doen, is geen gebruik maken van frames en <meta http-equiv="refresh">.
Waar we het wel over kunnen hebben, zijn onze voorkeuren. Wat vind jij een mooie URL (of URI, of IRI)?
De webrichtlijnen spreken over het opzetten van een leesbare, uitbreidbare directory-structuur. Hoe doe je dit met bijvoorbeeld tags (die gecombineerd kunnen worden)?
Als je wel de controle over de infrastructuur van de URL's hebt, hoe ver ga je dan? Zorg jij dat iedere pagina op slechts 1 URL te vinden is? Hoe ver ga je met HTTP? Denk je na over het verschil tussen een 301 header, en een 302? En als een pagina verwijderd is, gebruik je dan een 410, in plaats van een 404?
Hebben wij als front-enders, of de webrichtlijnen..als webrichtlijnen, genoeg overtuigingskracht (gehad) om grote, logge back-end systemen met nette URL's te laten werken? Of is dit vooral te danken aan SEO bedrijven en zoekmachines?
Reacties
- 1 Marcel op 06-05-2008 om 11:36 uur:
- Ik ga er zelf behoorlijk ver in. Bijvoorbeeld, in een site van me wil ik zodra je op "nieuws" klikt doorverwijzen naar het laatste nieuws artikel. Dus de links is feitelijk: site.nl/nieuws/ maar deze verwijst middels een serverside http redirect naar site.nl/nieuws/artikel-naam-en-zovoorts.html
Dus een 302 of een 301 redirect zou hier handig kunnen zijn, zeker voor opname in zoekmachines die deze codes (horen te) herkennen.
Maar mijn persoonlijke reden om url's te herschrijven is puur esthetisch. Ik vind site.nl/index.ext?id=21039 gewoon extreem lelijk.
Mijn favoriete rewrite voor een recente website:
http://nl.site.nl/nieuws/pagina.html
http://en.site.nl/news/page.html
Waarbij dus beide "nieuws" en "news" op de server dezelfde nieuws pagina (in mijn geval classic ASP, /news/index.asp) gebruiken, maar per language dus wel andere paden gebruiken.
Gewoon, omdat het kan ;-) - 2 Anne van Kesteren op 06-05-2008 om 11:54 uur:
- (Voor redirects naar het laatste artikel moet je geen 301 gebruiken. Dat geeft aan dat het permanent is. 302 is beter.)
- 3 Blaise Kal op 06-05-2008 om 14:12 uur:
- Welk CMS met nette URL's redirect site.nl/artikel/oude-titel naar site.nl/artikel/nieuwe-titel met een 301 als de titel van het artikel drastisch wordt aangepast? Een incorrecte URL-titel wil je in dat geval toch aanpassen. Ga je dan alle wijzigingen bijhouden?
In mijn CMS (ik hou me ook bezig met backend) houd ik hier geen rekening mee. Teveel moeite en database-clutter, te weinig winst op het gebied van gebruiksvriendelijkheid en SEO.
Ik geef wel een melding aan de gebruiker bij het URL titel veld dat het onverstandig is om de URL titels te wijzigen, en waarom.
En welk CMS kent het verschil tussen een 410 gone en 404 not found? Meestal wordt gewoon een hele row uit de database verwijderd en is het onmogelijk om het verschil te weten. Voor de gebruiker maakt het meestal ook weinig uit. Weg=weg.
In mijn CMS staat het na verwijdering nog een tijdje in de prullenbak (node_id krijgt een trash vlaggetje), dus totdat het definitief wordt verwijderd kan ik nog een 410 serveren.
Ook interessant: het gebruik van extensies. Ik gebruik ze alleen bij bronbestanden (.js .css .xml .jpg etc), niet bij HTML pagina's. Ik zie dat Marcel .html gebruikt. Waarom? Voor SEO of voor de gebruiker? - 4 Krijn op 06-05-2008 om 14:34 uur:
- @Blaise: Eerste probleem 'los ik op' door de URI/slug na invoeren niet meer te laten wijzigen. Erg 'cool', volgens sommigen :)
Voor een410status hou ik de URIs van verwijderde pagina's bij. Een request kijkt eerst of de resource een fysiek bestand is, daarna of de URI voorkomt als dynamische pagina, daarna of deze in de lijst met verwijderde pagina's staat (in dat geval een410, als die template er is). Als dat allemaal niet zo is, wordt er een404verstuurd. Het voegt weinig toe, maar het is technisch gezien ook niet zo lastig te maken. Vraag me alleen af of Google een410ook ziet als een404, en de resource dus uit de index haalt.
Wat betreft extensies hou ik ze ook aan voor fysieke bestanden (hoewel dat metMultiViewsook niet nodig is, maar daar zie ik weinig toegevoegde waarde), en voor andere content types (dantext/html) van een dynamisch gegenereerde pagina. - 5 Koen Willems op 07-05-2008 om 00:58 uur:
- Ik vind het wel apart dat je zo stellig beweert dat al deze webrichtlijnen buiten het bereik van de frontender vallen.
Waarom zou dat zo zijn?
Eigenlijk is een CMS toch ook niks meer en niks minder dan een (al dan niet uitgebreide) tool om content in een database te stoppen?
Je zou toch net zo goed kunnen beweren dat alles wat nodig is om content op een deugdelijke wijze aan bezoekers van een site te tonen als 'frontend' moet worden aangemerkt? - 6 Koen Willems op 07-05-2008 om 01:08 uur:
- Owh, en ik had ook nog een vraag:
(verdorie Krijn, ik kan mijn post hier dus niet editten!!!
Dealtje? Als jij die optie mogelijk maakt, krijg jij van mij op het congres in september een overheerlijke fles wijn).
Mijn vraag dus: wat is nou eigenlijk de beste manier om spaties in een URL weer te geven?
Zelf koos ik er ooit voor underscores te gebruiken. Het argument dat ik daarvoor had was dat een underscore in het Nederlands geen normaal leesteken is.
Veel later werd me duidelijk dat Google weinig of niks met die underscores kan, doch een verbindingsstreepje prefereert.
Moet ik dan maar zwichten voor de hegemonie van Google? Ofschoon Google 's-Gravenhage ten onrechte als twee woorden ziet? - 7 Jules op 07-05-2008 om 07:32 uur:
- Het gebruik van een underscore in hyperlinks heeft ook een nadeel als je een hyperlink in een e-mail of een (Word-)document opneemt. Zodra je de hyperlink in je tekst plakt, wordt deze onderstreept. De underscore wordt dan voor de lezer onzichtbaar.
Da's voor mij een extra reden om de underscore niet in URLs te gebruiken. - 8 Kilian Valkhof op 07-05-2008 om 10:09 uur:
- Nog een ander argument voor streepjes i.p.v. liggende strepen: Het schijnt voor je oog prettiger te zijn als de streep in het midden van de tekst staat. met een liggend streepje moet je ook telkens "verspringen" en neem je de link minder goed op.
In óns cms (hehe...) hebben we er voor gekozen om geen extenties te gebruiken, alle pagina's zijn dus "mappen": website.nl/pagina/. subpagina's komen daar onder te hangen. Voor spaties gebruiken we inderdaad streepjes.
Ik ben wel benieuwd hoe andere mensen meertalige sites aanpakken. In het verleden hebben wij zowel website.nl/nl/pagina/ als nl.website.nl/pagina/ gebruikt, en voor bijvoorbeeld Nederlands Belgisch website.com/benl/ (de taalcode be-NL, dus). Achteraf had daar misschien een streepje tussen gemoeten. Wat denkt de rest hierover?
Gelukkig is mij nog nooit gevraagd om een link voor meerdere tags aan te maken, en ook met de verschillende HTTP codes doen we nog niet zo veel (buiten de standaard errorpagina's om)
Koen, links worden vaak gegenereerd vanuit een CMS of framework, iets wat veelal door de backendpartij wordt gemaakt en geleverd. Hier heb je al "template-bouwer" dus weinig over te zeggen. Ik denk dat Krijn dus inderdaad ook een goed punt heeft dat de grote SEO bedrijven die in dure rapporten pleiten voor leesbare IRI's meer invloed hebben dan Front-enders. - 9 Monique op 07-05-2008 om 12:42 uur:
- Mijn voorkeur gaat ook uit naar "vriendelijke" URL's die iets zeggen over waar de pagina over gaat. Al die cijfertjes en lettertjes door elkaar zegt zo weinig.
Ik ben nog niets zo thuis in CMS-sen, maar dacht dat daarin vaak de mogelijkheid geboden wordt om die uitgebreide URL's om te zetten naar "vriendelijke" URL's?
Na het lezen van de diverse bovenstaande commentaren ben ik benieuwd of het noodzakelijk cq. wenselijk is om een streepje te gebruiken als een naam van een pagina uit meer dan één woord bestaat. Bijvoorbeeld deze pagina:
webrichtlijnen-over-urls
of
webrichtlijnenoverurls - 10 Kilian Valkhof op 07-05-2008 om 15:03 uur:
- Waarom wenselijk: wat als de site www.experts-exchange.com geen streepje had? ;)
Met streepjes is het duidelijk wat de woorden zijn, voor mensen én voor zoekmachines. Het is dus ook nog eens een goede plek voor keywords. - 11 Jules op 07-05-2008 om 15:21 uur:
- @ Monique
Er zijn nog veel (grote) CMS-sen waar je geen of weinig controle op de gegenereerde URL. - 12 Koen Willems op 07-05-2008 om 22:40 uur:
- Ok, bedankt voor alle reacties mbt. de spaties in de URL's.
Ik ga het spul omzetten. Ben benieuwd wat me dat feitelijk in Google gaat opleveren. - 13 Marcel op 08-05-2008 om 13:50 uur:
- @Blaise
>> Ik zie dat Marcel .html gebruikt.
>> Waarom? Voor SEO of voor de
>> gebruiker?
Puur mijn eigen voorkeur, ik vind het mooier. Qua SEO lijkt het niet bijzonder veel uit te maken. En het zou ook niet veel uit mogen maken. Google weet ook wel dat wij tegenwoordig aan URL rewrites doen ;-)
Mijn voorkeur projecteer ik dan weer op mijn bezoekers. Ik ga er vanuit dat ze een HTML document sneller vertrouwen dan een ".dll" of ".pl" document.
HTML-documenten zijn over het algemeen lekker neutraal. Door op een link met op het einde .html te klikken wek je in ieder geval de indruk dat het een veilige link is.
Wat betreft multi-lingual websites, zelf prefereer ik het volgende:
http://nl.website.tld/path/id/file.html
En voor Nederlandstalige Belgen zou ik gewoon "nl" blijven gebruiken, geen "nl-be" of iets dergelijks.
Als het even kan gebruik ik seperate domeinen ook voor respectievelijk hun languages.
http://nl.website.nl/..
Is dan overbodige informatie.
http://en.website.nl/..
Slaat nergens op als je ook het domein:
http://website.co.uk/..
Tot je beschikking hebt.
In dit soort gevallen gebruik ik liever meerdere domeinen met 1 hoofd domein welke een neutrale TLD gebruikt, zoals .net, .com, .org, .eu, et cetera.
www.website.nl verwijst dan naar:
http://nl.website.net/
www.website.co.uk verwijst naar:
http://en.website.net/
en.website.nl verwijst naar:
http://www.website.co.uk/
Welke op zijn beurt direct naar:
http://en.website.net/
Verwijst.
Zoals Anne al aangaf is het zaak om de juiste HTTP redirect codes te hanteren. Voor een homepage zou het een permanente redirect zijn, lijkt me.
Maar al dit is vooral gebaseerd op persoonlijke voorkeuren, niet beinvloed door enige up-to-date SEO kennis. De laatste SEO site die ik heb gemaakt is al weer een half jaar oud. - 14 Koen Willems op 12-05-2008 om 01:32 uur:
- Inmiddels heb ik na grondig testen de Regelingenbank omgezet van underscores naar dashes.
Voorzover gebruik wordt gemaakt van 'oude' bookmarks (met een underscore) wordt men keurig met een 301-header geredirect naar de nieuwe versie met dashes.
Daar kwam ik mij waarempel een probleem tegen waar ik me nog niet bewust van was: $_SERVER['REQUEST_URI'] bevat geen pagina-ankers (en die waren in de 'oude' versie ook met underscores genoteerd).
Daar heb ik nou al twee dagen op zitten prutsen, maar ik kom domweg tot de conclusie, dat er geen mogelijkheid is (tenzij met javascript uiteraard) om een anker (#) in een URL op serverniveau 'te pakken' te krijgen en die vervolgens te manipuleren.
Als iemand daar een oplossing voor weet hou ik me aanbevolen!!! - 15 Krijn op 12-05-2008 om 09:01 uur:
- Koen: Dat is het idee van een fragment identifier inderdaad. Alleen op te lossen door je
id's (en links naar dieid's) wel met underscores te houden, of door rond te hacken metlocation.hashtijdens het laden van de pagina.
Overigens kun je wel redirecten naar eenpagina-met#een-id, maar daar heb je weinig aan :)
(Heb je trouwens door dat ik reactie 6 heel sneaky negeer? :P) - 16 Koen Willems op 13-05-2008 om 01:22 uur:
- Koen noteert: 'Krijn lust geen wijn'.
- 17 Bob Coret op 07-09-2008 om 22:18 uur:
- Voor een ieder die een melding krijgt ten aanzien van R-pd.4.3:
De controle op R-pd.4.3 (sessie in URL) via de Webrichtlijnen Quickscan is niet goed. Ik ben in de (webrichtlijnen) code gedoken en heb een naar mijn mening te onnauwkeurige reguliere expressie gespot in de parse403 functie op regel 1401 van parser.php:if (preg_match('#href=\"?(.*)([a-f0-9]{16}|[a-f0-9]{32}|[a-f0-9]{64}|session=|sessionid=)#Ui', $rs_content,$matches)) {
Bovenstaande regel bleek een match te vinden in de volgende stukken HTML (van twee verschillende websites):href="/registreren/">Registreren is gratis</a>, <em>19.039</em> genealogen gingen u voor!</p><div class="rc_box"><div class="rc_top"><div></div></div><div class="rc_content" id="inlogbox"><form method="post" action="/inloggen/" onsubmit="return frmCheckInloggen();"><div><label for="usr_email">E-mail adres</label> <input name="usr_email" id="usr_email" type="text" value="" tabindex="1" size="25" maxlength="50"/><br/><input type="hidden" name="login" value="ok"/><input id="response" type="hidden" name="response" value=""/><input type="hidden" name="refer" value="http://www.stamboomforum.nl/"/><input type="hidden" id="challenge" name="challenge" value="cr8326398524804200
ofhref="http://www.stamboomgids.nl/bezoek/6328">Sint Anthoniepolder</a></p><p><a href="http://www.stamboomgids.nl/bezoek/6328"><img alt="Screenshot van website die in het zonnetje staat" width="200" src="http://www.thumbalizr.com/api/?url=http%3A%2F%2Fwww.familiemolema.nl%2Fsapra3.htm&width=200&api_key=12245b263e577807
Als er dus een href is met daarna ergens een hex-achtige string van (minimaal) 16 lang dan wordt dit - ten onrechte - geïnterpreteerd als een sessie id in een URL...
Heb het gemeld bij de auteur van de code.
mvg,
Bob