Il tuo tracker di posizioni invece di Topvisor e Serpstat: calcolo del costo per 1000 parole chiave al giorno

Le agenzie SEO e i marketer interni prima o poi si pongono la stessa domanda: perché pagare un abbonamento per un tracker di posizioni se si può costruire un proprio parser dei risultati? La risposta non è così semplice come sembra: il costo del monitoraggio autonomo è composto non solo dai server, ma anche dai proxy, dai captcha e dal tempo necessario per mantenere gli script. In questo articolo analizzeremo la matematica reale prendendo come esempio il controllo di 1000 frasi chiave al giorno.

Perché le agenzie creano il proprio tracker di posizioni

I servizi pronti come Topvisor, Serpstat, SE Ranking o Rush Analytics sono comodi: non è necessario pensare a proxy, captcha e server — basta inserire le parole chiave e ricevere il report. Ma questa comodità ha un prezzo, che cresce proporzionalmente al numero di frasi controllate e regioni. Se un'agenzia gestisce 15-20 clienti, e ognuno ha da 500 a 2000 parole chiave, il conto per l'abbonamento raggiunge rapidamente una cifra comparabile con lo stipendio di un junior.

La seconda ragione è la flessibilità. In un servizio pronto non puoi modificare la frequenza di controllo per singole parole chiave, aggiungere logica personalizzata (ad esempio, monitorare non solo la posizione, ma anche il snippet, la presenza di link rapidi o recensioni), esportare dati grezzi nel tuo sistema BI. Un tracker proprio risolve questi problemi, ma richiede un'infrastruttura: server, database, script di parsing e, soprattutto, proxy per aggirare la protezione dei motori di ricerca contro le richieste automatiche.

La terza ragione è il controllo sui dati. Le agenzie che lavorano con grandi clienti sotto NDA non sono sempre pronte a trasferire l'elenco delle parole chiave e dei domini a servizi cloud di terze parti. Un tracker proprio consente di mantenere tutto sulla propria infrastruttura.

Da cosa è composto il costo del controllo delle posizioni

Prima di calcolare i costi, è necessario comprendere la meccanica: per conoscere la posizione di un sito per una parola chiave, il parser deve inviare una richiesta ai risultati di Yandex o Google, ricevere la pagina HTML dei risultati e trovare al suo interno il dominio desiderato. Per 1000 parole chiave al giorno, questo significa almeno 1000 richieste, e se controlli entrambi i motori di ricerca e diverse regioni, il numero si moltiplica da 2 a 4 volte.

I motori di ricerca bloccano aggressivamente le richieste automatiche da un singolo IP: dopo 20-50 richieste consecutive da un indirizzo, Yandex inizia a mostrare captcha, mentre Google blocca temporaneamente l'IP per alcune ore. Pertanto, ogni richiesta deve passare attraverso un proxy separato o frequentemente cambiato. Da qui nasce la principale voce di spesa: non il server e non lo script, ma proprio l'infrastruttura proxy.

La struttura completa dei costi è la seguente:

• Proxy per la rotazione degli IP — la principale voce di spesa variabile, dipende dal volume delle richieste
• Server o VPS per l'esecuzione degli script secondo un programma — una piccola somma fissa
• Soluzione captcha (servizi anti-captcha) — una voce aggiuntiva, se i proxy non sono di qualità sufficiente
• Tempo dello sviluppatore per scrivere e mantenere il parser — spesa una tantum e periodica
• Archiviazione e visualizzazione dei dati — database, dashboard, generalmente spese minime

Abbonamento vs proprio tracker: confronto delle voci di spesa

Per valutare quando il proprio tracker è più vantaggioso dell'abbonamento, è utile confrontare direttamente le voci di spesa. Di seguito è riportata una tabella riassuntiva senza riferimento a tariffe specifiche, che mostra la logica della scelta.

Parametro	Servizio pronto (abbonamento)	Proprio tracker di posizioni
Costo per 1000 parole chiave/giorno	Cresce proporzionalmente al piano tariffario, somma fissa mensile	Composto dal traffico dei proxy + affitto del server, scalabile dolcemente
Flessibilità di configurazione	Limitata dalle funzionalità del servizio	Completa — qualsiasi frequenza, regione, profondità dei risultati
Necessità di uno sviluppatore	No	Sì, all'inizio e periodicamente per il supporto
Rischio di ban/captcha	A carico del servizio	A carico tuo, risolvibile con proxy e ritardi
Punto di pareggio	—	Di solito da 3000 a 5000 parole chiave al giorno e oltre

La conclusione dalla tabella è semplice: con un volume ridotto di parole chiave (fino a 2000-3000 al giorno) l'abbonamento è quasi sempre più vantaggioso, poiché i costi di sviluppo e supporto della propria soluzione non si ripagano. Ma con volumi maggiori — da alcune migliaia di parole chiave al giorno, specialmente se è necessario controllarle più volte al giorno o in diverse regioni — l'infrastruttura propria inizia a vincere in termini di economia.

Calcolo dei proxy per 1000 parole chiave al giorno

