SEO vriendelijke klikbare div's

Let op: Tweakers stopt per 2023 met Tweakblogs. In dit artikel leggen we uit waarom we hiervoor hebben gekozen.

Door joint_me op maandag 11 oktober 2010 21:21 - Reacties (21)
Categorieën: HTML, Optimalisatie, SEO, jQuery, Views: 5.240

Na het openen van mijn TweakBlog heb ik een tijdje nagedacht over een onderwerp voor mijn eerste bericht, om vervolgens mijn TweakBlog helemaal te vergeten. Totdat ik vandaag een stukje code tegenkwam wat voor mij een gewoonte is om te gebruiken.

Deze code is het directe gevolg van semantiek en het rekening houden met 3 soorten bezoekers.

Menselijke bezoeker, zonder visuele beperking
Menselijke bezoeker, met een visuele beperking
Crawlers, zoals de Google bot

Is een div klikbaar?

Nee, een div is niet klikbaar, maar je kunt hem wel klikbaar maken. En volgens mij is er maar 1 juiste manier.

Maar laten we eerst kijken hoe het niet moet:

HTML:

<div class="klikbare_div" onClick="top.location.href('http://www.tweakers.net/');">
  <h4>Title van het blok</h4>
  <p>Hier staat een stukje tekst, met interessante woorden en tekens.</p>
  <p>Lees meer ></p>
</div>

Waarom is dit geen optie? Er staat javascript direct in je code, dit gaat ten koste van tekst-code ratio beoordeling door een crawler. En een tekstreader zal in het beste geval de link lezen voordat de context behandeld is.

Een andere gebruikte optie is:

HTML:

<a href="http://www.tweakers.net/" id="klikbaar_blok" style="display: block;">
  <h4>Title van het blok</h4>
  <p>Hier staat een stukje tekst, met interessante woorden en tekens.</p>
  <p>Lees meer ></p>
</a>

Deze is niet veel beter, ten eerste staan er block elementen in een inline element. Dit is W3C niet toegestaan en levert je waarschijnlijk minpunten op van de crawler. Ook zal in dit geval een tekstreader de link voor de context behandelen.

Wat is dan wel een goede oplossing? Het antwoord is javascript en in mijn voorbeeld zal ik gebruik maken van jQuery. Waarom jQuery kun je jezelf afvragen? Nou daarom

De oplossing die ik gebruik, bestaat uit 3 delen:

In het <body> van de pagina maak ik gebruik van de volgende semantische HTML:

HTML:

<div class="klikbare_div">
  <h4>Title van het blok</h4>
  <p>Hier staat een stukje tekst, met interessante woorden en tekens.</p>
  <a href="http://www.tweakers.net/">Lees meer ></a>
</div>

In de <head> include in een stukje Javascript.

HTML:

1	<script src="/javascripts/website.js" type="text/javascript"></script>

En in het javascript bestand heb ik ongeveer 6 regels code staan.

JavaScript:

$(document).ready(function(){
  $('div.klikbare_div').click(function() {
    div_link = $(this).find('div.klikbare_div a').attr('href');
    window.location = div_link;
  });
});

Het resultaat is

duidelijk en leesbare HTML. Een text-reader zal geen problemen hebben de tekst goed lezen, net zoals een crawler.
Er staat geen onnodige Javascript in de Content, de verhouding text-code wordt hierdoor beter.
De link staat onderaan de div, zodat de link goed in de context kan worden gezien. Ook krijgt tekst in een link punten mee van google, we herinneren ons vast nog wel 'raar kapsel' op google.
De Javascript is generiek en zal alle div's met class "klikbare_div" klikbaar maken.
Met een paar regels kun je een cross-browser hover toevoegen op de div.

Dit was mijn eerste bijdrage, ik hoop dat jullie er wat aan hebben. En nu ga ik nadenken over een volgend onderwerp.

p.s. Bedankt voor de feedback!

Reacties

Door MittaM, maandag 11 oktober 2010 21:38

Interessant stukje code.

Door Sebazzz, maandag 11 oktober 2010 21:42

SEO vriendelijke klikbare div's

Search Engine Optimalization vriendelijke klikbare div's? Je bedoeld search- en accessibility friendly clickable div's.

Deze is niet veel beter, ten eerste staan er block elementen in een inline element. Dit is semantisch niet toegestaan en levert je waarschijnlijk minpunten op van de crawler.

