Votre propre outil de suivi des positions au lieu de Topvisor et Serpstat : calcul du coût pour 1000 mots-clés par jour

Les agences SEO et les marketeurs internes se posent tôt ou tard la même question : pourquoi payer pour un abonnement à un tracker de positions, si l'on peut créer son propre parser de résultats ? La réponse n'est pas si simple : le coût de la surveillance autonome ne se compose pas seulement des serveurs, mais aussi des proxies, des captchas et du temps consacré à la maintenance des scripts. Dans cet article, nous examinerons la véritable mathématique à travers l'exemple de la vérification de 1000 phrases clés par jour.

Pourquoi les agences créent leur propre tracker de positions

Les services prêts à l'emploi comme Topvisor, Serpstat, SE Ranking ou Rush Analytics sont pratiques : il n'est pas nécessaire de penser aux proxies, aux captchas et aux serveurs - il suffit d'entrer les mots-clés et d'obtenir un rapport. Mais cette commodité a un prix, qui augmente proportionnellement au nombre de phrases vérifiées et de régions. Si une agence gère 15-20 clients, et que chacun a entre 500 et 2000 mots-clés, la facture d'abonnement atteint rapidement un montant comparable au salaire d'un spécialiste junior.

La deuxième raison est la flexibilité. Dans un service prêt à l'emploi, vous ne pouvez pas modifier la fréquence de vérification pour des mots-clés spécifiques, ajouter une logique personnalisée (par exemple, suivre non seulement la position, mais aussi le snippet, la présence de liens rapides ou d'avis), ou exporter des données brutes vers votre système BI. Un tracker personnel résout ces problèmes, mais nécessite une infrastructure : serveur, base de données, scripts de parsing et, surtout, proxies pour contourner la protection des moteurs de recherche contre les requêtes automatiques.

La troisième raison est le contrôle des données. Les agences qui travaillent avec de grands clients sous NDA ne sont pas toujours prêtes à transmettre la liste des requêtes clés et des domaines à des services cloud tiers. Un tracker personnel permet de tout conserver sur sa propre infrastructure.

De quoi se compose le coût de la vérification des positions

Avant de compter l'argent, il faut comprendre la mécanique : pour connaître la position d'un site pour une requête clé, le parser doit envoyer une requête aux résultats de Yandex ou Google, obtenir la page HTML des résultats et y trouver le domaine souhaité. Pour 1000 mots-clés par jour, cela représente au minimum 1000 requêtes, et si vous vérifiez les deux moteurs de recherche et plusieurs régions, ce chiffre est multiplié par 2 à 4.

Les moteurs de recherche bloquent agressivement les requêtes automatiques provenant d'une seule IP : après 20 à 50 requêtes consécutives depuis une seule adresse, Yandex commence à afficher un captcha, et Google - à bannir temporairement l'IP pendant plusieurs heures. Par conséquent, chaque requête doit passer par un proxy distinct ou souvent changé. C'est ici que se trouve le principal article de dépense - ce n'est pas le serveur ni le script, mais bien l'infrastructure proxy.

La structure complète des coûts est la suivante :

• Proxies pour la rotation IP - principal article de dépense variable, dépend du volume de requêtes
• Serveur ou VPS pour exécuter des scripts selon un calendrier - somme fixe et modeste
• Résolution de captcha (services anti-captcha) - dépense supplémentaire si les proxies ne sont pas de qualité suffisante
• Temps du développeur pour écrire et maintenir le parser - dépense ponctuelle et périodique
• Stockage et visualisation des données - base de données, tableau de bord, généralement des dépenses minimales

Abonnement vs propre tracker : comparaison des articles de dépenses

Pour évaluer quand un tracker personnel est plus avantageux qu'un abonnement, il est utile de comparer directement les articles de dépenses. Ci-dessous se trouve un tableau récapitulatif sans lien avec des tarifs spécifiques, qui montre la logique de choix.

