Lighthouse SEO-score 100 — wat staat erin?

De 14 checks van Lighthouse SEO

1. Document has a <title> element

Elke pagina moet een title-tag hebben. Niet leeg. Niet "Untitled Document" (default in oude CMS-templates).

2. Document has a meta description

<meta name="description"> met 50-160 karakters. Google gebruikt 'm niet altijd in zoekresultaten, maar bij relevante zoekopdrachten wel — en het is je verkooppraatje in de search snippet.

3. Page has successful HTTP status code

200 OK. Lighthouse faalt op 4xx of 5xx response codes.

4. Links have descriptive text

Geen "klik hier" of "lees meer". Beschrijvende anchor-tekst. Zie internal linking uitleg voor uitgebreide context.

5. Links are crawlable

Echte <a href="...">-elementen, niet JavaScript-gebaseerde "onclick"-handlers. Google volgt JS-events soms wel, soms niet — dus altijd echte HTML-links voor belangrijke navigatie.

6. Page isn't blocked from indexing

Geen <meta name="robots" content="noindex">. Een verrassend vaak voorkomende fout — staging-instellingen die per ongeluk live zijn gegaan.

7. robots.txt is valid

De /robots.txt moet syntactisch correct zijn en geen accidentele Disallow: / bevatten.

8. Image elements have [alt] attributes

Elke <img> heeft een alt-attribuut. Voor decoratieve afbeeldingen leeg (alt=""), voor inhoudelijke afbeeldingen beschrijvend.

9. Document has a valid hreflang

Alleen relevant als je meerdere talen ondersteunt. Voor NL-only sites: irrelevant. Zie hreflang voor NL/BE-MKB.

10. Document has a valid rel=canonical

<link rel="canonical"> voorkomt duplicate-content-problemen. Wijst Google naar de "officiële" versie van een URL.

11. Document uses legible font sizes

Tekst >12px voor 60%+ van de body. Anders is je site mobiel onleesbaar.

12. Tap targets are sized appropriately

Klikbare elementen ≥48×48px op mobiel, met voldoende ruimte ertussen. Sites met kleine knoppen falen op deze check.

13. Document has a meta viewport

<meta name="viewport" content="width=device-width, initial-scale=1"> moet in de header staan. Anders is je site niet mobile-responsive.

14. Structured data is valid

Als je schema.org gebruikt, moet het syntactisch correct zijn. Lighthouse waarschuwt bij parse-errors. Zie schema.org voor MKB.

Wat Lighthouse SEO NIET test

Belangrijk om te beseffen — een 100-score zegt niets over:

• Content-kwaliteit. Lighthouse leest geen woorden. Een lege pagina met perfecte techniek krijgt 100, maar rankt nergens op.
• Zoekintentie-match. Lighthouse weet niet of jouw content matcht met wat zoekers zoeken.
• Backlinks. Geen externe authoriteits-meting.
• Lokale signalen. Google Business Profile, citations — onzichtbaar voor Lighthouse.
• Page Speed. Dat zit in een aparte Performance-categorie, niet in SEO. Performance is wél een ranking-factor (Core Web Vitals).
• Mobiele Usability. Wel deels (viewport, tap-targets, font-size) maar niet volledig.

Hoe je makkelijk naar 100 gaat

Voor de meeste MKB-sites op 70-90 zit het lek in:

• Anchor-tekst: 10-20 "klik hier"-links die je herschrijft
• Image alt-tags: bulk-update via CMS
• Meta description: 5-10 pagina's zonder description aanvullen
• Viewport: 1 regel in je header-template toevoegen
• Canonical tags: CMS-plugin gebruiken (WP: Yoast/RankMath, andere CMS'en hebben eigen oplossingen)

Werk vaak 1-4 uur. Bij DesignCheck Mijdrecht is een 100-score standaard op alle pagina's na een rebuild — niet als doel op zich, wel als "geen technische blokkade".

Hoe Lighthouse zich verhoudt tot echte ranking

Wij zien in audits vaak deze paradox:

• Site A: Lighthouse SEO 100, geen content, geen reviews → rankt op niets behalve eigen brand-naam
• Site B: Lighthouse SEO 78, sterke content, 40 reviews, actief profiel → top-3 voor primaire dienst-zoektermen

Conclusie: tech-fundamenten moeten goed zijn, maar zijn niet de doorslaggevende factor. Tech is de poortwachter, content + autoriteit zijn de versterker.

FAQ — Lighthouse SEO 100

Performance: de andere helft die Lighthouse meet

Lighthouse heeft naast de SEO-score nog drie categorieën die meetellen voor je vindbaarheid: Performance, Accessibility en Best Practices. De SEO-score is grotendeels een hygiëne-check, maar Performance bevat de echte ranking-factoren: Largest Contentful Paint, Interaction to Next Paint, en Cumulative Layout Shift. Google noemt deze samen "Core Web Vitals" en weegt ze sinds 2021 expliciet mee in zoekrankings.

Bij Keurmeesters halen we Lighthouse 96+ over alle 31 stadspagina's, en dat is geen toeval. Het komt door drie keuzes: kleine bundles (vanilla JS, geen frameworks waar het niet hoeft), images die in WebP of AVIF gecomprimeerd zijn met passende lazy-loading, en webfonts die met font-display swap geladen worden zodat tekst nooit onzichtbaar blijft tijdens font-fetch. Geen exotische trucs, geen CDN-magie, gewoon discipline in wat je laadt en in welke volgorde.

De drie metrics afzonderlijk: LCP meet hoe snel het grootste element op scherm verschijnt (doel onder 2.5 seconden), INP meet hoe snel de pagina reageert op klikken en tikken (doel onder 200 ms), CLS meet hoe stabiel de layout blijft tijdens laden (doel onder 0.1). Wie deze drie cijfers haalt, levert een ervaring die Google als kwalitatief erkent. Wie ze faalt, ziet rankings stilletjes wegzakken zonder duidelijke oorzaak.

Accessibility en best practices: de stille bonussen

Een hoge Accessibility-score is geen formele rankings-factor, maar wel een sterk indirect signaal. Toegankelijke sites zijn beter leesbaar voor screen readers, voor bots, en voor large language models die je content samenvatten. Een knop zonder aria-label, een input zonder label, een afbeelding zonder alt-tekst — al die kleine omissies maken je site letterlijk minder begrijpelijk voor automatische systemen.

Best Practices controleert HTTPS, console-fouten, deprecated API's en passieve veiligheidsproblemen. Een rode vlag hier vertaalt zich indirect naar gebrek aan vertrouwen. Wij behandelen Lighthouse-scores als één samenhangend pakket: alle vier de scores boven de 90, of het is geen oplevering. Klanten merken het niet direct, maar zoekmachines wel.

• Lighthouse SEO 100, Performance 90+, Accessibility 95+, Best Practices 100.
• Largest Contentful Paint onder 2.5 seconden op mobiel 4G.
• Interaction to Next Paint onder 200 milliseconden voor alle interactieve elementen.
• Cumulative Layout Shift onder 0.1 — geen springende content tijdens laden.
• Alle afbeeldingen in WebP of AVIF met responsive srcset en lazy-loading.
• Webfonts met font-display swap, gehost van eigen domein of preconnect-gewaarborgde CDN.
• Geen render-blocking scripts in de head — async of defer waar mogelijk.
• Inline kritieke CSS voor above-the-fold content, lazy-load de rest.
• HTTP/2 of HTTP/3 op de server, met juiste Cache-Control headers per resource-type.
• Brotli- of gzip-compressie standaard aan voor alle tekstuele assets.
• Alt-tekst op elke afbeelding, beschrijvend voor inhoudelijke beelden en leeg voor decoratieve.
• Aria-labels op elk interactief element zonder zichtbare tekst (icoon-knoppen).
• Contrastratio minimaal 4.5:1 voor body-tekst, 3:1 voor grote koppen.
• Focus-states zichtbaar voor keyboard-navigatie, niet weggehaald met outline: none.
• Geen console-errors of -warnings op productie — log alleen wat je daadwerkelijk debugt.

Wat een Lighthouse-rapport niet zegt

Een 100-score op alle vier de categorieën is geen garantie dat je site rankt. Lighthouse meet wat een browser kan controleren binnen één paginabezoek: techniek, structuur, snelheid, basis-toegankelijkheid. Het kan niet meten of je content de zoekvraag van de gebruiker beantwoordt, of je bedrijf vertrouwen wekt, of je merknaam bekend genoeg is voor mensen om er bewust naar te zoeken.

De volgorde die wel werkt: eerst Lighthouse 95+ over de hele site als ondergrens, dan inhoudelijk werk aan content, autoriteit, lokale signalen en review-volume. Andersom werkt het zelden — een sterke autoriteit op een trage, gebroken site verliest geleidelijk grond aan een mindere autoriteit met een snelle, schone site. Beide lagen tellen, en je hebt beide nodig.

Praktisch zien we het patroon waarbij ondernemers maanden besteden aan het optimaliseren van een 92 naar een 100, terwijl hun pagina's drie zinnen content bevatten. Andersom zien we sites met indrukwekkende inhoud die op een Lighthouse-score van 45 staan en daardoor 60% van hun potentieel mislopen. Beide groepen lossen het verkeerde probleem op. De vraag is altijd: wat is het zwakste punt in mijn keten, en wat levert mij de meeste bezoekers extra op?

Wat doe je vandaag?

• Open pagespeed.web.dev en draai een test op je vijf belangrijkste pagina's (homepage, twee diensten, twee blog).
• Noteer in een spreadsheet de vier scores per pagina als startmeting.
• Pak de drie meest voorkomende foutmeldingen op en los ze in één werksessie op.
• Controleer of je images allemaal WebP of AVIF zijn — zo niet, converteer met een batch-tool.
• Plan over zes weken een hertest om te zien of de scores ook bewaard blijven na inhoudelijke updates.

Schema.org als score-versterker

De Lighthouse-SEO-check bevestigt of je structured data syntactisch klopt, maar zegt niets over of je de juiste blokken gebruikt. Een Organization-blok op je homepage, LocalBusiness-blokken op je vestigings- of stadspagina's, Service-blokken op dienstpagina's en Article-blokken op blogposts vormen samen een rijke laag die crawlers en AI-modellen gebruiken om je site te begrijpen. Bij Keurmeesters hebben we op alle 31 stadspagina's een gedetailleerd LocalBusiness-blok met geo-coördinaten, openingstijden en serviceArea. Het effect is geen directe Lighthouse-score-boost, maar wel betere rich results, betere herkenning in knowledge-graphs en hogere doorklikrates vanuit zoekresultaten.

De valkuil zit in overpopulatie. Vijftien verschillende Schema-types op één pagina maakt de pagina niet sterker — Google leest het als ruis. Kies twee tot vier types die werkelijk passen bij de inhoud van die specifieke pagina, vul ze volledig in, en valideer ze met de Schema.org-validator van Google. Een onvolledig blok is slechter dan geen blok, want het wekt verwachtingen die de rest van de pagina niet waarmaakt.

Internal linking versterkt elke score

Een Lighthouse-rapport meet één pagina, maar Google ziet je hele site als netwerk. Pagina's die intern goed gelinkt zijn, krijgen sneller crawlbudget, worden vaker bezocht door bots, en zien hun verbeteringen sneller terug in rankings. Een geoptimaliseerde dienstpagina die orphan is — geen interne links — wacht maanden voordat Google überhaupt opmerkt dat er iets is veranderd. Dezelfde pagina met vijf inkomende interne links vanuit relevante blogartikelen ziet effect binnen weken.

Praktische volgorde: optimaliseer eerst de techniek van een pagina, dan de inhoud, dan de interne linking ernaartoe. Zonder dat laatste blijft het effect onder de radar van het algoritme. Bij elke rebuild bouwen we een handmatige interne linking-laag in op de geldverdiener-pagina's, zodat zodra de Lighthouse-cijfers groen zijn, de rankings ook werkelijk gaan stijgen. Dat is het verschil tussen "site is technisch klaar" en "site presteert".

De échte ranking-factoren naast Lighthouse

Lighthouse vinkt techniek af. Wat het niet meet maar wel meetelt voor rankings: Google Business Profile-kwaliteit, review-volume en -recentheid, NAP-consistentie over directories, autoriteit van inkomende externe links, helderheid van zoekintentie per pagina, recentheid van inhoud, en gedrag van bezoekers (bouncerate, sessie-duur, terugkeer naar zoekresultaten). Een site met perfecte Lighthouse-scores op alle pagina's maar zonder inkomende links, zonder reviews en zonder een goed gevuld Business Profile rankt nauwelijks.

De volgorde van prioriteiten die wij hanteren bij MKB-sites: één, Lighthouse 95+ als ondergrens; twee, Business Profile volledig en actief; drie, eerste tien tot vijftien reviews verzamelen; vier, content die letterlijk de zoekvraag beantwoordt; vijf, eerste vijf tot tien interne links naar geldverdieners; zes, eerste vijf eerlijke citations of backlinks. Pas wanneer alle zes lagen staan, ga je verder optimaliseren binnen de Lighthouse-score van 95 naar 99 — eerder is dat verspilde tijd.

Uitgebreide implementatie-checklist

• Test elke nieuwe pagina vóór publicatie op mobiel én desktop in Lighthouse — niet alleen na launch.
• Houd een dashboard bij met de scores van je top-20 pagina's, ververst maandelijks.
• Stel een ondergrens vast (bijvoorbeeld 90) waaronder geen pagina mag zakken zonder onderzoek.
• Detecteer regressies binnen 24 uur door automatische Lighthouse-runs op deploys.
• Bewaar oude rapporten om over tijd verschuivingen te kunnen zien.
• Test specifiek de mobiele variant op 4G en moderate CPU-throttling — daar valt 80% van de problemen.
• Lighthouse uit Chrome DevTools werkt voor losse pagina's, web.dev voor publieke audits met PSI-data.
• Search Console "Page Experience" rapport koppelt Lighthouse-data aan echte Chrome-bezoekers — die data zwaarder wegen.
• Bij elke deploy automatisch de drie Core Web Vitals checken via Web Vitals JS-library.
• Plan kwartaalsessies waarin je het hele scoreverloop terugkijkt en patroon-regressies aanpakt.
• Onderscheid Lab-data (Lighthouse, eenmalig) van Field-data (echte bezoekers, CrUX) — beide zijn relevant.
• Schema.org-blokken valideren met de Google Rich Results Test naast Lighthouse zelf.
• Performance-budget vaststellen in CI: maximaal aantal kilobytes JavaScript per pagina, anders faalt de build.
• Third-party scripts kwartaal-audits doen: trackers, chat-widgets, social-embed scripts wegen vaak het zwaarst.
• Privacy-vriendelijke alternatieven (zoals lichte custom analytics-beacons) overwegen boven zware GA-scripts.

Wat doe je vandaag (uitgebreid)?

• Open pagespeed.web.dev en draai een test op je vijf belangrijkste pagina's, noteer alle vier scores per pagina.
• Identificeer per pagina de top-drie "opportunities" en los de eerste binnen één werksessie op.
• Converteer de tien zwaarste afbeeldingen op je site naar WebP of AVIF en zet juiste lazy-loading aan.
• Voeg een Schema.org-validatie toe als laatste stap aan je publicatie-checklist.
• Plan over twee weken een hertest om te zien of de scores stabiel boven 90 blijven onder echte productiebelasting.

Verder lezen

• Internal linking uitgelegd
• Schema.org voor MKB uitgelegd
• Goede permalink-structuur

Door Lorenzo Ruisi — DesignCheck. Laatst bijgewerkt 16 mei 2026.