← Tous les articles
Cas d'usage 7 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 conçoit des outils de suivi de position, des tableaux de bord SEO ou des outils de veille concurrentielle, l'année 2026 a bouleversé vos coûts unitaires. Google a discrètement retiré le paramètre d'URL num=100 de Google Search cette année, l'astuce que chaque scraper de SERP utilisait pour extraire 100 résultats en une seule request. Désormais, obtenir la même couverture nécessite dix requests au lieu d'une.

C'est le coût évident. Les coûts cachés sont encore plus redoutables.

Le suivi des positions ne fonctionne que si vous voyez 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 position 4 à Londres peut se retrouver en position 11 à Édimbourg et en position 19 à Belfast. Packs locaux de 3, carrousels de shopping, blocs d'actualités, knowledge panels, AI Overviews. Chaque fonctionnalité 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 positionnement ne sont qu'une fiction présentée avec assurance.

Ainsi, un produit de suivi des SERP viable en 2026 nécessite trois éléments fonctionnant de concert : une request qui ressemble à un vrai navigateur au niveau réseau, un proxy situé exactement dans la ville que vous cherchez à cibler, et la capacité de faire du rendering JavaScript lorsque Google décide de charger la moitié des résultats côté client. Manquez l'un de ces trois éléments et vos données se dégraderont sans que vous ne le sachiez.

L'approche FourA

Le goulot d'étranglement du scraping de SERP à l'échelle n'est pas la request. C'est le routing.

La plupart des pipelines développés en interne commencent avec un pool de proxies fixe et traitent la requête comme la variable. Avec le ciblage géographique de Google, c'est l'inverse. La requête est ce que vous avez. Le proxy est ce que vous devez configurer correctement.

Nous avons vu des équipes structurer cela au-dessus de FourA à peu près de cette manière :

  1. Proxy Finder maintient un pool actif de proxies validés par des liveness checks récents et étiquetés par pays, région, ville et ASN. Lorsqu'une request doit provenir de Manchester, Boston ou São Paulo, Proxy Finder en choisit un qui est réellement situé là-bas et qui était actif lors du dernier test. La sélection se fait avant la récupération, pas pendant. Pour en savoir plus sur l'importance de cette couche de routing, consultez notre article sur le Smart Proxy Routing.

  2. Single gère la récupération de la SERP elle-même. Pour les résultats organiques standards, le HTML brut est amplement suffisant. Définissez unblocker: true et la request franchit les barrières anti-bot au niveau du handshake sans que vous ayez besoin de savoir quelle signature Google vérifie cette semaine-là. Nous avons détaillé le fonctionnement de ce paramètre au niveau réseau dans notre article sur le Web Unblocker.

  3. Browser gère les SERP où le contenu critique s'affiche après l'exécution du JavaScript. AI Overviews, packs de shopping étendus, contenu des knowledge panels, packs locaux de 3 persistants. Même URL, même cible, la request s'exécute simplement via une session de navigateur complète et renvoie la page entièrement générée. (Plus des captures d'écran, qui vous sauvent la mise le jour où un responsable SEO vous demande pourquoi votre tableau de bord indique la position 3 alors qu'il voit la position 6 dans son navigateur.)

Un seul appel à l'API avec routing de 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 permet de séparer proprement trois problématiques : la gestion des proxies géociblés (Proxy Finder), la request elle-même (Single) et le rendering JavaScript en cas de besoin (Browser). Votre code n'embarque pas de logique de santé des proxies et ne devine pas quelle IP est encore active à 3 heures du matin. C'est le problème de quelqu'un d'autre.

Et stockez chaque response indexée par (keyword, location, device, timestamp). C'est la véritable unité de vérité pour le suivi des positions. Non pas « nous étions classés ici pour ce mot-clé aujourd'hui », mais « nous étions classé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 et vous n'aurez aucun moyen de savoir laquelle était correcte. Les équipes SEO qui surveillent des secteurs réglementés vivent déjà avec cela. Nous avons également écrit sur la façon dont la détection de bots est devenue comportementale, ce qui ajoute un quatrième axe (la continuité de session) pour les sites qui analysent le séquençage des requests plutôt que les signaux par request.

Résultats

Un outil de suivi de positions surveillant 5 000 mots-clés dans 12 villes, deux fois par jour, représentait environ 120 000 requests par jour sous l'ancien régime num=100. Aujourd'hui, on est plus proche de 1,2 million, par un simple calcul de pagination (scénario illustratif basé sur les standards du secteur).

Les équipes qui ont transposé cette architecture sur une stack de trois produits rapportent généralement :

  • Une réduction de 40 à 60 % du coût par request par rapport à la gestion de leur propre pool de proxies, principalement parce qu'elles ont cessé de payer pour le renouvellement des proxies, les IP mortes et les heures d'ingénierie nécessaires pour maintenir la rotation.
  • Une précision de localisation au niveau de la ville passant d'environ 70 % à plus de 95 %, car Proxy Finder filtre par ville et vérifie la liveness lors du dernier test avant de transmettre le proxy.
  • Pas de traitement spécifique pour les AI Overviews. Un mot-clé récupéré via Single peut être basculé vers Browser sans réécrire le pipeline. Le contrat est identique : URL en entrée, response en sortie.

Vous n'avez pas besoin de tout cela pour dix mots-clés et un ordinateur portable. Mais vous en avez besoin dès que le pipeline surveille des dizaines de milliers de mots-clés à travers plusieurs pays, que vos clients actualisent leur tableau de bord le lundi à 9 heures du matin, et que les classements doivent être réels.

Ce qu'il faut retenir

La partie difficile du suivi des SERP a cessé d'être la request il y a bien longtemps. C'est le routing. Depuis la ville de qui effectuez-vous la récupération ? Cette IP est-elle active ? Google a-t-il renvoyé la mise en page qu'un véritable utilisateur de cet endroit verrait réellement, ou celle, vide, qu'il sert lorsqu'il détecte un scraper ?

Si vous êtes une équipe SEO exécutant le suivi des positions sur une stack que vous avez construite vous-même, 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 à produire des classements fiables lorsque les règles changent sans préavis, et quelle part de votre équipe d'ingénierie vous êtes prêt à consacrer pour qu'il en reste ainsi.