Saltar al contenido

Cómo construir un scraper que no se rompe con cada cambio de la web

6 min de lectura Software
  • scraping
  • python
  • playwright
  • mantenimiento
  • software

Un scraper que falla cada vez que la web objetivo cambia su HTML no sirve en producción. Muchos proyectos de extracción de datos empiezan con un script rápido que funciona un día y se rompe al siguiente. La realidad es que construir un sistema de scraping robusto es más un ejercicio de ingeniería de software que de magia.

Mi experiencia me dice que la clave no está solo en la herramienta que elijas, sino en la estrategia de diseño y, sobre todo, de mantenimiento.

La fragilidad de un scraper mal diseñado

Los sitios web no son APIs estables; cambian su estructura HTML, sus clases CSS o incluso su JavaScript sin previo aviso. Si tu scraper depende de selectores CSS muy específicos o de la posición exacta de un elemento, está condenado a romperse. Esto es una fuente constante de frustración y un desperdicio de tiempo.

El problema no es que la web cambie, sino que tu scraper no esté preparado para ese cambio.

La base de un scraping robusto con Playwright y Python

Para construir un scraper que aguante, uso Python por su ecosistema y Playwright por su capacidad de interactuar con la web como un navegador real. Playwright no solo carga la página, también ejecuta JavaScript, maneja cookies y puede simular interacciones de usuario. Esto lo hace ideal para páginas dinámicas o que requieren login.

Lo que sí hago es evitar selectores CSS o XPath demasiado largos y específicos. Prefiero buscar atributos únicos, IDs o texto visible que sean menos propensos a cambiar.

from playwright.sync_api import sync_playwright

def obtener_datos_producto(url: str) -> dict:
    with sync_playwright() as p:
        browser = p.chromium.launch()
        page = browser.new_page()
        page.goto(url)

        titulo = page.inner_text("h1.product-title") # Selector más genérico
        precio = page.locator("data-testid=product-price").inner_text() # Usando data-testid
        
        browser.close()
        return {"titulo": titulo, "precio": precio}

# Ejemplo de uso:
# datos = obtener_datos_producto("https://ejemplo.com/producto/123")
# print(datos)

Estrategias de mantenimiento y alerta temprana

Un scraper robusto necesita un sistema de mantenimiento activo. Esto significa monitorizar su funcionamiento y recibir alertas cuando algo falla. No puedes esperar a que un cliente te diga que los datos están desactualizados.

Mi regla es clara: cada scraper que monto en producción tiene un sistema de notificación. Uso servicios como Telegram o Slack para recibir mensajes automáticos si el scraper no puede acceder a la web, si los selectores no encuentran los elementos esperados o si el volumen de datos extraídos cae drásticamente. Un buen sistema de notificaciones es tu primera línea de defensa.

Además, los tests automatizados resultan clave. Escribo tests que verifican que los selectores siguen funcionando y que los datos extraídos tienen el formato esperado. Esto es una inversión inicial que ahorra mucho dinero en el futuro al atrapar fallos antes de que lleguen a producción.

Gestión de credenciales y proxys

Si el scraping requiere autenticación o es susceptible a bloqueos por IP, la gestión de credenciales y proxys es necesaria. Nunca hardcodeo secretos en el código. Para esto, utilizo variables de entorno o un gestor de secretos. Esto no solo mejora la seguridad, sino que facilita el despliegue y la configuración.

Por ejemplo, si el scraper necesita un login, las credenciales de usuario se cargan desde el entorno, no se escriben directamente. Esto es una buena práctica general para gestionar secretos en cualquier software.

El tradeoff honesto al construir un scraper robusto

Lo que ganas:

  • Fiabilidad: Un flujo de datos constante y de calidad.
  • Menos interrupciones: El scraper aguanta mejor los cambios en la web objetivo.
  • Ahorro de tiempo: Menos horas dedicadas a depurar y arreglar scripts rotos.
  • Escalabilidad: Puedes extraer más datos con menos preocupaciones.

Lo que complicas:

  • Complejidad inicial: Requiere más tiempo de diseño y desarrollo, incluyendo la configuración de tests y alertas.
  • Recursos: Playwright, al lanzar un navegador, consume más RAM y CPU que una simple petición HTTP.
  • Mantenimiento activo: Necesitas revisar periódicamente las alertas y ajustar el scraper si los cambios son muy drásticos.

Lo que no negocias:

  • Alertas: Siempre debe haber un sistema que te notifique si el scraper falla.
  • Tests: Los tests automatizados son tu red de seguridad contra cambios inesperados.
  • Gestión de errores: El scraper debe manejar errores de red, bloqueos y datos faltantes de forma elegante, sin romperse por completo.

Si necesitas automatizar la extracción de datos de forma fiable, la inversión en un scraper robusto siempre se paga. Para la puesta en marcha de estos sistemas, las GitHub Actions son una herramienta potente para automatizar tareas de despliegue y ejecución. Si tus necesidades de automatización van más allá del scraping, tengo una sección dedicada a automatizaciones para negocios donde explico cómo integro estas herramientas para resolver problemas reales.

Lucas Juárez
Lucas Juárez

Técnico freelance especializado en desarrollo a medida, automatizaciones con IA y gestión técnica para negocios en España. Más sobre mí →

Compartir:

¿Necesitas desarrollo a medida?

Desarrollo funcionalidades específicas, integraciones entre sistemas y herramientas internas. Si se puede programar, probablemente puedo hacerlo.

Chat