Mobiele SEO in 2026: Ranking in een Mobile-First-index

TL;DR: Mobile-first indexing staat sinds juli 2024 volledig live. De pagina die Google daadwerkelijk indexeert en waarop het ook rangschikt, is je mobiele pagina: gecrawled met een smartphone-agent. De check die bijna niemand draait: open Google Search Console, splits je topzoekopdrachten op apparaat en kijk welke queries op mobiel aanzienlijk slechter scoren dan op desktop. Daar verdwijnt je ontbrekende traffic.

Mobile-first indexing in één minuut

In juni 2024 kondigde Google de laatste stap aan in zijn jarenlange migratie: vanaf 5 juli 2024 zouden de resterende sites die nog werden gecrawld met de desktop Googlebot, overschakelen naar de Googlebot Smartphone-crawler. Content die niet toegankelijk is op mobiel, is niet langer indexeerbaar. Klaar is kees.

Wat dit in de praktijk betekent: Google gebruikt de mobiele versie van je content, gecrawled met de smartphone-agent, voor indexing en ranking. De mobiele pagina is de canonieke versie voor zoekdoeleinden. Desktoprankings volgen op wat mobiel indexeert.

Nog één onderscheid dat je moet maken: “mobile-friendly” zegt niets over of je goed rankt. Het betekent alleen dat je niet de interstitial-penalty krijgt. Dat zijn volledig verschillende dingen, en het door elkaar halen is precies waar de meeste mobile SEO-adviezen de mist in gaan.

De check die bijna niemand draait: je mobile-vs-desktop ranking gap

Ik keek langer dan goed voor me was niet naar de Device-dimensie in Google Search Console. Die staat gewoon in het Zoekresultatenrapport: één klik verwijderd van de standaardweergave, en ik behandelde het jaren als een voetnoot. Fout. Bij SEOJuice zien we bij mobile audits op nieuwe sites dat de vergelijking per device bijna altijd als eerste het gat blootlegt dat de site-eigenaar niet eens wist dat hij had.

Zo pak je het aan. Open GSC, ga naar Zoekresultaten, klik op “Nieuw”, voeg een vergelijkingfilter toe en kies “Device: Mobile vs Desktop”. Je krijgt de Average Position naast elkaar voor dezelfde queries. Sorteer op de queries met de grootste negatieve mobile delta: de gevallen waarin je mobile positie duidelijk slechter is dan desktop.

Een kleine, gelijkmatige gap over alle queries heen is ruis. Mobile SERPs hebben een andere lay-out en je positie kan 1 à 2 plekken verschuiven puur door hoe Google resultaten op kleinere schermen formatteert. Waar je naar zoekt is iets specifieks: een query waarop je op desktop #4 staat en op mobiel #9. Dat patroon wijst meestal op een probleem met de mobiele versie van die pagina zelf. Content en links zijn hetzelfde. De mobiele uitvoering niet. Snelheid, ontbrekende content of een renderfout kosten je positie op die query, en dat zie je niet tenzij je het device-onderscheid bekijkt.

Deze audit is gratis, kost tien minuten en laat direct zien welke pagina’s mobile-specifiek werk nodig hebben. De meeste sites doen ’m nooit. De sites die het wél doen vinden meestal minstens één high-traffic query met een verschil van 3-5 posities dat ze daarvoor niet kenden.

Mobile Core Web Vitals: dezelfde drempels, strengere test

Een correctie die veel SEOs in de problemen brengt, omdat meerdere prominente guides dit nog steeds verkeerd doen: de drie huidige Core Web Vitals zijn LCP (Largest Contentful Paint, goed bij 2,5 seconden of minder), INP (Interaction to Next Paint, goed bij 200 milliseconden of minder) en CLS (Cumulative Layout Shift, goed bij 0,1 of minder). Drempels gelden voor het 75e percentiel van echte velddata.

INP verving FID (First Input Delay) op 12 maart 2024. Zoals het Chrome-team het verwoordde: “After years of work, we're finally ready to make Interaction to Next Paint (INP) a stable Core Web Vital metric. This marks a significant step forward in the way we measure interaction responsiveness, addressing many of the shortcomings of First Input Delay (FID).” FID is per september 2024 volledig verwijderd uit de Chrome tooling. Staat FID nog steeds op je lijstje als Core Web Vital, dan zit je guide achter met meer dan twee jaar. Dat is relevant omdat FID en INP verschillende dingen meten: FID mat alleen de vertraging vóórdat de browser begon met het verwerken van input, terwijl INP de totale interactielatency meet tot de volgende paint. Strenger én representatiever.

Waarom mobile CWV-scores regelmatig falen terwijl desktop scores net goed blijven: labtests simuleren een mid-tier Android-toestel op een 4G-verbinding met CPU throttling. Je M-serie MacBook met Chrome DevTools is niet dat toestel. Een pagina die bij je laptop 1,8 seconde nodig heeft om te renderen, kan op een echt Moto G-device bij 4G-signaalsterkte 3,2 seconden halen. Zelfde codebase, zelfde hosting. Die throttling-penalty is precies waar mobile scores uiteenlopen.

(Eerlijk is eerlijk:) de exacte throttling-multipliers die Chrome DevTools toepast, zijn verschoven door de versies heen, en velddata uit echte CrUX kan in beide richtingen afwijken van labscores, afhankelijk van de toestelverdeling van je echte gebruikers. Gebruik velddata uit PageSpeed Insights, specifiek het mobile-tabblad, als je primaire signaal. Labscores zijn nuttig om regressies te spotten, maar minder geschikt als enige bron van waarheid.

Waar check je je mobile velddata: PageSpeed Insights haalt CrUX-data op die gesegmenteerd is per device. Het Core Web Vitals-rapport in Search Console toont mobile als een eigen bucket, los van desktop. Een pagina die in de desktop-bucket “goed” is en in de mobile-bucket “slecht” moet mobile-specifiek werk hebben. Onze Core Web Vitals audit guide laat zien hoe je elke metric leest én wat je vervolgens doet. Voor context bij Lighthouse scoring: zo berekent Lighthouse je SEO-score legt uit hoe labmetrics doorwerken naar de uitkomst van een echte audit.

Mobile rendering, parity en de JS/SPA-valkuil

Google is expliciet over content parity: “Alleen de content die op de mobiele site wordt getoond, wordt gebruikt voor indexing.” Designverschillen zijn prima. Accordeons, uitklapbare secties, tabs: content achter die elementen wordt nog steeds geïndexeerd. Wat niet wordt geïndexeerd, is content die helemaal ontbreekt in de mobiele DOM, of content die user interaction nodig heeft om te verschijnen. Als je desktoptemplate productdetails in een sidebar laat zien die op mobiel inklapt en nooit echt rendert in de mobiele DOM, dan bestaat die content niet in de index.

De SPA-situatie is subtieler. Google verwerkt JavaScript-apps in drie fasen: crawling, rendering, indexing. Pagina’s worden in een renderqueue gezet; Google’s documentatie vermeldt dat de pagina “mogelijk een paar seconden in die queue blijft, maar het kan ook langer duren”, en zodra resources het toelaten, rendert een headless Chromium de pagina. Op een throttled mobile CPU stapelt trage hydration de vertraging in de queue verder op. Als de mobile crawl van Googlebot je SPA raakt en de main content pas 4-5 seconden in de hydration zichtbaar wordt, is de kans groot dat de gerenderde snapshot incompleet is. Je development machine, waar dezelfde app op draait, laat geen enkel teken hiervan zien. Daar hydrateert alles in minder dan een seconde.

De test: in Search Console open je URL Inspection voor elke pagina die je verdenkt. Klik “Test live URL”, daarna “View tested page” en schakel naar het tabblad HTML. Dat is de HTML die Googlebot heeft vastgelegd. Vergelijk het met wat je in de browser ziet. Als er body content ontbreekt of duidelijk is ingekort in de inspectieweergave, is het probleem rendering. Oplossingsopties (server-side rendering, static generation, prerendering van content above the fold) komen aan bod in onze SPA SEO guide.

Viewport, tap targets en intrusieve interstitials

Dit zijn basis-hygiënepunten. Eén keer bevestigen is genoeg; je hoeft er niet elke week op te blijven kauwen.

Viewport meta tag: <meta name="viewport" content="width=device-width, initial-scale=1"> in je <head>. Zonder deze renderen mobiele browsers op desktop-breedte en zoomen ze uit. Dertig seconden werk als je ’m mist.

Tap targets: Knoppen en links moeten minimaal 48 CSS-pixels hoog en breed zijn, met voldoende ruimte ertussen. Lighthouse geeft een vlag als targets te klein zijn of te dicht bij elkaar staan (de eigen WCAG-minimumwaarde ligt lager, maar 48px is de veilige ondergrens om Lighthouse te halen). Dit is minder direct rankinggerelateerd en meer een kwestie van bouncegedrag dat terugvoert naar gebruikerssignalen.

Intrusive interstitials: Google heeft een gedocumenteerde demotie-signaal voor pagina’s die bij binnenkomst op mobiel een fullscreen popup tonen voordat de gebruiker de content kan openen. Exit-intent popups, cookie banners die wettelijk vereist zijn en overlays die pas na een paar seconden engagement verschijnen zijn prima. Een fullscreen “subscribe voordat je leest” die afgaat bij het laden van de pagina is dat niet.

