3 belangrijke pijlers voor succes in mobile en voice search

Wil je klaar zijn voor het mobile- en voice search-first tijdperk? Dan zijn er 3 punten van belang in je SEO-strategie. Eén: optimaliseer je content voor de juiste type featured snippets. Twee: implementeer structured data met relevante how-to item types. En drie: zorg voor een feilloos snel kritieke-weergavepad. In dit artikel geven we praktische tips en voorbeelden hoe jij deze elementen aan kunt pakken.

We vergroeien meer en meer met onze smartphone. En het percentage mobiele internetgebruikers blijft alleen maar groeien. Grote kans dat jij dus dit artikel op je mobiel leest. Een mobile friendly website is daarom essentieel in je SEO-strategie. Laadsnelheid is hierin onbetwist een belangrijke factor: één seconde voelt al als een eeuwigheid.

Met de opkomst van voice search – stemgeactiveerde zoekopdrachten – wil je je content geoptimaliseerd hebben voor dergelijke zoekopdrachten. Het inspreken van zoekopdrachten verandert de manier waarop we zoeken naar een antwoord. ‘Gin-tonic maken’verandert bijvoorbeeld in ‘Hoe maak je een gin-tonic?’ of ‘Hoe maak ik een gin-tonic?’.

Dit betekent in de praktijk niet alleen je content herschrijven, maar ook Google een handje helpen in het begrijpen van de daadwerkelijke relatie tussen woorden en zinnen. Ofwel: semantiek in je content brengen.

Het inspreken van zoekopdrachten verandert de manier waarop we zoeken naar een antwoord.

Tijdens de BrightonSEO conference op 27 april waren voice search readiness en snelheid hot topics. Volgens Rob Bucci (Stat Search Analytics) vormen featured snippets, de uitgelichte zoekresultaten op positie 0, een belangrijke pijler voor voice search. Google’s machine learning-modellen ontwikkelen in rap tempo om de vragen van gebruikers zo nauwkeurig mogelijk te beantwoorden in de zoekresultatenpagina. Zo krijg jij als gebruiker ook echt antwoord op je vraag. Hoe ga je hier nu zelf mee aan de slag?

1. Optimaliseer content voor het type featured snippet

Volgens de statistieken van Rob Bucci laat Google steeds meer featured snippets voor ‘menselijke’ vragen zien. Dus zoals jij ze inspreekt. Een interessant gegeven, gezien featured snippets in het algemeen een afname in Google laat zien. Zijn boodschap: zoekintentie verdwijnt niet. Achter elk zoekwoord zitten namelijk één of meerdere intenties. En bij een intentie past ook weer een bepaald contentformat om de gebruiker zo goed mogelijk te bedienen.

Zoek ik naar ‘gin-tonic maken’, dan heeft voor de ene gebruiker een stapsgewijze uitleg in een video de voorkeur. Maar iemand anders wil misschien de ingrediënten weten om de cocktail te maken en heeft daarom liever een lijstje in blogvorm.

Al die intenties wil je opvangen door je content begrijpelijk te maken voor Google. Dit bereik je door je content te optimaliseren voor de intentie.

Wat betekent ‘optimaliseren’ dan in de praktijk?

Analyseer welk type snippets jouw keywords genereren en pas je contentformat zodanig aan. Wat wil de gebruiker zien bij het invoeren van een zoekopdracht? Een antwoord in een zin of alinea? Of een lijstje met een stappenplan? Zoek ik bijvoorbeeld naar ‘gin-tonic garnering’ dan wil ik weten welke garnering ik het beste kan gebruiken. Maar nog beter: ik wil weten welk type citrusvrucht past bij welke gin en tonic. Deze opsomming van informatie vangt de meerdere intenties accuraat op.

Je creëert dus een semantische laag door een tabel in HTML (en eventueel CSS) te construeren. Hieronder vind je de HTML-code van een dergelijke tabel:

Voor stemgestuurde zoekopdrachten moet je nog een stapje verder gaan, met name om de semantiek te verbeteren. Structured data vormt de geschikte bemiddeling tussen de gebruiker en Google’s algoritmes om te begrijpen wat de woorden in een zoekopdracht samen betekenen.

2. De juiste structured data

Met structured data verstrek je aan Google in een gestandaardiseerd formaat informatie over een pagina en classificeer je de pagina-inhoud. Alexis Sanders (Merkle inc.) deelde in Brighton haar toekomstperspectief over hoe de ‘HowTo’-types in structured data mogelijk helpen om voice search te ondersteunen. Volgens Rob Bucci genereert 68 procent van alle how-to-woorden een ‘list’-snippet. Dat biedt een ‘HowTo’-type markup een sterke fundering om Google te helpen de vragen van gebruikers zo nauwkeurig mogelijk te beantwoorden.

Wil je weten hoe je een gin-tonic moet maken, dan zoek je via voice waarschijnlijk ‘Hoe maak ik een gin-tonic?’.

Binnen het type recipe kun je met properties als ‘performTime’ en ‘recipeIngredient’ aangeven wat je precies nodig hebt en hoelang het maken van de cocktail duurt. Met de ‘HowTo’-properties als ‘HowToTool’, ‘HowToStep’ en ‘HowToSupply’ kun je Google duidelijk maken welke tools en benodigdheden nodig zijn en welke stappen je achtereenvolgens moet uitvoeren.

Google search ondersteunt structured data in meerdere indelingen, waaronder JSON-LD. Dit is een JavaScript-notatie, ingebed in een script-tag in de head-sectie van je HTML. Een groot voordeel van JSON-LD ten opzichte van andere indelingen is dat je het script in één keer kunt implementeren. Een JSON-LD-script voor ‘Hoe maak je/ik een gin-tonic’ ziet er dan als volgt uit.

Eerst de basis recipe properties:

Vervolgens definieer je de ‘HowTo’-type in het JSON-LD-script.

Tip: met de ‘@graph’ property kun je meerdere ‘types’ toevoegen in je structured data-script.

Je kunt uiteraard meerdere properties toevoegen of de huidige properties uitbreiden, zoals meer ‘HowToStep’-items toevoegen bij de verschillende stappen.

Meer dan alleen structured data

Een derde belangrijke pijler naast structured data en optimalisaties is laadsnelheid. Content en mark ups die geoptimaliseerd zijn voor voice search verliezen hun toegevoegde waarde als de pagina niet snel genoeg laadt. Laadtijd beïnvloedt de kans of een gebruiker op je pagina blijft (of niet) aanzienlijk. Maar liefst 53 procent van alle mobiele bezoekers verlaat de pagina als het langer dan 3 seconden duurt om te laden (1).

Om de snelheid van een webpagina te verbeteren, kun je onder andere caching-optimalisaties doorvoeren of afbeeldingen verkleinen. Bastian Grimm (Peak Ace AG) betoogt hoe veranderingen in het kritieke weergavepad de snelheid kunnen boosten. Daarmee wordt de belangrijkste, above the fold-content – de content waarvoor de bezoeker naar je website komt – geladen.

3. Het kritieke weergavepad

Begin 2017 analyseerde Google 900.000 mobiele landingspagina’s van Googlepartners uit verschillende landen en sectoren. De resultaten waren vrij schokkend: bij 70 procent van de pagina’s duurde het bijna 7 seconden voordat de visuele above the fold-content op het scherm werd getoond. Bij deze pagina’s duurde het maar liefst ruim 10 seconden om alle visuele content (ook below the fold) te laden. Een langere laadtijd is slecht voor zowel de gebruikerservaring als voor de organische rankings van je website.

De boodschap is duidelijk: zorg ervoor dat de belangrijkste content als eerst voorgeschoteld wordt, terwijl de overige content nog laadt.

Hoe zet je het kritieke weergavepad op?

Het kritieke weergavepad zet je samen met een developer op! Deze stappen helpen je op weg.

Welke onderdelen zijn kritiek?

Analyseer welke onderdelen van de pagina ‘kritiek’ zijn voor het laden van de above the fold-weergave – de versie die de gebruiker direct ziet als hij op je pagina landt. Welke content wil je in deze weergave tonen? En welke HTML, CSS en Javascript-elementen zijn hiervoor essentieel?

Let op: de above the fold-weergave verschilt per schermformaat. Niet alleen moet je rekening houden met desktop en mobiel, maar ook binnen mobiel bestaat een verscheidenheid aan schermformaten. Analyseer daarom eerst op welke apparaten jouw website het meest bezocht wordt. Bepaal aan de hand daarvan welke onderdelen above the fold zijn.

Wat draagt niet bij?

Verwijder of verplaats de Javascript en CSS-elementen die niet bijdragen aan de above the fold-weergave van de pagina.

Optimaliseer en verklein

Optimaliseer en verklein de Javascript- en CSS-elementen die wel van belang zijn (later meer hierover).

Optimaliseren van het kritieke weergavepad

Als je het kritieke weergavepad hebt vormgegeven, kun je deze samen met de developer optimaliseren. Zorg er in eerste instantie voor dat je pagina zo min mogelijk critical resources bevat. Een critical resource is een bron die het renderen van de pagina blokkeert. Meer critical resources vereisen simpelweg meer van je browser, waardoor het langer duurt voordat je browser de pagina kan renderen. Een voorbeeld is een Javascript-file.

Om te achterhalen welke request chains kritiek zijn, gebruik je bijvoorbeeld Lighthouse van Google. Deze Chrome-extensie vertelt je ook hoe lang het downloaden van elke hulpbron duurt en hoeveel bytes hiervoor nodig zijn.

Het diagram dat de extensie samenstelt, ziet er zo uit:

Vervolgens kun je het aantal kritieke bytes van de resources zo klein mogelijk maken. Dit doe je door elke resource te comprimeren (met bijvoorbeeld GZIP en minify/uglify).

Daarna maak je het kritieke weergavepad zo kort mogelijk door de volgorde van de kritieke resources aan te passen. Sommige resources kunnen pas worden geladen nadat anderen geladen zijn. Om het pad zo kort mogelijk te houden, moeten alle kritieke elementen dus zo vroeg mogelijk gerenderd worden. Naast in serie laden (na elkaar), kunnen resources ook asynchroon worden ingeladen.

Een paar tips voor optimaliseren

1. Vermijd zware scripts

Selecteer op de meest ‘lean en mean’-oplossing in samenwerking met je developer.

2. Plaats scripts – waar mogelijk – onderaan in de HTML

Het script voor een chatfunctie op je pagina hoeft niet direct beschikbaar te zijn, maar het script voor bijvoorbeeld Visual Website Optimizer (A/B-testen) wel.

3. Check de laadtijd van je kritieke weergavepad op verschillende momenten

Het aantal gebruikers op je website verschilt per moment. Als je deze meetmomenten vervolgens naast elkaar zet, heb je een volledig beeld van de snelheid van je pagina. Zorg dat deze snelheid in ieder geval onder de 2 of 3 seconden is.

Critical en non-critical CSS

Ook CSS kan geoptimaliseerd worden. Webbrowsers gebruiken CSS om een pagina te renderen. Een CSS-request zorgt voor een significante toename van de laadtijd van een webpagina als alle CSS in de <head> van een pagina staat.

Om crawlbudget optimaal te alloceren en je belangrijkste content binnen je above the fold-weergave dus zo snel mogelijk te laden, zet je volgens Bastian Grimm (Peak Ace AG) alleen de minimale hoeveelheid CSS voor de belangrijkste content erin. Dit is je critical CSS. Splits je critical CSS (above the fold) en non-critical CSS (below the fold). De stylesheets voor je belangrijkste content in je kritieke weergavepad plaats je dus in de <head> van je HTML.

CSS voor de overige content laad je asynchroon in.

Asynchroon inladen van resources

Bij asynchroon inladen worden de resources parallel geladen in plaats van na elkaar. Dit scheelt laadtijd. Je kunt het op verschillende manieren opzetten. Met de property font-display: swap; geef je aan dat de browser direct het best matchende beschikbare font laat zien, en ‘swapt’ indien een beter passend font geladen is. Als gebruiker zie je dus in een flits het font veranderen. Een andere optie is font-display: fallback;. Na een korte font block period valt de browser terug op een alternatief. Als het juiste font niet binnen ongeveer 3 seconden geladen is, blijft het alternatief staan.

Idealiter heb je natuurlijk geen ‘swap’ van fonts en wil je dat het best passende alternatief gewoon blijft staan. Dat kan! Dit is wat font-display: optional; doet. Font rendering wordt nog steeds ongeveer 100 milliseconden geblokkeerd, wat het juiste font de kans geeft om geladen te worden. Hierna wordt direct het alternatief blijvend geladen.

Voor elke genoemde variant valt wat te zeggen. Kijk samen met je developer welke manier van inladen het beste bij jouw website past.

Takeaways

• Onderzoek welke semantische lagen je kunt aanbrengen, zodat je content geoptimaliseerd is voor het juiste type featured snippets
• Implementeer structured data markup met relevante types voor how-to-items
• Zorg voor een feilloos snel kritieke weergavepad door onder andere het asynchroon inladen van resources doorvoeren van tweaks in critical en non-critical CSS. 

Overige bron: 

1 Google Data, Global, n=3,700 aggregated, anonymized Google Analytics data from a sample of mWeb sites opted into sharing benchmark data, Mar. 2016.