Weet je wel wat semantiek betekent? Los hiervan, het is gewoon volgens de HTML specificatie niet toegestaan.

Overigens zou ik qua usability zoiets niet doen, en als ik het zou doen dan zou ik hem ten minste een pointer cursor geven.

[Reactie gewijzigd op maandag 11 oktober 2010 21:43]

Door AW_Bos, maandag 11 oktober 2010 21:45

Geweldige tutorial.

Door plofkip, maandag 11 oktober 2010 21:47

Sebazzz schreef op maandag 11 oktober 2010 @ 21:42:
Overigens zou ik qua usability zoiets niet doen, en als ik het zou doen dan zou ik hem ten minste een pointer cursor geven.

Dat doet ie natuurlijk via CSS en z'n 'klikbare_div'-class

Door veldmuis, maandag 11 oktober 2010 21:47

Volgens mij maak je een oplossing voor een probleem wat niet bestaat. Voor groep 1, de bezoekers met een 'gewone' browser, maak je iets wat anders reageert dan je mag verwachten.

Over semantiek, SEO e.d. gesproken: een H1 voor een titel van een blok lijkt me niet handig.

Door joint_me, maandag 11 oktober 2010 21:51

Sebazzz schreef op maandag 11 oktober 2010 @ 21:42:
[...]
Weet je wel wat semantiek betekent? Los hiervan, het is gewoon volgens de HTML specificatie niet toegestaan.

Overigens zou ik qua usability zoiets niet doen, en als ik het zou doen dan zou ik hem ten minste een pointer cursor geven.

Blijkbaar heb ik semantiek niet goed gebruikt volgens jou, jammer dan, volgende keer beter. Maar leg dan maar eens uit, zodat ik het de volgende keer wel goed gebruikt?

Maar usability technisch gezien zou ik het juist wel gebruiken! IE browsers zijn nog steeds veel gebruikt en ondersteund tot en met IE7 geen :hover op div's. Met jQuery kan je makkelijk een class toevoegen. Wat je daaraan dan toewijst is aan jouw.

JavaScript:

$(this).hover(function () {
  $(this).addClass('hover');
}, function () {
  $(this).removeClass('hover');
});
$(this).click(function () {
  div_link = $(this).find('div.klikbare_div a').attr('href'); 
  window.location = div_link; 
});

Maar dat beschrijf ik al in mijn stukje.

[Reactie gewijzigd op maandag 11 oktober 2010 21:52]

Door i-chat, maandag 11 oktober 2010 21:51

maar nu natuurlijk de grote vraag? waarom een klikbare div, wat is er zo bijzonder aan een klickable_div...

als je een beetje pech hebt denkt je screenreader dat het hele ding een link is en maakt ie de boel blauw, heb je ooit wel eens met screenreaders gewerkt? zo neej doe dat dan eens ...

dan is dit gelijk de laatste keer dat je ooit nog over klikbare divs hebt nagedacht...

Door joint_me, maandag 11 oktober 2010 22:11

i-chat schreef op maandag 11 oktober 2010 @ 21:51:
maar nu natuurlijk de grote vraag? waarom een klikbare div, wat is er zo bijzonder aan een klickable_div...

als je een beetje pech hebt denkt je screenreader dat het hele ding een link is en maakt ie de boel blauw, heb je ooit wel eens met screenreaders gewerkt? zo neej doe dat dan eens ...

dan is dit gelijk de laatste keer dat je ooit nog over klikbare divs hebt nagedacht...

Als je een div klikbaar maakt, hoef je niet meer zo te mikken op 1 stukje tekst. Je kunt het gebruiken voor actieblokken, prijsblokken, opsommingen, etc.

Ik klik bijvoorbeeld vaak op de tekst bij "Reviews & Features" op de homepage en vind het dan jammer dat hij niet verder gaat. Of je moet op de titel klikken, of op de kleine pijltjes naast de tekst of de afbeelding, waarom dan niet op de tekst?

Voorzover ik het begrepen heb, leest een screenreader geen Javascript, daarom staat de link dan ook in de div als een standaard href. De Javascript haalt hem er alleen uit en plakt hem aan de div. Dus ik denk niet dat een screenreader hier problemen mee heeft.

Door joint_me, maandag 11 oktober 2010 22:16

veldmuis schreef op maandag 11 oktober 2010 @ 21:47:
Over semantiek, SEO e.d. gesproken: een H1 voor een titel van een blok lijkt me niet handig.

Die zal ik voor jou aanpassen!

