SEO-expert heeft steeds meer technische kennis nodig

Je ziet het design en de functionaliteiten van websites enorm veranderen, doordat gebruikers veeleisender zijn geworden. Zij verwachten een interactieve ervaring die vergelijkbaar is met een mobiele app. Twee technische ontwikkelingen die hieruit voortvloeien zijn voor SEO-experts van groot belang: JavaScript en Progressive Web Apps.

Kennis over traditionele SEO-technologie en -activiteiten is niet meer voldoende om succes te blijven boeken op het gebied van search. Een focus op techniek, content en autoriteit is weliswaar nog steeds relevant, maar voor toekomstgerichte SEO-activiteiten moet je ook rekening houden met vier belangrijke technische invloedfactoren: syntax (data en content toegankelijk maken op basis van de principes van zoekmachines), semantics (betekenis en context geven aan die data), user experience en AI. In dit artikel lichten we de experience-laag van de SEO-piramide toe aan de hand van twee actuele technische ontwikkelingen, JavaScript en Progressive Web Apps (PWA’s).

Afb. 1 De vier lagen van de SEO Value Piramid

JavaScript

Om een mooie userinterface en goede functionaliteiten te kunnen bieden, kiezen steeds meer ontwikkelaars voor JavaScript. Sinds de introductie van frameworks zoals Angular is het mogelijk om hele websites in JavaScript te bouwen. Dit noemen we Single Page Applications (versus Multiple Page Applications, de traditionele website die is gebouwd in HTML).

Afb. 2 Verschil MPA en SPA

Deze ontwikkeling is van belang voor eenieder die zich bezighoudt met zoekmachineoptimalisatie. Er kleeft namelijk vanuit SEO bezien twee grote nadelen aan het gebruik van JavaScript waar je een oplossing voor moet zien te vinden:

 1. Crawlen gebeurt minder vaak en diep

Bij een Multiple Page Application (MPA) heeft elke pagina zijn eigen HTML-bron. Bij een Single Page Application (SPA) is er één HTML-bron voor alle pagina’s die bovendien ook nog eens leeg is, als je het vanuit het perspectief van de crawlbot bekijkt. Er staan immers geen metadata, content of links in, alleen verwijzingen naar JavaScript en CSS.

De crawlbot zal in plaats van de HTML-bron bij SPA’s gebruik moeten maken van het Document Object Model (DOM), de dynamische weergave van de pagina zoals de browser die ziet. Om dat mogelijk te maken moet er client-side rendering plaats vinden. Google kan dit als enige zoekmachine maar het duurt wel vijf keer zolang als het crawlen van MPA’s.

Dit betekent ook dat er veel tijd overheen gaat voordat nieuwe of bijgewerkte content zichtbaar is. Sites worden dus minder vaak én minder diep gecrawld waardoor ze niet volledig worden geïndexeerd en je content niet altijd te vinden is met als gevolg minder organisch verkeer.

Hoewel Google met behulp van haar web rendering service (WRS) JavaScript kan renderen is deze dienst gebaseerd op een oude versie van de Google Chrome-browser. Die versie is niet zo geavanceerd als de browsers die op dit moment door websitebezoekers wordt gebruikt. Dat betekent dat Googlebot en andere search bots geholpen moeten worden.

Een oplossing hiervoor en voor de overige zoekmachines (anders dan Google) die niet met JavaScript overweg kunnen, is pre-rendering. Voordat je een website lanceert of een nieuwe release doet maak je van alle pagina’s een statische HTML-snapshot. Hierbij moet wel worden aangetekend dat dit niet kan bij heel grote sites met duizenden pagina’s die regelmatig worden bijgewerkt.

Aan pre-rendering kleeft bovendien een risico: als de snapshot die je hebt gemaakt niet overeenkomt met het resultaat van de web rendering service, oftewel als er verschillen zitten tussen pre-rendering en rendering, dan is er sprake van cloaking en krijg je mogelijk een penalty van Google.

Afb. 3 Verschillende vormen van rendering

Google adviseert zelf als oplossing voor deze problematiek Isomorphic JavaScript. Dit is een complexe techniek waarvoor je aardig wat technische kennis in huis moet hebben. Maar op dit moment is het wel de beste optie om een website die bestaat uit een groot aantal pagina’s en is ontwikkeld met een JavaScript-framework toch goed weer te geven in de zoekmachine. Andere, minder complexe vormen van rendering zijn server-side rendering en dynamic rendering.

 2. Zware websites brengen laadtijd in gevaar

Een ander gevaar bij veel gebruik van JavaScript binnen de website zit hem in de performance. JavaScript kan de website heel erg zwaar maken waardoor de laadtijd te lang duurt, wat nadelig is voor de user experience. Het duurt door JavaScript niet alleen langer voordat de pagina wordt weergegeven, maar ook langer voordat de pagina of browser kan reageren op input (klikken, scrollen, toetsaanslagen) van gebruikers. Een pagina die geladen lijkt, is nog niet klaar voor gebruik en reageert niet of met aanzienlijke vertraging.

De laadtijd wordt in Nederland niet zozeer bepaald door het netwerk, omdat we bijna overal 4G hebben. Het uitvoeren van JavaScript bij een complexe applicatie is daarentegen wel een issue. Minder krachtige devices kost het veel inspanning (lees: tijd) om de pagina van een SPA te renderen. De processor van de smartphone van de gebruiker is de bottleneck in de performance en daar wordt nauwelijks rekening mee gehouden. Met als gevolg dat de website het prima doet op een desktop maar niet is getest op de smartphones die de doelgroep gebruikt.

 Afb. 4. Browserverwerkingstijd voor toegepaste JavaScipt van de website cnn.com | bron

