Todas las guías de "Scrapy vs. Selenium" en internet dicen más o menos lo mismo: Scrapy es más rápido, Selenium maneja JavaScript, elige tu veneno. La idea general no está mal, pero las afirmaciones universales sobre páginas por minuto no sirven. El rendimiento depende del sitio objetivo, la red, la concurrencia, el ciclo de vida del navegador, las esperas y los controles antibots.
Esta guía compara las arquitecturas y las decisiones operativas que realmente se mantienen de un proyecto a otro. También cubre lo que la mayoría de comparativas omite: cómo la automatización de navegador cambia el modelo de recursos, por qué el renderizado selectivo suele ganar a un rastreo con navegador completo y cuándo una API de extracción gestionada encaja mejor que cualquiera de los dos frameworks.
Veredicto rápido: Scrapy vs. Selenium en 2026
Si quieres la versión corta: Scrapy gana en velocidad, escala y eficiencia de recursos para cualquier cosa renderizada en el servidor. Selenium gana cuando necesitas un navegador real haciendo cosas de navegador real: hacer clic, escribir, esperar a que aparezca un modal con animación. Ninguno de los dos es especialmente bueno frente a las defensas antibot modernas de fábrica, y Playwright se ha comido en silencio la mayoría de los casos de uso para los que antes se recurría a Selenium.
Esta es la matriz de decisión que yo realmente uso:
| Tu situación | Lo mejor es |
|---|---|
| Páginas estáticas o renderizadas en servidor, alto volumen | Scrapy |
| SPA con mucho JS, logins, clics y flujos de varios pasos | Selenium o Playwright |
| Sitio mixto: sobre todo estático, con algunas secciones solo JS | Híbrido Scrapy + Playwright |
| URLs conocidas, solo necesitas datos estructurados y poco mantenimiento | API de extracción con IA (Thunderbit y similares) |
A mediados de 2026, Scrapy 2.17.0 ya está disponible, Selenium 4 sigue ampliando el soporte de WebDriver BiDi, y scrapy-playwright ofrece una forma mantenida de enviar solicitudes concretas de Scrapy a través de un navegador. Ten esa matriz de decisión a mano: el resto del artículo explica por qué funciona.
Qué son Scrapy y Selenium (y por qué los desarrolladores siguen discutiendo sobre ellos)
Comparar Scrapy con Selenium es un poco como comparar un camión de reparto con un coche. Ambos llevan cosas del punto A al punto B, pero uno fue creado para mover volumen de forma eficiente y el otro para ser conducido por una persona que necesita interactuar de verdad con la vía. El debate sigue vivo porque ambos pueden hacer scraping; simplemente están pensados para trabajos distintos, y muchos equipos eligen el equivocado antes de darse cuenta.
Scrapy: el motor de rastreo asíncrono
Scrapy es un framework solo para Python construido sobre el modelo de E/S no bloqueante y orientado a eventos de Twisted. No es un navegador —nunca lo fue—, solo lanza solicitudes HTTP y analiza el HTML que devuelve la respuesta. Ese es todo el truco. Como no tiene que esperar a que un navegador renderice nada, puede disparar docenas de solicitudes a la vez sin bloquearse.
De serie, Scrapy incluye spiders, pipelines de ítems, exportadores de feeds, middleware de reintentos y limitación de velocidad. No es un framework de "tendrás que construir esto tú mismo": muchas necesidades de producción ya vienen resueltas. La documentación de arquitectura de Scrapy describe Engine, Scheduler, Downloader e Item Pipeline como componentes separados y reemplazables, y precisamente por eso el framework ha envejecido tan bien: puedes añadir piezas sin reescribir el núcleo.
El límite es claro: sin navegador no hay ejecución de JavaScript. Si tus datos se cargan mediante una llamada fetch del lado del cliente después de que la página renderiza, Scrapy no verá nada de eso. Solo lee el HTML inicial, punto.
Selenium: el navegador que puedes programar
Selenium controla navegadores reales —Chrome, Firefox, Edge— a través del protocolo W3C WebDriver, una especificación estándar que hace que Selenium sea independiente del lenguaje y del navegador, en lugar de ser un truco exclusivo de Chrome. Renderiza JavaScript, ejecuta llamadas AJAX y puede hacer clic, desplazarse y escribir exactamente como lo haría una persona.
Eso convierte a Selenium en la opción adecuada para cualquier cosa que dependa de interacción: logins de varios pasos, asistentes, scroll infinito, menús desplegables que disparan llamadas a la API. Pero cada sesión de navegador pesa mucho. La propia guía de dimensionamiento de Grid de Selenium sugiere reservar aproximadamente 1 GB de RAM por sesión de navegador solo como referencia de planificación, y eso antes de sumar la carga de CPU de renderizar páginas de verdad.
Un detalle que siempre confunde a la gente: que termine la carga de la página no significa que la interfaz esté lista. La documentación de Selenium advierte además contra mezclar esperas implícitas y explícitas porque los tiempos de espera resultantes se vuelven impredecibles muy rápido. Si tu script de Selenium falla de forma intermitente, normalmente esa es la razón.
Scrapy vs. Selenium: rendimiento sin cifras universales inventadas
Un benchmark fiable tiene que publicar las páginas objetivo, el estado de caché, las condiciones de red, la concurrencia, la estrategia de reutilización del navegador, las condiciones de espera y el código completo. Sin ese contexto, una cifra de páginas por minuto es marketing, no evidencia. Aun así, la comparación arquitectónica sigue siendo útil:
| Característica de la carga | Scrapy | Selenium | Scrapy-Playwright |
|---|---|---|---|
| HTML renderizado en servidor | Ruta HTTP directa | Ruta de navegador completo | Usa la ruta directa de Scrapy |
| Contenido renderizado con JavaScript | Requiere un renderizador adicional | Ejecución nativa en navegador | Renderizado selectivo en navegador |
| Modelo de concurrencia | Programador asíncrono de solicitudes | Sesiones de navegador gestionadas por tu código o Grid | Programador de Scrapy + contextos de navegador |
| Perfil de recursos | Sin sobrecarga de renderizado del navegador | Sobrecarga de CPU y memoria del navegador | Coste de navegador solo para solicitudes etiquetadas |
| Mejor métrica | Ítems por minuto con tasa de error segura | Flujos completados por minuto con tasa de error segura | Medir por separado solicitudes estáticas y renderizadas |
La configuración concurrente por defecto de Scrapy es un límite superior, no una cifra prometida de rendimiento. La velocidad real depende de la latencia, los límites por dominio, el throttling, los reintentos, el tamaño de las respuestas, el trabajo de análisis y la tasa de solicitudes aceptable del sitio objetivo.
Selenium puede reutilizar una sesión de navegador, así que no está limitado por definición a lanzar un navegador nuevo por página, pero cada sesión activa sigue ejecutando y renderizando un entorno de navegador.
El modelo híbrido resulta atractivo porque mantiene las solicitudes normales en la ruta HTTP de Scrapy y envía al navegador solo las páginas que necesitan renderizado. Eso suele reducir el trabajo del navegador, pero no es automáticamente más rápido: mide por separado las rutas estática y renderizada, incluye las tasas de fallo y reintento, y ajusta la concurrencia tanto por seguridad para el sitio como por la memoria disponible.
Diferencias clave que determinan tu decisión
La velocidad no es la única variable. Hay varios factores prácticos que pesan tanto como ella cuando esto ya corre en producción.
Renderizado de JavaScript y contenido dinámico
Scrapy, por sí solo, no ve nada que se renderice del lado del cliente. Selenium lo ve todo porque es un navegador real. El punto medio —Scrapy-Splash (más antiguo, scriptable con Lua) y scrapy-playwright (más moderno y recomendado)— permite renderizar JavaScript de forma selectiva dentro del ciclo de rastreo de Scrapy, en lugar de comprometerse con un navegador completo para cada solicitud. Si el 80-90% de tus páginas objetivo son HTML estático y solo unas pocas necesitan JS, el renderizado selectivo es la arquitectura evidente. Renderizar todo con un navegador porque algunas páginas lo necesitan es un gasto innecesario de cómputo.
Escalabilidad y concurrencia
Escalar Scrapy de 1.000 páginas a 1.000.000 es, sobre todo, una conversación de aprovisionamiento: añadir más solicitudes concurrentes y quizá distribuir el trabajo entre workers con Redis. Escalar Selenium significa añadir instancias de navegador de forma lineal, lo que a su vez implica añadir RAM y CPU de forma lineal, así que ahora estás gestionando una granja de navegadores con Selenium Grid y lidiando con recuperación ante fallos. No es que Selenium no escale; es que escalarlo es un proyecto de infraestructura, no un simple cambio de configuración.
Pipeline de datos y exportación
El pipeline de ítems de Scrapy se encarga de la validación, la deduplicación y la exportación a JSON, CSV o una base de datos como función integrada. Selenium no te da nada de eso: tienes que escribir tú mismo la lógica de serialización y almacenamiento desde cero. Si la calidad de los datos y la integración posterior importan de verdad —y deberían—, este es un ventaja muy real que Scrapy te da gratis.
Mantenimiento y fiabilidad a largo plazo
He visto un patrón muy claro: los spiders de Scrapy suelen envejecer razonablemente bien porque la arquitectura basada en middleware impone cierta estructura. Los scripts de Selenium se vuelven frágiles: las actualizaciones del navegador rompen drivers, los problemas de sincronización provocan ejecuciones inestables y cualquier cambio en el DOM obliga a actualizar selectores. He visto desarrolladores en foros decir sin rodeos que un scraper basado en Selenium "no parece la mejor opción para algo que vayamos a vender a un cliente", y sinceramente, esa intuición es correcta si el proyecto tiene que sobrevivir más de unos pocos meses sin tocarse.
Realidad antibots: cómo le va a cada herramienta frente a las defensas de 2026
Esta es la parte que casi todas las comparativas pasan por alto, y la que de verdad determina si tu scraper funciona o no. Ni Scrapy ni Selenium fueron creados pensando en la infraestructura antibot moderna, y fingir lo contrario solo te prepara para una mala sorpresa en producción.
| Capa de defensa | Scrapy | Selenium | Scrapy-Playwright | API de Thunderbit |
|---|---|---|---|---|
| Renderizado JS | ❌ Necesita middleware | ✅ | ✅ | ✅ Integrado |
| Huella TLS | ⚠️ Detectable | ⚠️ Detectable | ⚠️ Mejor, pero no resuelto | ✅ Gestionado |
| Resolución de CAPTCHA | ❌ Manual | ❌ Manual | ❌ Manual | ✅ Integrado |
| Rotación por rate limit | ⚠️ Proxies DIY | ⚠️ Proxies DIY | ⚠️ Proxies DIY | ✅ Gestionado |
Scrapy falla directamente en las comprobaciones de huella del navegador porque, de hecho, no hay navegador que perfilar: es solo un cliente HTTP, y muchos proveedores antibot marcan el tráfico que no parece venir de un navegador real. Selenium supera las comprobaciones básicas de JS porque sí es un navegador real, pero se puede detectar mediante señales como navigator.webdriver, un indicador estandarizado que vale true bajo automatización. Parchear esto con herramientas como undetected-chromedriver intenta disimularlo, pero es una carrera contra los equipos de detección, que actualizan sus firmas con regularidad.
La carrera del sigilo (y por qué hacerlo tú mismo es frágil)
Aquí está la verdad incómoda sobre los parches anti-detección: son una cinta de correr de mantenimiento, no una solución. undetected-chromedriver y playwright-stealth funcionan hasta que Cloudflare Turnstile o DataDome lanza una actualización que detecta justo la técnica que estaban usando. Entonces toca parchear otra vez. He visto equipos gastar más tiempo de ingeniería manteniendo viva su capa de sigilo que el que dedicaron a construir el scraper real.
La limitación de frecuencia merece mención aparte. Cuando un servidor devuelve 429 Too Many Requests, el encabezado Retry-After es una sugerencia, no una orden: muchos sitios ni siquiera lo envían y algunos te limitan por otras señales por completo. El AutoThrottle de Scrapy ayuda ajustando el retardo según la latencia observada, pero reacciona, no previene.
Aquí es donde una API de extracción gestionada demuestra su valor: el manejo antibot pasa a ser problema de otro en lugar de tuyo. Más adelante vuelvo sobre esto.
El factor Playwright: por qué "Scrapy vs. Selenium" ya no cuenta toda la historia
Plantearlo como un debate entre dos herramientas se queda corto frente a lo que realmente ha pasado en la comunidad de scraping en los últimos años. Los foros de desarrolladores están llenos de gente diciendo algo como "me cambié de Selenium a Playwright y quedé bastante contento"; aun así, la mayoría de los artículos comparativos menciona Playwright solo de pasada, si es que lo menciona.
Playwright, creado por Microsoft, controla Chromium, Firefox y WebKit a través de una única API. Su modelo de accionabilidad espera a que los elementos estén visibles, estables y realmente interactivos antes de ejecutar una acción, lo que reduce los fallos relacionados con sincronización que afectan a muchos scripts de Selenium. Además, gestiona contextos de navegador de forma más eficiente, permitiéndote levantar sesiones aisladas sin el coste de lanzar un navegador completamente nuevo cada vez.
Cuándo Playwright sustituye por completo a Selenium
Para scraping en concreto —no para pruebas de navegador con infraestructura Selenium ya existente— Playwright suele ser simplemente la mejor herramienta en 2026. Creación de contextos más rápida, menor consumo de recursos por página, soporte asíncrono nativo e interceptación de red integrada. Si vas a empezar un proyecto de scraping desde cero y no tienes una suite de pruebas de Selenium que preservar, no hay demasiados motivos para elegir Selenium primero.
La excepción: si tu equipo ya tiene infraestructura de pruebas con Selenium, o necesitas una personalización muy concreta del perfil del navegador que Playwright no soporta con tanta limpieza, Selenium sigue teniendo sentido.
Cómo funciona scrapy-playwright
scrapy-playwright es un download handler para Scrapy que envía solo las solicitudes marcadas con meta={"playwright": True} a través de un navegador real; todo lo demás sigue por la ruta HTTP asíncrona y rápida de Scrapy. Aquí va un spider simplificado que rastrea un catálogo paginado donde las tarjetas de producto se renderizan con JS del lado del cliente:
import scrapy
class CatalogSpider(scrapy.Spider):
name = "catalog"
def start_requests(self):
yield scrapy.Request(
"https://example.com/products?page=1",
meta={"playwright": True, "playwright_include_page": True},
)
async def parse(self, response):
page = response.meta["playwright_page"]
products = response.css("div.product-card")
for product in products:
yield {
"title": product.css("h3::text").get(),
"price": product.css(".price::text").get(),
}
next_page = response.css("a.next::attr(href)").get()
if next_page:
yield scrapy.Request(
response.urljoin(next_page),
meta={"playwright": True, "playwright_include_page": True},
)
await page.close()
Solo las páginas que realmente necesitan renderizado pasan por el navegador. Ese es el objetivo del enfoque híbrido: no pagas el coste del navegador en cada solicitud, solo en las que lo requieren.
Scrapy-Splash vs. Scrapy-Playwright: qué middleware usar
Scrapy-Splash requiere levantar un servicio Docker separado de Splash y escribir scripts Lua para interactuar; funciona, pero es una configuración más pesada y antigua. scrapy-playwright se integra directamente en el bucle asíncrono de Scrapy, soporta los tres motores principales de navegador y gestiona interacciones complejas sin añadir un segundo lenguaje de scripting. Si empiezas un proyecto nuevo en 2026, realmente no hay razón para seguir recurriendo a Splash.
Arquitectura híbrida lista para producción
La mayoría de los artículos dice "puedes combinar Scrapy y Selenium" y lo deja ahí. Eso no es una arquitectura. Eso es una sugerencia. Así luce de verdad una configuración de producción.
El flujo: un programador de Scrapy enruta solicitudes a través de un router de URLs que comprueba si una página es estática o dinámica. Las solicitudes estáticas pasan directamente por el descargador estándar de Scrapy. Las solicitudes dinámicas se etiquetan y se envían al middleware de Playwright, que gestiona un conjunto de contextos de navegador. Ambas rutas convergen de nuevo en el mismo pipeline de ítems para validación, deduplicación y exportación; tanto si los datos proceden de HTML sin procesar como de un DOM renderizado, terminan en la misma salida JSON, CSV o base de datos.
Algunas notas de despliegue si vas a llevar esto a producción: usa Docker para que los binarios del navegador de Playwright se distribuyan de forma consistente entre entornos, limita los contextos concurrentes de Playwright según la RAM disponible (yo no pasaría de 8-10 contextos en una máquina estándar de 4 GB) y ejecuta los trabajos programados mediante cron o un pipeline de CI/CD en lugar de dejar un proceso corriendo indefinidamente.
Esta configuración te da el máximo control. También significa que ahora eres responsable de las actualizaciones de los binarios del navegador, de los fallos en el ciclo de vida de los contextos (las páginas sin cerrar pueden bloquear un rastreo), de la rotación de proxies y de los parches antibot que tengas que añadir. Es un compromiso de ingeniería real, y merece la pena ser honesto con eso antes de asumirlo.
Para los equipos que quieren la salida estructurada sin hacerse cargo de esa infraestructura, la CLI de Thunderbit aborda el mismo problema desde otro ángulo:
thunderbit batch extract --schema schema.json --file urls.txt
La misma salida JSON estructurada. Sin código de spider, sin pool de navegadores, sin mantenimiento de la capa antibot. Cambias algo de personalización por rapidez de puesta en producción; es un intercambio legítimo, no una mejora universal, y depende por completo del nivel de control que tu proyecto necesite de verdad.
La vía de "sáltate el framework": cuándo una API de scraping con IA supera a ambas opciones
Llega un punto en que un desarrollador se da cuenta de que en realidad no necesita un framework de rastreo. Necesita datos estructurados de 500 URLs conocidas, y montar un spider, un pool de navegadores y una capa antibot para eso parece excesivo —porque normalmente lo es.
Ese es el hueco que Thunderbit está diseñado para cubrir, y lo digo desde el principio: no sustituye a Scrapy en un rastreo complejo, recursivo y con lógica personalizada. Es una herramienta distinta para un problema distinto y más acotado.
API abierta: POST /extract recibe un JSON Schema y devuelve datos estructurados que coinciden con él —no HTML en bruto, ni un montón de Markdown que tengas que parsear tú. POST /distill hace el trabajo inverso y devuelve Markdown limpio listo para alimentar una tubería RAG o un LLM. El servicio gestionado admite renderizado de JavaScript y manejo antibot, así que no tienes que encargarte de esa infraestructura. La guía actual Distill vs. Extract indica 1 crédito por página Distill y 20 por página Extract; revisa la documentación en vivo antes de presupuestar porque las condiciones del producto pueden cambiar.
Servidor MCP: para agentes de IA como Claude o Cursor, el servidor MCP de Thunderbit expone distillación, extracción estructurada, sugerencia de campos y trabajos por lotes como herramientas, permitiendo que un agente obtenga datos web actualizados durante una tarea sin salir de su entorno.
CLI: la CLI de Thunderbit documentada admite comandos como thunderbit extract <url> --schema schema.json y encaja perfectamente en flujos de terminal y tareas programadas. También puedes encadenar el Markdown distillado con otra herramienta para investigaciones puntuales rápidas.
Si prefieres evitar escribir código por completo, la extensión de Chrome de Thunderbit cubre el mismo terreno con una interfaz de apuntar y hacer clic, algo que merece la pena mirar si en tu equipo hay personas no técnicas que necesitan datos sin tocar una terminal. He escrito más sobre el panorama general de web scraping con IA y web scraping sin programar si quieres una visión más completa.
Sé honesto contigo mismo sobre en qué grupo estás: Scrapy sigue siendo la mejor opción para rastreos complejos en varios sitios con lógica personalizada y seguimiento recursivo de enlaces. Selenium o Playwright, para flujos con mucha interacción. Pero "necesito datos estructurados de estas URLs conocidas" es un problema más específico de lo que cualquiera de esas herramientas fue pensada para resolver, y una API puede eliminar de verdad el código del spider, la infraestructura antibot y el mantenimiento continuo que implica poseer esa infraestructura tú mismo.
Scrapy vs. Selenium vs. Playwright vs. API de IA: comparación lado a lado
| Función | Scrapy | Selenium | Scrapy-Playwright | Thunderbit API |
|---|---|---|---|---|
| Compatibilidad de lenguajes | Solo Python | Python, Java, C#, JS, Ruby | Python | REST (cualquier lenguaje) |
| Renderizado de JS | No (necesita middleware) | Sí | Sí | Sí, integrado |
| Asíncrono/concurrencia | Nativo, alta | Limitada por instancia | Nativo vía Scrapy | Gestionado en servidor |
| Manejo antibot | Hecho a medida | Hecho a medida | Parcial | Integrado |
| Pipeline/exportación de datos | Integrado | Hecho a medida | Integrado | JSON estructurado de salida |
| Complejidad de configuración | Media | Baja para empezar, alta a escala | Media a alta | Mínima |
| Carga de mantenimiento | Baja-media | Alta | Media | Casi nula |
| Mejor para | Rastreo estático de alto volumen | Flujos con mucha interacción | Sitios mixtos estáticos/dinámicos | URLs conocidas, salida estructurada |
Si estás comparando otras opciones de scraping más allá de estas cuatro, también merece la pena echar un vistazo a cómo se posicionan las alternativas a Instant Data Scraper y los mejores scrapers web con IA: el mercado se ha llenado y no todas las herramientas resuelven el mismo problema.
Notas legales y éticas para el web scraping en 2026
Lo resumo porque no es el foco principal, pero importa. La configuración ROBOTSTXT_OBEY de Scrapy hará que tu spider respete las reglas de robots.txt: buena práctica, aunque conviene saber que el propio Robots Exclusion Protocol afirma explícitamente que sus reglas no son una autorización legal de acceso. Selenium y Playwright no tienen cumplimiento de robots.txt integrado; eso depende por completo de ti. Independientemente de la herramienta, revisa los términos de servicio del sitio y la legislación aplicable en tu jurisdicción antes de hacer scraping y reutilizar datos; que algo sea público no significa automáticamente que sea legal usarlo en todas partes.
Cómo elegir la herramienta adecuada para tu proyecto de scraping en 2026
La decisión realmente se reduce a cuatro preguntas: qué tipo de contenido es, cuál es la escala, cuánta interacción necesitas y cuánto mantenimiento continuo estás dispuesto a asumir. Si son páginas estáticas a gran escala, ve con Scrapy. Si son páginas con mucho JS y hay interacción real, usa Selenium o Playwright. Si es una mezcla de ambas, monta el híbrido. Si son URLs conocidas y solo necesitas salida estructurada con poco mantenimiento, una API como la de Thunderbit probablemente te ahorre más tiempo del que cuesta.
"Scrapy vs. Selenium" nunca fue realmente la pregunta completa; simplemente era el único marco de referencia disponible. Playwright cambió el terreno intermedio, y las APIs de extracción con IA crearon una vía totalmente nueva para quienes se dieron cuenta de que estaban construyendo infraestructura en lugar de resolver un problema de negocio. Vale la pena probar el plan gratuito antes de comprometerse con cualquiera de los dos caminos: suggest-fields es gratis y distill consume un solo crédito, así que puedes comprobar si la vía de la API encaja antes de escribir una sola línea de código de spider.
Preguntas frecuentes
¿Scrapy es más rápido que Selenium para hacer web scraping? En mis pruebas, sí; muchas veces por un orden de magnitud en páginas estáticas, porque la arquitectura asíncrona de Scrapy evita por completo la sobrecarga del navegador. Esa diferencia se reduce cuando Scrapy usa middleware de Playwright en páginas con mucho JS, pero Scrapy sigue ganando en rendimiento total en cargas mixtas porque las páginas sin JS siguen por la ruta rápida.
¿Scrapy puede manejar páginas renderizadas con JavaScript?
No por sí solo: Scrapy solo ve la respuesta HTML inicial. Añadir scrapy-playwright o el más antiguo Scrapy-Splash como middleware permite renderizar selectivamente solicitudes concretas a través de un navegador real mientras el resto del rastreo sigue por la ruta nativa y más rápida de Scrapy.
¿Cuándo debería usar Selenium en lugar de Scrapy? Cuando necesitas interacción completa con el navegador —logins de varios pasos, clics a través de asistentes, relleno de formularios— y el número de páginas es moderado, no masivo. También es la elección sensata si ya tienes infraestructura de pruebas basada en Selenium que quieras reutilizar para scraping.
¿Es Playwright mejor que Selenium para scraping en 2026? Para scraping en concreto, en general sí: Playwright suele ofrecer mejor rendimiento, autoespera integrada y una huella de recursos más ligera por contexto de navegador. Selenium todavía conserva ventaja para equipos que ejecutan suites consolidadas de pruebas multiplataforma que Playwright no fue creado para reemplazar.
¿Qué es una API de scraping con IA y cuándo sustituye a Scrapy o Selenium? Una API de scraping con IA, como la Open API de Thunderbit, gestiona el renderizado de JS, las defensas antibot y la extracción de datos en el lado del servidor, y devuelve JSON estructurado que coincide con el esquema que definas. Es la opción correcta cuando tienes URLs conocidas y necesitas salida estructurada sin construir ni mantener la infraestructura de rastreo; no sustituye a Scrapy en rastreos complejos, recursivos y con lógica personalizada.
Saber más