De mobile-vs-desktop audit checklist

De referentieversie van de gap-audit. De symptoomkolom is wat je ziet in GSC of analytics; de rest vertelt je hoe je het diagnoseert en oplost.

Mobile keyword- en SERP-verschillen

Mobile SERPs tonen minder organische resultaten boven de vouw, meer entries in de lokale pack en meer “near me”-intentie. Mobile zoekers leunen vaker richting lokale en transactionele queries. Heb je locatiespecifieke pagina’s die op desktop goed scoren maar op mobiel niet converteren? Check dan of een map pack je organische resultaat volledig onder de vouw duwt. Dat is een SERP-lay-outprobleem; de fix is lokale optimalisatie.

Mobile SEO triage in 20 minuten

Op impactvolgorde. Draai deze checks één keer en je weet precies waar je tijd naartoe moet.

1. GSC device gap-audit. Zoekresultaten, device comparison, sorteer op de grootste negatieve mobile delta. Markeer elke query met een gap van 3+ posities en noteer de URLs.
2. PageSpeed Insights op je gap-pagina’s. Laat de gemarkeerde URLs door het mobile-tabblad lopen. Kijk eerst naar CrUX velddata, daarna pas naar labscores. Noteer welke van LCP, INP of CLS faalt.
3. URL Inspection rendered-HTML check. Voor je high-traffic gap-pagina’s, zeker als je een React, Vue of Angular SPA draait: open URL Inspection en bevestig dat de body content aanwezig is in de gerenderde HTML. Ontbreekt die? Fix rendering eerst — snelheid is secundair.
4. Drie mechanische fixes. Controleer dat de viewport meta bestaat, check tap targets in Lighthouse en verifieer dat er geen entry interstitial afgaat op mobiel. Een uur om dit over je site te bevestigen en makkelijk te delegeren.

Het doel is te achterhalen welk probleem je hebt, voordat je tijd steekt in het fixen van het verkeerde. Onze SEO hygiene audit checklist behandelt het bredere technische landschap als je na deze triage nog een vollediger ronde wilt doen.

Mobiele apparaten nemen grofweg de helft van al het wereldwijde webverkeer voor hun rekening — ongeveer 50–52% in StatCounter’s data over mei 2026 (mobile alleen 50,3%, mobile en tablet samen 51,8%). Welke figuur je ook gebruikt: de mobiele versie van je site is het primaire commerciële oppervlak, en dat is de enige versie die Google rangschikt.

Run een gratis SEO-audit om je mobile-vs-desktop gaps te zien en welke mobile issues je rankings kosten.

Veelgestelde vragen

Wat is mobile-first indexing?

Mobile-first indexing betekent dat Google je site crawlt en indexeert met de Googlebot Smartphone-agent, en dat de content van je mobiele pagina wordt gebruikt voor ranking. De uitrol is compleet: sinds juli 2024 geldt dit voor 100% van de geïndexeerde sites. Content die alleen op je desktopversie verschijnt, is onzichtbaar voor Google.

Rangschikt Google mobiel en desktop apart?

Er is één index, opgebouwd uit je mobiele pagina. De SERP-lay-out verschilt per device, dus gemiddelde posities kunnen 1 of 2 plekken schelen. Een grote gap per query (bijvoorbeeld #4 op desktop en #9 op mobiel) wijst meestal op een probleem specifiek met je mobiele pagina.

Hoe check ik mijn mobiele rankings?

Google Search Console → Zoekresultaten → klik “Nieuw” → Device comparison → Mobile vs Desktop, met Average Position. Sorteer op de grootste negatieve mobile delta. Rank trackers die device-segmentatie ondersteunen geven je dit beeld op keyword-niveau, wat handig is om het over tijd te monitoren.

Is snelheid van mobiele pagina’s een rankingfactor?

Ja. Mobile Core Web Vitals (LCP, INP en CLS) voeden de page experience-signalen, en omdat de mobiele pagina de geïndexeerde versie is, beïnvloedt snelheid op mobiel je rankings voor alle zoekers. De throttled-device test die Google gebruikt betekent dat dezelfde pagina vaak slechter scoort op mobiel dan op desktop, ook zonder verschillen in mobile-specifieke code.

Meer lezen:

• Core Web Vitals in 2026: Wat veranderde er en hoe audit je dit
• SPA SEO Best Practices: JavaScript-apps indexeerbaar maken
• SEO Hygiene Audit Checklist: voorkom dat je traffic verliest
• Wat je Lighthouse SEO-score echt meet