SEO en single page applications: nog geen gelukkig huwelijk

Single Page Applications (SPAs) zien we steeds vaker opduiken in het wild. Voor digitale producten met een interface en voor marketing websites. Een trend die niet te negeren is. Een simpele search in Google Trends laat zien dat wereldwijd de vraag naar SPAs significant blijft. 

single page application google trends
Ontwikkeling wereldwijde interesse in ‘single page application’ (Google trends, 2019)

So far so good. En inderdaad. Ook voor de laadsnelheid en de user experience van je website is een SPA fantastisch. Jammer genoeg is het huwelijk met SEO – je website goed vindbaar maken in de gratis zoekresultaten bij Google – een stuk ingewikkelder. Het gaat vaak fout. En meestal wordt er te laat in het ontwikkelproces een SEO specialist aangehaakt.

In dit verhaal helpen we je op weg om SEO met een Single Page Application te overleven. En geen zorgen. We beginnen bij de basis en houden het simpel. Een paar dingen die je moet weten terwijl we verder de diepte in gaan:

Mooi. Nu kunnen we verdiepen..

Wat is een SPA?

Een Single Page Application (SPA) is een website of applicatie die feitelijk uit één pagina bestaat waarin de volledige experience wordt geleverd. Vandaar ook de naam Single Page Application natuurlijk. React en Angular zijn frameworks en libraries die vaak worden gekozen voor het ontwikkelen van een SPA.

Non-SPAs kenmerken zich doordat bij iedere link of klik je fysiek naar een andere pagina en URL wordt gestuurd. En op die pagina is vrijwel alle content direct in de front-end code opgeslagen.

Bij een SPA wordt op basis van acties van de gebruiker nieuwe content in de pagina geladen. Hij reageert op wat er gebeurd. Er is daarmee by default geen sprake van een URL structuur. Ook is er geen content opgeslagen in de front-end code. Hier ontstaat ook de complexiteit voor SEO.

De geschiedenis van SEO en SPAs

Om eerlijk te zijn. Er is een tijd geweest waarin ik SPAs vervloekte en hoopte dat het zou overwaaien als de Flippo hype. Eens in de zoveel tijd kwamen mijn collega’s en ik een klant tegen met een SPA die de wereld van inbound marketing wilde domineren. Dat waren destijds moeilijke gesprekken.

Google was nog zodanig slecht in het begrijpen en indexeren van een SPA en Javascript dat het meestal uitdraaide op een complete rebuild van het platform. Duur. Risicovol. En SEO specialisten waren de boosdoeners die een development team van de roze wolk af knikkerden.

Als tussenoplossing bood Google een destijds revolutionaire oplossing. De hashbang methode (#!). Klonk enorm fancy, werkte enigszins en was een nachtmerrie om te onderhouden.

Het kwam er ‘simpelweg’ op neer dat er URL strings met een #! werden geïmplementeerd in de SPA en dat via een meta tag in HTML de Google bots werden doorverwezen naar een schaduwsite met exact dezelfde content maar dan in platte HTML en zonder opmaak.

Praktisch gezien onderhield je dus twee websites met exact dezelfde content, waarbij Google je gratie gaf over dat de user experience van de te indexeren website crappy was. Blijft bijzonder. Ondanks dat dit met de kennis van nu de voorloper is geweest van een verbeterde remedie voor SPAs die ‘isomorphic JavaScript’ in de SEO wandelgangen wordt genoemd.

Ook Google had in de gaten dat de hashbang oplossing niet duurzaam was. Daarom werd al vrij snel na de hashbang introductie deze vakkundig de nek om gedraaid. En dat niet alleen. Direct daarna claimde Google dat het nu echt JavaScript (en dus SPAs) kon indexeren.

Vandaag de dag zien we dat Google inderdaad steeds beter wordt met SPAs en JavaScript, maar dat het vooral nog extra SEO issues in plaats van voordelen creëert. En dat daarmee winnen in competitieve markten met een SPA nog ver weg lijkt. Maar één ding is duidelijk: SPAs zijn geen hype en dus moeten SEO specialisten er gewoon mee leren dealen.

JavaScript was niet bedoeld voor het uitserveren van content

Voordat JavaScript überhaupt gemeengoed werd in de website development wereld waren webpagina’s statisch en gebouwd in HTML. JavaScript werd eigenlijk alleen gebruikt om extra interactie aan een pagina toe te voegen. Pop-ups, content die uitklapt als je erop klikt, een drop down menu die uitklapt door te ‘hoveren’ of een configurator feature. Dit soort interacties konden worden uitgevoerd zonder een call naar de server.

Lang was het recept voor een website daarom vrij simpel. Je gebruikte HTML voor het uitserveren van content, CSS voor de opmaak en JavaScript voor interactieve features.

Voor de crawlers die zoekmachine als Google gebruiken om een website te indexeren was het dus vooral van belang om HTML en CSS te kunnen lezen en downloaden. JavaScript was niet zo belangrijk omdat het simpelweg slechts voor een aantal features werd gebruikt die weinig vertelden over de inhoud van een pagina of website.

Vandaag de dag is dat niet meer zo. Om de beste experience op je website te bieden hang je deze vol met interactieve elementen (en dus JavaScript). Want je website bezoekers verwachten immers meer dan een statische pagina met tekst.

Met een SPA is het uitserveren van je content een interactieve feature. Heerlijk voor de customer experience. Moeilijk voor Googlebot. Waar in het verleden de HTML van een pagina werd geïndexeerd om te begrijpen wat het topic is, moet er nu eerst ‘Javascript’ worden uitgepakt voordat Google begrijpt waar je pagina over gaat.

SEO issues met SPA, waarom kiezen developers er dan voor?

Developers worden wel eens beschreven als vreemde vogels. Een rits aan zwarte schermen met kleine gekleurde letters waar ze dagenlang naar staren. Driftig tikkend op hun toetsenborden. En je customer experiences werken ineens. Maar tijdens de uitleg van wat ze precies hebben gedaan begrijpen jij en ik meestal niet de helft van wat ze zeggen.

developer bureau met meerdere schermen

Zou communicatie dan misschien de reden zijn dat developers – ondanks de problemen met SEO – toch steeds vaker voor een SPA kiezen? Nope. Moet je je voorstellen: je moet ‘iets’ maken en dat kan op twee manieren. Voor route 1 moet je 10 regels code schrijven. Voor route 2 moet je 10.000 regels code schrijven. En beide routes doen exact hetzelfde. Dan is de keuze simpel toch?

Developers zijn altijd op zoek naar de meest efficiënte en elegante oplossingen. Vaak gebruikmakend van de nieuwste mogelijkheden. En als je snel en elegant een website wilt bouwen is een Single Page Application met de vele beschikbare frameworks en libraries inderdaad een uitstekende keuze. Of in ieder geval tot het moment dat SEO een belangrijke rol voor de business gaat spelen. Zo vreemd zijn die development vogels dus eigenlijk niet.

Veelvoorkomende SEO problemen bij Single Page Applications

Om gevonden te worden in de zoekmachine van Google ‘crawlt’ of ‘spidert’ de Googlebot je webpagina’s. De HTML wordt gedownload, nieuwe pagina’s worden ontdekt door links in de HTML en dit wordt allemaal opgeslagen door Google om vervolgens met een algoritme te bepalen hoe goed je rankt op bepaalde zoektermen. Dit proces vormt de basis voor drie veelvoorkomende SEO problemen bij SPAs.

SEO probleem 1: extra werk voor Googlebot

Bij websites die JavaScript-based (zoals SPAs) zijn wordt het indexatie proces bemoeilijkt. Om de informatie op te slaan is er een extra stap benodigd van Googlebot. Alle JavaScript moet worden uitgevoerd of ‘gerenderd’ om je content en links te kunnen indexeren. Voor iedere pagina die Googlebot tegenkomt.

Je kunt je voorstellen dat dit proces veel minder efficient is dan de traditionele manier. En aangezien het makkelijk indexbaar zijn van je website een belangrijk element binnen SEO is heb je direct een achterstand op concurrenten die hun content in HTML uitserveren. Deze zijn immers simpeler en sneller te indexeren, waardoor Google – door interne links – sneller begrijpt welke pagina’s meer of minder belangrijk zijn.

Bij een website met slechts een paar pagina’s is dit probleem niet heel complex. Maar bij een website die uit honderden of duizenden pagina’s bestaat is dit een serieus probleem voor je SEO.

SEO probleem 2: waarde per pagina vaststellen is moeilijker

Om te kunnen bepalen welke pagina’s binnen je website belangrijker zijn en dus relatief gezien beter moeten ranken, gebruikt Google link equity. Iedere link – zowel intern als extern – geeft waarde aan de bestemmingspagina. Iedere link kun je zien als een soort stem. En om te winnen gelden de meeste stemmen.

Doordat het indexeren van een SPA intensief is voor Google, is het aannemelijk dat je interne linkstructuur niet wordt begrepen en je daarmee geen tot weinig controle hebt over welke pagina’s in de ogen van een zoekmachine het meest belangrijk zijn.

SEO probleem 3 – managen waar je Googlebot toelaat is tijdsintensief

Nu je weet dat Google links op je pagina volgt om nieuwe pagina’s te ontdekken, zul je ook begrijpen dat het cruciaal is om Google te informeren welke links niet moeten worden gevolgd voor het crawl proces. Denk hierbij aan bijvoorbeeld een link naar de inlogpagina, een dynamische zoekmachine, je algemene voorwaarden of een configuratiepagina.

Je wilt immers dat Google het ‘crawlbudget’ (de tijd die Googlebot per bezoek aan je website besteed om te crawlen) zo effectief mogelijk gebruikt. Voor pagina’s die belangrijk zijn voor je SEO dus. Bij een SPA is dit een stuk intensiever om te onderhouden doordat je content en pagina’s dynamisch zijn.

Gaat dit één keer per ongeluk mis, dan stuur je zonder pardon Googlebot het bos in. En net zoals de uitsmijter bij je favoriete club zal beamen: iemand eruit zetten die is binnengelaten is lastiger dan iemand weren aan de deur. Het is moeilijk om pagina’s die zijn geïndexeerd door Google te laten verdwijnen uit de zoekresultaten.

One-size-fits-all SEO oplossing voor je SPA

Die bestaat dus (nog) niet. Wanneer je wilt meedoen op SEO met je SPA zul je de problemen die je onderweg tegenkomt moeten tackelen met creatieve oplossingen. Dit proces kun je vergemakkelijken door te beginnen met de end-state te ontwerpen. Zo begrijpen je developers in ieder geval waar je uiteindelijk gezamenlijk heen wilt.

Omdat technische SEO voor een Single Page Application behoorlijk in de papieren kan lopen (vaak kost het fixen van SEO op een SPA meer tijd dan het bouwen van de SPA), is het verstandig een SEO specialist aan te haken. Eentje die eerder met het bijltje heeft gehakt.

Het komt wel goed

Ontmoedigd? Ontredderd? Nergens voor nodig. Ook moeilijke huwelijken zijn weer op de rit te krijgen. En kijkend naar de de populariteit van SPAs bij developers is het een kwestie van tijd voordat er echt goed schaalbare SEO oplossingen beschikbaar komen. Niemand weet alleen hoelang dat nog duurt. Maar uiteindelijk zal het huwelijk tussen je SPA en SEO gaan werken. Tot die tijd moeten we dealen met de status quo. Een mooie uitdaging toch?