Met de mobile-first filosofie van Google kan het zijn dat als je het heel slecht doet qua mobiele laadtijd, je minder goed gaat ranken. Zorg er daarom voor dat je weet welk device je doelgroep overwegend gebruikt en neem die mee in de test. Er zitten namelijk grote verschillen tussen de snelle iPhone en andere high-end modellen met krachtige processors en de goedkopere Android-smartphones.

Of je in de gevarenzone zit, kun je eenvoudig zien. Google meet via Google Chrome laadtijden van pagina’s door. Ze kijken dus naar de ervaring van echte gebruikers, op verschillende locaties, devices en verbindingen. Deze data (voor je eigen site en in vergelijking met concurrenten) zijn te vinden in het Chrome User Experience Report (CrUX) en beschikbaar in Google BigQuery.

Afb. 5 Performance dashboard op basis van CrUX data

Overigens is dit een kwestie van ‘pick your battles’: als je een snelle website nog sneller weet te maken, zal je die inspanning niet of nauwelijks terugzien in de ranking. Google wil met name de websites die slecht presteren stimuleren om een betere gebruikerservaring te bieden.

Daar staat tegenover dat de laadtijd van pagina’s ook invloed heeft op de conversie. Snellere pagina’s resulteren in meer omzet. Gebruik de Google Speed Scorecard om de snelheid van je site te vergelijken met die van je belangrijkste concurrenten en bereken met de Impact Calculator hoeveel extra omzet het oplevert als je site sneller wordt dan die van de snelste concurrent.

Progressive Web Apps (PWA’s)

PWA’s zijn ontstaan als alternatief voor native iOS en Android apps en leggen de lat van mobielvriendelijkheid aanzienlijk hoger. Responsive sites die op mobiel worden geopend hebben meestal de basis op orde, zoals niet in hoeven zoomen om iets te lezen, geen omleidingen naar irrelevante pagina’s en gemakkelijk de juiste link aanraken.

Afb. 6 Voordelen PWA

PWA’s gaan een paar stappen verder: zij kunnen gebruikmaken van de functionaliteiten waar de browser in combinatie met het besturingssysteem ondersteuning voor biedt, zoals notificaties en toegang tot de camera en contacten. Hierdoor kun je een rijkere of betere user experience bieden. Een ander belangrijk voordeel is dat PWA’s niet in een app-store hoeven te worden gedownload. Updates gebeuren automatisch dus de gebruiker heeft er geen omkijken naar.

Misverstanden over PWA’s

Er zijn veel misverstanden over het gebruik en de ontwikkeling van Progressive Web Apps. Met de volgende punten hopen we die enigszins weg te nemen:

• Elke website kan een PWA zijn;
• Een PWA kan functioneren en aanvoelen als een native app, maar is opgebouwd met webtechnieken als HTML, CSS & JavaScript;
• Een PWA hoeft geen Single Page App te zijn en het is ook niet nodig om een JavaScript framework te gebruiken (maar het kan wel);
• Zelfs met AMP kan een PWA ontwikkeld worden;
• Een PWA is bedoeld voor elk device, niet alleen voor smartphones en zeker niet alleen voor Android;
• Door een sterke focus op (client-side) caching laden PWA’s sneller, zijn ze betrouwbaarder en zelfs beschikbaar wanneer de gebruiker offline is;
• Een PWA vormt voor Google geen rankingfactor, maar kan een betere user experience en daarmee een beter antwoord bieden voor gebruikers van Google.

Voor de zoekmachinevriendelijkheid van een PWA gelden dezelfde vereisten als elke andere website. Wanneer een SPA de basis vormt van een PWA betekent dat er rekening gehouden moet worden met de client-side rendering-capaciteit van zoekmachines, zoals hierboven beschreven.

Is een PWA noodzakelijk?

Of je een PWA moet laten ontwikkelen hangt af van het type website, toegepaste technieken en doelgroep. Als je nu bijvoorbeeld voor een e-commerce site een iOS-, Android- en webversie in beheer hebt, kun je overwegen om daar met behulp van een PWA één versie van te maken.

Vooral online shoppers hebben een duidelijk voorkeur voor het web boven apps. Met een PWA ligt de focus met name op een betere user experience. Een PWA biedt wellicht betere kansen om de doelstellingen te realiseren en combineert het bereik van het mobiele web met de capaciteiten van een native app.

Met technische kennis je SEO-strategie waarborgen

De gebruikerservaring bepaalt in welke richting websites en apps zich ontwikkelen. Hoe die verandering wordt vormgegeven, is bij de meeste bedrijven in handen van developers, voor wie SEO waarschijnlijk niet meeweegt als keuzefactor. Des te belangrijker is het om je als SEO-expert te verdiepen in de technische implicaties van nieuwe ontwikkelingen zoals JavaScript en PWA’s. Zo word je een serieuze gesprekspartner voor developers en kun je de voordelen van nieuwe webtechnieken benutten en de nadelen goed managen. Maar ook voor marketeers is dit belangrijke informatie waarmee je de SEO-experts en developers waar je mee werkt bewust kunt maken van de impact van nieuwe ontwikkelingen.

Mobile SEO in 2018

Sinds juli 2018 betekent langer wachten (lees: een langere laadtijd) een lagere organische ranking voor mobiele pagina’s. Dit geldt voor alle pagina’s en staat los van de technologie die toegepast wordt. Deze en andere ontwikkelingen zijn van grote invloed op het succes van mobile SEO. Wij hebben deze ontwikkelingen daarom gebundeld in een whitepaper. Wil je weten aan welke eisen een mobiele website anno 2018 nog meer moet voldoen? In ons whitepaper lees je hoe je op het gebied van mobile SEO kunt excelleren.