Reportages, Strategie

Technische SEO in 2018: waar begin jij met optimaliseren?

0

Om goed te kunnen scoren in Google’s organische zoekresultaten is het van belang dat je de techniek op orde hebt. Techniek is één van de basiselementen van SEO. Op internet kun je genoeg checklists vinden waarmee je een prima audit kan doen. Wat echter vaak mist, is de context. Waarom moet je sommige dingen juist wel of niet doen? Als je niet begrijpt waarom, zie je kansen of problemen over het hoofd waarvan je niet wist dat ze bestonden.

Tijdens de conferentie Friends of Search op 8 februari werden er veel onderwerpen behandeld over SEO en Paid Search. Één daarvan was een masterclass over technische SEO in 2018, gegeven door Barry Adams van Polemic Digital. Hij bracht een aantal belangrijke punten aan het licht die vreemd genoeg vaak onderschat worden: JavaScript, sitesnelheid en gestructureerde data.

Om te begrijpen hoe deze drie elementen SEO kunnen beïnvloeden, moeten we eerst even kijken naar hoe Google en daarmee het proces van ranking, werkt.

  1. Crawling. Het bezoeken van je pagina’s door googlebot. Enkel de HTML wordt gelezen, op zoek naar links (a href) om verder te gaan met crawlen
  2. Indexing. Het daadwerkelijke ‘renderen’ van de pagina in twee stappen: eerst de ruwe HTML-code en daarna de volledige pagina met o.a. JavaScript. In dit proces wordt ook bepaald of een pagina in de index van Google wordt opgenomen
  3. Ranking. De aloude blackbox van Google waarmee bepaald wordt hoe de pagina’s gerangschikt worden op specifieke zoekopdrachten

Lees ook: 4 niet te missen (technische) SEO-trends

JavaScript & SEO

Een vraag die veel wordt gesteld is: kan Google JavaScript crawlen/indexeren? Barry reageert hier terecht op met: “Dat is de verkeerde vraag om te stellen.” Het simpele antwoord op die vraag luidt namelijk: “Ja!” Maar dat wil nog niet zeggen dat het gebruik van JavaScript geen negatieve gevolgen kan hebben op SEO.

Om te beginnen: JavaScript is niet per definitie slecht. Het kan zeer nuttig zijn voor de functionaliteit van een website en daarbij enorm bijdragen aan de gebruiksvriendelijkheid. In de meeste gevallen wordt JavaScript echter bij de gebruiker pas gerenderd in de browser. De manier waarop JavaScript gebruikt wordt, kan dan ten koste gaan van de efficiëntie waarmee de site wordt gecrawld en geïndexeerd.

Progressive enhancement

In theorie is JavaScript het best te gebruiken als laatste functionele laag over een al goed werkende HTML/CSS-website (ook wel Progressive enhancement genoemd). Dat wil zeggen dat een website zonder JavaScript al goed zou moeten functioneren en dat JavaScript enkel wordt toegevoegd ten behoeve van gebruiksvriendelijkheid en/of additionele en complexe functionaliteit (bijvoorbeeld calculators of widgets).

Als JavaScript echter noodzakelijk is bij de basisfunctionaliteit van een website, bijvoorbeeld voor het tonen van een lijst met producten op een categoriepagina van een e-commercewebsite, dat is als er voor SEO-problemen zouden kunnen ontstaan. Doordat JavaScript de producten en daarmee ook de links naar de productdetailpagina’s genereert, staan deze niet in de broncode (HTML). Hierdoor zal de crawler deze links in de eerste instantie niet vinden en niet crawlen.

Gevolg: de producten worden in de eerste instantie niet gevonden en zullen dus ook geen linkwaarde krijgen. Pas als de pagina wordt gerenderd tijdens het indexeringsproces zouden de producten en links zichtbaar kunnen worden. Dit kost Google aanzienlijk meer moeite dan als dit allemaal in de broncode aanwezig zou zijn.

Impact op crawlbudget

Als Google het uiteindelijk wel kan vinden, dan is er toch niets aan de hand? Fout! Waarom? Dat is waar het onderwerp ‘crawlbudget’ aan bod komt. Het crawlbudget geeft aan hoeveel aandacht Google aan een site schenkt. De grootte hiervan is niet openbaar, verschilt per site en wordt bepaald aan de hand van het linkprofiel. Hoe groter de autoriteit van een site, hoe meer aandacht de site krijgt van Google.

Wat is crawlbudget dan precies? Het is een verzamelnaam voor verschillende zaken in het crawlproces, URL importance, crawl prioritisation, crawl scheduling, etc. Geeft het crawlbudget dus aan hoeveel pagina’s er precies gecrawld worden? Ja en nee. Ja, omdat een groot crawlbudget ook inhoudt dat er meer pagina’s bezocht worden. Nee, omdat jij ook dit aantal kunt beïnvloeden door je site ‘crawlvriendelijker’ te maken. Als het crawlbudget dan toch een eenheid moeten geven, dan zou het ‘tijd’ zijn. Een paar voorbeelden.

  • Zorg jij ervoor dat er geen JavaScript gerenderd hoeft te worden? Dan scheelt dat enorm veel tijd en kan deze tijd gebruikt worden om andere pagina’s te crawlen.
  • Zorg jij ervoor dat je site twee keer zo snel wordt? Dan is een logisch vervolg dat er ook twee keer zoveel pagina’s gecrawld worden, zoals in dit voorbeeld (gejat van Barry’s presentatie (pdf)):

Impact site speed op crawlbudget

Laten we dit terugbrengen naar het stukje ‘JavaScript & SEO’ in combinatie met de term ‘crawlefficiëntie’. Als JavaScript noodzakelijk is voor de basisfunctionaliteit van je site, dan zal het aanzienlijk meer crawlbudget kosten om alle pagina’s te crawlen en indexeren, dan als dat niet het geval zou zijn. En in die gevallen is het gebruik van JavaScript wel degelijk schadelijk voor SEO. Wat zijn dan de oplossingen om dit tegen te gaan? Dit zijn er een aantal:

  • Asynchroon laden. Dit zorgt ervoor dat de JavaScript pas geladen wordt als al het overige al klaar is. De pagina kan dan al gebruikt worden terwijl de JavaScript in de achtergrond wordt geladen.
  • Server side rendering. Dit zorgt ervoor dat alle JavaScript al gerenderd is op de server en dat dit dus niet meer door de browser bij de gebruiker gedaan hoeft te worden.
  • Geen JavaScript. Het klinkt extreem, maar er zijn genoeg sites die zonder JavaScript prima functioneren. Gebruik het dus alleen als het daadwerkelijk toegevoegde waarde biedt.

Sitesnelheid/performance

Laadtijd is een rankingsfactor. Niets nieuws, hoop ik. Toch is het vaak een hele klus om dingen gedaan te krijgen, omdat veel verbeteringen veel technische mankracht vereisen. Als je alles tot in de puntjes wil optimaliseren, ontkom je er ook niet aan. Soms hangt het fruit echter lager dan je denkt en kan je vaak toch al best wat teweeg brengen met relatief simpele oplossingen.

Time to first byte (oftewel server response time)

Hoeveel tijd verstrijkt er nog voordat de eerste byte wordt gedownload? Je zult er soms versteld van staan hoeveel winst hierbij te pakken valt. Een goede server response time is ongeveer 200-300ms. In het geval van mijn site is daar dus nog wel wat verbetering te behalen:

Je kunt de volgende stappen ondernemen om de time to first byte te verbeteren:

  • Zorg voor een snellere server. Heb je een VPS? Overweeg naar meer cores/RAM of misschien zelfs naar een dedicated server. Zit je op een shared server? Dan wordt het tijd om je website serieus te nemen met op z’n minst een eigen IP en serverkracht.
  • HSTS protocol. Draai je volledig op HTTPs? Zorg er dan voor dat je het HSTS-protocol hebt geïmplementeerd. Check hiervoor de eisen op HSTSpreload.org. Als je voldoet aan de eisen, kom je op een lijst van sites terecht, die bij browsers bekend zijn dat ze altijd op HTTPs draaien. Als je site zonder HTTPs wordt opgevraagd, wordt er niet eerst een connectie gemaakt met de server voor de redirect naar HTTPs, maar vindt de redirect al in de browser plaats. Dit scheelt toch al gauw zo’n 200ms.

Paginagrootte

Het klinkt zo simpel, maar hier is vaak ook veel verbetering mogelijk:

  • Optimaliseer je afbeeldingen. Laad geen afbeeldingen groter in dan dat ze getoond worden en gebruik tools als ReSmush.it (handig voor platforms als WordPress en Magento) of tinypng.com (drag & drop afbeeldingen optimaliseren) om ze nog kleiner te maken.
  • Schone code! Ruim die code op van ongebruikte spaties, enters, etc. Dit gaat verder dan het gebruikelijk minimaliseren. Heb je namelijk wel eens onderzocht hoeveel code op je pagina niet gebruikt wordt? Dit kan je als volgt in Chrome opzoeken: Inspecteren > CTRL/CMD + Shift + P > “Show Coverage” en daarna de pagina herladen. Wat je te zien krijgt, is iets als het volgende (voorbeeld is mijn site):

Ongebruikte codeGezien het hier om WordPress gaat, verbaast dit percentage mij niet veel. Platforms als WordPress staan namelijk bekend om hun uitgebreide mogelijkheden, maar waar je in de praktijk slechts een klein deel van gebruikt. De code wordt dan vaak wel ingeladen, maar niet gebruikt.

Afstand tussen server en gebruiker

Ja, de afstand tussen de server en de gebruiker kan een grote rol spelen bij het verbeteren van de snelheid. Als je bijvoorbeeld een website hebt die wereldwijd goed bereikbaar moet zijn, overweeg dan het volgende.

  • Lokale servers. Simpel, maar doeltreffend.
  • CDN met lokale servers. Dit zorgt ervoor dat de content wordt geserveerd vanaf een server die dichterbij gelegen is.

Tot zover de sitesnelheid. Heb jij nog goede tips die relatief snel te implementeren zijn? Laat het weten in de reacties!

Structured data

Tot slot wil ik het nog hebben over structured data. In de volksmond ook wel rich snippets genoemd. Hoewel je daarmee de gedachte en werking van structured data enorm tekort doet. Allereerst helpen structured data Google om je site beter te begrijpen. Een gevolg daarvan zou kunnen zijn dat je resultaten in Google er iets beter uit gaan zien (product snippets, anyone?)
Products structured data

Goed, de werking en de eventuele resultaten van structured data zijn bekend en spreken voor zich. Toch zijn er een aantal implementaties die vaak onder de radar doorvliegen, omdat ze ogenschijnlijk niet direct een grote impact hebben. Ik zal hiervan de zes belangrijkste benoemen.

  1. Organization. Helpt bij het definiëren van je website als een organisatie en kan als resultaat de ‘brand onebox’ hebben. Vergeet niet je socialmedia-profielen hierin te verwerken, gezien deze ook in de onebox kunnen verschijnen. Let wel op: dit wordt niet zomaar bij alle sites getoond, maar doorgaans bij grotere merken of websites met autoriteit.
  2. Local busines. Heb je meerdere vestigingen? Implementeer dan deze schema. Dit verhoogt ook de kans dat vooral op mobiel je vestigingen er mooi uit komen te zien.
  3. SearchAction. Dit zorgt ervoor dat bij je resultaat er een zoekveld verschijnt, waarmee er meteen gebruik kan worden gemaakt van de interne zoekfunctie op je site. Zorg er wel voor dat je interne zoekfunctie goed werkt, anders kan je deze beter overslaan.
  4. Reviews. Een hele populaire, maar wordt vaak toch verkeerd gebruikt. Gebruik deze enkel om de beoordeling van producten of diensten te tonen en niet om sterretjes te krijgen bij alle pagina’s op je site. De kans is dan groot dat deze uiteindelijk weer verwijderd worden.
  5. Products. Misschien wel de bekendste, maar mag in zo’n lijst niet ontbreken. Combineert meteen de review snippets met informatie over het product. Bedenk wel of je alle informatie in je snippet wil tonen. Voorbeeld: als dingen als prijs en voorraad regelmatig wijzigen, kun je deze wellicht beter niet als structured data opgeven. De kans dat de informatie verkeerd wordt weergegeven in Google is dan redelijk groot. Denk bijvoorbeeld aan een product dat even geen voorraad had, nu weer wel, maar in Google nog steeds staat als ‘uitverkocht’.
  6. WebSite. Het lijkt zo simpel en voor-de-hand-liggend, maar in een tijd waarbij lang niet alle resultaten in Google-websites staan, bevestigt deze code toch maar dat jouw site echt een website is.

 

Wil jij in een paar uur tijd zoveel mogelijk te weten komen over SEO? Volg dan een training of webinar [tip]

Implementatie & testen van structured data

Structured data dienen in de code geïmplementeerd te worden. Er zijn hier meerdere manieren voor, waarvan JSON-LD de meest flexibele is en nota bene door Google de aangeraden manier is. Het voordeel van JSON-LD is dat je niet hoef te rommelen in de code en verschillende elementen moet voorzien van extra stukjes code (zoals bij microformats). JSON-LD wordt namelijk als een leesbaar lijstje geïmplementeerd in de header.

Tenslotte nog een paar tips met betrekking tot de implementatie:

  • Gebruik de structured data testing tool van Google om te controleren of de implementatie goed is gegaan.
  • Gebruik niét Google Tag Manager om JSON-LD toe te voegen aan de code. Het nadeel hiervan is namelijk dat deze werkt met externe JavaScript, waardoor deze pas bij het indexeren wordt gelezen. JSON-LD in de header staat in de broncode en wordt dus sneller gelezen. Deze methode is echter wel prima om structured data te testen.
  • Hetzelfde geldt voor de data highlighter tool in de Google Search Console. Ook dit is prima als test.

Waar begin jij met optimaliseren?

Ik hoop dat ik je met bovenstaande handvatten hebt gegeven om verder te gaan met de optimalisatie van je website. Heb jij nog goede suggesties voor relatief laagdrempelige optimalisatieslagen? Dan hoor ik ze graag in de reacties. Succes!

Dit artikel is gecheckt door het SEO-panel.