El 70% de los scrapers que llegan a nuestra mesa como “proyecto de rescate” tienen los mismos errores: selectores frágiles, cero monitoreo, manejo de fallos pobre y arquitectura monolítica. Estos errores no se notan en demo; se notan a las 3 semanas cuando el sitio cambia y el pipeline lleva 48 horas regresando datos basura.
Si vas a poner un scraper en producción (o ya tienes uno corriendo), estos son los siete errores más caros y cómo evitarlos. Datos basados en 47 pipelines en producción durante los últimos 5 años en DevActivo.
Error 1: Selectores frágiles sin fallback
El error más común. Un scraper que usa document.querySelector('.product-card__price') funciona el día de la entrega y se rompe la primera vez que el sitio actualiza su CSS.
Por qué pasa: Los desarrolladores escriben el selector que funciona con el HTML actual sin pensar en estabilidad. Cuando el equipo del sitio renombra una clase o reordena divs, el scraper devuelve datos nulos o, peor, datos del elemento equivocado.
Cómo evitarlo: Selectores defensivos con múltiples estrategias por dato:
- Buscar por atributos semánticos primero:
[data-product-price],[itemprop="price"] - Fallback a clase principal:
.product-card .price - Fallback a estructura: tercer span dentro del div principal
- Validación de formato: el valor extraído debe parsearse como número con símbolo de moneda
- Si todos fallan, log estructurado y alerta inmediata
La diferencia entre un scraper de 200 USD y uno de 2,000 USD está en este nivel de defensividad.
Error 2: Cero monitoreo de calidad de datos
Tu scraper corre todos los días y extrae 5,000 registros. Una semana después descubres que durante 3 días extrajo 5,000 strings vacíos porque el sitio cambió y nadie revisó. Tu base de datos tiene 15,000 registros sin valor.
Cómo evitarlo: Monitoreo a tres niveles:
- Métricas técnicas: requests por segundo, tasa de error HTTP, latencia promedio
- Métricas de calidad: % de campos no-nulos por extracción, distribución de valores (si los precios suben 10x de un día a otro, algo se rompió)
- Alertas semánticas: si el conteo de registros cae más de 30% vs el día anterior, notificación inmediata
Stack típico: Grafana para dashboards, Prometheus para métricas, Sentry para errores no manejados, Telegram para alertas.
Error 3: No manejar rate limiting del sitio objetivo
El scraper hace 200 requests por segundo el día 1 porque la red local lo permite. El sitio objetivo detecta el patrón en el día 2, bloquea la IP y el scraper extrae 0 registros durante 5 días mientras nadie nota.
Cómo evitarlo:
- Respetar tiempos entre requests: 1-3 segundos con jitter aleatorio para sitios sensibles
- Backoff exponencial cuando el sitio devuelve 429 (Too Many Requests) o 503
- Rotación de IPs residenciales para volúmenes altos
- Patrones de navegación realistas: scroll, espera, click, no solo GET puro
- User-agent rotativo y consistente con cookies
Error 4: Arquitectura monolítica sin paralelización
El script corre en un solo proceso, secuencialmente. Funciona para 1,000 registros; muere para 100,000.
Cómo evitarlo: Separar tres capas desde el inicio:
- Producer: genera URLs a scrapear y las pone en una cola (Redis)
- Workers: procesos paralelos que toman URLs, ejecutan el scraping y guardan resultados
- Storage: base de datos con índices apropiados y manejo de duplicados
Frameworks que ayudan: Arq, Celery, Scrapy con su scheduler interno. Para volúmenes pequeños un simple asyncio.gather() con semáforo es suficiente.
Error 5: Manejar JavaScript con bibliotecas estáticas
El sitio carga datos vía AJAX después del HTML inicial. El scraper usa requests + BeautifulSoup y solo ve el HTML vacío. Resultado: cero datos extraídos.
Cómo identificarlo: Si el HTML que devuelve curl https://sitio.com no tiene los datos que ves en el navegador, necesitas un navegador real.
Cómo resolverlo:
- Opción A — Mejor: Identificar la API REST que llama el front. Muchas veces son endpoints documentados o fácilmente identificables en DevTools. Scrapear esa API directo es 50-100x más rápido que un navegador.
- Opción B: Usar Playwright o Selenium para sitios complejos. Más lento (10-30 segundos por página) pero funciona para todo.
- Opción C — Para sitios con detección avanzada: Playwright con configuración stealth, o Camoufox para fingerprinting realista.
Error 6: No normalizar ni validar los datos extraídos
El scraper saca “$1,250.00 MXN” como string y lo guarda así. El siguiente paso del pipeline intenta sumar precios y truena. Otro registro tiene “1250“. Otro “$1.250,00“. Tu base es un caos.
Cómo evitarlo: Capa de normalización inmediata después de la extracción:
- Precios → float en moneda única, símbolo guardado por separado
- Teléfonos → formato E.164 internacional usando bibliotecas como phonenumbers
- Emails → lowercase, validación de formato, dominio existente
- Fechas → ISO 8601, zona horaria explícita
- Direcciones → parseadas en componentes (calle, número, colonia, CP)
Error 7: Cero plan de mantenimiento
El pipeline se entrega “funcionando”. Tres meses después el sitio rediseña su frontend y nadie está mirando. Cuando lo descubren, ya hay un mes de datos perdidos.
Cómo evitarlo: Tratar el scraper como software vivo, no como entregable.
- Tests automatizados de regresión: diariamente, validar que los selectores funcionan contra el sitio real
- Plan de respuesta: cuando suena la alerta, quién mira y en cuánto tiempo
- Versionado de selectores: mantener historial de cambios para entender cuándo y por qué se modificaron
- Re-extracción incremental: después de un fix, re-extraer solo lo que se perdió, no todo desde cero
Anti-patrones que vemos seguido
Otros errores frecuentes que no merecen sección propia pero hay que mencionar:
- Guardar todo en CSV/Excel: bien para extracciones one-off, terrible para producción. Usar base de datos desde el día 1.
- Sin idempotencia: correr el scraper dos veces duplica los datos. Usar UNIQUE constraints o upsert siempre.
- Credenciales hardcoded en el código: usar variables de entorno o secret managers desde el principio.
- Sin logs estructurados: cuando algo falla, necesitas saber qué URL, qué selector y qué error. Logs en JSON con contexto.
- Demasiado JavaScript para tareas simples: usar Playwright para un sitio HTML estático es desperdiciar CPU y memoria.
- Cero documentación: 6 meses después nadie recuerda por qué ese sleep es de 7 segundos.
Cómo se ve un pipeline correctamente armado
Un scraper de producción digno se ve así:
- Capa de descubrimiento — genera URLs a scrapear con cola Redis, deduplicación y prioridad
- Capa de extracción — workers paralelos con la biblioteca correcta (HTTP simple, navegador headless o navegador stealth)
- Capa de normalización — validación, formateo y enriquecimiento de cada registro extraído
- Capa de persistencia — base de datos con índices, deduplicación y versionado
- Capa de monitoreo — métricas técnicas, calidad de datos y alertas tempranas
- Capa de entrega — exportación a CSV, ingesta a data warehouse o webhook a sistema cliente
- Capa de mantenimiento — tests de regresión diarios y plan de respuesta a fallas
Cada capa parece overhead cuando construyes el primero. Después de operar 47 scrapers en producción, cada capa nos ahorra semanas de trabajo de mantenimiento.
Cuándo construir y cuándo contratar
Si tu equipo tiene experiencia construyendo software de producción (no scripts), puede construir scrapers serios. La curva de aprendizaje es de 3-6 meses para llegar al nivel de defensividad necesario.
Si tu equipo necesita los datos ya y no quiere ser experto en scraping, contratar es más barato. Nuestros pipelines de extracción de datos en producción arrancan en 250 USD para casos simples y 1,500-5,000 USD para sistemas complejos con dashboard y monitoreo incluidos.
Servicios relacionados: