Hoe u uw Core Web Vitals in AmICited controleert

Snelle, stabiele pagina’s zijn ook belangrijk voor AI-zichtbaarheid — antwoordmachines geven de voorkeur aan snel ladende bronnen. Voordat u zich verdiept in de audit van AmICited, is het nuttig om te begrijpen wat Core Web Vitals precies meten en waarom een probleem met paginasnelheid ongemerkt kan uitgroeien tot een probleem met AI-citaties.

Wat zijn Core Web Vitals?

Core Web Vitals zijn een set gestandaardiseerde metrieken die Google heeft ontwikkeld om de praktijkervaring van een pagina — de page experience — meetbaar te maken: hoe snel de hoofdinhoud van een pagina verschijnt, hoe snel deze reageert op input, en hoe visueel stabiel de pagina blijft tijdens het laden. Ze zijn bedacht om vage noties als “de site voelt traag aan” te vervangen door cijfers die u kunt volgen, benchmarken en waarop u engineeringteams kunt afrekenen. Google heeft ze jaren geleden al opgenomen in de rankingsignalen voor zoekresultaten, en dezelfde onderliggende data — verzameld bij echte Chrome-gebruikers via het Chrome UX Report (CrUX) — bepaalt in toenemende mate welke bronnen antwoordmachines bereid zijn op te halen, te renderen en te citeren.

De drie kernmetrieken zijn Largest Contentful Paint (LCP), Interaction to Next Paint (INP) en Cumulative Layout Shift (CLS), elk gekoppeld aan een geslaagd/mislukt-drempelwaarde die Google publiceert en periodiek bijwerkt. Twee aanvullende metrieken, First Contentful Paint (FCP) en Time to First Byte (TTFB), maken het volledige beeld van de paginasnelheid compleet door te isoleren hoe snel de server reageert en hoe snel er iets wordt weergegeven, zelfs voordat de hoofdinhoud klaar is. Omdat CrUX is opgebouwd uit geanonimiseerde velddata — daadwerkelijke bezoeken door daadwerkelijke Chrome-gebruikers — weerspiegelen de cijfers reële omstandigheden (apparaatmix, netwerkkwaliteit, geografie) in plaats van een eenmalige labtest op een snelle kantoorverbinding.

Waarom is dit specifiek relevant voor generative engine optimization ? AI-crawlers en de retrievalsystemen achter AI Overviews, ChatGPT search en Perplexity moeten uw pagina ophalen en verwerken voordat ze deze kunnen citeren. Een pagina die een time-out geeft, traag rendert, of tijdens het laden van inhoud verschuift, is duurder om op grote schaal te crawlen en minder betrouwbaar om er schone inhoud uit te extraheren. Vooral een trage TTFB kan ervoor zorgen dat een crawler een fetch afbreekt voordat uw hoofdinhoud ooit arriveert. Niets hiervan is de doorslaggevende factor voor of u geciteerd wordt — relevantie, autoriteit en structuur van de content wegen veel zwaarder — maar een chronisch trage of instabiele homepage is wrijving die antwoordmachines geen enkele reden hebben te tolereren wanneer een snellere concurrent dezelfde informatie aanbiedt.

Dit is ook een geval waarin technische SEO en answer engine optimization nagenoeg volledig overlappen: dezelfde technische verbeteringen die uw Google-rankings verhogen — beeldformaten, serverresponstijd, lay-outstabiliteit — zijn ook de verbeteringen die uw pagina’s toegankelijk en citeerbaar houden voor AI-systemen. Die overlap is precies de reden waarom AmICited Core Web Vitals toont binnen een bredere AI-zichtbaarheids audit in plaats van als losstaande SEO-tool: het is één van de factoren die bepalen of AI-engines uw site betrouwbaar en gemakkelijk te verwerken vinden.

Waar vindt u het

Open Audit → Web Vitals in de linkernavigatie. De pagina legt het uit: “Core Web Vitals voor de homepage van uw domein… paginasnelheid is een Google-rankingfactor en AI-antwoordmachines geven de voorkeur aan snel ladende pagina’s.” AmICited haalt deze data automatisch op voor uw gevolgde domein en voor elke concurrent die u monitort, zodat u geen aparte tool hoeft te gebruiken of URL’s handmatig hoeft te plakken — het is dezelfde concurrentieset die u elders in het platform al gebruikt om share of voice en citatierang te volgen.

Omdat CrUX een minimumvolume aan echt Chrome-verkeer vereist voordat het stabiele cijfers voor een URL publiceert, tonen domeinen met weinig verkeer — waaronder veel B2B- en niche-sites — soms een tijdlang lege waarden. Dat is verwacht gedrag, geen bug: het betekent dat Google nog niet genoeg velddata heeft verzameld om met zekerheid te rapporteren, en de waarden verschijnen zodra er voldoende verkeer (of tijd) is opgebouwd.

Wat de metrieken betekenen

De concurrentievergelijkingstabel geeft elk domein weer met:

