Comment fonctionne réellement le scraping SERP en 2026 (après que Google a supprimé num=100 et rendu JavaScript obligatoire)
Deux changements discrets — JavaScript obligatoire et la disparition du paramètre num=100 — ont réécrit l'économie du scraping de recherche. Voici ce qui a réellement changé, pourquoi votre outil de suivi de position a cessé de fonctionner, et comment collecter des données SERP de manière fiable en 2026.
Si votre outil de suivi de position est soudainement devenu silencieux fin 2025, ou si votre scraper Google maison a commencé à renvoyer des pages vides, vous ne rêviez pas. En l'espace de neuf mois, Google a effectué deux changements qui, individuellement, semblaient être de simples tâches d'entretien mais qui, ensemble, ont discrètement réécrit l'économie du scraping de recherche. Ceci est un guide pratique sur ce qui a réellement changé, pourquoi cela a cassé tant d'outils en même temps, et comment collecter des données SERP de manière fiable en 2026 sans brûler votre infrastructure — ou vos IPs.
Changement un : Google a rendu JavaScript obligatoire
Le 17 janvier 2025, Google a commencé à exiger JavaScript pour utiliser Google Search. Désactivez-le et vous recevez un court message — "Activez JavaScript pour continuer à rechercher" — au lieu de résultats. Un porte-parole de l'entreprise a déclaré à TechCrunch que l'objectif était de "mieux protéger nos services et utilisateurs contre les bots et les formes évolutives d'abus et de spam," et a confirmé que moins de 0,1 % des recherches proviennent d'utilisateurs avec JavaScript désactivé.
Ce chiffre de 0,1 % est révélateur. Avec environ 8,5 milliards de recherches par jour, un dixième de pour cent représente encore des millions de requêtes — et une part disproportionnée d'entre elles n'étaient jamais des humains. C'étaient des outils de suivi de position, des crawlers SEO, et des scrapers bon marché frappant la version légère, sans JavaScript, de la page de résultats. Search Engine Journal a confirmé la lecture directe : Google exige JavaScript pour bloquer les bots et scrapers, y compris les outils SEO.
Activer JavaScript nous permet de mieux protéger nos services et utilisateurs contre les bots et les formes évolutives d'abus et de spam, et de fournir l'information la plus pertinente et à jour.
La conséquence pratique : l'ère de l'analyse de Google en récupérant une URL et en exécutant une regex sur du HTML statique est terminée. Les résultats sont désormais assemblés côté client. Si votre scraper ne peut pas exécuter JavaScript, il ne voit pas une page dégradée — il ne voit aucune page.
Changement deux : la mort de num=100
Le deuxième changement était plus petit en apparence et plus grand en impact. Vers le 11 septembre 2025, Google a désactivé le paramètre d'URL &num=100 — le petit drapeau qui disait à Search de retourner 100 résultats sur une seule page au lieu des 10 par défaut. Pendant une décennie, c'était l'épine dorsale du suivi de position en profondeur : une requête, cent positions.
Quand il a disparu, les calculs se sont inversés du jour au lendemain. Pour voir les 100 premiers résultats, vous avez maintenant besoin de jusqu'à dix requêtes paginées au lieu d'une. Keyword Insights a exprimé le coût sans détour le jour où cela s'est produit.
Google a supprimé le paramètre n=100 du SERP. Au lieu de 1 requête pour 100 résultats SERP, il en faut maintenant 10 (10x le coût). Cela impacte notre module de classement. Nous examinons les options et mettrons bientôt à jour la plateforme.
La répercussion a également touché Google Search Console. À partir du 10 septembre environ, les équipes SEO ont vu les impressions sur desktop chuter fortement tandis que la position moyenne semblait s'améliorer. La théorie de l'analyste Brodie Clark — largement discutée mais jamais confirmée par Google — est qu'une grande partie de ces impressions antérieures n'étaient jamais humaines : c'étaient des bots chargeant des pages de 100 résultats via num=100, chacune enregistrant dix fois les impressions qu'une page normale ferait. Retirez le paramètre, et les impressions fantômes disparaissent avec lui. C'est une interprétation communautaire, pas une explication officielle, mais elle correspond exactement au timing.
Pourquoi cela a cassé tant d'outils en même temps
La plupart des outils SERP étaient construits sur deux hypothèses qui étaient vraies pendant des années et sont toutes deux fausses maintenant : que Google servirait du HTML utilisable sans JavaScript, et que vous pourriez récupérer 100 résultats par requête. Retirez les deux la même année et les modes de défaillance s'empilent :
- Les récupérateurs statiques renvoient des pages vides ou de défi au lieu de résultats.
- Les collecteurs basés sur la pagination ont besoin de 10x le volume de requêtes pour la même couverture, ce qui signifie 10x la bande passante proxy et 10x la surface de blocage.
- Plus de requêtes provenant des mêmes plages IP déclenchent plus rapidement les systèmes anti-bot, donc les taux de succès chutent exactement au moment où le volume doit augmenter.
- Les bases de référence de Search Console ont changé, donc les tableaux de bord historiques ne comparent plus de manière équivalente.
Comme l'a formulé l'ingénieur SEO Ryan Jones, la vague de scraping agressif — dont une grande partie alimente maintenant les produits d'IA — est précisément ce qui a poussé Google à riposter, cassant les vérificateurs de position et les scrapers SERP en tant que dommages collatéraux. Les outils n'ont pas échoué parce qu'ils étaient mal écrits. Ils ont échoué parce que le terrain a bougé.
À quoi ressemble un scraping SERP fiable en 2026
La nouvelle base a trois incontournables. Manquez-en un et votre taux de succès s'effondre sous la charge.
1. Exécutez JavaScript — mais seulement quand c'est nécessaire
Parce que les résultats sont assemblés côté client, vous avez besoin d'un client qui exécute JavaScript pour les pages qui l'exigent. Mais lancer un navigateur sans tête pour chaque requête est lent et coûteux. Le schéma efficace est d'essayer d'abord une récupération légère avec une vraie empreinte TLS et d'escalader vers un rendu complet du navigateur uniquement lorsque la page vous défie réellement. La plupart des requêtes n'ont jamais besoin du navigateur ; celles qui le font l'obtiennent automatiquement.
2. Faites tourner les sorties résidentielles avec de vraies empreintes de navigateur
Les IPs de datacenter et les empreintes par défaut des clients HTTP sont le moyen le plus rapide d'obtenir un CAPTCHA. Les requêtes doivent provenir d'IPs résidentielles, portant l'empreinte TLS et d'en-tête d'un vrai navigateur comme Chrome. Lorsqu'une sortie est signalée, la rotation vers une nouvelle efface généralement le blocage sans aucun changement à la requête elle-même — ce qui est exactement comment un collecteur résilient se remet d'une page de "trafic inhabituel" au lieu de mourir dessus.
3. Analysez en données structurées, pas en HTML brut
Le balisage de Google change constamment, et après num=100, la mise en page est plus fragmentée, pas moins. Maintenir vos propres sélecteurs contre une cible mouvante est un travail à plein temps. Un point de terminaison SERP structuré qui renvoie du JSON propre — résultats organiques, publicités, shopping, panneaux de connaissances, People Also Ask, AI Overviews — isole votre pipeline de chaque changement cosmétique du côté de Google.
Le schéma en pratique
Au lieu de maintenir vous-même des navigateurs, des pools de proxies et des analyseurs, vous confiez une requête à un point de terminaison qui fait les trois et renvoie des résultats structurés propres. Avec l'API SERP de QuantumProxies, une seule requête authentifiée gère l'exécution de JavaScript, la rotation résidentielle et l'analyse pour vous :
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"La réponse est en JSON, pas en HTML — résultats organiques avec positions, publicités, unités de shopping, le graphe de connaissances, People Also Ask, et AI Overviews là où présents. Pas de navigateur sans tête à surveiller, pas de sélecteur à réparer lorsque Google réorganise la page, et la pagination est gérée pour que vous ne reconstruisiez pas manuellement ce que num=100 vous donnait gratuitement. Lorsqu'une sortie déclenche une page anti-bot, le service réessaie automatiquement sur une nouvelle IP résidentielle — le même comportement de rotation pour récupérer qui maintient un pipeline en vie sous une vraie charge.
Si vous préférez voir la forme complète de la requête et de la réponse avant d'écrire du code, les documents interactifs de l'API SERP à https://quantumproxies.io/serp-api/docs vous permettent de lancer une requête en direct et de copier des extraits prêts à l'emploi pour cURL, Python, JavaScript, PHP, Go, et Ruby.
La conclusion
Le scraping SERP n'est pas devenu plus difficile de manière vague et incrémentale — il a changé de forme deux fois en un an. JavaScript est maintenant obligatoire, donc vous avez besoin d'un vrai client. num=100 est parti, donc une couverture en profondeur coûte un ordre de grandeur de plus en requêtes, ce qui signifie que la qualité de votre couche de proxy et l'intelligence de votre logique d'escalade comptent maintenant plus que le volume brut de requêtes. Les équipes qui collectent encore des données SERP propres à grande échelle en 2026 ne sont pas celles qui envoient plus de requêtes. Ce sont celles qui envoient des requêtes plus intelligentes — capables de JavaScript, avec des empreintes résidentielles, et structurées dès le premier octet.