[Reactie gewijzigd op maandag 11 oktober 2010 22:49]

Door ACM, maandag 11 oktober 2010 22:22

joint_me schreef op maandag 11 oktober 2010 @ 22:11:
Ik klik bijvoorbeeld vaak op de tekst bij "Reviews & Features" op de homepage en vind het dan jammer dat hij niet verder gaat. Of je moet op de titel klikken, of op de kleine pijltjes naast de tekst of de afbeelding, waarom dan niet op de tekst?

Vziw hebben daar gebruikers expliciet van gevraagd om het niet klikbaar te hebben... Wellicht ivm het niet ongebruikelijke gedrag om tekst aan te klikken die men leest.

Door veldmuis, maandag 11 oktober 2010 22:40

joint_me schreef op maandag 11 oktober 2010 @ 22:16:
[...]

Die zal ik voor jouw aanpassen!

Dat hoeft niet voor mijn.

[Reactie gewijzigd op maandag 11 oktober 2010 22:40]

Door Sebazzz, maandag 11 oktober 2010 23:50

joint_me schreef op maandag 11 oktober 2010 @ 21:51:
[...]

Blijkbaar heb ik semantiek niet goed gebruikt volgens jou, jammer dan, volgende keer beter. Maar leg dan maar eens uit, zodat ik het de volgende keer wel goed gebruikt?

Semantiek is niet iets van HTML, het is gewone taal. Zoek maar eens op in het Van Dale en je ziet dat 'semantiek' 'betekenis' betekent

Dus de betekenis van elementen en attributen in deze context. Niet validatie.

Door RobIII, dinsdag 12 oktober 2010 00:01

Waarom is dit geen optie? Er staat javascript direct in je code, dit gaat ten koste van tekst-code ratio beoordeling door een crawler.

Tekst-code ratio? En sinds wanneer is dat interessant? Heb je een (gezaghebbende) bron?

En een tekstreader zal in het beste geval de link lezen voordat de context behandeld is.

En dus

