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. Todos se pagan en el mismo lugar: semanas de tu equipo arreglando algo que no era su trabajo, mientras el dato que necesitabas llega tarde o llega mal. 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 ya construye software de producción, puede construir scrapers serios. Vale la pena saber qué se está comprando con esa decisión: llegar al nivel de defensividad que describimos arriba toma de tres a seis meses, y esos meses no aparecen en ninguna factura. Se pagan en el tiempo de tu gente y en los datos que llegaron mal mientras tanto.
Esa es la cuenta que casi nadie hace. Un desarrollador aprendiendo scraping en horas de trabajo cuesta lo mismo que un desarrollador entregando otra cosa, y mientras tanto el proyecto que sí genera dinero está esperando. Los siete errores de arriba se aprenden en producción, con datos reales de por medio, o se compran ya resueltos.
Si lo que necesitas son los datos y no volverte experto en scraping, nosotros armamos el pipeline completo: extracción de datos en producción con monitoreo, alertas y mantenimiento para cuando el sitio cambie, que va a cambiar. Escríbenos por WhatsApp con qué necesitas extraer y de dónde, y te decimos si conviene construirlo o si tu caso se resuelve con algo más chico.
Si todavía estás decidiendo con qué construirlo, la comparación de herramientas está en Playwright contra Selenium y Scrapy. Y si lo que extraes son datos de empresas para prospectar, ese pipeline ya lo tenemos armado en Outreach Suite, que es la herramienta que usamos nosotros para eso.
Servicios relacionados: