Skip to main content
La mayoría de los sitios modernos ya no sirven su contenido como HTML estático. Frameworks como React, Vue y Angular construyen la página dinámicamente en el navegador: el servidor envía una estructura HTML mínima y paquetes de JavaScript, y el contenido real solo aparece cuando JavaScript se ejecuta en el cliente. Por eso un scraper HTTP básico basado en la biblioteca requests de Python suele devolver una página casi vacía: recupera el HTML sin procesar, pero no ejecuta el JavaScript que lo completaría con los datos deseados. Hay tres formas de resolverlo. La adecuada depende de cómo esté construido el sitio. La opción más barata es preferible cuando resulta aplicable, así que compruébalas en este orden.

​
Enfoque 1: representar la página en un navegador real

La solución universal consiste en ejecutar un motor de navegador real que procese JavaScript igual que el navegador de un usuario. La página se carga, los scripts se ejecutan, las API reciben llamadas y el contenido se representa; solo entonces el scraper extrae datos del DOM completo. Funciona con cualquier sitio representado mediante JavaScript, pero consume más recursos: cada página requiere una instancia del navegador con memoria y CPU reales. Elegir el motor es una decisión independiente: hay bibliotecas distintas (Puppeteer, Playwright y Selenium), API en la nube y ventajas e inconvenientes entre navegadores con interfaz y sin ella. Consulta Panorama de entornos de ejecución del navegador y Navegadores con interfaz frente a navegadores sin interfaz. La sobrecarga importa a gran escala, por lo que un motor específico puede costar considerablemente menos por página que un navegador estándar.

​
Enfoque 2: interceptar la API subyacente

Las páginas representadas mediante JavaScript obtienen su contenido de API backend mediante solicitudes XHR o fetch. Si identificas esos endpoints, puedes llamarlos directamente y recibir JSON estructurado sin representar un navegador. Es más rápido, ligero y fiable: no hay que esperar al DOM, los selectores no se rompen al cambiar el diseño y los datos ya llegan analizados. Estas API pueden carecer de documentación, requerir autenticación, limitar las solicitudes o cambiar sin previo aviso. Abre la página en un navegador real con el panel Red de DevTools, observa las solicitudes mientras se carga el contenido y busca llamadas XHR/fetch cuyas respuestas contengan los datos. Después puedes reproducirlas fuera del navegador, a veces con un solo comando curl. Octoparse incorpora este proceso a su editor visual. Su Navegador integrado ofrece el mismo panel de red que DevTools y permite seleccionar la respuesta de una API igual que un elemento del DOM. La tarea utiliza ese endpoint en lugar de representar la página. Así, el ciclo de abrir DevTools, localizar la llamada, copiar encabezados y reconstruir la solicitud se convierte en un único paso visual. Siempre que esté disponible, este es el enfoque más sólido para las páginas con JavaScript, y está disponible con más frecuencia de la que suele suponerse. Conviene comprobarlo antes de recurrir a un navegador.

​
Enfoque 3: detectar la representación del lado del servidor

Algunos sitios con frameworks del cliente también implementan representación del lado del servidor (SSR) o generación estática por rendimiento y SEO. En esos casos, la respuesta HTML inicial contiene todo el contenido y basta con una solicitud HTTP ligera. Consulta el código fuente (Cmd+U/Ctrl+U, no «Inspeccionar», que muestra el DOM activo); si los datos están en el HTML sin procesar, puedes evitar el navegador. Algunos sitios sirven contenido diferente según el User-Agent; por ejemplo, representan previamente las páginas para los crawlers de buscadores. Establecer el User-Agent como el de un bot conocido puede permitir en ocasiones acceder a una versión generada en el servidor. Utiliza esta posibilidad respetando siempre las condiciones del sitio.

​
Consejos prácticos cuando se necesita un navegador real

Los modos de fallo son previsibles:
  • Espera al elemento correcto, no al evento «load». El evento se activa cuando llegan el HTML y los recursos, aunque el contenido del cliente todavía no esté listo. Espera al selector o texto concreto.
  • Ten en cuenta la carga diferida. El contenido que solo aparece al desplazarse no existe hasta que el scraper hace scroll. Las bibliotecas de automatización pueden simularlo.
  • El enrutamiento del cliente confunde a los scrapers tradicionales. En una SPA, pasar de /products a /products/42 puede cambiar la URL sin una nueva solicitud HTTP. No esperes un evento pageload; espera cambios en el contenido.
  • El desplazamiento infinito y «cargar más» requieren interacción. Consulta Gestionar la Paginación.

​
Prueba primero el enfoque más barato

Sigue este orden:
  1. Consulta el código fuente. Si el contenido está en el HTML sin procesar, basta una solicitud HTTP.
  2. Examina las llamadas de red. Si la página obtiene contenido de una API, llama a la API directamente.
  3. Representa la página en un navegador real. Si nada de lo anterior funciona, ejecuta la página con el entorno adecuado.
Cada paso adicional aumenta la latencia, la infraestructura y el riesgo de roturas. Un sitio que exige representar el navegador cuesta órdenes de magnitud más que otro cuya API puede llamarse directamente, y el coste se acumula en miles de páginas. Cuando un flujo necesita varios enfoques según el tipo de página —SSR, API o representación completa—, una plataforma que permita cambiar de estrategia dentro de la misma tarea evita configurar e integrar tres cadenas de herramientas distintas.