Lijkt me nou niet je grootste probleem (zie ACM's opmerking).

en levert je waarschijnlijk minpunten op van de crawler

Minpunten? Het levert je hooguit niet méér "punten" op.

Wat is dan wel een goede oplossing? Het antwoord is javascript

Wat meteen je ding onklikbaar maakt voor mensen die geen JS gebruiken.

Ik zie deze hele oplossing als eenzelfde oplossing als de target="_blank" niet gebruiken omdat 't niet W3C valid is en dus maar een JS omheen bakken zodat de code valideert... Daarmee hou je hooguit jezelf voor de gek.

Het resultaat is

* duidelijk en leesbare HTML. Een text-reader zal geen problemen hebben de tekst goed lezen, net zoals een crawler.

Dat heb je in de andere twee gevallen ook (goed leesbaar en een crawler zal er geen moeite mee hebben). Hooguit het verschil van de onclick en de anchor in voorbeeld 1 en je oplossing zal wat verschil hebben; maar je vergeet een optie: je kan die anchor ook gewoon in de div mikken en met CSS hiden

* Er staat geen onnodige Javascript in de Content, de verhouding text-code wordt hierdoor beter.

Heel die verhouding is, IMHO, uit de lucht gegrepen onzin.

Ook krijgt tekst in een link punten mee van google, we herinneren ons vast nog wel 'raar kapsel' op google.

Wat in 1996 ofzo interessant was. Je weet dat Google om de paar maanden z'n algoritmes herziet? En dat er nog 1001 andere dingen meewegen? En dat je van Google HTML 'moet' schrijven voor gebruikers en niet voor zoekmachines?

Je vergeet voor 't gemak ook even dat je (minimaal) 24Kb overhead op jQuery inlevert (want die zal toch geladen moeten worden (los van caching)) en dus ook nog een extra HTTP request (mits je jQuery zelf host). Gebruik je toch al jQuery en gebruik je (bijv.) de Google CDN dan is het nog andere koek, maar ik vind 't dus wat kort door de bocht.

ACM schreef op maandag 11 oktober 2010 @ 22:22:
[...]

Vziw hebben daar gebruikers expliciet van gevraagd om het niet klikbaar te hebben... Wellicht ivm het niet ongebruikelijke gedrag om tekst aan te klikken die men leest.

Juist!

[Reactie gewijzigd op dinsdag 12 oktober 2010 00:08]

Door i-chat, dinsdag 12 oktober 2010 08:13

joint_me schreef op maandag 11 oktober 2010 @ 22:11:
[...]

Voorzover ik het begrepen heb, leest een screenreader geen Javascript, daarom staat de link dan ook in de div als een standaard href. De Javascript haalt hem er alleen uit en plakt hem aan de div. Dus ik denk niet dat een screenreader hier problemen mee heeft.

niet helemaal, het probleem is dat je je screnreader dus niet kunt vertrouwen, er zijn al een tijde screenreaders die zelfs met javascript proberen om te gaan, en dan zijn dit soort dingen JUIST niet handig.

wat dan wel? - de titiel van je bron zegt het al 'no template' met andere woorden maak een bijna ouderwetse html versie van je pagina. gebruik webbased scripts voor dingen die je normaal in ajax zou doen. - en bovenalles schrijf html voor de gebruiker

Door -RetroX-, dinsdag 12 oktober 2010 08:43

Er zijn genoeg textreaders en SEO checkers in omloop om te zien wat wel en niet meegenomen wordt vanuit je code.

Google neemt ook je JS en CSS files mee die je aanroept vanuit je html. Hoe de berekening dan gaat is aan google. De beste optie om te scoren in zoekmachines is degelijke content. Als je echt afhankelijk bent van optimalisatietrucs dan weet je dus ook dat je content beter kan.

De gekozen oplossing is wel mooi. HTML voor de elementen, CSS voor opmaak, en JS voor de effecten. Of het volledig volgens standaard is... who cares? Ontwikkelaars die echt volgens standaarden ontwikkelen kiezen wel hun eigen methodes. Voor wie niet absoluut strict hoeft is dit echt een goede oplossing.

(en wie nog trucs gaat toepassen om IE6 en IE7 browsers te ondersteunen zou opgeknoopt moeten worden.)

Door ReneDx, dinsdag 12 oktober 2010 09:36

Wat is er mis met de volgende methode?;

code:

<a href="#">
   <strong>Title</strong>
   <em>Description</em>
</a>

Breed gebruikt. Ik ben een groot fan van JavaScript, maak er dan ook van alles in, maar ben altijd van mening geweest dat je CSS en (X)HTML de content as-is moet leveren. JavaScript laat je vervolgens de "extra's" regelen zoals effecten zover deze niet met CSS3 kunnen.

Vooral in deze situatie kan ik het niet eens worden met het JavaScript gebruik. Het is gewoon niet netjes naar mijn mening..

[Reactie gewijzigd op dinsdag 12 oktober 2010 09:52]

Door crisp, dinsdag 12 oktober 2010 09:50

Pas je doctype aan; blocklevel elementen in een <a> zijn in HTML5 gewoon toegestaan

Door -RetroX-, dinsdag 12 oktober 2010 09:50

... ReneDx heeft post aangepast. Reactie hierop niet meer relevant ...

(@ReneDx: je vroeg om wat is er mis is met een bepaald voorbeeld. Je kan daarover best discusieren. Later heb je de uitleg bijgevoegd waardoor de hele strekking van de post veranderd.)

Gebruik van HTML5 kan ook. Wel is aan te raden dan de juiste elementen te gebruiken. Er zijn heel wat mooiere elementjes die je kan gebruiken ipv strong en em. Als je toch bezig bent met SEO dan zou je dit meteen mee moeten nemen.

[Reactie gewijzigd op dinsdag 12 oktober 2010 10:39]

Door ReneDx, dinsdag 12 oktober 2010 10:02

-RetroX- schreef op dinsdag 12 oktober 2010 @ 09:50:
... ReneDx heeft post aangepast. Reactie hierop niet meer relevant ...

Die was al niet relevant hè

Vroeg enkel wat er mis is met deze (veel gebruikte) methode. Maar crisp punt is inderdaad ook een goeie.

Door Booster, dinsdag 12 oktober 2010 11:19

Op het gebied van SEO kan ik je afraden om dit soort anchor teksten te gebruiken:

code:

1	<a href="http://www.tweakers.net/">Lees meer ></a>

Anchor text helps users and search engines understand what page you’re linking to is about, and should be short, descriptive and on-topic.

Bad = “click here” or “read more”
Good = “The previous article in this series gave an introduction to SEO.”

Door Anoniem: 173717, dinsdag 12 oktober 2010 11:27

Crisp heeft gelijk. Block in inline is ok in HTML5. Erg handig!

Reageren is niet meer mogelijk

Interaction on Rails