De impact van een headless CMS-aanpak op SEO
Bij een headless aanpak worden de frontend (wat je ziet) en backend (waar de inhoud beheerd wordt) van een website van elkaar losgekoppeld. Dat kan heel wat voordelen hebben, maar er zijn ook een aantal aandachtspunten. In deze blogpost gaan we verder in op wat de impact is van het gebruik van deze technologie op vlak van SEO en dus je plaats in de zoekresultaten.
In onze blogpost over het hoe en waarom van een headless CMS, legden we al uit hoe zo'n headless aanpak precies in elkaar zit. Even kort herhalen:
Wat is een headless CMS?
Een headless CMS of contentmanagementsysteem is een backend-systeem dat losgekoppeld is van de frontend (de app of website) en ervoor zorgt dat content toegankelijk is via webservices/API’s voor verschillende bronnen, zoals de website, maar bijvoorbeeld ook voor apps.
Flapperen je oren bij het lezen van deze inleiding? Lees dan misschien eerst even het eerste deel van deze blog, een introductie tot een headless CMS-architectuur.
SEO en single-page applications
Een headless CMS is vaak gekoppeld aan een front-end via een SPA (single-page application). Een single-page application is een webapplicatie of website die een vlotte gebruikservaring biedt, en geen pagina’s herlaadt tijdens het gebruik.
Het gebruik van single-page applications (in plaats van de klassieke manier waarop webpagina's gerenderd worden) kan in een aantal gevallen heel wat voordelen hebben, maar er zijn ook aandachtspunten. Zeker wanneer single-page applications worden ingezet op publieke websites die ook hoog moeten scoren in zoekmachines.
De basics: hoe webpagina’s gerenderd worden
Server-side rendering bij klassieke webtechnologieën
Bij een traditionele website en met gebruik van een traditionele webtechnologie (PHP, .NET …), doet de browser van de gebruiker een aanvraag naar de webserver op het internet: 'geef mij pagina X terug'. Dat noemen we server-side rendering en gaat als volgt:
-
De browser stuurt een request naar een URL.
-
De server verwerkt de broncode van de opgevraagde pagina (in PHP, .NET …) en genereert een volledige HTML-code.
-
De browser ontvangt de volledige HTML-code, interpreteert bijbehorende CSS (opmaak) en JavaScript, en toont de webpagina op het scherm.
-
Wanneer de gebruiker doorklikt naar een volgende pagina, begint het hele proces opnieuw en moet alle info opnieuw verwerkt en opgebouwd te worden.
Zoekmachines die zo'n traditionele website doorzoeken of crawlen, vinden normaal gezien alle inhoud makkelijk terug en kunnen de hele site indexeren.
JavaScript-gebaseerde applicaties: single-page applications
Bij een client-side single-page application (SPA) verschuift het deel van de server-side rendering naar de browser van de gebruiker, wat we de client-side noemen.
Concreet betekent dit dat de browser, of de Googlebot, een minimale HTML-pagina zonder teksten, afbeeldingen … ontvangt. Na het ontvangen van de basis-HTML, ontvangt de gebruiker ook de JavaScript-bestanden, waarmee de rest van de pagina wordt opgebouwd.
Die JavaScript zal dan aan de browser vertellen waar hij de content kan vinden: 'haal bij API X de info voor dit blokje op', 'haal bij webservice Y de afbeeldingen voor deze zone op' enzovoort. Dat gaat ongeveer zo:
-
De browser stuurt een request naar een URL.
-
De browser ontvangt van de server een index.html als antwoord.
-
De browser stuurt vervolgens verschillende requests naar de server om verschillende stukken inhoud of scripts te downloaden waar naar verwezen wordt in de index.html.
-
De browser wacht tot alle scripts zijn binnengekomen van de server.
-
De browser stelt de pagina volledig samen van zodra alle fragmenten zijn binnengekomen.
-
Zodra de gebruiker op een link klikt, zal enkel de relevante inhoud op de achtergrond ingeladen worden. De pagina moet dus niet volledig opnieuw opgebouwd worden, wat niet enkel voor tijdswinst en efficiëntie zorgt, maar de gebruiker ook een betere ervaring geeft.
Het SEO-probleem bij single-page applications
Daar waar bij een klassiek model alle inhoud van de eerste keer door de server naar de browser (en zoekrobot) worden gestuurd, wordt in dit model de inhoud in kleine fragmentjes opgehaald en pas na het uitvoeren van de JavaScript-code die hiervoor de opdracht geeft getoond.
Een client-side SPA (single-page application) is een JavaScript website/app waar de code client-side op het apparaat draait. De applicatie moet over browser-rendermogelijkheden beschikken, om de content te kunnen interpreteren en ‘zien’.
In het verleden was dat vaak een probleem omdat zoekmachines zoals Google deze code niet, of slechts beperkt, konden interpreteren. Daardoor leken belangrijke delen van de inhoud te ontbreken, met alle gevolgen van dien voor de positie van je website in de zoekresultaten.
Gelukkig zijn daar nu een aantal oplossingen voor.
Bij een single-page application ontvangt de browser (en zoekrobot) slechts een basis-set HTML waarna door het uitvoeren van de JavaScript, alle fragmenten inhoud worden ingelezen via webservices en API’s.
Waarom SPA's slechter scoorden in Google
Er zijn dus een aantal redenen waarom single-page applications minder goed scoorden in de zoekresultaten:
-
De eerste inhoud die de gebruiker (en dus ook Googlebot) ontvangt is leeg. Een zoekmachine die het JavaScript niet kan interpreteren zal denken dat de pagina leeg is en hem dus niet weergeven in de zoekresultaten.
-
Het feit dat de browser wacht met de webpagina samen te stellen totdat alle inhoud is ontvangen betekent dat de gebruiker het gevoel kan krijgen dat de website trager is, omdat de pagina langer wit blijft (hoewel de totale rendertijd vaak wel ongeveer dezelfde is als bij een klassieke methode).
-
Een van de belangrijke factoren voor zoekranking is naast inhoud ook snelheid. Google voert dan ook al een tijdje campagne naar webbouwers om er voor te zorgen dat websites supersnel zijn. Deze 'first time to content' kan dus ook negatieve invloed hebben op de SEO-ranking omdat ook de Googlebot langer moet wachten totdat de eerste tekst 'binnenkomt'.
Wat Google eraan doet
Het goede nieuws is dat sinds maart 2019 Google in de Googlebot-crawler (zoekrobot) de laatste Chromium-versie gebruikt. Dat is de engine waarmee de Google Chrome-browser op je computer de websites 'rendert', waardoor JavaScript-gebaseerde applicaties nu ook beter 'begrepen' (en dus geïndexeerd) kunnen worden.
Bovenstaande problemen worden dus door de uitrol van deze update opgelost. Toch spelen we toch liever op veilig en willen we onze JavaScript-gebaseerde single-page application websites optimaal voorbereiden op de komst van Google.
Bovendien moeten we er rekening mee houden dat andere zoekmachines zoals Bing, DuckDuckGo en anderen (nog) geen of in beperkte mate JavaScript-ondersteuning hebben tijdens het indexeren.
Technisch scoringsmodel van Google:
Nog even snel een theoretische opfrissing van de drie algemene criteria voor de indexering die Google hanteert (vanuit technisch standpunt):
-
Crawlability; het moet mogelijk zijn om daar een website te crawlen met een semantische structuur.
-
Renderability; er mogen geen problemen optreden tijdens het renderen van de website.
-
Crawl budget; de tijd die Google nodig heeft om door je website te crawlen en hem te renderen.
Single-page applications optimaliseren voor Google
Wanneer de browser/Googlebot een website ontvangt waarin de teksten niet in de HTML verwerkt zitten maar asynchroon worden ingeladen, kan dat dus voor problemen met de crawling en/of rendering zorgen. De volgende oplossingen worden als basisprincipes beschouwd om dergelijke webapplicaties toch goed te doen scoren in de zoekmachines:
1
SSR (server-side rendering) to the rescue
Het grootste probleem bij JavaScript-websites is dat er geen HTML/content beschikbaar is tijdens het ophalen van de website. Er kan dus geen content worden geïndexeerd. De oplossing hiervoor is SSR of server-side rendering.
We grijpen terug naar de basisprincipes van klassieke webtechnologie, waar (bijvoorbeeld) PHP-code op de server wordt uitgevoerd, om dan vervolgens HTML naar de browser te sturen. Hetzelfde doen we nu voor de JavaScript-gebaseerde single-page application.
Bij de eerste request van de browser aan de server, zal de server zelf deze JavaScript interpreteren, alle verschillende fragmentjes ophalen en verwerken, om vervolgens een kant-en-klaar HTML-bestand naar de browser te sturen. Vervolgens zal de browser in de achtergrond, zoals een SPA hoort te doen, alle scripts in de achtergrond verder inladen om zich verder te gedragen als een single-page application.
We spreken hier dus over een 'best of both worlds'. De gebruiker (en Googlebot) krijgen een kant-en-klare HTML van de server, maar nadien gedraagt de website zich toch als een single-page application. Het proces is dus dit:
-
De browser stuurt een request naar een URL.
-
De server verwerkt de broncode van de opgevraagde pagina (JavaScript) en genereert een volledige HTML-code.
-
De browser ontvangt de volledige HTML-code, interpreteert bijbehorende CSS en JavaScript, en toont de webpagina op het scherm.
-
Intussen stuurt de browser verschillende requests naar de server om verschillende scripts te downloaden die nodig zijn om de webpagina te doen gedragen als een single-page application.
-
De browser past de pagina aan, vaak onzichtbaar voor de gebruiker, op basis van de ontvangen en uitgevoerde scripts.
-
Verdere acties van de gebruikers worden verwerkt als single-page application-gedrag. Met andere woorden: enkel de relevante stukken worden ingeladen voor een snelle en efficiënte werking.
Server-side rendering heeft tegenwoordig zijn ingang gevonden in veel systemen zoals Nuxt.js (Vue.js), Next.js (React), Angular Universal (Angular).
2
Pre-rendering als alternatief
De verplichte architectuur voor server-side rendering (Node.js-server) kan voor sommige kleine applicaties overkill zijn, en met pre-rendering los je dit probleem op zonder een zwaardere architectuur nodig te hebben. Er zijn natuurlijk wel paar aandachtspunten wat server-side rendering betreft, maar daar vertel ik verderop meer over.
Pre-rendering kan je zien als een combinatie van client-side en server-side. Je maakt nog steeds je website als single-page application. Echter, tijdens het samenvoegen van code voor de browser zullen er door de frontend-processen statische HTML-pagina’s gecreëerd worden.
Wanneer een browser (of Googlebot) de pagina komt opvragen, zal de server onmiddellijk de statische HTML terugsturen die op voorhand is klaargemaakt. De gebruiker krijgt dus altijd de (statische HTML-) pagina te zien.
Ondertussen zal, net zoals bij server-side rendering, de browser de overige scripts en inhoud inladen en de pagina constant (vaak subtiel of zelfs onzichtbaar) updaten totdat de pagina helemaal actueel is en werkt als volwaardige single-page application. Samengevat loopt het proces dus als volgt:
-
De browser stuurt een request naar een URL.
-
De server stuurt onmiddellijk de volledige HTML-code terug die hij vooraf heeft gegenereerd.
-
De browser ontvangt de volledige HTML-code, interpreteert bijbehorende CSS en JavaScript, en toont de webpagina op het scherm.
-
Intussen stuurt de browser verschillende requests naar de server om verschillende scripts te downloaden die nodig zijn om de webpagina zich te doen gedragen als een single-page application.
-
De browser past de pagina aan, vaak onzichtbaar voor de gebruiker, op basis van de ontvangen en uitgevoerde scripts.
-
Verdere acties van de gebruikers worden verwerkt als single-page application-gedrag (enkel de relevante stukken worden met andere woorden ingeladen voor een snelle en efficiënte werking).
Het voordeel hieraan is dat de gebruiker erg snel de eerste inhoud op het scherm te zien krijgt. Ook scoor je hiermee gegarandeerd goede punten bij Google: de inhoud van de webpagina zit ingebakken in het eerste antwoord van de server, en de time-to-first-byte is erg kort. Zoals eerder vermeld is de serverarchitectuur ook veel simpeler dan bij een SSR-applicatie.
Het nadeel hier is dat je voor dynamische content alle detailpagina’s moet gaan genereren, en bij elke verandering moet het ‘bouwproces’ van de applicatie opnieuw gebeuren. Wanneer je met veel dynamische content werkt, kan dat voor bottlenecks zorgen en is het aangeraden om met server-side rendering te werken.
Nuxt.js biedt naast de SSR-modus ook een pre-rendered modus aan.
Is het nog aantrekkelijk om client-side te bouwen?
Het antwoord is simpelweg ja. Google heeft de zoekrobot geüpdatet naar de laatste versie van Chromium, wat betekent dat ook de meest recente JavaScript ondersteund wordt. Hoewel het meer moeite kost om een client-side website indexeerbaar te maken, zijn er altijd goede redenen te vinden waarom een CSR-app beter past dan een SSR-app voor een specifieke situatie:
-
Technologische architectuur. Als het bijvoorbeeld niet mogelijk is om voor een SSR-architectuur te gaan, dan zou pre-rendering een oplossing kunnen bieden.
-
Afgeschermde applicaties. Vrijwel alle (kleinere) applicaties achter een inlogscherm, niet toegankelijk voor zoekmachines. Qua performantie kan veel bereikt worden met pre-rendering en code-splitting (lees: alleen noodzakelijke code per url/component laden).
Er zijn nog genoeg andere punten te vinden in het voordeel van CSR-applicaties, en dat is per situatie anders. Neem contact op met onze experts om je te laten informeren.
Waar moet je rekening mee houden?
-
Client-side plugins; er kunnen bepaalde plugins zijn die enkel op client-side werken. Zorg ervoor dat dit niet server side ingeladen wordt.
-
Lege links; sommige frameworks en/of developers gebruiken een lege link, om daar vervolgens een click-event op toe te passen. Dat werkt niet voor de Googlebot, enkel een valide href-link.
-
Blokkeer geen JS met robots.txt; JavaScript-bestanden die voor content zorgen, mogen niet geblokkeerd worden voor zoekmachines.
-
Performantie; Google let veel op performantie in het crawl-budget (lees: je website moet goed werken), en indexeert en sorteert hierop.
-
Hash in URL; website.com/news#detail werkt niet, omdat een Googlebot de hash anders gaat interpreteren dan JavaScript. Hash-tekens mag je enkel voor anchors gebruiken.
Conclusie: server-side rendering als waardevol alternatief
We kunnen dus stellen dat er met server-side rendering nauwelijks verschil is op vlak van SEO als we vergelijken met traditionele CMS'en. Het resultaat voor de zoekmachines zal hetzelfde zijn, namelijk leesbare HTML-pagina’s.
Maak een weloverwogen keuze voor je online architectuur en of een headless CMS een meerwaarde is voor de organisatie. Besteed in dat geval voldoende aandacht en resources aan de ingrepen die nodig zijn om de applicatie klaar te stomen voor SEO-indexatie.
Maak een afspraak met onze experts
Meer weten over SEO binnen een headless omgeving zoals JavaScript-gebaseerde applicaties in React of Vue? Onze specialisten overladen je graag met hun kennis en ervaring in deze materie om Google & friends tevreden te houden!
Neem contact op