• Score — een algehele geslaagd/mislukt-samenvatting van Core Web Vitals, waarmee u in één oogopslag ziet of een domein over de hele linie aan Google’s drempelwaarden voldoet.
• LCP (Largest Contentful Paint) — hoe snel de hoofdinhoud laadt, meestal de grootste afbeelding of tekstblok in het beeldscherm. Dit is de metriek die het meest direct samenhangt met de perceptie van een bezoeker — of een crawler — of “deze pagina klaar is”.
• INP (Interaction to Next Paint) — hoe responsief de pagina aanvoelt wanneer een gebruiker er daadwerkelijk mee interacteert (klikken, tikken, typen). Deze metriek verving de oudere First Input Delay omdat hij de responsiviteit meet over het hele paginabezoek, niet alleen bij de eerste interactie.
• CLS (Cumulative Layout Shift) — hoe visueel stabiel de pagina is tijdens het laden. Een hoge CLS betekent dat elementen verspringen terwijl afbeeldingen, advertenties of lettertypen laden, wat storend is voor bezoekers en het voor geautomatiseerde systemen moeilijker kan maken om inhoud consistent te verwerken.
• FCP (First Contentful Paint) — hoe snel er iets voor het eerst op het scherm verschijnt, zelfs voordat de hoofdinhoud klaar is. Het is een vroeg signaal dat de pagina überhaupt laadt, in plaats van dat de gebruiker naar een leeg scherm staart.
• TTFB (Time to First Byte) — snelheid van de serverrespons: de tijd tussen het opvragen van de pagina en het ontvangen van de eerste byte terug. Dit is bijna volledig een backend-/infrastructuurmetriek en vaak de eenvoudigste om op te lossen met hosting-, caching- of CDN-aanpassingen.

Uw eigen domein wordt gemarkeerd als U, met de homepages van uw gevolgde concurrenten eronder, zodat elke metriek meteen wordt vergeleken in plaats van los te worden bekeken.

Hoe gebruikt u het

1. Vergelijk met concurrenten. Als de pagina’s van concurrenten sneller zijn, is dat een extra voordeel dat zij hebben in zowel zoekresultaten als AI-antwoorden — en het is een verschil dat relatief goedkoop te dichten is vergeleken met werk aan content of autoriteit.
2. Los de rode waarden op. Een falende LCP of CLS wijst op specifiek technisch werk: overdreven grote hero-afbeeldingen, ontbrekende width/height-attributen, renderblokkerende scripts of niet-geoptimaliseerde weblettertypen zijn de gebruikelijke boosdoeners.
3. Geef prioriteit aan TTFB als deze traag is. Omdat deze metriek stroomopwaarts van alle andere metrieken zit, trekt een trage TTFB ook de LCP omlaag, en het is vaak de metriek die het snelst te verbeteren is — vaak via caching, een CDN of een hosting-upgrade in plaats van het herschrijven van content.
4. Controleer opnieuw na wijzigingen. Naarmate veldgegevens worden bijgewerkt, komt u terug om te bevestigen dat verbeteringen zijn doorgevoerd. CrUX-data is een voortschrijdend venster van 28 dagen, dus wijzigingen hebben tijd nodig om zichtbaar te worden — verwacht niet dat de cijfers de dag na een deploy al veranderen.
5. Behandel TTFB als een vroegtijdig waarschuwingssignaal. Een server die regelmatig meer dan een seconde nodig heeft om de eerste byte terug te sturen, is een sterke kandidaat voor crawl- en renderingproblemen die veel verder reiken dan deze ene audit — het is de moeite waard om te lezen waarom crawler-engineers een snelle TTFB steeds vaker als drempelwaarde voor betrouwbaar AI-crawlersucces beschouwen in plaats van als bijkomstig voordeel.

Geen van deze vier metrieken opereert los van de rest van uw technische fundament. Een homepage die goed scoort op Core Web Vitals maar AI-crawlers blokkeert in robots.txt, of een grotendeels lege pagina serveert aan clients zonder JavaScript, wordt nog steeds niet geciteerd — snelheid helpt pas zodra een crawler daadwerkelijk wordt toegelaten en kan verwerken wat er staat. Daarom is het de moeite waard om deze audit te behandelen als één controlepunt binnen een bredere routine in plaats van als eenmalige fix: voer hem regelmatig uit naast uw andere AmICited-audits, net zoals u periodiek een bredere technische auditchecklist zou doornemen die crawlbaarheid, gestructureerde data en extraheerbaarheid van content omvat.

Web Vitals winnen op zichzelf geen citaties, maar langzame, instabiele pagina’s kunnen u tegenhouden — deze audit vertelt u waar u staat ten opzichte van de sites waaruit AI-engines kiezen. Wilt u de diepere onderbouwing achter deze aanbeveling, lees dan meer over of paginasnelheid daadwerkelijk invloed heeft op AI-zoekzichtbaarheid , en combineer deze controle met een bredere AI-toegankelijkheidsaudit van uw site om ook de crawlbaarheidskant van het verhaal te dekken. Van daaruit is de logische volgende stap om Web Vitals op te nemen in uw reguliere monitoringritme, naast de AI-ranktracker en citatietracking van AmICited, zodat een prestatieregressie op hetzelfde moment wordt opgemerkt als een daling in vermeldingen — in plaats van pas weken later apart ontdekt te worden, wanneer het u al zichtbaarheid heeft gekost.