Canonical: https://www.strataigize.com/nl/insights/check-mobile-friendliness-website/
Description: Google heeft de Mobielvriendelijke test stopgezet. De gratis tools die hem vervangen, een voorbeeld met de PageSpeed-API en de drempels om te halen.
Published: 2025-12-15T00:00:00.000Z
Modified: 2026-09-06T00:00:00.000Z

[← Blog](https://www.strataigize.com/nl/insights/)

![](https://www.strataigize.com/blog/real/cover-check-mobile-friendliness-website.webp)

# Mobielvriendelijke test 2026: gratis tools en de PSI-API

Door [**Ian McGavin**](https://www.strataigize.com/nl/about/team/ian/), Oprichter en CMO · Gepubliceerd 15 december 2025 · Bijgewerkt 6 september 2026 · 16 min leestijd

Om in 2026 te controleren of je site mobielvriendelijk is, haal je je URL door Google PageSpeed Insights, controleer je hem met Lighthouse in Chrome DevTools, bekijk je de breakpoints in de apparaatmodus van DevTools, lees je het Core Web Vitals-rapport in Search Console en bevestig je alles op een echte telefoon. Google heeft de losse Mobielvriendelijke test in december 2023 stopgezet, en dit zijn de tools die hem hebben vervangen.

In dit artikel

1.  [Welke tools voor mobielvriendelijkheid werken in 2026 nog](https://www.strataigize.com/nl/insights/check-mobile-friendliness-website/#welke-tools-voor-mobielvriendelijkheid-werken-in-2026-nog)
2.  [Een mobiele audit met PageSpeed Insights en Lighthouse](https://www.strataigize.com/nl/insights/check-mobile-friendliness-website/#een-mobiele-audit-met-pagespeed-insights-en-lighthouse)
3.  [Is er een vervanger voor de API van de Mobielvriendelijke test?](https://www.strataigize.com/nl/insights/check-mobile-friendliness-website/#is-er-een-vervanger-voor-de-api-van-de-mobielvriendelijke-test)
4.  [Lighthouse lokaal draaien](https://www.strataigize.com/nl/insights/check-mobile-friendliness-website/#lighthouse-lokaal-draaien)
5.  [Stap voor stap: apparaatemulatie in Chrome DevTools](https://www.strataigize.com/nl/insights/check-mobile-friendliness-website/#stap-voor-stap-apparaatemulatie-in-chrome-devtools)
6.  [Mobiele Core Web Vitals-gegevens lezen in Search Console](https://www.strataigize.com/nl/insights/check-mobile-friendliness-website/#mobiele-core-web-vitals-gegevens-lezen-in-search-console)
7.  [De meest voorkomende mobiele fouten en oplossingen](https://www.strataigize.com/nl/insights/check-mobile-friendliness-website/#de-meest-voorkomende-mobiele-fouten-en-oplossingen)
8.  [De audit die wij draaien, stap voor stap](https://www.strataigize.com/nl/insights/check-mobile-friendliness-website/#de-audit-die-wij-draaien-stap-voor-stap)
9.  [Wat als je WordPress of Shopify gebruikt](https://www.strataigize.com/nl/insights/check-mobile-friendliness-website/#wat-als-je-wordpress-of-shopify-gebruikt)
10.  [Veelgestelde vragen](https://www.strataigize.com/nl/insights/check-mobile-friendliness-website/#veelgestelde-vragen)
11.  [Vier tools vervingen die ene badge](https://www.strataigize.com/nl/insights/check-mobile-friendliness-website/#vier-tools-vervingen-die-ene-badge)

[Voeg ons toe als voorkeursbron op Google](https://www.google.com/preferences/source?q=strataigize.com)

Een gratis Google-instelling om meer van onze relevante artikelen in uw zoekervaring te zien. U kunt dit altijd wijzigen.

Google heeft de losse Mobielvriendelijke test in december 2023 stopgezet, maar je kunt de mobiele bruikbaarheid nog steeds gratis controleren. Gebruik PageSpeed Insights en Lighthouse voor prestatiediagnose, Chrome DevTools voor layoutcontroles en een echte telefoon voor navigatie en formulieren. Die controles beantwoorden verschillende vragen. Een snelle pagina kan nog steeds knoppen hebben die je niet bereikt, en een goed bruikbare pagina kan nog steeds traag laden.

> Wil je het oordeel in 20 seconden? Gebruik onze gratis [Mobielvriendelijke test](https://www.strataigize.com/tools/mobile-friendly-test/): plak een URL en krijg een score voor viewport, vaste breedtes, te kleine tekst, paginagewicht en crawlbaarheid, met de oplossing voor elk punt. Zonder e-mail.

![Mobiel rapport van PageSpeed Insights met de veldgegevensbeoordeling van de Core Web Vitals en een prestatiescore van Lighthouse, de controle die de stopgezette Mobielvriendelijke test van Google heeft vervangen](https://www.strataigize.com/blog/real/pagespeed-result.webp)

## Welke tools voor mobielvriendelijkheid werken in 2026 nog

Het advies om „de Mobielvriendelijke test van Google te draaien” is achterhaald. Google kondigde aan dat het [het rapport Mobiele bruikbaarheid in Search Console, de tool Mobielvriendelijke test en de bijbehorende API vanaf 1 december 2023 zou uitfaseren](https://developers.google.com/search/blog/2023/04/page-experience-in-search), en de uitfasering werd op [4 december 2023](https://searchengineland.com/google-officially-drops-mobile-usability-report-mobile-friendly-test-tool-and-mobile-friendly-test-api-435377) publiek bevestigd. De reden die Google in die aankondiging gaf: mobiele bruikbaarheid blijft deel van de richtlijnen voor paginabeleving, maar sinds 2015 zijn er andere hulpmiddelen bijgekomen, „including Lighthouse from Chrome”.

Google heeft ook [op 1 december 2023 elke vermelding van de tool uit de helpdocumentatie van Zoeken verwijderd](https://www.seroundtable.com/google-search-consoles-mobile-usability-report-mobile-friendly-tests-are-gone-36497.html) en de URL’s voor mobiele bruikbaarheid in Search Console doorgestuurd naar het overzicht van de property. In de [aankondiging van april 2023](https://developers.google.com/search/blog/2023/04/page-experience-in-search) wijst Google [Lighthouse](https://developer.chrome.com/docs/lighthouse/overview) aan als vervanger. Een gids die de stopgezette tool nog als actieve optie aanbiedt, is verouderd.

Er is nog één losse controletool: de [Mobile Friendliness Test Tool van Bing](https://www.bing.com/webmaster/tools/mobile-friendliness). Die controleert hoe Bing de pagina op mobiel ziet, waaronder de viewportinstelling, de breedte van de content, de leesbaarheid en de afstand tussen tikdoelen. Het oordeel zegt niets over hoe Google of een AI-assistent de pagina rangschikt of citeert.

| Tool | Kosten | Wat hij meet | Beperkingen |
| --- | --- | --- | --- |
| PageSpeed Insights | Gratis | Mobiele labrun van Lighthouse plus Core Web Vitals van echte gebruikers | Veldgegevens vragen genoeg verkeer; deelbare rapportlinks blijven als momentopname [tot 30 dagen](https://developers.google.com/speed/docs/insights/release_notes) bewaard |
| Lighthouse in Chrome DevTools | Gratis | Prestaties, toegankelijkheid, best practices, SEO en tikdoelen in mobiele emulatie | Alleen lab; resultaten wisselen met de belasting van je computer |
| Apparaatmodus van Chrome DevTools | Gratis | Layout, overloop en vaste elementen op echte viewportformaten | Emulatie, geen echte hardware of echte aanraking |
| Core Web Vitals in Search Console | Gratis | Mobiele veldgegevens van de hele site, per URL-groep | Voortschrijdend venster van 28 dagen; geen controle op tikdoelen of viewport |
| Bing Mobile Friendliness Test | Gratis | Viewport, contentbreedte, leesbaarheid, tikafstand, plug-ins | Het oordeel van Bing, geen rankingfactor van Google |
| Echte apparaten of BrowserStack | Gratis niveau, betaalde abonnementen | Echte aanraking, gebaren, eigenaardigheden in browserweergave | Veel apparaten kosten geld en tijd |
| Mobielvriendelijke test van Google | Verdwenen | Niets | Stopgezet op 1 december 2023 |

### Mobiele bruikbaarheid en mobile-first indexering zijn verschillende controles

Google gebruikt de mobiele versie van de content van een pagina voor indexering en ranking. De [richtlijnen voor mobile-first indexering](https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing) ondersteunen responsive design, dynamische weergave en aparte mobiele URL’s. Responsive design is de aanbevolen optie, omdat die makkelijker te bouwen en te onderhouden is.

Controleer of Googlebot op mobiel bij de content, afbeeldingen en metadata kan. Controleer daarna hoe makkelijk een mens ze kan gebruiken. Een geblokkeerde mobiele pagina is een crawlprobleem; een krappe knop is een bruikbaarheidsprobleem. Een Lighthouse-score of een meting van tikdoelen zegt op zichzelf niet of een pagina wordt geïndexeerd.

> Liever een deskundige blik op je site dan nog een audittabblad? Bekijk onze [diensten voor websiteoptimalisatie](https://www.strataigize.com/nl/services/website-optimization/).

## Een mobiele audit met PageSpeed Insights en Lighthouse

Begin met [PageSpeed Insights](https://pagespeed.web.dev/). Plak een URL, start de test en lees het tabblad Mobiel vóór het tabblad Desktop.

Het rapport bestaat uit twee helften die mensen steeds door elkaar halen:

-   **Veldgegevens** bovenaan: metingen van echte Chrome-gebruikers uit het Chrome UX Report, dagelijks bijgewerkt in een [voortschrijdend venster van 28 dagen](https://developer.chrome.com/docs/crux/methodology/tools). Dit gebruiken de signalen voor paginabeleving van Google echt.
-   **Labgegevens** daaronder: één gesimuleerde Lighthouse-run op de servers van Google. Handig voor diagnose, geen oordeel over echte gebruikers.

Om een volledige Core Web Vitals-beoordeling met alle drie de statistieken te halen, moet een pagina de drempel „goed” halen op het [75e percentiel voor alle drie de statistieken](https://web.dev/articles/vitals). Ontbrekende veldgegevens betekenen dat het rapport die volledige beoordeling niet kan geven; het bewijst niet dat de pagina is gezakt. Lighthouse kan INP uit het veld niet meten met één navigatierun.

| Statistiek | Goed | Slecht |
| --- | --- | --- |
| Largest Contentful Paint (LCP) | 2,5 s of minder | meer dan 4,0 s |
| Interaction to Next Paint (INP) | 200 ms of minder | meer dan 500 ms |
| Cumulative Layout Shift (CLS) | 0,1 of minder | meer dan 0,25 |

Bron: [drempels van de Core Web Vitals op web.dev](https://web.dev/articles/defining-core-web-vitals-thresholds), actueel in 2026. INP [verving First Input Delay (FID) op 12 maart 2024 als Core Web Vital](https://web.dev/blog/inp-cwv-march-12), dus negeer elke checklist die je nog vertelt FID te optimaliseren.

### Twee wijzigingen in PageSpeed Insights die de lat verlegden

Op [5 december 2024 paste PageSpeed Insights aan hoe sterk de CPU (de processor) wordt afgeremd](https://developers.google.com/speed/docs/insights/release_notes), wat de Total Blocking Time in mobiele labruns meestal verhoogde. Veld- en desktopresultaten bleven ongemoeid. Als je mobiele labscore daalde zonder dat er iets live ging, is dit een aannemelijke oorzaak.

PageSpeed Insights (PSI) en de API [stapten op 20 oktober 2025 over op Lighthouse 13.0](https://developers.google.com/speed/docs/insights/release_notes). Versies kunnen veranderen welke diagnoses je ziet, dus noteer bij elk resultaat de Lighthouse-versie. Voor doorlopende monitoring van echte gebruikers raadt Google de [CrUX API of CrUX History API](https://developers.google.com/speed/docs/insights/v5/get-started) aan: Google is van plan om geen CrUX-veldgegevens meer in de PSI-API op te nemen.

## Is er een vervanger voor de API van de Mobielvriendelijke test?

De oude API van de Mobielvriendelijke test is samen met de tool stopgezet. De **PageSpeed Insights-API** kan een mobiele Lighthouse-run automatiseren, maar geeft niet het oude geslaagd-of-gezakt-resultaat voor mobielvriendelijkheid. Controles op layout en interactie blijven nodig.

Dit verzoek vraagt diagnoses op voor mobiele prestaties, toegankelijkheid en SEO. Vervang de voorbeeld-URL door een openbare pagina die je wilt testen:

```
curl --get \
  'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
  --data-urlencode 'url=https://example.com/' \
  --data-urlencode 'strategy=mobile' \
  --data-urlencode 'category=performance' \
  --data-urlencode 'category=accessibility' \
  --data-urlencode 'category=seo'
```

De [startgids](https://developers.google.com/speed/docs/insights/v5/get-started) van Google staat toe dat je de API zonder sleutel probeert en raadt een sleutel aan voor frequente geautomatiseerde verzoeken. Controleer het huidige quotum van je project voordat je een batch inplant. Krijg je HTTP 429 terug, onderzoek dan het quotum in plaats van het antwoord als resultaat voor de geteste pagina te behandelen. De [API-referentie](https://developers.google.com/speed/docs/insights/v5/reference/pagespeedapi/runpagespeed) beschrijft de parameters en antwoordvelden.

Lees `lighthouseResult.categories` voor de categoriescores en `lighthouseResult.audits` voor de afzonderlijke resultaten. Scores staan op een schaal van nul tot één; 0,92 staat voor 92 van de 100. Sla `fetchTime` en `lighthouseVersion` op bij de geteste URL, zodat latere vergelijkingen een bekende run gebruiken. Handel HTTP-fouten en `runtimeError` af voordat je een antwoord als audit behandelt.

Gebruik voor veldprestaties de [CrUX API](https://developer.chrome.com/docs/crux/api) of de [CrUX History API](https://developer.chrome.com/docs/crux/history-api). Voor een URL zijn er misschien niet genoeg gegevens van echte gebruikers. Houd die situatie gescheiden van een slecht resultaat, en rapporteer een labscore nooit als geslaagde Core Web Vitals in het veld.

## Lighthouse lokaal draaien

Lighthouse zit in Chrome DevTools. Open je pagina, klik met de rechtermuisknop, kies Inspecteren, open het paneel **Lighthouse**, kies **Mobiel** en klik op Rapport genereren. Het [draait in je geïnstalleerde Chrome en stuurt nooit resultaten naar een externe server](https://github.com/GoogleChrome/lighthouse), dus je kunt ook staging- en met een wachtwoord beveiligde versies controleren die PSI niet bereikt.

De mobiele voorinstelling is geen gok. Lighthouse past een [CPU-vertragingsfactor van 4x](https://github.com/GoogleChrome/lighthouse/blob/main/docs/throttling.md) toe om een desktop-CPU naar het niveau van een middenklassetelefoon te brengen, plus een netwerkvoorinstelling „Slow 4G” die het langzaamste kwart van de 4G-verbindingen voorstelt. De apparaatemulatie gebruikt een Moto G Power-profiel met een [viewport van 412 bij 823 en een apparaatschaalfactor van 1,75](https://github.com/GoogleChrome/lighthouse/blob/main/core/config/constants.js), met mobiel en aanraking ingeschakeld, volgens het eigen `constants.js` van Lighthouse (een eerdere versie van dit artikel noemde 2,625, de schaalfactor van het oudere Moto G4-profiel dat Lighthouse heeft uitgefaseerd, niet de huidige waarde).

[Lighthouse 13 verving veel prestatieaudits door inzichten die aansluiten op DevTools](https://developer.chrome.com/blog/lighthouse-13-0) en hield `unsized-images` en `non-composited-animations` als diagnoses. Ook de oude audit voor lettergrootte verdween. Een verwijderde diagnose maakt onleesbare tekst niet acceptabel; controleer de echte tekst van de pagina op een telefoon.

## Stap voor stap: apparaatemulatie in Chrome DevTools

Scores vertellen je iets over snelheid. Emulatie vertelt je of de pagina bruikbaar is. Doe allebei.

1.  Open de pagina in Chrome, gebruik de sneltoets voor Inspecteren en zet de **Apparaatwerkbalk** aan.
2.  Kies eerst een smalle viewport. Test op 360 bij 800 en 390 bij 844, en werk dan omhoog naar tabletbreedtes.
3.  Zet de beperking op **Mid-tier mobile** of stel handmatig Slow 4G plus 4x CPU in, gelijk aan het Lighthouse-profiel.
4.  Draai naar liggend. Open in elke stand je hoofdnavigatie, een formulier en een afreken- of contactstap.
5.  Houd het paneel Elements in de gaten terwijl je het formaat wijzigt, om te zien welke container overloopt.

Wat emulatie vindt en een score nooit zal vinden:

-   Kleine tikdoelen die tegen een buurelement zijn geperst, inclusief de gevallen uit de [Lighthouse-audit voor tikdoelen](https://developer.chrome.com/docs/lighthouse/seo/tap-targets)
-   Horizontale overloop door een tabel met vaste breedte, een embed of een te grote afbeelding
-   Vaste headers en cookiebanners die op een laag scherm de halve viewport opslokken
-   Modale vensters waarvan de sluitknop buiten beeld is geschoven
-   Invoervelden die bij focus het verkeerde toetsenbord openen of inzoomen

Mik voor prettige aanraakknoppen op 48 bij 48 CSS-pixels waar de layout dat toelaat. De gedocumenteerde regel van Lighthouse kijkt naar zowel de grootte van het doel als de overlap met doelen in de buurt; niet elk kleiner element zakt. Het aparte [WCAG 2.2 AA-criterium voor doelgrootte](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html) gebruikt 24 bij 24 CSS-pixels met ruimte en andere uitzonderingen. Geen van beide is een universele rankingdrempel van Google.

Ken de grens. Emulatie verkleint een desktopbrowser en doet alsof de CPU traag is. Ze bootst geen echte aanraakvertraging na, geen eigenaardigheden van Safari op iOS, niet het bereik van je duim en niet hoe een middenklasse-Android een zwaar script afhandelt als hij door warmte vertraagt. Sluit elke audit af op een echte telefoon.

## Mobiele Core Web Vitals-gegevens lezen in Search Console

Het oude rapport Mobiele bruikbaarheid is weg. Gebruik het Core Web Vitals-rapport van Search Console voor de prestaties bij echte gebruikers, en controleer layout en interacties apart.

Open [Search Console](https://search.google.com/search-console), ga naar Core Web Vitals en werk het rapport voor mobiel door. Google [splitst het overzicht per apparaat, groepeert URL’s met een vergelijkbare beleving en geeft elke groep de status van haar slechtste statistiek](https://support.google.com/webmasters/answer/9205520). Eén slechte statistiek in een sjabloon trekt dus elke URL van dat sjabloon naar Slecht.

Zo lezen wij het:

-   Klik naast de grafiek voor mobiel op **Rapport openen** en wissel tussen de tabbladen Slecht, Verbetering nodig en Goed.
-   Lees de tabel „Waarom URL’s niet als goed worden beschouwd”. Die noemt de gezakte statistiek en de overschreden drempel.
-   Repareer het sjabloon, niet de URL. De status per groep betekent dat één sjabloonfix veel pagina’s verplaatst.
-   Gebruik na het live zetten **Tracking starten**. Google draait een [monitoringsessie van 28 dagen en markeert het probleem alleen als opgelost als het het hele venster wegblijft](https://support.google.com/webmasters/answer/9205520).

Twee kanttekeningen. De gegevens zijn een voortschrijdend totaal over 28 dagen, dus een fix van dinsdag zie je woensdag nog niet. En Google zegt duidelijk dat [gegevens van PageSpeed Insights kunnen afwijken van het Core Web Vitals-rapport](https://support.google.com/webmasters/answer/9205520), omdat het ene een labrun op één apparaatprofiel is en het andere duizenden echte sessies. Als ze het oneens zijn, vertrouw dan op de veldgegevens en gebruik de labrun om de oorzaak te vinden. [web.dev legt het verschil tussen lab en veld uit](https://web.dev/articles/lab-and-field-data-differences) in meer detail. Dezelfde statistieken zitten in hoe wij [websiteoptimalisatie](https://www.strataigize.com/nl/services/website-optimization/) aanpakken.

## De meest voorkomende mobiele fouten en oplossingen

Dit zijn de fouten waarvoor de tools hierboven gemaakt zijn, met de drempel of regel die elk gebruikt.

| Fout | Gevonden door | Drempel of regel | Oplossing |
| --- | --- | --- | --- |
| Ontbrekende of verkeerd ingestelde viewport-metatag | DevTools-emulatie, Bing-test | Desktoplayout op een telefoon geforceerd | Voeg `<meta name="viewport" content="width=device-width, initial-scale=1">` toe |
| Trage LCP-hoofdafbeelding | PSI veld en lab, Search Console | LCP moet op p75 2,5 s of minder zijn | Comprimeren, moderne formaten leveren, het LCP-element vooraf laden, lazy loading ervan weghalen |
| Afbeeldingen en embeds zonder afmetingen | Lighthouse-diagnose `unsized-images` | CLS moet op p75 0,1 of minder zijn | Breedte en hoogte of aspect-ratio instellen op elk media-element |
| Zware JavaScript van derden | Lighthouse voor blokkerend werk; CrUX of monitoring van echte gebruikers voor INP | Goede INP in het veld is op p75 200 ms of minder | Lange taken opknippen; scripts nalopen en daarbij toestemming en noodzakelijke functies behouden |
| Tikdoelen te klein of te dicht op elkaar | Lighthouse-audit voor tikdoelen en controle op een echte telefoon | Grootte en overlap met buurdoelen tellen allebei | Knoppen groter maken en ruimte toevoegen; 48 px is een prettig doel |
| Content breder dan het scherm | Apparaatmodus van DevTools, Bing-test | Geen horizontaal scrollen op een viewport van 360 px | Flexibele tabellen, `max-width: 100%` op media, geen containers met vaste pixels |
| Opdringerige interstitials | Handmatige controle op een echte telefoon | Content geblokkeerd bij het laden | Pop-ups over het hele scherm uitstellen, verkleinen of verwijderen |
| Laat ladende lettertypen en ingevoegde banners | CLS-groep in Search Console | CLS op p75 | Lettertypen vooraf laden, ruimte reserveren voor banners en advertenties |

Let op welke tool wat vindt. Geen enkele controletool dekt de hele lijst, en precies daarom was de oude geslaagd-of-gezakt-badge nooit genoeg.

## De audit die wij draaien, stap voor stap

Dit is de volgorde die we op onze eigen site en op klantsites gebruiken.

1.  **Kies drie URL’s, niet één.** De homepage, een belangrijke dienst- of productpagina en een blogartikel. Sjablonen falen op verschillende manieren.
2.  **Eerst Search Console.** Core Web Vitals, weergave voor mobiel. Noteer welke URL-groepen op Slecht of Verbetering nodig staan en welke statistiek wordt genoemd. Dit zijn echte gebruikers, dus dit bepaalt de prioriteit.
3.  **PSI op één URL uit elke gezakte groep.** Vergelijk veldgegevens met labgegevens. Zegt het veld Slecht en het lab dat het prima is, zoek dan naar scripts van derden, ingelogde toestanden of trage oorspronkelijke servers die een schone labrun nooit ziet.
4.  **Lighthouse lokaal op dezelfde drie URL’s.** Mobiele voorinstelling. Lees de diagnoses voor tikdoelen en `unsized-images`, en het paneel Toegankelijkheid voor contrastfouten.
5.  **Apparaatmodus van DevTools op 360 bij 800.** Open de navigatie, een formulier en de belangrijkste conversiestap. Draai het scherm. Zoek naar overloop en geblokkeerde content.
6.  **De Mobile Friendliness Test van Bing** op dezelfde URL’s, voor het oordeel van een tweede crawler over viewport, breedte, leesbaarheid en tikafstand.
7.  **Eén echte telefoon, liefst een middenklasse-Android.** Laden via mobiel internet, niet via de wifi op kantoor. Voer de conversieactie van begin tot eind uit.
8.  **Zet de sjabloonfixes live en start daarna de tracking in Search Console**, en reken op 28 dagen voordat de validatie klaar is.

### Waarom veldgegevens en labgegevens het oneens zijn

Google zegt uitdrukkelijk dat [gegevens van PageSpeed Insights kunnen afwijken van het Core Web Vitals-rapport](https://support.google.com/webmasters/answer/9205520). Labgegevens zijn één gesimuleerde run op één apparaatprofiel. Veldgegevens zijn een voortschrijdend totaal over 28 dagen van echte Chrome-gebruikers. [De gids van web.dev over lab- en veldgegevens](https://web.dev/articles/lab-and-field-data-differences) noemt de gebruikelijke oorzaken: echte apparaten en netwerken wisselen meer dan het lab, scripts van derden gedragen zich anders bij echte gebruikers, cache en back-forward cache veranderen terugkerende bezoeken, en CrUX rapporteert alleen URL’s met genoeg verkeer. Als ze het oneens zijn, behandel dan de veldgegevens als oordeel en de labrun als diagnose.

Als we een site beoordelen, kijken we eerst naar de veldgegevens in Search Console en gebruiken we daarna PSI en Lighthouse om het element of script aan te wijzen. De eigen optimalisatiegidsen van Google zijn het draaiboek:

-   Trage LCP: [Largest Contentful Paint optimaliseren](https://web.dev/articles/optimize-lcp). Comprimeer de hoofdafbeelding, lever een modern formaat, laad het LCP-element vooraf en gebruik er geen lazy loading voor.
-   Hoge INP: [Interaction to Next Paint optimaliseren](https://web.dev/articles/optimize-inp). Knip lange taken op en stel JavaScript van derden dat de hoofdthread blokkeert uit of verwijder het.
-   Hoge CLS: [Cumulative Layout Shift optimaliseren](https://web.dev/articles/optimize-cls). Stel breedte, hoogte of aspect-ratio in op afbeeldingen en embeds, zodat de layout niet verspringt als ze laden.

Search Console [groepeert URL’s met een vergelijkbare beleving en geeft elke groep de status van haar slechtste statistiek](https://support.google.com/webmasters/answer/9205520). Eén sjabloonfix, zoals afbeeldingsafmetingen in een gedeeld kaartcomponent, kan veel URL’s tegelijk verplaatsen. Gebruik na het live zetten **Tracking starten** en wacht het volledige venster van 28 dagen af voordat Google het probleem als opgelost markeert.

Herhaal de acht stappen na themawissels, na installaties van plug-ins of apps en na elke publicatie in de tagmanager, plus een geplande controle per kwartaal. Scripts van derden zijn in [de INP-richtlijnen van Google](https://web.dev/articles/optimize-inp) gedocumenteerd als risico voor INP, en daarom vergelijkt stap 3 de veldgegevens met een schone labrun. Voor crawlen, indexering en werk op de pagina rond deze mobiele controle, zie onze dienst voor [zoekmachineoptimalisatie](https://www.strataigize.com/nl/services/website-optimization/search-engine-optimization/).

## Wat als je WordPress of Shopify gebruikt

Beide platforms brengen je met configuratie in plaats van code het grootste deel van de weg:

-   Een responsive thema, getest op 360 px voordat je ervoor kiest
-   Native lazy loading overal behalve bij de LCP-afbeelding
-   Moderne afbeeldingsformaten op de juiste afmetingen, geen desktopbestanden die met CSS (Cascading Style Sheets) worden verkleind
-   Sjablonen van Shopify Online Store 2.0 en afbeeldingsformaten per sectie
-   Een audit van geïnstalleerde apps en plug-ins, omdat elk ervan meestal renderblokkerende JavaScript toevoegt

Draai Lighthouse opnieuw na elke wijziging aan thema of apps. Precies daar zakken mobiele scores ongemerkt weg. Als het thema zelf de grens is, is de oplossing een herbouw op een modern framework met prestaties en SEO er vanaf het begin in ontworpen, en dat is wat onze dienst voor [websiteontwikkeling](https://www.strataigize.com/services/development-services/website-development/) levert.

## Veelgestelde vragen

### Hoe controleer ik mobielvriendelijkheid nu de test van Google weg is?

Draai Lighthouse in Chrome DevTools met de mobiele voorinstelling, bekijk het tabblad Mobiel in PageSpeed Insights, lees het mobiele Core Web Vitals-rapport in Search Console en bevestig alles op een echte telefoon. De Mobile Friendliness Test van Bing geeft nog steeds een geslaagd-of-gezakt-oordeel als je dat wilt.

### Wat is het verschil tussen mobielvriendelijk en responsive?

Mobielvriendelijk betekent dat de pagina bruikbaar is op een telefoon. Responsive design past dezelfde pagina met flexibele layouts en CSS-mediaquery’s aan verschillende viewports aan. Google [raadt responsive design aan omdat het makkelijker te onderhouden is](https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing), maar ondersteunt ook dynamische weergave en aparte mobiele URL’s.

### Heb ik een aparte mobiele website nodig?

Nee. Eén responsive URL is makkelijker te onderhouden, voorkomt gedoe met dubbele content en geeft één set signalen voor SEO en [optimalisatie voor generatieve zoekmachines](https://www.strataigize.com/nl/insights/what-is-generative-engine-optimization/).

### Straft Google websites af die niet mobielvriendelijk zijn?

Controleer toegang tot content en gebruikservaring apart. Google moet je mobiele content kunnen ophalen en weergeven om die te indexeren. Core Web Vitals worden gebruikt voor ranking, maar [Google zoekt nog steeds naar relevante content, ook als de paginabeleving tekortschiet](https://developers.google.com/search/docs/appearance/page-experience). Een slechte mobiele score bewijst op zichzelf geen verwijdering uit de index, geen straf en geen bepaald rankingverlies.

### Waarom zijn PageSpeed Insights en Search Console het oneens?

Google zegt dat de twee kunnen verschillen. Labgegevens van PSI zijn één gesimuleerde run op één apparaatprofiel. Search Console rapporteert een voortschrijdend totaal over 28 dagen van echte Chrome-gebruikers voor een hele URL-groep. [De documentatie van Google over het Core Web Vitals-rapport](https://support.google.com/webmasters/answer/9205520) en [het artikel van web.dev over lab en veld](https://web.dev/articles/lab-and-field-data-differences) zeggen allebei dat je veldgegevens als oordeel en labgegevens als diagnose behandelt.

## Vier tools vervingen die ene badge

De losse geslaagd-of-gezakt-badge is weg en komt niet terug. Wat ervoor in de plaats kwam, is beter: veldmetingen van echte gebruikers, een labaudit die je op staging kunt draaien, viewportemulatie voor de layout en het oordeel van een tweede crawler, die van Bing. Bouw je proces rond die vier, bepaal prioriteiten op basis van wat echte gebruikers volgens Search Console ervaren, en repareer sjablonen in plaats van losse URL’s.

We doen dit vanuit Vancouver als [websiteoptimalisatie](https://www.strataigize.com/nl/services/website-optimization/). Kost de mobiele prestatie je rankings of conversies, dan is een [groei-audit](https://www.strataigize.com/nl/audit/) de plek om te beginnen.

Auteur

**Ian McGavin**

Volgende stap

Verkeer prima, maar zwakke conversie op de telefoon? In twintig seconden weet je of de pagina überhaupt als mobiele pagina rendert.

[Test mijn pagina →](https://www.strataigize.com/tools/mobile-friendly-test/)

Praat met ons

### Spreek met het team dat het zou runnen

Vertel ons waar we moeten kijken en we antwoorden binnen 24 uur met het startpunt. Geen pitch tot u de waarde ziet.

[Voeg ons toe als voorkeursbron op Google](https://www.google.com/preferences/source?q=strataigize.com)

Een gratis Google-instelling om meer van onze relevante artikelen in uw zoekervaring te zien. U kunt dit altijd wijzigen.

[Alle Website en CRO-artikelen →](https://www.strataigize.com/nl/insights/topics/cro-lifecycle/)

## Wilt u dat wij dit voor u doen?

Boek een gratis consult van 30 minuten. Geen pitch tot u de waarde ziet.

[Groeiconsult boeken →](https://www.strataigize.com/nl/audit/) [Beoordeling **5,0** op Clutch](https://clutch.co/profile/strataigize-marketing)