← Tous les articles
Cas d'usage 6 min de lecture

Suivi des SERP à l'échelle après num=100

Le suivi des positions Google à l'échelle est devenu plus difficile avec la disparition de num=100. Voici comment les équipes d'ingénierie SEO reconstruisent leur infrastructure de suivi des SERP pour 2026.

serp-monitoringrank-trackingseoweb-scrapinggoogle-search

Le défi

Si votre équipe développe des outils de suivi de positionnement (rank tracking), des tableaux de bord SEO ou des solutions de veille concurrentielle, 2026 a bouleversé votre modèle économique unitaire. Google a discrètement retiré le paramètre d'URL num=100 de Google Search cette année, l'astuce utilisée par tous les scrapers de SERP pour récupérer 100 résultats en une seule requête. Désormais, la même couverture nécessite dix requêtes au lieu d'une seule.

Il s'agit du coût évident. Les coûts cachés sont encore plus problématiques.

Le suivi de positionnement n'est fiable que si vous visualisez la SERP qu'un véritable utilisateur verrait dans le bon pays, la bonne région et la bonne ville. Un mot-clé classé en 4e position à Londres peut se retrouver en 11e position à Édimbourg et en 19e position à Belfast. Packs locaux de 3 résultats, carrousels shopping, blocs d'actualités, panneaux Knowledge Graph, aperçus génératifs (AI Overviews). Chaque composant de la SERP varie selon la géographie et l'appareil. (Scrape.do a mesuré que le texte des AI Overviews apparaissait dans environ 36% des requêtes au début de 2026.) Si votre scraper passe par un proxy situé dans la mauvaise ville, vos données de classement deviennent une fiction présentée avec assurance.

Un produit de scraping de SERP viable en 2026 exige donc la combinaison de trois éléments: une requête qui reproduit un vrai navigateur au niveau réseau, un proxy situé précisément dans la ville ciblée, et la capacité d'exécuter le JavaScript lorsque Google choisit de charger la moitié des résultats côté client. Négligez l'un de ces trois aspects, et la qualité de vos données se dégrade silencieusement.

L'approche FourA

Le véritable goulot d'étranglement dans le scraping de SERP à grande échelle n'est pas la requête. C'est le routage.

La plupart des architectures internes partent d'un pool de proxys fixe et considèrent la requête comme la variable. Avec le ciblage géographique de Google, c'est l'inverse. La requête est une donnée fixe. Le proxy est l'élément que vous devez ajuster avec précision.

Nous avons vu des équipes structurer leur architecture sur FourA selon ce schéma:

  1. Proxy Finder maintient un pool actif de proxys validés par des tests de disponibilité récents et étiquetés avec le pays, la région, la ville et l'ASN. Lorsqu'une requête doit provenir de Manchester, Boston ou São Paulo, Proxy Finder sélectionne un proxy réellement situé sur place et opérationnel lors de la dernière vérification. Cette sélection s'effectue avant la récupération, et non pendant. Pour en savoir plus sur l'importance de cette couche de routage, consultez notre article sur le routage intelligent de proxys.

  2. Single prend en charge la récupération de la SERP elle-même. Pour les résultats organiques standards, le HTML brut suffit amplement. Activez unblocker: true et la requête transmet une signature de navigateur à jour, sans que vous ayez besoin de savoir quelle empreinte Google contrôle cette semaine-là. Nous avons détaillé le comportement réseau de ce paramètre dans notre article sur le Web Unblocker.

  3. Browser gère les SERP dont le contenu critique s'affiche après l'exécution du JavaScript. AI Overviews, packs shopping étendus, contenu des Knowledge Panels, blocs locaux persistants. Même URL, même cible: la requête s'exécute simplement au sein d'une session de navigateur complète et renvoie la page intégralement rendue. (Avec en plus des captures d'écran, bien utiles le jour où un responsable SEO vous demande pourquoi votre tableau de bord indique la 3e position alors qu'il voit la 6e dans son navigateur.)

Un simple appel vers l'API avec routage par proxy:

curl -X POST "https://api.foura.ai/api/proxy" \
  -H "x-api-key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "maxTries": 3,
    "timeout_ms": 20000,
    "request": {
      "method": "GET",
      "url": "https://www.google.co.uk/search?q=plumber+manchester&hl=en-GB",
      "unblocker": true,
      "validate": {
        "status": { "accept": [200] },
        "data": { "fail": ["unusual traffic", "/sorry/", "captcha"] }
      }
    }
  }'

Cela sépare nettement trois responsabilités : le routage proxy géolocalisé (Proxy Finder), la requête elle-même (Single), et le rendu JavaScript lorsque vous en avez besoin (Browser). Votre code n'a pas à gérer la logique d'état des proxys ni à deviner quelle IP est encore active à 3h du matin. C'est le problème de quelqu'un d'autre.

Stockez également chaque réponse indexée par (keyword, location, device, timestamp). C'est la véritable unité de référence pour le suivi des positions. Pas « nous étions positionnés ici pour ce mot-clé aujourd'hui », mais « nous étions positionnés ici pour ce mot-clé, depuis cette ville, sur cet appareil, à cette minute précise ». Sans ce niveau d'attribution, deux jours de données peuvent discrètement se contredire sans que vous puissiez déterminer laquelle est exacte. Les équipes SEO qui surveillent des secteurs protégés y sont déjà confrontées. Nous avons aussi expliqué comment la détection de bots est devenue comportementale, ce qui ajoute un quatrième axe (la continuité de session) pour les sites qui analysent l'enchaînement des requêtes plutôt que des signaux isolés.

Résultats

Un outil de rank tracking surveillant 5 000 mots-clés dans 12 villes, deux fois par jour, représentait environ 120 000 requêtes quotidiennes sous l'ancien modèle num=100. Désormais, on approche des 1,2 million, par simple calcul de pagination (scénario illustratif basé sur les standards de l'industrie).

Les équipes ayant migré cette architecture vers une stack à trois produits constatent généralement :

  • Une réduction de 40 à 60 % du coût par requête par rapport à la gestion de leur propre pool de proxys, principalement parce qu'elles ne paient plus pour le churn de proxys, les IP mortes et le temps d'ingénierie consacré à maintenir la rotation.
  • Une précision géographique à l'échelle de la ville passant d'environ 70 % à plus de 95 %, car Proxy Finder filtre par ville et valide l'état actif lors de la dernière vérification avant de fournir le proxy.
  • Aucun chemin spécifique pour les AI Overviews. Un mot-clé récupéré via Single peut passer sur Browser sans réécrire le pipeline. Le contrat reste identique : URL en entrée, réponse en sortie.

Vous n'avez pas besoin de tout cela pour dix mots-clés sur un ordinateur portable. En revanche, cela devient indispensable dès que le pipeline suit des dizaines de milliers de mots-clés dans plusieurs pays, que vos clients actualisent leur tableau de bord le lundi à 9h, et que les positions doivent être fiables.

À retenir

La difficulté du suivi des SERP ne réside plus dans la requête elle-même depuis longtemps. Elle repose sur le routage. Depuis quelle ville effectuez-vous l'extraction ? Cette IP est-elle active ? Google a-t-il renvoyé la mise en page qu'un internaute réel verrait à cet endroit précis, ou la version épurée servie dès qu'un scraper est détecté ?

Si vous êtes une équipe SEO effectuant du rank tracking sur une stack développée en interne, la question pour 2026 n'est pas de savoir s'il faut scraper Google. Vous le faites déjà. La question est de savoir si votre infrastructure peut continuer à générer des données de positionnement fiables quand les règles changent sans préavis, et combien de ressources d'ingénierie vous êtes prêts à y consacrer pour la maintenir.