Paramètre	Service prêt à l'emploi (abonnement)	Propre tracker de positions
Coût pour 1000 mots-clés/jour	Augmente proportionnellement au plan tarifaire, somme fixe mensuelle	Se compose du trafic proxy + location de serveur, évolue en douceur
Flexibilité de configuration	Limitée par les fonctionnalités du service	Complète - n'importe quelle fréquence, région, profondeur des résultats
Besoin d'un développeur	Non	Oui, au début et périodiquement pour le support
Risque de bans/captchas	Prend en charge le service	Incombe à vous, résolu par des proxies et des délais
Point de rentabilité	—	Généralement à partir de 3000-5000 mots-clés par jour et plus

La conclusion du tableau est simple : avec un petit volume de mots-clés (jusqu'à 2000-3000 par jour), un abonnement est presque toujours plus avantageux, car les coûts de développement et de maintenance de votre propre solution ne sont pas rentabilisés. Mais avec de grands volumes - à partir de plusieurs milliers de mots-clés par jour, surtout si vous devez les vérifier plusieurs fois par jour ou dans différentes régions - une infrastructure personnelle commence à être plus rentable économiquement.

Calcul des proxies pour 1000 mots-clés par jour

La question principale concernant le coût est de savoir combien de proxies sont nécessaires pour 1000 requêtes par jour sans bans ni captchas. Prenons les limites sécuritaires moyennes, qui sont pratiquement utilisées par les parsers de résultats :

• Yandex : 30-50 requêtes par IP par jour sans risque de captcha avec des délais aléatoires entre les requêtes de 10 à 30 secondes
• Google : 15-25 requêtes par IP par jour, le système bannit plus rapidement et plus sévèrement

Si vous vérifiez 1000 mots-clés uniquement sur Yandex, avec une limite de 40 requêtes par IP, vous aurez besoin d'au moins 25 adresses uniques par jour. En tenant compte des retries en cas de requêtes échouées et d'une marge pour d'éventuels bans temporaires, prévoyez 30-40 IP. Si vous vérifiez les deux moteurs de recherche, le chiffre double - il faudra environ 60-80 IP par jour.

Un point important : lors de l'utilisation d'un pool d'IP avec rotation par requête (et non par session), un même serveur proxy physique peut "fermer" beaucoup plus d'adresses IP si le fournisseur offre une rotation dynamique. Dans ce cas, le calcul se fait non pas en fonction du nombre d'adresses, mais en fonction du volume de trafic - généralement, une vérification de position pèse 50-200 Ko de HTML, donc 1000 requêtes par jour représentent 50-200 Mo de trafic, ce qui n'est pas une charge critique même pour un tarif moyen.

Quels proxies sont nécessaires pour Yandex et Google

Le type de proxy influence directement le nombre de captchas et de bans que vous obtiendrez, et donc le coût réel de la vérification. Analysons trois options.

Proxies de data center - l'option la moins chère en termes de coût de trafic, mais ils ont une mauvaise réputation dans les bases de données des moteurs de recherche : les IP des data centers sont massivement utilisées pour le parsing, donc Yandex et Google les reconnaissent rapidement et affichent des captchas après quelques requêtes. Pour une vérification à faible fréquence d'un petit nombre de mots-clés, les proxies de data center peuvent encore être utilisés, mais à un volume de 1000+ requêtes par jour, la part de captchas devient trop élevée, et les économies sur le trafic sont mangées par les coûts des services anti-captcha.

Proxies résidentiels - adresses IP de véritables utilisateurs domestiques, que les moteurs de recherche perçoivent comme un trafic normal. La part de captchas est beaucoup plus faible ici, ce qui est critique pour de grands volumes de vérification. Pour le parsing des résultats sur 1000 mots-clés ou plus par jour, les proxies résidentiels offrent généralement le meilleur rapport coût/stabilité, surtout lors du travail avec Google, qui bannit le plus sévèrement les adresses des data centers.

Proxies mobiles - utilisent des IP des opérateurs mobiles, qui changent souvent chez des milliers de véritables abonnés (NAT), donc une même adresse peut "appartenir" à différents utilisateurs au cours de la journée. Cela offre une durabilité maximale lors du parsing agressif, mais coûte plus cher. Les proxies mobiles sont justifiés si vous vérifiez les positions dans les résultats mobiles séparément de ceux de bureau ou si vous travaillez avec des requêtes régionales particulièrement capricieuses de Yandex.

Type de proxy	Part de captcha pour 1000 requêtes	Quand utiliser
Data center	Élevée	Jusqu'à 200-300 mots-clés par jour, faible fréquence
Résidentiels	Faible	1000+ mots-clés par jour, Google et Yandex
Mobiles	Minimale	Résultats mobiles, régions complexes

Configuration étape par étape de votre propre tracker

Analysons le processus de construction de votre tracker de positions étape par étape - sans plonger profondément dans le code, au niveau de l'architecture de la solution.

1. Choix de la source de données. Déterminez si vous parsez directement les résultats du moteur de recherche via des requêtes HTTP ou si vous utilisez un navigateur sans tête (par exemple, via Puppeteer/Playwright) pour simuler un utilisateur réel. La deuxième option est plus fiable contre la protection anti-bot, mais plus lente et coûteuse en ressources serveur.
2. Configuration du pool de proxies. Connectez un fournisseur de proxies avec rotation IP par requête ou par temps. Pour Yandex et Google, il est préférable d'utiliser différents pools de proxies, car les systèmes ont des seuils de blocage différents.
3. Logique des retries. Si une requête renvoie un captcha ou une erreur, le script doit automatiquement changer d'IP et répéter la requête, et non simplement enregistrer l'erreur.
4. Parsing du résultat. La position du domaine souhaité dans les résultats est extraite du HTML obtenu - généralement par recherche dans les balises de liens et comparaison avec le domaine du client.
5. Stockage de l'historique. Les résultats sont enregistrés dans une base de données avec la date de vérification, afin de pouvoir construire des graphiques de la dynamique des positions.
6. Planification de l'exécution. Le script est exécuté par cron ou un planificateur de tâches une fois par jour (ou plus souvent), répartissant uniformément 1000 requêtes dans le temps, afin de ne pas créer de charge de pointe sur le pool de proxies.

Exemple de code pour vérifier les positions en Python

Ci-dessous se trouve un exemple simplifié de la logique de requête aux résultats de recherche via un proxy avec rotation. C'est une structure démonstrative qui montre le principe de fonctionnement, et non une solution prête à l'emploi.

import requests
import random
import time

PROXY_LIST = [
    "http://user:[email protected]:8000",
    "http://user:[email protected]:8000",
    # ... pool de proxies de centaines d'adresses
]

HEADERS = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
}

