JavaScript wordt een steeds een belangrijker onderdeel van het internet. Toch durven veel marketeers hun vingers er niet aan te branden. Waarom is dit zo? En hoe kan je JavaScript SEO-proof op je website inzetten? In dit blogbericht lees je hoe SEO en JavaScript tóch hand in hand kunnen gaan.
Wat is JavaScript?
JavaScript is een van de meest voorkomende programmeertalen voor websites. Het is een scripttaal die ervoor zorgt dat je content op een pagina dynamisch kan aanpassen. De tekst zelf die je hier leest wordt ingeladen via HTML en de opmaak (kleur, lettertype en grootte) wordt bepaald door middel van CSS. Met JavaScript kunnen we dit achteraf, eventueel door een interactie van de gebruiker, aanpassen. Zo kan je met de onderstaande knop het kopje van deze paragraaf aanpassen:
Wat zijn veelgebruikte toepassingen van JavaScript?
Het voorbeeld in de bovenstaande paragraaf is natuurlijk een versimpeling van wat JavaScript allemaal kan. Het aanpassen van een H2-attribuut is namelijk niet iets wat je vaak via een knop (en door de gebruiker) laat doen. Wel is dit een goed voorbeeld van hoe je met JavaScript aanpassingen kan maken aan de website. Hier zijn natuurlijk meer praktijkvoorbeelden van, waarin het wél van toegevoegde waarde kan zijn.
In het kort wordt JavaScript dus gebruikt om de statische content op een pagina dynamisch te maken. De mogelijkheden hierin zijn eindeloos. JavaScript toepassingen die wij vaak tegenkomen zijn de volgende:
Lay-out aanpassingen
Bij veel websites wordt JavaScript ingezet om de lay-out aan te passen. Denk hierbij bijvoorbeeld aan het vergroten of verkleuren van een afbeelding bij een hover.
Ook wordt JavaScript vaak ingezet om bepaalde stukken content te verbergen of juist weer te geven. Dit gebeurt vaak met de hoofdnavigatie van een website. Zo zie je bijvoorbeeld dat op deze website de hoofdnavigatie met een dropdown werkt: de subcategorieën worden pas zichtbaar zodra de gebruiker over de hoofdcategorie heen hovert:
Zonder JavaScript werkt deze functionaliteit niet:
Bovenstaande toepassing is niet per se goed of fout. Wat wel van belang is, is dat de belangrijkste content van de hoofdnavigatie (de interne links dus) altijd beschikbaar zijn in de broncode. In het geval van mvhmedia.nl is dit zo:
Dynamische content
Vaak wordt Javascript ook ingezet voor het genereren van dynamische content. De meest bekende zijn de meldingen en pop-ups die je op steeds meer websites langs ziet komen. Zolang hier geen cruciale content in staat, is het geen probleem in dit via JavaScript in te laden.
Wanneer het over categorie- en productteksten gaat, dan wordt het al wat spannender. Ook voor het inladen van dit soort content wordt JavaScript namelijk regelmatig ingezet. Dit heeft een aantal voor en nadelen:
| + In bulk mogelijkheid om veel content in 1 keer te plaatsen | – Content in mindere mate uniek |
| + Minder foutgevoelig voor typfouten | – Als je een fout maakt, dan heeft dit veel gevolgen |
| + Niet langer afhankelijk van je CMS | – Google kan deze content minder makkelijk lezen |
Technische SEO aspecten
Iedere SEO’er zal afraden om technische SEO aspecten, zoals meta robots, canonicals en hreflangs, via JavaScript in te schieten. Deze elementen hebben op SEO-technisch vlak zo’n grote invloed op de crawling en indexering van je website, dat het nodig geacht wordt om deze in je broncode op te nemen. In een ideale situatie moet je dat ook altijd doen, maar veel websites draaien op een CMS waar dit niet mogelijk is. In dat geval kan je ervoor kiezen om deze elementen door middel van JavaScript dynamisch te laten genereren en in te schieten.
In het onderstaande voorbeeld is een case te zien waarbij de hreflangs van een website ingeschoten zijn via JavaScript. Ondanks dat het langer duurt om dit op te pakken, heeft Google er toch ruim 10.000 kunnen ontdekken:
Google Tag Manager & JavaScript
JavaScript kan je door een developer laten inbouwen in je website, maar in dat geval is het voor SEO-facetten vaak beter om het direct in de broncode in te bouwen. Vooral wanneer je in een gesloten CMS (bijvoorbeeld Shopify of Lightspeed) werkt, dan kan het interessant zijn om bepaalde zaken via JavaScript in te schieten. In dit soort systemen is het namelijk erg lastig om direct in de broncode aanpassingen te maken. Google Tag Manager is een goede tool om deze JavaScript tags in een website te implementeren.
Bovenstaande geldt voor technische SEO-aspecten, maar kan ook breder ingezet worden. Een bekend probleem in gesloten CMS’en, is dat automatisch gegenereerde pagina’s (zoals een pagina met een assortiment van een bepaald merk) niet aanpasbare meta data hebben. Via Google Tag Manager kan je deze toch eenvoudig aanpassen. Het resultaat hiervan is dat Google hier toch een geoptimaliseerde paginatitel en meta description kan laten zien, zonder dat dit standaard in de broncode voorzien is:
In dit blogbericht lees je hoe je dit zelf kan opzetten. Daarnaast geven we daarin nog een aantal praktische toepassingen van JavaScript Tags in Google Tag Manager.
Wat zijn de problemen met JavaScript op het gebied van SEO?
Het dynamische karakter van JavaScript is ook gelijk de valkuil. Browser en bots moeten meer moeite doen om je website succesvol te verwerken. Dit is een onderliggende reden voor meerdere problemen die heavy JavaScript-based websites vaak hebben. Het oplossen van deze problemen begint bij een goede constatering van wat er precies mis gaat. Controleer daarom altijd de onderstaande punten als je veel gebruik maakt van JavaScript.
Rendering als extra stap naar een goede indexering en ranking
Het renderen van JavaScript zorgt voor een langere doorlooptijd richting een goede indexering en ranking. Er is immers een extra stap bij gekomen om tot een uiteindelijke pagina te komen. Googlebot kan namelijk initieel geen JavaScript renderen. Dit betekent dat eerst de niet-gerenderde broncode gecrawld wordt, deze doorgeschoven wordt om gerenderd wordt, terug in de crawl queue gezet wordt en vervolgens de gerenderde broncode gecrawld wordt. Gevisualiseerd ziet dit proces er als volgt uit:
Vanzelfsprekend zorgt dit ervoor dat de indexering van je pagina een stuk langzamer gaat, dan wanneer de belangrijkste content direct in de broncode beschikbaar is. Zeker bij grotere webshops kan dit een issue zijn: je crawlefficiënte komt in gevaar zodra Google miljoenen gerenderde en niet-gerenderde pagina’s moet crawlen.
Trage website door overmatig gebruik van (extern) JavaScript
Het gebruik van JavaScript kan je website aanzienlijk vertragen. Op nieuwere apparaten is dit voor de gebruiker vaak geen probleem, maar op oudere systemen (met name mobiele telefoons) kan dit tot een behoorlijke vertraging leiden. Ook wanneer je externe scripts inlaadt, kan dit een groot verschil maken. In dat geval ben je namelijk ook afhankelijk van de snelheid van een externe partij.
Zeker gezien de ontwikkelingen rondom de Core Web Vitals, is het van belang dat de snelheid van je website goed op orde is. Benieuwd hoe je dit kan verbeteren en waar je precies op moet letten? Recentelijk publiceerden we daar deze blog over.
Hoe kan je dit SEO-proof oplossen?
Al deze problemen zijn prima op te lossen. Wel is hier een samenwerking vereist tussen marketeer, developer en webhost. Geen van deze partijen kan namelijk de onderstaande oplossingen op zichzelf uitvoeren. Als marketeer ben je vooral verantwoordelijk voor de input en voor het prioriseren van welke content wel of niet in de broncode moet komen te staan. De technische uitvoering wordt meestal opgepakt door de developer in samenwerking met de webhost. Zeker wanneer we het hebben over server side rendering, dan is de laatstgenoemde partij van belang.
Belangrijke content? >>> Direct in de broncode
Als eerste moet je bepalen welke content precies van belang is. Deze moet vervolgens altijd direct bereikbaar zijn in de broncode (voor JavaScript rendering dus) Denk hierbij bijvoorbeeld aan:
- Technische SEO facetten
- Meta robots
- Canonicals
- Hreflangs
- Structured data
- Interne links
- Hoofdnavigatie
- Footer
- Tekstuele content
- Productomschrijvingen
- Categorieteksten
- Paginatitels
- Meta descriptions
- Blogposts
- CMS-pagina’s
Uiteraard verschilt het per website en zelfs per pagina wat er precies van belang is. Loop je website dus altijd grondig na om te bepalen wat er precies in de broncode terug moet komen.
Server side rendering / Dynamic rendering
Zodra je bepaald hebt wat in je broncode moet komen en wat in de DOM mag blijven hangen, kan je een oplossing gaan zoeken. Je zou ervoor kunnen kiezen om bepaalde dynamische functionaliteiten te laten vallen of om een manier te vinden om het via HTML op te lossen. Gelukkig is dit zeker niet altijd nodig. Je zou er ook voor kunnen kiezen om je JavaScript aan de server zijde te laten renderen.
Wat houdt dit precies in? Standaard wordt je JavaScript door de browser van de gebruiker gerenderd. Dit zorgt ervoor dat de server niet te zwaar belast wordt en dat de snelheid van de website vooral afhankelijk is van het apparaat van de gebruiker. Echter, voor Googlebot betekent dit dus ook dat dit aan hun kant gerenderd moet worden.
Met Server Side Rendering kun je dit ontlopen. Je zorgt er namelijk voor dat de JavaScript al aan de zijde van de server uitgevoerd wordt en in hapklare HTML aan Googlebot (en de gebruiker) aangeboden wordt. Ook voor gebruikers met oudere apparaten kan dit dus als prettig worden ervaren. De manier waarop de site wordt geladen wordt hierdoor namelijk ook duidelijk anders:
Naast Client Side Rendering en Server Side Rendering bestaat er ook nog Dynamic Rendering. Dit is een serieus interessante optie, omdat dit het beste van beide technieken combineert. Voor de gebruiker en je server load is CSR vaak de fijnere methode, terwijl voor zoekmachines SSR juist weer interessanter is. Met Dynamic Rendering laat je de server JavaScript uitvoeren voor je belangrijkste bots, maar zorg je ervoor dat de rendering voor gebruikers via de browser loopt. Dit loopt dus naast elkaar:
If it ain’t broke don’t fix it
De vuistregel in SEO (en met heel veel andere dingen) blijft: ‘If it ain’t broke don’t fix it’. Met andere woorden: als je belangrijkste content zichtbaar is in de broncode en alleen je minder belangrijke onderdelen worden via JavaScript ingeladen: so be it. Niet alles hoeft terug te komen in je broncode. Je hoeft dus niet alle JavaScript van je website te verbannen en zelfs voor de belangrijkste onderdelen hoeft het nog geen ramp te zijn. Met wat vertraging komt het voor je belangrijkste pagina’s toch wel goed. Pas als je een groot aantal geoptimaliseerde pagina’s hebt die grotendeels op JavaScript leunen, dan kan het problematisch worden. Uiteraard blijft het wel een goed idee om te inventariseren hoe afhankelijk jouw website is van JavaScript.
Praktische JavaScript SEO tips
Na dit artikel weet je in grote lijnen wat JavaScript voor invloed heeft op SEO en hoe je (samen met een developer) deze problemen kan aanpakken. Maar hoe constateer je problemen? En waar moet je nou beginnen? Hieronder heb ik nog een aantal praktische JavaScript SEO tips verzameld:
- Sluit JavaScript bestanden nooit uit in robots.txt. Hiermee zou je namelijk ervoor zorgen dat Google je website niet kan renderen. Zo kan deze ook niet goed geïndexeerd worden;
- Benieuwd hoe Google jouw website rendert en ziet? Met Mobile Friendly Test kan je een snapshot hiervan zien;
- Met de Chrome extensie View Rendered Source kan je inzien wat er precies aangepast wordt door JavaScript
- Gebruik tooling om jouw scripts te testen. Dit kan je doen met bijvoorbeeld JSFiddle.
Heb je een vraagstuk over JavaScript en SEO waar je zelf niet uitkomt? Of wil je graag even sparren? Aarzel dan niet om contact met ons op te nemen. We helpen je graag verder bij het verbeteren van jouw SEO.
