Si tu scraper se rompe cada semana, casi nunca es por un unico selector mal elegido. Suele ser porque todo el pipeline depende de supuestos fragiles y no deja evidencia suficiente cuando esos supuestos cambian.
Un scraper robusto es un sistema de produccion controlado. Necesita versionado de parsers, retries estables, limites sobre datos publicos, deteccion de cambios y trazabilidad suficiente para explicar por que un registro se guardo o se rechazo. Esa es la diferencia entre una extraccion puntual y un pipeline en el que una empresa puede apoyarse de verdad.
Por que se rompen tantos scrapers
Las webs cambian markup, nombres de clases, reglas de paginacion, lazy loading y flujos de control. Eso es normal. Lo que convierte un cambio normal en una incidencia cara es un mal diseno del sistema.
- los selectores dependen de ruido visual en vez de estructura estable
- navegacion, parseo y escritura en base de datos viven en un solo script
- los fallos no guardan capturas ni HTML de evidencia
- operaciones no puede reproducir un job roto con seguridad
- todos los errores usan la misma logica de retry
Por eso muchos equipos que arrancan con un script rapido acaban reconstruyendo alrededor de las mismas ideas que aparecen en una arquitectura limpia con Puppeteer o en otras stacks de automatizacion controlada.
Disena el scraper por capas, no como un script gigante
La forma mas directa de ganar estabilidad es separar responsabilidades.
scheduler
-> decide que URLs rastrear
worker
-> carga la pagina y guarda evidencia
extractor
-> devuelve campos en bruto
parser
-> normaliza valores y valida esquema
storage
-> escribe registros aceptados y auditoriaCuando esas capas existen, un ajuste de parser no obliga a tocar el navegador y un cambio de DOM no deberia contaminar el almacenamiento final. La estabilidad mejora porque cada fallo afecta a menos partes.
Estrategia de selectores, no selectores aleatorios
Un scraper que depende de cadenas largas de clases generadas esta pidiendo romperse. Conviene priorizar estructura, etiquetas, bloques repetidos o texto cercano estable. Si no queda otra, manten perfiles de selectores versionados para corregir sin improvisar.
Ese versionado importa para la trazabilidad. Si un cliente pregunta por que un campo empezo a fallar el lunes, quieres responder con evidencia y no con intuicion.
Errores comunes
El primer error es tratar las capturas como algo opcional. Si una pagina falla al parsearse, quieres screenshot, URL, version de parser y fragmento de HTML.
El segundo error es reintentar igual un schema error y un timeout. Un timeout puede recuperarse. Un selector roto normalmente no.
El tercer error es extraer datos publicos sin limites operativos. Aunque el dato sea publico, necesitas ritmo razonable, revision de fuentes, almacenamiento documentado y un objetivo de negocio claro.
El cuarto error es escribir directo en la tabla final sin validacion ni control de duplicados. Un solo cambio de markup puede ensuciar todo el dataset.
El quinto error es pensar que mas proxies arreglan una mala ingenieria. La red importa, pero el pipeline sigue necesitando arquitectura limpia y comportamiento predecible.
Checklist practico para un scraper robusto
- los jobs entran en cola con crawl profile y tipo de retry
- los workers guardan capturas y HTML cuando falla la extraccion
- selectores y parsers estan versionados
- la validacion de esquema se ejecuta antes de escribir en base de datos
- hay deteccion de duplicados antes del guardado final
- el uso de datos publicos esta documentado y limitado cuando aplica
- operaciones puede reproducir un job fallido en aislamiento
- la tasa de exito, parseo y latencia se ve en logs
- hay revision manual para registros ambiguos o valiosos
- el mantenimiento semanal se basa en diffs y evidencia
Detecta la rotura antes de que lo haga negocio
No quieres que la primera alerta llegue desde ventas u operaciones. Un mantenimiento serio vigila indicadores tempranos: caida de selectores, aumento de campos vacios, cambios en paginacion, picos de duplicados o rechazos de almacenamiento.
{
"job_id": "listing-2841",
"source": "marketplace-a",
"parser_version": "v6",
"result": "selector_miss",
"evidence_path": "s3://scrapers/evidence/listing-2841.png",
"retry_class": "manual_fix"
}Ese tipo de evidencia convierte el mantenimiento en ingenieria y no en apagar fuegos.
Cuando tiene sentido contratar a alguien tecnico
Si tu equipo ya tiene scripts, algunos registros llegan a base de datos y el negocio depende de esa salida, pero nadie confia en el pipeline cuando cambian los layouts, el problema ya no es la sintaxis de scraping. El problema es la propiedad tecnica del sistema.
Ahi es donde servicios tecnicos o apoyo directo de CTO tecnico fractional puede ahorrar tiempo y dinero. El valor esta en definir fronteras de parser, recogida de evidencia, flujos seguros sobre datos publicos y un mantenimiento estable.
Conclusion
Si quieres evitar que un scraper se rompa cada semana, deja de pensar en un script y piensa en un sistema. El navegador es solo una capa. La estabilidad llega por trazabilidad, aislamiento, validacion y disciplina operativa.
Si necesitas auditar o redisenar un pipeline de scraping inestable, usa contacto y trae las fuentes actuales, patrones de fallo, camino de almacenamiento y los limites que debes respetar. Ahi empieza el trabajo util.