def check_position(keyword, domain, search_engine="yandex"):
    proxy = random.choice(PROXY_LIST)
    proxies = {"http": proxy, "https": proxy}

    if search_engine == "yandex":
        url = f"https://yandex.ru/search/?text={keyword}"
    else:
        url = f"https://www.google.com/search?q={keyword}"

    try:
        response = requests.get(url, headers=HEADERS, proxies=proxies, timeout=10)
        if "captcha" in response.text.lower():
            return None  # rotation IP nécessaire et répétition de la requête
        position = find_domain_position(response.text, domain)
        return position
    except requests.RequestException:
        return None

def find_domain_position(html, domain):
    # logique simplifiée pour trouver la position d'un domaine dans les résultats
    results = extract_links(html)
    for i, link in enumerate(results, start=1):
        if domain in link:
            return i
    return None

for keyword in keyword_list:
    pos = check_position(keyword, "example.com")
    save_to_db(keyword, pos)
    time.sleep(random.uniform(5, 15))  # délai aléatoire entre les requêtes
  

Dans un projet réel, au lieu du parsing manuel du HTML, on utilise souvent un navigateur sans tête avec substitution de User-Agent et fingerprint, et le pool de proxies est connecté via un fournisseur avec rotation automatique au niveau de l'endpoint - cela élimine la nécessité de conserver manuellement une liste d'adresses et facilite l'évolutivité à plusieurs milliers de requêtes par jour.

Combien peut-on réellement économiser

Pour répondre à la question de l'économie, il faut comparer deux modèles de dépenses dans le temps à mesure que le volume de mots-clés augmente.

Avec un petit volume - jusqu'à 1000-2000 mots-clés par jour - le coût d'un abonnement à un tracker prêt à l'emploi est généralement comparable, voire inférieur aux coûts cumulés de développement et de maintenance de votre propre solution, si l'on tient compte du temps du spécialiste. Le développement d'un parser minimalement viable à partir de zéro prend de quelques jours à quelques semaines, plus un support périodique lors des changements de mise en page des résultats de recherche - et Yandex et Google changent souvent la mise en forme des résultats.

Le point de basculement se produit lorsque le volume de vérification augmente à plusieurs milliers de mots-clés par jour ou qu'il est nécessaire de vérifier les positions plusieurs fois par jour, dans différentes régions et sur différents appareils (bureau/mobile). Dans ce scénario, le coût d'un abonnement prêt à l'emploi augmente de manière linéaire ou même progressive avec le volume, tandis que les dépenses pour votre propre tracker augmentent beaucoup plus lentement - le principal article (trafic proxy) ne devient pas aussi cher que les plans tarifaires des services SaaS lors du passage au niveau supérieur du forfait.

Un repère pratique pour les agences : si vous suivez les positions de 5 à 10 clients ou plus simultanément, le volume total dépasse généralement 5000-10000 phrases clés par jour - c'est à cette échelle qu'un tracker personnel est presque toujours plus avantageux qu'un abonnement prêt à l'emploi, à condition qu'il y ait quelqu'un dans l'équipe capable de maintenir le parser.

Erreurs fréquentes lors du parsing autonome

Dans la pratique, la plupart des problèmes avec son propre tracker de positions sont liés non pas au code, mais à une sous-estimation des nuances infrastructurelles.

• Économie sur les proxies. Essayer d'économiser sur des proxies de data center bon marché entraîne des captchas massifs, qui doivent être résolus via des services anti-captcha tiers - au final, les dépenses totales s'avèrent plus élevées que si l'on avait utilisé des proxies de meilleure qualité dès le départ.
• Absence de délais entre les requêtes. Des requêtes consécutives trop rapides depuis une seule IP attirent immédiatement l'attention des systèmes anti-bot, même si l'IP est de qualité.
• Ignorer la régionalité. Yandex affiche des résultats différents selon la région de l'utilisateur - sans une bonne géolocalisation des proxies, les données sur les positions seront incorrectes.
• Absence de surveillance de la santé du parser. Les moteurs de recherche changent périodiquement la mise en page de la page de résultats, et sans alertes sur la chute du succès du parsing, on peut collecter des données vides ou incorrectes pendant des semaines sans s'en rendre compte.
• Ignorer les résultats mobiles. Les résultats de bureau et mobiles diffèrent souvent, et si la position mobile est importante pour le client, un contour de parsing séparé avec des User-Agent appropriés et, de préférence, des IP mobiles est nécessaire.

Conclusion

Un tracker de positions personnel devient économiquement justifié lorsque le volume de vérification dépasse plusieurs milliers de mots-clés par jour, et qu'il y a des ressources dans l'équipe pour maintenir le parser. À des volumes plus faibles, un abonnement prêt à l'emploi est presque toujours moins cher en tenant compte des coûts cachés de développement. La principale variable dans le coût de votre solution n'est pas le serveur ni le code, mais l'infrastructure proxy, qui détermine la part de captcha et la stabilité des données.

Si vous envisagez de créer un tracker de positions pour 1000 mots-clés ou plus par jour, commencez par calculer le trafic et tester un pool de proxies sur un petit échantillon de requêtes. Pour un parsing stable de Yandex et Google à de tels volumes, il est raisonnable de prévoir dès le départ des proxies résidentiels - ils offrent une part minimale de captcha à un coût de trafic acceptable et se scalent bien avec l'augmentation du nombre de clients suivis.