Hoe SERP Scraping Echt Werkt in 2026 (Nadat Google num=100 Verwijderde en JavaScript Vereiste)
Twee stille veranderingen — verplichte JavaScript en het einde van de num=100 parameter — herschreven de economie van zoekopdrachten scrapen. Hier is wat er daadwerkelijk veranderde, waarom je rank tracker kapot ging, en hoe je in 2026 betrouwbaar SERP-gegevens kunt verzamelen.
Als je rank tracker plotseling stil viel eind 2025, of je zelfgemaakte Google scraper lege pagina's begon terug te geven, dan verbeeldde je het je niet. In een tijdsbestek van negen maanden maakte Google twee veranderingen die, afzonderlijk, leken op kleine huishoudelijke taken en, samen, stilletjes de economie van zoekopdrachten scrapen herschreven. Dit is een praktische gids voor wat er daadwerkelijk veranderde, waarom het zoveel tools tegelijk brak, en hoe je in 2026 betrouwbaar SERP-gegevens kunt verzamelen zonder je infrastructuur — of je IP's — te verbranden.
Verandering één: Google maakte JavaScript verplicht
Op 17 januari 2025 begon Google met het vereisen van JavaScript om Google Search te gebruiken. Zet het uit en je krijgt een kort bericht — "Zet JavaScript aan om verder te zoeken" — in plaats van resultaten. Een woordvoerder van het bedrijf vertelde TechCrunch dat het doel was om "onze diensten en gebruikers beter te beschermen tegen bots en zich ontwikkelende vormen van misbruik en spam," en bevestigde dat minder dan 0,1% van de zoekopdrachten afkomstig is van gebruikers met JavaScript uitgeschakeld.
Dat cijfer van 0,1% is veelzeggend. Bij ongeveer 8,5 miljard zoekopdrachten per dag is een tiende van een procent nog steeds miljoenen verzoeken — en een onevenredig deel daarvan waren nooit mensen. Het waren rank trackers, SEO crawlers, en goedkope scrapers die de lichte, geen-JavaScript versie van de resultatenpagina opzochten. Search Engine Journal bevestigde de lezing direct: Google vereist JavaScript om bots en scrapers te blokkeren, inclusief SEO-tools.
Het inschakelen van JavaScript stelt ons in staat om onze diensten en gebruikers beter te beschermen tegen bots en zich ontwikkelende vormen van misbruik en spam, en om de meest relevante en actuele informatie te bieden.
Het praktische gevolg: het tijdperk van het parsen van Google door een URL op te halen en een regex over statische HTML te draaien is voorbij. De resultaten worden nu client-side samengesteld. Als je scraper geen JavaScript kan uitvoeren, ziet het geen gedegradeerde pagina — het ziet helemaal geen pagina.
Verandering twee: het einde van num=100
De tweede verandering was kleiner in verschijning en groter in impact. Rond 11 september 2025 schakelde Google de &num=100 URL parameter uit — het kleine vlaggetje dat Search vertelde om 100 resultaten op één pagina terug te geven in plaats van de standaard 10. Tien jaar lang was het de ruggengraat van diep rank tracking: één verzoek, honderd posities.
Toen het verdween, keerde de wiskunde van de ene op de andere dag om. Om de top 100 resultaten te zien heb je nu tot tien gepagineerde verzoeken nodig in plaats van één. Keyword Insights zette de kosten op de dag zelf botweg uiteen.
Google heeft de n=100 SERP parameter verwijderd. In plaats van 1 verzoek voor 100 SERP resultaten, zijn nu 10 verzoeken nodig (10x de kosten). Dit beïnvloedt onze rankingsmodule. We bekijken opties en zullen het platform binnenkort bijwerken.
De rimpel trof ook Google Search Console. Vanaf ongeveer 10 september zagen SEO-teams dat desktopvertoningen sterk daalden terwijl de gemiddelde positie leek te verbeteren. Analist Brodie Clark's theorie — veel besproken maar nooit bevestigd door Google — is dat een groot deel van die eerdere vertoningen nooit menselijk waren: het waren bots die 100-resultaten pagina's laadden via num=100, elk registreerde tien keer de vertoningen van een normale pagina. Verwijder de parameter, en de fantoomvertoningen verdwijnen ermee. Het is een gemeenschapsinterpretatie, geen officiële uitleg, maar het past precies bij de timing.
Waarom dit zoveel tools tegelijk brak
De meeste SERP-tools waren gebouwd op twee aannames die jarenlang beide waar waren en nu beide onwaar zijn: dat Google bruikbare HTML zou serveren zonder JavaScript, en dat je 100 resultaten per verzoek kon ophalen. Verwijder beide in hetzelfde jaar en de faalmodi stapelen zich op:
- Statische fetchers geven lege of challenge-pagina's terug in plaats van resultaten.
- Op paginering gebaseerde verzamelaars hebben 10x het aantal verzoeken nodig voor dezelfde dekking, wat betekent 10x de proxybandbreedte en 10x het blokoppervlak.
- Meer verzoeken vanuit dezelfde IP-bereiken activeren anti-botsystemen sneller, dus de succespercentages dalen precies wanneer het volume moet stijgen.
- Search Console baselines verschoven, dus historische dashboards vergelijken niet langer gelijkwaardig.
Zoals SEO-ingenieur Ryan Jones het verwoordde, is de agressieve scraping-golf — waarvan nu veel AI-producten voedt — precies wat Google ertoe bracht om terug te vechten, waardoor rank checkers en SERP scrapers als bijvangst werden gebroken. De tools faalden niet omdat ze slecht geschreven waren. Ze faalden omdat de grond bewoog.
Hoe betrouwbaar SERP scraping eruitziet in 2026
De nieuwe basislijn heeft drie niet-onderhandelbare elementen. Mis er één en je succespercentage stort in onder belasting.
1. Voer JavaScript uit — maar alleen wanneer het moet
Omdat resultaten client-side worden samengesteld, heb je een client nodig die JavaScript uitvoert voor de pagina's die het vereisen. Maar voor elke aanvraag een headless browser opstarten is traag en duur. Het efficiënte patroon is om eerst een lichte, echte TLS-vingerafdruk fetch te proberen en op te schalen naar een volledige browserweergave alleen wanneer de pagina je daadwerkelijk uitdaagt. De meeste verzoeken hebben de browser nooit nodig; de verzoeken die dat wel doen krijgen het automatisch.
2. Roteer residentiële exits met echte browser-vingerafdrukken
Datacenter IP's en standaard HTTP-client vingerafdrukken zijn de snelste weg naar een CAPTCHA. Verzoeken moeten afkomstig zijn van residentiële IP's, met de TLS en header vingerafdruk van een echte browser zoals Chrome. Wanneer één exit wordt gemarkeerd, zorgt rotatie naar een nieuwe meestal voor het opheffen van de blokkade zonder enige wijziging aan het verzoek zelf — wat precies is hoe een veerkrachtige verzamelaar herstelt van een "ongebruikelijke verkeers" pagina in plaats van erop te sterven.
3. Parseer naar gestructureerde data, niet naar ruwe HTML
De markup van Google verandert voortdurend, en post-num=100 is de lay-out meer gefragmenteerd, niet minder. Het onderhouden van je eigen selectors tegen een bewegend doelwit is een fulltime baan. Een gestructureerd SERP endpoint dat schone JSON retourneert — organische resultaten, advertenties, winkelen, kennispanelen, Mensen Vragen Ook, AI Overzichten — isoleert je pijplijn van elke cosmetische verandering aan de kant van Google.
Het patroon in de praktijk
In plaats van zelf browsers, proxypools en parsers te onderhouden, geef je een query aan een endpoint dat alle drie doet en schone gestructureerde resultaten retourneert. Met de QuantumProxies SERP API handelt een enkele geauthenticeerde aanvraag JavaScript-uitvoering, residentiële rotatie en parsing voor je af:
curl --location --request GET \
"https://app.quantumproxies.io/api/v1/serp/google/search?q=best+running+shoes&cc=us" \
--header "Authorization: Bearer YOUR_API_KEY"De respons is JSON, niet HTML — organische resultaten met posities, advertenties, winkelunits, het kennisgrafiek, Mensen Vragen Ook, en AI Overzichten waar aanwezig. Geen headless browser om op te passen, geen selector om te repareren wanneer Google de pagina herschikt, en paginering afgehandeld zodat je niet handmatig opnieuw opbouwt wat num=100 je vroeger gratis gaf. Wanneer één exit een anti-bot pagina activeert, probeert de service automatisch opnieuw op een nieuwe residentiële IP — hetzelfde roteer-om-te-herstellen gedrag dat een pijplijn levend houdt onder echte belasting.
Als je liever de volledige vorm van verzoek en respons wilt zien voordat je code schrijft, laten de interactieve SERP API-documenten op https://quantumproxies.io/serp-api/docs je een live query uitvoeren en kant-en-klare snippets kopiëren voor cURL, Python, JavaScript, PHP, Go, en Ruby.
De conclusie
SERP scraping werd niet op een vage, incrementele manier moeilijker — het veranderde twee keer van vorm in één jaar. JavaScript is nu verplicht, dus je hebt een echte client nodig. num=100 is weg, dus diepe dekking kost een orde van grootte meer in verzoeken, wat betekent dat de kwaliteit van je proxylayer en de intelligentie van je escalatielogica nu belangrijker zijn dan het ruwe aanvraagvolume ooit was. De teams die in 2026 nog steeds schone SERP-gegevens op schaal verzamelen, zijn niet degenen die meer verzoeken sturen. Het zijn degenen die slimmere verzoeken sturen — JavaScript-capabel, residentieel-vingerafgedrukt, en gestructureerd vanaf de eerste byte.