La domanda principale sul costo è: quanti proxy servono per 1000 richieste al giorno senza ban e captcha. Prendiamo i limiti medi sicuri che i parser di risultati utilizzano nella pratica:

• Yandex: 30-50 richieste da un IP al giorno senza rischio di captcha con ritardi casuali tra le richieste di 10-30 secondi
• Google: 15-25 richieste da un IP al giorno, il sistema blocca più severamente e rapidamente

Se controlli 1000 parole chiave solo su Yandex, con un limite di 40 richieste per IP hai bisogno di almeno 25 indirizzi unici al giorno. Tenendo conto dei retry in caso di richieste non riuscite e di un margine per eventuali ban temporanei, prevedi 30-40 IP. Se controlli entrambi i motori di ricerca, il numero raddoppia: saranno necessari circa 60-80 IP al giorno.

Un aspetto importante: quando si lavora attraverso un pool di IP con rotazione per richiesta (e non per sessione), lo stesso server proxy fisico può "chiudere" molti più indirizzi IP se il provider offre rotazione dinamica. In questo caso, il calcolo si basa non sul numero di indirizzi, ma sul volume di traffico: di solito un controllo di posizione pesa 50-200 KB di HTML, quindi 1000 richieste al giorno corrispondono a 50-200 MB di traffico, un carico non critico anche per una tariffa media.

Quali proxy servono per Yandex e Google

Il tipo di proxy influisce direttamente su quanti captcha e ban riceverai, e quindi sul costo reale del controllo. Analizziamo tre opzioni.

Proxy dei data center — l'opzione più economica in termini di costo del traffico, ma hanno una cattiva reputazione nelle banche dati dei motori di ricerca: gli IP dei data center sono ampiamente utilizzati per il parsing, quindi Yandex e Google li riconoscono rapidamente e mostrano captcha già dopo alcune richieste. Per il controllo a bassa frequenza di un numero ridotto di parole chiave i proxy dei data center possono ancora essere utilizzati, ma a un volume di 1000+ richieste al giorno la quota di captcha diventa troppo alta e il risparmio sul traffico viene eroso dai costi dell'anti-captcha.

Proxy residenziali — indirizzi IP di utenti domestici reali, che i motori di ricerca percepiscono come traffico normale. La quota di captcha qui è di gran lunga inferiore, il che è critico per grandi volumi di controllo. Per il parsing dei risultati su 1000 e più parole chiave al giorno, i proxy residenziali offrono generalmente il miglior rapporto costo-stabilità, soprattutto quando si lavora con Google, che blocca più severamente gli indirizzi dei data center.

Proxy mobili — utilizzano IP di operatori mobili, che cambiano frequentemente tra migliaia di abbonati reali (NAT), quindi lo stesso indirizzo può "appartenere" a diversi utenti nel corso della giornata. Questo offre la massima longevità durante il parsing aggressivo, ma costa di più. I proxy mobili sono giustificati se controlli le posizioni nei risultati mobili separatamente da quelli desktop o lavori con richieste regionali particolarmente capricciose di Yandex.

Tipo di proxy	Quota di captcha su 1000 richieste	Quando utilizzare
Data center	Alta	Fino a 200-300 parole chiave al giorno, bassa frequenza
Residenziali	Bassa	1000+ parole chiave al giorno, Google e Yandex
Mobili	Minima	Risultati mobili, regioni complesse

Impostazione passo-passo del proprio tracker

Analizziamo il processo di costruzione del proprio tracker di posizioni passo dopo passo — senza un'immersione profonda nel codice, a livello di architettura della soluzione.

1. Scelta della fonte dei dati. Determina se stai parsando direttamente i risultati del motore di ricerca tramite richieste HTTP o se utilizzi un browser headless (ad esempio, tramite Puppeteer/Playwright) per simulare un utente reale. La seconda opzione è più affidabile contro la protezione anti-bot, ma più lenta e costosa in termini di risorse del server.
2. Impostazione del pool di proxy. Collega un fornitore di proxy con rotazione degli IP per richiesta o per tempo. Per Yandex e Google è meglio utilizzare pool di proxy diversi, poiché i sistemi hanno soglie di blocco diverse.
3. Logica dei retry. Se la richiesta restituisce un captcha o un errore, lo script deve automaticamente cambiare IP e ripetere la richiesta, e non semplicemente registrare l'errore.
4. Parsing del risultato. Dall'HTML ricevuto viene estratta la posizione del dominio desiderato nei risultati — di solito attraverso la ricerca nei tag dei link e il confronto con il dominio del cliente.
5. Archiviazione della storia. I risultati vengono salvati in un database con la data di controllo, in modo da poter costruire grafici sulla dinamica delle posizioni.
6. Programmazione dell'esecuzione. Lo script viene eseguito tramite cron o pianificatore di attività una volta al giorno (o più spesso), distribuendo uniformemente 1000 richieste nel tempo, per non creare un carico di picco sul pool di proxy.

Esempio di codice per il controllo delle posizioni in Python

