Hai avviato un parser su Wildberries o Ozon, configurato i proxy, e dopo un'ora ti sei scontrato con i limiti e hai ricevuto un sacco di IP bloccati — anche se hai raccolto solo un paio di migliaia di schede? Il problema è quasi sempre lo stesso: i parametri URL. Filtri, ordinamenti, paginazione e parametri UTM trasformano un catalogo in decine di migliaia di duplicati tecnici, e il parser li elenca tutti, invece di raccogliere dati unici.
Cosa sono i duplicati di pagine a causa dei parametri URL
Un duplicato di pagina è un URL che è tecnicamente diverso da un altro, ma restituisce lo stesso o quasi lo stesso contenuto. Un esempio classico: il catalogo di abiti su Wildberries è accessibile all'indirizzo /catalog/zhenshchinam/odezhda/platya, ma lo stesso risultato, ordinato per prezzo, diventa /catalog/zhenshchinam/odezhda/platya?sort=price. Aggiungi un filtro per taglia, marca, colore, fascia di prezzo — e otterrai centinaia di combinazioni di parametri, ognuna delle quali è formalmente un URL unico.
Per un utente reale è comodo: seleziona un filtro — vede il prodotto desiderato. Ma per un parser, che esplora i link secondo un modello o segue la paginazione, ogni combinazione è una pagina separata da caricare, analizzare e salvare. Se non vengono impostate regole, il robot "scivolerà" in un vortice infinito di filtri: ordinamento per prezzo → filtro per marca → filtro per taglia → di nuovo ordinamento, ma in un altro ordine. Il numero di URL unici cresce esponenzialmente, mentre i dati utili in essi non aumentano — sono le stesse schede prodotto, solo in un ordine diverso o con un set ridotto.
Una categoria separata di duplicati sono i parametri UTM e i parametri di sessione (utm_source, clid, _openstat). Questi non influenzano affatto il contenuto della pagina, ma se il parser raccoglie i link da altre pagine del sito così come sono, tirerà la stessa scheda prodotto decine di volte con diverse appendici nell'indirizzo.
Perché è critico per il parser
Per un SEO specialist, i duplicati di pagina sono un problema di indicizzazione e di diluizione del peso. Per chi estrae dati dai marketplace per monitorare i prezzi o raccogliere assortimenti, i duplicati rappresentano una perdita diretta di denaro e tempo, e questo su tre fronti contemporaneamente.
In primo luogo, ogni caricamento di una pagina duplicata è una richiesta tramite proxy. Se utilizzi proxy rotativi a pagamento (e per aggirare la protezione di Wildberries e Ozon non puoi fare a meno di loro), paghi il traffico anche per richieste inutili. Con un volume di decine di migliaia di schede, il 30-40% in più di richieste per duplicati aumenta notevolmente il consumo.
In secondo luogo, la velocità di raccolta diminuisce drasticamente. Se il tuo parser è fisicamente in grado di fare 10 richieste al secondo, e un terzo di esse va a pagine con gli stessi dati, la reale velocità di raccolta di contenuti unici scende a 6-7 schede al secondo. Nei grandi cataloghi, questa è la differenza tra raccogliere in un'ora e in mezza giornata.
In terzo luogo, e questo è il punto più doloroso — il rischio di ban dell'IP cresce proporzionalmente al numero di richieste. I sistemi anti-bot dei marketplace monitorano la frequenza delle richieste da un singolo indirizzo. Se fai tre volte più richieste di quelle necessarie per raccogliere dati target, esaurisci tre volte più velocemente il "credito di fiducia" del proxy e finisci sotto captcha o blocco.
Esempi reali: Wildberries, Ozon, Avito
Su Wildberries lo stesso catalogo può essere restituito con i parametri ?sort=popular, ?sort=rate, ?sort=newly, più filtri fbrand, fsize, priceU. Se il parser raccoglie i link "scheda → prodotti simili → di nuovo scheda", genera facilmente URL con combinazioni di tutti questi parametri, anche se il set di prodotti all'interno si sovrappone per il 90%.
Su Ozon la storia è simile con il parametro ?sorting= e filtri per le caratteristiche del prodotto — lì ci sono ancora più combinazioni, perché ogni categoria ha il proprio set di filtri (materiale, volume, colore e così via).
Su Avito il problema è separato — i parametri di geolocalizzazione e raggio di ricerca (?radius=, ?district=). Lo stesso annuncio può "riemergere" nei risultati con diverse combinazioni di questi parametri, e un parser ingenuo considererà queste come diverse scoperte, gonfiando il database con record duplicati.
Come i duplicati consumano il budget per i proxy e il tempo
Facciamo un esempio ipotetico. Supponiamo che una categoria abbia 500 prodotti unici, ma a causa di 8 opzioni di ordinamento e 12 combinazioni di filtri popolari, il parser senza normalizzazione degli URL esplora non 500, ma 4000-5000 pagine con elenchi più accessi ripetuti alle stesse schede. Se una richiesta tramite un proxy residenziale costa un'unità di traffico, con un'analisi ingenua si spende 8-10 volte di più di quanto necessario per ottenere lo stesso volume di dati unici.
Peggio ancora, le richieste ripetute dallo stesso IP a URL simili sono un modello caratteristico per i sistemi anti-bot. Maggiore è la frequenza e l'uniformità delle richieste, più velocemente scatta la protezione. Si crea così un circolo vizioso: i duplicati aumentano il numero di richieste → cresce il carico sul pool di proxy → gli IP vengono bloccati più rapidamente → è necessario cambiare più spesso i proxy e riavviare la raccolta → il tempo e il costo finale del parsing aumentano ulteriormente.
Nella pratica, questo si traduce in: un venditore vuole monitorare i prezzi di 200 concorrenti su Wildberries una volta al giorno, ma a causa di URL non puliti, il suo script fa 15.000 richieste invece di 2.000, si scontra con i limiti del pool di proxy e ottiene dati incompleti alla sera invece che al mattino.
Come rilevare i duplicati prima di avviare il parser
Prima di scalare la raccolta, vale la pena dedicare un'ora ad analizzare la struttura degli URL del sito target. Ecco un ordine pratico delle azioni:
- Apri il catalogo target nel browser e scorri manualmente i filtri e gli ordinamenti — annota quali parametri appaiono nella barra degli indirizzi.
- Controlla se il contenuto della pagina cambia quando aggiungi un parametro che non influisce sui risultati (ad esempio, un parametro UTM) — se il contenuto è lo stesso, questo parametro deve essere ignorato durante la raccolta.
- Guarda il
rel="canonical"nel codice sorgente della pagina — i siti spesso indicano quali URL sono considerati "principali" per le varianti duplicate. - Raccogli un piccolo campione di prova di 100-200 URL e passalo attraverso una semplice deduplicazione in base ai parametri chiave — verifica quanto si riduce l'elenco.
- Controlla il robots.txt — a volte ci sono già direttive Disallow per URL parametrizzati, questo è anche un suggerimento su quali parametri sono considerati "spazzatura".
Normalizzazione degli URL: regole ed esempi
La normalizzazione è il processo di riduzione degli URL a una forma canonica prima di decidere se esplorarli. Il principio di base: isolare i parametri "significativi" (ad esempio, il numero di pagina della paginazione o la categoria) e scartare quelli "non significativi" (ordinamento, UTM, identificatori di sessione).
Un esempio pratico di regola di normalizzazione per un catalogo simile a Wildberries:
import urllib.parse as up
IGNORED_PARAMS = {"sort", "utm_source", "utm_medium", "utm_campaign", "clid", "_openstat"}
def normalize_url(url: str) -> str:
parsed = up.urlparse(url)
query = up.parse_qsl(parsed.query)
# manteniamo solo i parametri significativi, gli altri vengono scartati
filtered = [(k, v) for k, v in query if k not in IGNORED_PARAMS]
filtered.sort() # uniformiamo l'ordine dei parametri
new_query = up.urlencode(filtered)
return up.urlunparse(parsed._replace(query=new_query))
Dopo la normalizzazione, tutte le varianti dello stesso elenco con diversi ordinamenti si riducono a un solo URL. Prima di inviare una richiesta tramite proxy, il parser verifica se questo indirizzo normalizzato è già stato incontrato — se sì, lo salta. Questo è il modo più economico per ridurre il numero di richieste senza perdere la completezza dei dati.
Per casi semplici, questa logica può essere implementata senza codice — tramite le impostazioni dello strumento di parsing: specificare "ignorare i parametri" e elencare la lista, oppure impostare un'espressione regolare per tagliare la coda dell'URL dopo il punto interrogativo, se i parametri non portano informazioni significative per il tuo compito.
Configurazione del parser per ignorare i parametri
La maggior parte delle soluzioni pronte per la raccolta di dati dai marketplace e dei costruttori di parsing supportano le regole di esclusione dei parametri URL a livello delle impostazioni del progetto. Ecco cosa controllare e configurare per prima cosa:
- Elenco dei parametri ignorati. Includi tutti quelli trovati nella fase di analisi, ordinamenti, parametri UTM e identificatori di sessione.
- Deduplicazione per hash dell'URL normalizzato. Molti parser memorizzano un elenco di indirizzi già visitati — è importante che il confronto avvenga sulla versione normalizzata, non sulla stringa originale.
- Limitazione della profondità di esplorazione dei filtri. Se l'obiettivo è raccogliere l'assortimento di una categoria, è sufficiente un "passaggio di base" senza ordinamenti e filtri, piuttosto che un'esplorazione ricorsiva di tutte le combinazioni.
- Prioritizzazione della paginazione rispetto ai filtri. Se il sito restituisce l'elenco completo dei prodotti tramite navigazione per pagine, di solito è sufficiente — esplorare separatamente lo stesso elenco con filtri applicati è ridondante.
Dopo tale configurazione, il volume delle richieste di solito si riduce di 3-6 volte a seconda di quanto "parametrizzato" sia il catalogo del sito sorgente.
Ruolo dei proxy nella scalabilità del parsing
Anche dopo una normalizzazione perfetta degli URL, il parsing di grandi cataloghi su Wildberries o Ozon richiede la distribuzione delle richieste tra molti indirizzi IP — altrimenti la protezione anti-bot rileverà rapidamente un'attività anomala da una singola fonte. Qui è importante scegliere correttamente il tipo di proxy per il compito.
Per la raccolta su larga scala di schede prodotto e il monitoraggio dei prezzi, dove sono importanti volume e velocità a un costo ragionevole, di solito bastano proxy di data center — sono più veloci e più economici rispetto ai proxy residenziali, il che è critico con milioni di richieste al giorno. Ma se la protezione del sito blocca aggressivamente i range di IP dei data center, vale la pena passare a proxy residenziali, che appaiono come utenti normali di fornitori reali e vengono bloccati meno frequentemente.
Per compiti specifici — ad esempio, controllare come viene visualizzato il prezzo di un prodotto specifico da un dispositivo mobile in una determinata regione — sono utili proxy mobili, che emulano una connessione tramite un operatore di telefonia mobile e raramente vengono bloccati in massa.
È importante capire: la scelta corretta dei proxy non sostituisce la normalizzazione degli URL, ma la completa. Senza la pulizia dai duplicati, brucerai semplicemente più velocemente anche il miglior pool di indirizzi IP. Prima riduci il numero di richieste inutili, poi scalare quelle rimanenti tramite rotazione dei proxy — solo in questo ordine si ottiene il massimo risparmio.
Checklist prima di avviare la raccolta dati
Prima di avviare il parser su larga scala, segui un breve elenco di controlli:
| Punto di controllo | Perché è necessario |
|---|---|
| Elenco dei parametri di ordinamento e filtri identificato | Comprendere quali URL possono essere considerati duplicati |
| Regola di normalizzazione degli URL configurata | Ridurre i duplicati a un unico indirizzo canonico |
| Deduplicazione per hash attivata | Escludere il caricamento ripetuto degli stessi dati |
| Tipo di proxy selezionato in base al volume e all'aggressività della protezione | Ridurre il rischio di ban e accelerare la raccolta |
| Limiti di richieste per IP impostati con margine | Evitare il ban massiccio del pool di proxy |
Conclusione
Filtri, ordinamenti e parametri di servizio negli URL non sono solo un dettaglio tecnico, ma una delle principali fonti di traffico inutile durante il parsing dei marketplace. Senza la normalizzazione degli URL, il parser può effettuare da 5 a 10 volte più richieste di quelle necessarie per ottenere gli stessi dati, il che colpisce direttamente il budget per i proxy, la velocità di raccolta e il rischio di blocchi.
La soluzione è semplice nella formulazione, ma richiede disciplina nella fase di preparazione: analizza la struttura degli URL del sito target, determina quali parametri influenzano il contenuto e quali no, configura la deduplicazione per l'indirizzo normalizzato e solo dopo scala la raccolta tramite rotazione dei proxy. Se il tuo obiettivo è un monitoraggio stabile dei prezzi e dell'assortimento su Wildberries, Ozon o Avito in grande volume, è consigliabile iniziare con proxy residenziali — offrono il miglior equilibrio tra fiducia nei sistemi anti-bot e flessibilità di configurazione per compiti specifici.