¿Has lanzado un parser en Wildberries o Ozon, configurado proxies, y después de una hora te has topado con límites y has recibido un montón de IPs bloqueadas — aunque solo hayas recopilado un par de miles de tarjetas? El problema casi siempre es el mismo: los parámetros de URL. Los filtros, ordenamientos, paginación y etiquetas UTM convierten un solo catálogo en decenas de miles de duplicados técnicos, y el parser los recorre todos, en lugar de recopilar datos únicos.
Qué son los duplicados de páginas debido a parámetros de URL
Un duplicado de página es una URL que es técnicamente diferente de otra, pero el contenido que entrega es el mismo o casi el mismo. Un ejemplo clásico: el catálogo de vestidos en Wildberries está disponible en /catalog/zhenshchinam/odezhda/platya, pero la misma salida, ordenada por precio, se convierte en /catalog/zhenshchinam/odezhda/platya?sort=price. Agrega un filtro por tamaño, marca, color, rango de precios — y al final obtendrás cientos de combinaciones de parámetros, cada una de las cuales es formalmente una URL única.
Para un usuario en vivo, esto es conveniente: eliges un filtro y ves el producto deseado. Pero para un parser, que recorre enlaces según una máscara o sigue la paginación, cada combinación es una página separada que necesita ser cargada, analizada y guardada. Si no se establecen reglas, el robot caerá en un embudo infinito de filtros: ordenación por precio → filtro por marca → filtro por tamaño → nuevamente ordenación, pero en otro orden. La cantidad de URLs únicas crece exponencialmente, y los datos útiles no aumentan — son las mismas tarjetas de productos, solo en otro orden o con un conjunto reducido.
Una categoría separada de duplicados son las etiquetas UTM y los parámetros de sesión (utm_source, clid, _openstat). Estos no afectan en absoluto el contenido de la página, pero si el parser recopila enlaces de otras páginas del sitio tal como están, estará extrayendo la misma tarjeta de producto decenas de veces con diferentes sufijos en la dirección.
Por qué es crítico para el parser
Para un especialista en SEO, los duplicados de páginas son un problema de indexación y dilución del peso. Para quien está scraping un marketplace con el fin de monitorear precios o recopilar el surtido, los duplicados son una pérdida directa de dinero y tiempo, y esto ocurre en tres direcciones al mismo tiempo.
En primer lugar, cada carga de una página duplicada es una solicitud a través de un proxy. Si utilizas proxies rotativos de pago (y para sortear la protección de Wildberries y Ozon no puedes prescindir de ellos), pagas por el tráfico incluso por solicitudes inútiles. A gran escala, con decenas de miles de tarjetas, un 30-40% adicional de solicitudes a duplicados aumenta significativamente el gasto.
En segundo lugar, la velocidad de recopilación disminuye drásticamente. Si tu parser es físicamente capaz de hacer 10 solicitudes por segundo, y un tercio de ellas se va a páginas con los mismos datos, la velocidad real de recopilación de contenido único cae a 6-7 tarjetas por segundo. En grandes catálogos, esta es la diferencia entre recopilar en una hora y en medio día.
En tercer lugar, y esto es lo más doloroso: el riesgo de bloqueo de IP aumenta proporcionalmente al número de solicitudes. Los sistemas anti-bot de los marketplaces consideran la frecuencia de las solicitudes desde una misma dirección. Si haces tres veces más solicitudes de las necesarias para recopilar datos objetivos, agotas tres veces más rápido el "crédito de confianza" del proxy y caes en un captcha o bloqueo.
Ejemplos reales: Wildberries, Ozon, Avito
En Wildberries, el mismo catálogo puede ser entregado con parámetros ?sort=popular, ?sort=rate, ?sort=newly, más filtros fbrand, fsize, priceU. Si el parser recopila enlaces "tarjeta → productos similares → nuevamente tarjeta", genera fácilmente URLs con combinaciones de todos estos parámetros, aunque el conjunto de productos dentro se superponga en un 90%.
En Ozon, la historia es similar con el parámetro ?sorting= y filtros por características del producto — allí hay aún más combinaciones, porque cada categoría tiene su propio conjunto de filtros (material, volumen, color, etc.).
En Avito, el dolor es diferente: los parámetros de geolocalización y radio de búsqueda (?radius=, ?district=). Un mismo anuncio puede "aparecer" en los resultados con diferentes combinaciones de estos parámetros, y un parser ingenuo considerará esto como diferentes hallazgos, inflando la base de registros duplicados.
Cómo los duplicados consumen el presupuesto de proxies y tiempo
Calculemos con un ejemplo hipotético. Supongamos que una categoría tiene 500 productos únicos, pero debido a 8 opciones de ordenamiento y 12 combinaciones de filtros populares, el parser sin normalización de URL recorre no 500, sino 4000-5000 páginas con listados más visitas repetidas a las mismas tarjetas. Si una solicitud a través de un proxy residencial cuesta una unidad de tráfico, entonces con un recorrido ingenuo gastas de 8 a 10 veces más de lo necesario para obtener el mismo volumen de datos únicos.
Peor aún, las solicitudes repetidas desde la misma IP a URLs similares son un patrón característico para los sistemas anti-bot. Cuanto mayor sea la frecuencia y la uniformidad de las solicitudes, más rápido se activa la protección. Así se forma un círculo vicioso: los duplicados aumentan el número de solicitudes → aumenta la carga en el pool de proxies → las IPs se bloquean más rápido → hay que cambiar los proxies con más frecuencia y reiniciar la recopilación → el tiempo y el costo final del scraping aumentan aún más.
En la práctica, esto se ve así: un vendedor quiere monitorear los precios de 200 competidores en Wildberries una vez al día, pero debido a las URLs no limpias, su script hace 15,000 solicitudes en lugar de 2,000, se topa con los límites del pool de proxies y obtiene datos incompletos por la tarde en lugar de por la mañana.
Cómo detectar duplicados antes de lanzar el parser
Antes de escalar la recopilación, vale la pena dedicar una hora a analizar la estructura de URL del sitio objetivo. Aquí hay un orden práctico de acciones:
- Abre el catálogo objetivo en el navegador y revisa manualmente los filtros y ordenamientos — registra qué parámetros aparecen en la barra de direcciones.
- Verifica si el contenido de la página cambia al agregar un parámetro que no afecta la salida (por ejemplo, una etiqueta UTM) — si el contenido es el mismo, este parámetro debe ser ignorado al recopilar.
- Mira el
rel="canonical"en el código fuente de la página — los sitios a menudo indican cuál URL se considera "principal" para las variantes duplicadas. - Recopila una pequeña muestra de prueba de 100-200 URLs y pásala a través de una simple deduplicación por parámetros clave — observa cuánto se reduce la lista.
- Revisa el robots.txt — a veces ya hay directivas Disallow para URLs parametrizadas, esto también es una pista sobre qué parámetros se consideran "basura".
Normalización de URL: reglas y ejemplos
La normalización es el proceso de llevar las URLs a una forma canónica única antes de decidir si deben ser recorridas. El principio básico: identificar los parámetros "significativos" (por ejemplo, el número de página de paginación o la categoría) y descartar los "insignificantes" (ordenamiento, UTM, identificadores de sesión).
Un ejemplo práctico de la regla de normalización para un catálogo similar 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)
# mantenemos solo los parámetros significativos, los demás se eliminan
filtered = [(k, v) for k, v in query if k not in IGNORED_PARAMS]
filtered.sort() # ordenamos los parámetros a una forma uniforme
new_query = up.urlencode(filtered)
return up.urlunparse(parsed._replace(query=new_query))
Después de la normalización, todas las variantes de un mismo listado con diferentes ordenamientos se consolidan en una sola URL. Antes de enviar una solicitud a través de un proxy, el parser verifica si ya se ha encontrado esta dirección normalizada — si es así, la omite. Este es el método más económico para reducir el número de solicitudes sin perder la integridad de los datos.
Para casos sencillos, esta misma lógica se puede implementar sin código — a través de la configuración de la herramienta de scraping: especificar "ignorar parámetros" y enumerar la lista, o establecer una expresión regular para cortar el sufijo de la URL después del signo de interrogación, si los parámetros no llevan información significativa para tu tarea.
Configuración del parser para ignorar parámetros
La mayoría de las soluciones listas para la recopilación de datos de marketplaces y constructores de scraping admiten reglas de exclusión de parámetros de URL a nivel de configuración del proyecto. Aquí hay algunas cosas que debes verificar y configurar primero:
- Lista de parámetros ignorados. Incluye todos los encontrados en la etapa de análisis de ordenamiento, etiquetas UTM e identificadores de sesión.
- Deduplicación por hash de URL normalizada. Muchos parsers mantienen una lista de direcciones ya visitadas — es importante que la comparación se realice sobre la versión normalizada, no sobre la cadena original.
- Límite de profundidad de recorrido de filtros. Si la tarea es recopilar el surtido de una categoría, es suficiente con un "recorrido básico" sin ordenamientos y filtros, en lugar de un recorrido recursivo de todas las combinaciones.
- Priorizar la paginación sobre los filtros. Si el sitio entrega la lista completa de productos a través de navegación paginada, esto suele ser suficiente — recorrer la misma lista con filtros aplicados es redundante.
Después de tal configuración, el volumen de solicitudes generalmente se reduce de 3 a 6 veces dependiendo de cuán "parametrizado" esté el catálogo del sitio fuente.
El papel de los proxies al escalar el scraping
Incluso después de una normalización ideal de URL, el scraping de grandes catálogos de Wildberries o Ozon requiere distribuir las solicitudes entre múltiples direcciones IP — de lo contrario, la protección anti-bot rastreará rápidamente la actividad anómala desde una misma fuente. Aquí es importante elegir correctamente el tipo de proxy para la tarea.
Para la recopilación masiva de tarjetas de productos y monitoreo de precios, donde el volumen y la velocidad son importantes a un costo razonable, generalmente son suficientes proxies de centros de datos — son más rápidos y más baratos que los residenciales, lo cual es crítico con millones de solicitudes al día. Pero si la protección del sitio bloquea agresivamente los rangos de IP de centros de datos, es mejor cambiar a proxies residenciales, que parecen usuarios normales de proveedores reales y son menos propensos a ser sospechosos.
Para tareas puntuales — por ejemplo, verificar cómo se muestra el precio de un producto específico desde un dispositivo móvil en una región concreta — son útiles proxies móviles, que emulan una conexión a través de un operador de telefonía móvil y casi nunca son bloqueados masivamente.
Es importante entender: la elección correcta de proxies no sustituye la normalización de URL, sino que la complementa. Sin la limpieza de duplicados, simplemente quemarás más rápido incluso el mejor pool de direcciones IP. Primero reduces el número de solicitudes inútiles, luego escalas las restantes a través de la rotación de proxies — este orden proporciona el máximo ahorro.
Lista de verificación antes de iniciar la recopilación de datos
Antes de lanzar el parser a gran escala, revisa esta breve lista de verificaciones:
| Punto de verificación | Por qué es necesario |
|---|---|
| Lista de parámetros de ordenamiento y filtros identificada | Entender qué URLs se pueden considerar duplicados |
| Regla de normalización de URL configurada | Consolidar duplicados en una dirección canónica |
| Deduplicación por hash activada | Excluir la recarga de los mismos datos |
| Tipo de proxy seleccionado según volumen y agresividad de protección | Reducir el riesgo de bloqueo y acelerar la recopilación |
| Límites de solicitudes por IP establecidos con margen | Evitar el bloqueo masivo del pool de proxies |
Conclusión
Los filtros, ordenamientos y parámetros de servicio en las URL no son solo un detalle técnico, sino una de las principales fuentes de tráfico inútil al hacer scraping en marketplaces. Sin la normalización de URL, un parser puede hacer de 5 a 10 veces más solicitudes de las necesarias para obtener los mismos datos, lo que impacta directamente en el presupuesto de proxies, la velocidad de recopilación y el riesgo de bloqueos.
La solución es simple en su formulación, pero requiere disciplina en la etapa de preparación: analiza la estructura de URL del sitio objetivo, determina qué parámetros afectan al contenido y cuáles no, configura la deduplicación por dirección normalizada y solo después de eso escala la recopilación a través de la rotación de proxies. Si tu tarea es un monitoreo estable de precios y surtido en Wildberries, Ozon o Avito en gran volumen, es recomendable comenzar con proxies residenciales — ofrecen el mejor equilibrio entre la confianza de los sistemas anti-bot y la flexibilidad de configuración para tareas específicas.