Di seguito è riportato un esempio semplificato della logica di richiesta ai risultati di ricerca tramite proxy con rotazione. Questo è un framework dimostrativo che mostra il principio di funzionamento, non una soluzione pronta per l'uso.

import requests
import random
import time

PROXY_LIST = [
    "http://user:[email protected]:8000",
    "http://user:[email protected]:8000",
    # ... pool di proxy da centinaia di indirizzi
]

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  # è necessaria la rotazione dell'IP e la ripetizione della richiesta
        position = find_domain_position(response.text, domain)
        return position
    except requests.RequestException:
        return None

def find_domain_position(html, domain):
    # logica semplificata per cercare la posizione del dominio nei risultati
    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))  # ritardo casuale tra le richieste
  

In un progetto reale, invece del parsing manuale dell'HTML si utilizza spesso un browser headless con sostituzione dell'User-Agent e fingerprint, e il pool di proxy viene collegato tramite un fornitore con rotazione automatica a livello di endpoint — questo elimina la necessità di mantenere manualmente un elenco di indirizzi e semplifica la scalabilità fino a diverse migliaia di richieste al giorno.

Quanto si può realmente risparmiare

Per rispondere alla domanda sul risparmio, è necessario confrontare due modelli di spesa in dinamica man mano che cresce il volume delle parole chiave.

Con un volume ridotto — fino a 1000-2000 parole chiave al giorno — il costo dell'abbonamento a un tracker pronto è solitamente comparabile o addirittura inferiore ai costi complessivi per lo sviluppo e il supporto della propria soluzione, se si considera il tempo dello specialista. Lo sviluppo di un parser minimamente funzionante da zero richiede da alcuni giorni a un paio di settimane, più il supporto periodico in caso di modifiche nel layout dei risultati di ricerca — e Yandex e Google cambiano spesso il markup dei risultati.

Il punto di svolta si verifica quando il volume di controllo cresce fino a diverse migliaia di parole chiave al giorno o è necessario controllare le posizioni più volte al giorno, in diverse regioni e dispositivi (desktop/mobile). In questo scenario, il costo dell'abbonamento pronto cresce linearmente o addirittura progressivamente con il volume, mentre le spese per il proprio tracker crescono molto più lentamente: la principale voce (traffico proxy) non aumenta così drasticamente come i piani tariffari dei servizi SaaS quando si passa al livello successivo del pacchetto.

Un'indicazione pratica per le agenzie: se monitori le posizioni di 5-10 e più clienti contemporaneamente, il volume complessivo supera solitamente le 5000-10000 frasi chiave al giorno — è proprio a questa scala che il proprio tracker è quasi sempre più vantaggioso di qualsiasi abbonamento pronto, a condizione che ci sia qualcuno nel team in grado di mantenere il parser.

Errori comuni nel parsing autonomo

Nella pratica, la maggior parte dei problemi con il proprio tracker di posizioni è legata non al codice, ma alla sottovalutazione delle sfide infrastrutturali.

• Risparmio sui proxy. Tentare di risparmiare su proxy economici dei data center porta a massicci captcha, che devono essere risolti tramite servizi anti-captcha di terze parti — alla fine, le spese complessive risultano superiori a quelle che si avrebbero utilizzando proxy di qualità migliore sin dall'inizio.
• Assenza di ritardi tra le richieste. Richieste troppo rapide e consecutive da un IP attirano immediatamente l'attenzione dei sistemi anti-bot, anche se l'IP è di qualità.
• Ignorare la regionalità. Yandex mostra risultati diversi a seconda della regione dell'utente — senza una corretta geolocalizzazione dei proxy, i dati sulle posizioni saranno errati.
• Assenza di monitoraggio della salute del parser. I motori di ricerca cambiano periodicamente il layout della pagina dei risultati, e senza avvisi sulla diminuzione del successo del parsing si possono raccogliere dati vuoti o errati per settimane senza accorgersene.
• Ignorare i risultati mobili. I risultati desktop e mobili spesso differiscono, e se per il cliente è importante la posizione mobile, è necessario un contorno di parsing separato con i corrispondenti User-Agent e, preferibilmente, IP mobili.

Conclusione

Un tracker di posizioni proprio diventa economicamente giustificato quando il volume di controllo supera alcune migliaia di parole chiave al giorno, e nel team c'è una risorsa per mantenere il parser. A volumi inferiori, un abbonamento pronto è quasi sempre più economico considerando i costi nascosti dello sviluppo. La principale variabile nel costo della propria soluzione non è il server e non il codice, ma l'infrastruttura proxy, che determina la quota di captcha e la stabilità dei dati.

Se prevedi di costruire un tracker di posizioni per 1000 e più parole chiave al giorno, inizia calcolando il traffico e testando un pool di proxy su un piccolo campione di richieste. Per un parsing stabile di Yandex e Google a questi volumi, è ragionevole considerare subito proxy residenziali — offrono una quota minima di captcha a un costo accettabile del traffico e si scalano bene con l'aumento del numero di clienti monitorati.