Vous avez lancé un parseur sur Wildberries ou Ozon, configuré des proxies, et après une heure, vous êtes tombé sur des limites et avez reçu une multitude d'IP bannies — alors que vous n'avez collecté que quelques milliers de fiches ? Le problème est presque toujours le même : les paramètres URL. Les filtres, les tris, la pagination et les balises UTM transforment un seul catalogue en dizaines de milliers de doublons techniques, et le parseur les parcourt tous, au lieu de collecter des données uniques.
Qu'est-ce qu'une page en double à cause des paramètres URL
Une page en double est une URL qui diffère techniquement d'une autre, mais dont le contenu est le même ou presque le même. Un exemple classique : le catalogue de robes sur Wildberries est accessible à l'adresse /catalog/zhenshchinam/odezhda/platya, mais le même résultat, trié par prix, devient /catalog/zhenshchinam/odezhda/platya?sort=price. Ajoutez un filtre par taille, marque, couleur, gamme de prix — et vous obtiendrez des centaines de combinaisons de paramètres, chacune étant formellement une URL unique.
Pour un utilisateur vivant, c'est pratique : il choisit un filtre — il voit le produit souhaité. Mais pour un parseur, qui parcourt les liens selon un modèle ou suit la pagination, chaque combinaison est une page distincte à charger, à parser et à sauvegarder. Si aucune règle n'est définie, le robot va « tomber » dans un entonnoir infini de filtres : tri par prix → filtre par marque → filtre par taille → à nouveau tri, mais dans un autre ordre. Le nombre d'URL uniques augmente de manière exponentielle, mais les données utiles ne s'accumulent pas — ce sont les mêmes fiches produits, juste dans un ordre différent ou avec un ensemble réduit.
Une catégorie distincte de doublons concerne les balises UTM et les paramètres de session (utm_source, clid, _openstat). Ils n'affectent pas du tout le contenu de la page, mais si le parseur collecte des liens d'autres pages du site tels quels, il tirera la même fiche produit des dizaines de fois avec des suffixes différents dans l'adresse.
Pourquoi c'est critique pour le parseur
Pour un spécialiste SEO, les pages en double sont un problème d'indexation et de dilution du poids. Pour ceux qui parsèment un marketplace pour surveiller les prix ou collecter l'assortiment, les doublons représentent une perte directe d'argent et de temps, et ce sur trois fronts à la fois.
Tout d'abord, chaque chargement d'une page en double est une requête via un proxy. Si vous utilisez des proxies rotatifs payants (et pour contourner la protection de Wildberries et Ozon, vous ne pouvez pas vous en passer), vous payez pour le trafic même pour des requêtes inutiles. À l'échelle de dizaines de milliers de fiches, 30-40 % de requêtes supplémentaires sur des doublons augmentent considérablement les dépenses.
Deuxièmement, la vitesse de collecte diminue de manière exponentielle. Si votre parseur est physiquement capable de faire 10 requêtes par seconde, et qu'un tiers d'entre elles est consacré à des pages avec les mêmes données, la vitesse réelle de collecte de contenu unique tombe à 6-7 fiches par seconde. Sur de grands catalogues, cela fait la différence entre une collecte en une heure et en une demi-journée.
Troisièmement, et c'est le plus douloureux — le risque de bannissement d'IP augmente proportionnellement au nombre de requêtes. Les systèmes anti-bots des marketplaces calculent la fréquence des accès depuis une même adresse. Si vous faites trois fois plus de requêtes que nécessaire pour collecter des données cibles, vous épuisez trois fois plus vite le « crédit de confiance » du proxy et vous vous retrouvez sous captcha ou blocage.
Exemples réels : Wildberries, Ozon, Avito
Sur Wildberries, un même catalogue peut être rendu avec les paramètres ?sort=popular, ?sort=rate, ?sort=newly, plus les filtres fbrand, fsize, priceU. Si le parseur collecte des liens « fiche → produits similaires → à nouveau fiche », il génère facilement des URL avec toutes ces combinaisons de paramètres, bien que l'ensemble des produits se chevauche à 90 %.
Sur Ozon, c'est une histoire similaire avec le paramètre ?sorting= et les filtres par caractéristiques du produit — il y a encore plus de combinaisons, car chaque catégorie a son propre ensemble de filtres (matériau, volume, couleur, etc.).
Sur Avito, la douleur distincte concerne les paramètres de géolocalisation et de rayon de recherche (?radius=, ?district=). Une même annonce peut « remonter » dans les résultats avec différentes combinaisons de ces paramètres, et un parseur naïf considérera cela comme différentes trouvailles, gonflant la base avec des enregistrements en double.
Comment les doublons épuisent le budget pour les proxies et le temps
Calculons sur un exemple conditionnel. Supposons qu'une catégorie ait 500 produits uniques, mais à cause de 8 options de tri et de 12 combinaisons de filtres populaires, le parseur sans normalisation des URL parcourt non pas 500, mais 4000-5000 pages avec des listings plus des visites répétées sur les mêmes fiches. Si une requête via un proxy résident coûte une unité de trafic, alors avec une collecte naïve, vous dépensez 8 à 10 fois plus que nécessaire pour obtenir le même volume de données uniques.
Pire encore, les requêtes répétées depuis une même IP vers des URL similaires sont un motif caractéristique pour les systèmes anti-bots. Plus la fréquence et l'uniformité des requêtes sont élevées, plus la protection s'active rapidement. Cela crée un cercle vicieux : les doublons augmentent le nombre de requêtes → la charge sur le pool de proxies augmente → les IP sont bannies plus rapidement → il faut changer plus souvent de proxies et redémarrer la collecte → le temps et le coût de parsing augmentent encore plus.
En pratique, cela se traduit ainsi : un vendeur souhaite surveiller les prix de 200 concurrents sur Wildberries une fois par jour, mais à cause des URL non nettoyées, son script effectue 15 000 requêtes au lieu de 2 000, atteint les limites du pool de proxies et obtient des données incomplètes le soir au lieu du matin.
Comment détecter les doublons avant de lancer le parseur
Avant de mettre à l'échelle la collecte, il vaut la peine de passer une heure à analyser la structure des URL du site cible. Voici un ordre d'actions pratique :
- Ouvrez le catalogue cible dans votre navigateur et parcourez manuellement les filtres et les tris — notez quels paramètres apparaissent dans la barre d'adresse.
- Vérifiez si le contenu de la page change lorsque vous ajoutez un paramètre qui n'affecte pas les résultats (par exemple, une balise UTM) — si le contenu est le même, ce paramètre doit être ignoré lors de la collecte.
- Regardez la
rel="canonical"dans le code source de la page — les sites indiquent souvent eux-mêmes quelle URL est considérée comme « principale » pour les variantes en double. - Collectez un petit échantillon de test de 100-200 URL et faites-le passer par une simple dé-duplication basée sur des paramètres clés — regardez combien la liste sera réduite.
- Vérifiez le fichier robots.txt — parfois, des directives Disallow pour les URL paramétrées y sont déjà inscrites, ce qui est aussi un indice sur les paramètres considérés comme « indésirables ».
Normalisation des URL : règles et exemples
La normalisation consiste à ramener les URL à une forme canonique unique avant de décider si elles doivent être parcourues. Le principe de base : identifier les paramètres « significatifs » (par exemple, le numéro de page de pagination ou la catégorie) et ignorer les « insignifiants » (tri, UTM, identifiants de session).
Un exemple pratique de règle de normalisation pour un catalogue similaire à 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)
# ne garder que les paramètres significatifs, les autres sont rejetés
filtered = [(k, v) for k, v in query if k not in IGNORED_PARAMS]
filtered.sort() # ramener l'ordre des paramètres à une forme unique
new_query = up.urlencode(filtered)
return up.urlunparse(parsed._replace(query=new_query))
Après normalisation, toutes les variantes d'un même listing avec des tris différents se regroupent en une seule URL. Avant d'envoyer une requête via un proxy, le parseur vérifie si cette adresse normalisée a déjà été rencontrée — si oui, il l'ignore. C'est le moyen le moins coûteux de réduire le nombre de requêtes sans perdre la complétude des données.
Pour des cas simples, cette même logique peut être mise en œuvre sans code — via les paramètres de l'outil de parsing : indiquer « ignorer les paramètres » et énumérer la liste, ou définir une expression régulière pour couper la queue de l'URL après le point d'interrogation, si les paramètres ne portent pas d'informations significatives pour votre tâche.
Configuration du parseur pour ignorer les paramètres
La plupart des solutions prêtes à l'emploi pour la collecte de données sur les marketplaces et les constructeurs de parsing prennent en charge les règles d'exclusion des paramètres URL au niveau des paramètres du projet. Voici ce qu'il convient de vérifier et de configurer en premier :
- Liste des paramètres ignorés. Ajoutez-y tous ceux trouvés lors de l'analyse des tris, des balises UTM et des identifiants de session.
- Dé-duplication par hachage de l'URL normalisée. De nombreux parseurs conservent une liste des adresses déjà visitées — il est important que la comparaison se fasse sur la version normalisée, et non sur la chaîne d'origine.
- Limitation de la profondeur de parcours des filtres. Si l'objectif est de collecter l'assortiment d'une catégorie, un seul passage « de base » sans tris ni filtres suffit, et non un parcours récursif de toutes les combinaisons.
- Priorisation de la pagination sur les filtres. Si le site fournit une liste complète de produits via une navigation paginée, cela suffit généralement — parcourir à nouveau la même liste avec des filtres appliqués est superflu.
Après une telle configuration, le volume de requêtes est généralement réduit de 3 à 6 fois selon le degré de « paramétrisation » du catalogue du site source.
Rôle des proxies lors de l'échelle du parsing
Même après une normalisation parfaite des URL, le parsing de grands catalogues Wildberries ou Ozon nécessite la répartition des requêtes entre de nombreuses adresses IP — sinon, la protection anti-bots détectera rapidement une activité anormale provenant d'une même source. Il est important de choisir correctement le type de proxy pour la tâche.
Pour la collecte à grande échelle de fiches produits et la surveillance des prix, où le volume et la vitesse sont importants à un coût raisonnable, il suffit généralement de proxies de centre de données — ils sont plus rapides et moins chers que les proxies résidentiels, ce qui est critique pour des millions de requêtes par jour. Mais si la protection du site bannit agressivement les plages d'IP des centres de données, il vaut mieux passer à des proxies résidentiels, qui ressemblent à des utilisateurs ordinaires avec de vrais fournisseurs et sont moins souvent suspectés.
Pour des tâches spécifiques — par exemple, vérifier comment le prix d'un produit spécifique s'affiche sur un appareil mobile dans une région donnée — des proxies mobiles seront utiles, qui simulent une connexion via un opérateur de téléphonie mobile et ne sont presque jamais bloqués massivement.
Il est important de comprendre : le choix correct des proxies ne remplace pas la normalisation des URL, mais la complète. Sans nettoyage des doublons, vous allez simplement brûler plus rapidement même le meilleur pool d'adresses IP. D'abord, réduisez le nombre de requêtes inutiles, puis mettez à l'échelle les restantes via la rotation des proxies — c'est dans cet ordre que cela permet d'économiser au maximum.
Liste de contrôle avant de lancer la collecte de données
Avant de lancer le parseur à grande échelle, parcourez une courte liste de vérifications :
| Point de vérification | Pourquoi c'est nécessaire |
|---|---|
| Liste des paramètres de tri et de filtres identifiée | Comprendre quelles URL peuvent être considérées comme des doublons |
| Règle de normalisation des URL configurée | Regrouper les doublons en une seule adresse canonique |
| Dé-duplication par hachage activée | Exclure le rechargement des mêmes données |
| Type de proxy sélectionné en fonction du volume et de l'agressivité de la protection | Réduire le risque de bannissement et accélérer la collecte |
| Limites de requêtes par IP définies avec une marge | Éviter le bannissement massif du pool de proxies |
Conclusion
Les filtres, les tris et les paramètres de service dans l'URL ne sont pas simplement un détail technique, mais l'une des principales sources de trafic inutile lors du parsing des marketplaces. Sans normalisation des URL, le parseur peut faire 5 à 10 fois plus de requêtes que nécessaire pour obtenir les mêmes données, ce qui impacte directement le budget pour les proxies, la vitesse de collecte et le risque de blocages.
La solution est simple à formuler, mais nécessite de la discipline à l'étape de préparation : analysez la structure des URL du site cible, déterminez quels paramètres affectent le contenu et lesquels ne le font pas, configurez la dé-duplication par adresse normalisée et seulement après cela, mettez à l'échelle la collecte via la rotation des proxies. Si votre tâche est un suivi stable des prix et de l'assortiment sur Wildberries, Ozon ou Avito à grande échelle, il vaut la peine de commencer avec des proxies résidentiels — ils offrent le meilleur équilibre entre la confiance des systèmes anti-bots et la flexibilité de configuration pour une tâche spécifique.