A Scrapy se la suele encasillar como una herramienta que “no puede con los sitios modernos” porque no ejecuta JavaScript. En realidad, esa idea está al revés. No renderizar la página es justamente el enfoque, y en cuanto entiendes cómo funciona, deja de parecer una carencia.
Yo mismo lo comprobé en una sola ejecución. Monté una maqueta de catálogo renderizada con JavaScript, apunté Scrapy a la página tal como la vería un navegador y obtuve 0 tarjetas de producto. Luego dirigí la misma araña al endpoint JSON que esa página llamaba en segundo plano y recuperé 8/8 elementos, limpios. Misma herramienta y misma sesión, resultados opuestos: esa diferencia entre ambos números es precisamente el eje de toda esta reseña.
Qué es realmente Scrapy (y qué no)
Scrapy es un framework en Python para rastrear sitios y extraer datos estructurados. Esa es la definición que dan sus propios mantenedores en la documentación general, y después de usarlo encaja perfectamente: no hace falta adornarlo con marketing. Tiene la madurez suficiente como para ser la respuesta automática cuando un desarrollador de Python pregunta con qué trabajan quienes se toman el scraping en serio. Y el repositorio lo respalda: alrededor de 62,981 estrellas en GitHub al 2026-07-07 (scrapy/scrapy), además de 11,773 forks y 590 incidencias abiertas ese mismo día. Licencia BSD-3-Clause, Python 3.10 o superior, y la versión que puse a prueba fue 2.17.0, que casualmente se publicó la misma mañana en que corrí estas pruebas; así que aquí no hay asterisco por estar usando una versión antigua.
La línea que lo separa de la nueva ola de rastreadores con IA es esta: Scrapy, por defecto, solo trabaja por HTTP. Sin navegador. Sin motor de renderizado. Descarga el HTML por la red, se lo pasa a un parser y te permite extraer campos con selectores CSS o XPath. Llamarlo limitación es quedarse corto y no entender el diseño. La premisa de Scrapy es que levantar Chrome en modo headless para una extracción rutinaria suele ser mala idea; lo más inteligente es encontrar la petición de datos que la página ya hace y atacarla directamente.
Esa premisa no es una interpretación mía del producto. La documentación oficial sobre contenido dinámico lo dice de forma explícita: primero localiza y reproduce la petición de datos subyacente, y recurre a un navegador sin interfaz solo como último recurso cuando reproducir esa petición no sea viable. La mayoría de scrapers abre el navegador primero y ni siquiera piensa en la API. Scrapy invierte ese orden por defecto.
Funciones clave y la decisión de diseño detrás de cada una
Por dentro, Scrapy combina varias piezas que parten de una misma idea: que eres un desarrollador que quiere control, no un asistente de un clic.
Spiders. Escribes una clase, le das URLs iniciales y defines una función de callback parse que devuelve elementos o sigue más enlaces. Eso exige más trabajo que un extractor no-code —las reglas de extracción las escribes tú—, pero a cambio obtienes control exacto sobre qué se captura y hacia dónde avanza el rastreo.
Selectores. El análisis se apoya en parsel, que a su vez usa lxml. CSS y XPath son de primera clase, no añadidos. Gracias a lxml, la selección sigue siendo rápida y el código de extracción se lee como una intención clara, no como un enredo de trozos de cadenas.
Exportación de feeds. Si apuntas una araña a un archivo, Scrapy serializa tus elementos a JSON, JSON Lines, CSV o XML sin que tengas que montar nada más. En mi prueba, una araña de catálogo estático generó JSON y CSV sin que yo escribiera una sola línea de código de exportación: la funcionalidad de feed export es real y cumple lo prometido.
AutoThrottle y controles de rastreo. Las peticiones se programan de forma asíncrona sobre Twisted, y dispones de límites de concurrencia, retrasos de descarga, restricciones de profundidad, AutoThrottle para ajuste adaptativo de la velocidad y respeto de robots.txt. Son los controles que evitan que un rastreo amplio termine convirtiéndose en un problema para el servidor.
Solo HTTP, dicho como ventaja. No usar navegador implica menos memoria, más rendimiento y cero mantenimiento de un motor de renderizado, siempre que los datos que buscas sean accesibles por HTTP. Y, más a menudo de lo que cree el mundo “browser-first”, lo son.
Instalación: la pila de dependencias que nadie captura en una captura
La instalación fue un trámite, y para un framework de este tamaño merece decirse sin rodeos. pip install Scrapy==2.17.0 terminó correctamente en un entorno virtual nuevo en macOS arm64, descargando wheels binarios y sin compilar nada hasta estrellarse contra la pared. No hubo nada dramático que contar, y justamente ese es el punto.
Eso sí, mira lo que entró por la puerta. scrapy version -v informó de Scrapy 2.17.0 apoyado en lxml 6.1.1, Twisted 26.4.0, pyOpenSSL 26.3.0 y cryptography 49.0.0, con parsel, cssselect y tldextract completando el conjunto. Es una huella real: la de todo un framework de rastreo, no la de un simple parser HTML de un archivo. En esta máquina había wheels para todo y la instalación fue sin dolor. En otros entornos, la documentación oficial sigue advirtiendo de fricciones con dependencias específicas de la plataforma, y tradicionalmente donde más se nota es en cryptography y Twisted, así que conviene preverlo si trabajas en un sistema poco común. Aquí la configuración fue fluida; aun así, el tamaño de lo que se instala sigue siendo un dato útil antes de comprometerte, porque estás metiendo un framework completo y pesa lo que pesa un framework.
Pruebas prácticas: lo que sí aguantó
Una vez instalado, el camino estático funcionó sin problemas. Cobertura completa, sin pérdidas.
| Prueba | Resultado | Tiempo |
|---|---|---|
| Catálogo estático local + paginación | 12/12 productos | 0.557s |
| Exportación CSV de catálogo estático | 12 filas escritas | (misma ejecución) |
| Extracción de artículo | título + 3/3 párrafos del cuerpo | 0.416s |
| Grafo de rastreo, DEPTH_LIMIT=2 | 11 páginas en profundidades 0/1/2 | 0.904s |
| Página local 500 | estado 500 capturado, sin caída | 0.424s |
| Books to Scrape (público) | 20 productos | 2.053s |
| Spider de Quotes to Scrape (público) | 12 citas | 3.465s |
La araña del catálogo estático recorrió la paginación de la página uno a la dos y capturó 12/12 registros esperados, y después los exportó como JSON y CSV en la misma pasada. La maqueta de artículo es la que merece más atención. Scrapy no intentó limpiar automáticamente la página y convertirla en un Markdown ordenado; en cambio, me dejó apuntar a los campos article con selectores explícitos y mantener el texto de navegación y pie de página en campos separados, así que obtuve 3/3 párrafos del cuerpo con el material de relleno aislado y no mezclado en la salida. Ahí está el intercambio: tú escribes los selectores y recibes exactamente lo que pediste, ni más ni menos.
El control del rastreo también respondió bien a pequeña escala. Con DEPTH_LIMIT=2, un pequeño retraso de descarga, concurrencia por dominio y robots.txt activado, el grafo recorrió 11 páginas en las profundidades 0, 1 y 2, y el conteo de profundidad se comportó como debía. La gestión de errores fue igual de tranquila. La página 500 intencional volvió como un elemento estructurado con estado 500 expuesto mediante handle_httpstatus_list —sin excepción y sin tumbar la ejecución. Scrapy trata un código de error como algo que gestionas dentro de la lógica de la araña, no como una sorpresa que derriba todo el rastreo.
Pruebas prácticas: el muro de JavaScript y la puerta al lado
Y ahora, el resultado sobre el que se construye esta reseña.
Apunté el fetcher HTTP de Scrapy a una maqueta de catálogo renderizada con JavaScript. Descargó el HTML fuente, encontró 0 nodos .product-card y siguió adelante, porque nunca ejecutó el script que habría dibujado esas tarjetas. La página pública Quotes to Scrape JS contó la misma historia: 0 nodos de citas renderizadas. Si te quedas ahí, escribirías Scrapy fuera de juego para cualquier cosa construida en esta década.
Pero no te quedes ahí. Ese catálogo JS se alimentaba desde una API JSON en segundo plano, como ocurre con la mayoría. Apunté la misma araña de Scrapy a ese endpoint y obtuve 8/8 productos en 0.416s —sin navegador, sin renderizado, solo una petición a la URL que la página ya estaba llamando y el análisis del JSON que devolvió.
Esa comparación lado a lado resume en miniatura la filosofía de “reproducir la petición”. La página renderizada es una distracción; los datos llevaban todo el tiempo detrás de una API, y el diseño de Scrapy te empuja a llamarla directamente en lugar de pagarle a un navegador sin interfaz para que se quede mirando cómo la página se construye sola. Es más rápido, más ligero y falla menos: un contrato de API es mucho más estable que un DOM ensamblado en el cliente. El inconveniente es que es un proceso manual. Tienes que abrir la pestaña de red, encontrar la petición y reproducir sus cabeceras y parámetros tú mismo. Scrapy no descubre la API por ti; simplemente hace trivial atacarla cuando ya la has encontrado.
Dos límites, dicho con claridad. Cuando de verdad no existe una petición subyacente que reproducir —datos incrustados por renderizado del lado del cliente sin ninguna API detrás—, Scrapy necesita una integración con navegador headless que debes conectar tú, y en esta prueba no ejercité ese camino. Además, todo lo anterior se ejecutó sobre maquetas pequeñas y páginas de demostración públicas. No lancé un rastreo de 100 a 1,000 páginas, así que no hago afirmaciones sobre memoria, rendimiento o comportamiento de reintentos a gran escala: el núcleo asíncrono y los controles de rastreo son señales sólidas, pero una señal no es una medición.
Pros y contras
Pros:
- Diseño solo HTTP, rápido y ligero: 12/12 de cobertura estática en aproximadamente medio segundo, 8/8 desde una API JSON en 0.416s, sin coste de navegador.
- El enfoque de reproducir la petición sí funciona: una página JS que devolvía 0 entregó los 8 elementos a través de su API.
- Los selectores CSS y XPath apoyados en
lxmlhacen que el código de extracción sea legible y veloz. - Exportación de feeds a JSON/CSV/XML sin tener que programar la salida.
- Gestión explícita de errores: un 500 llega como estado que puedes capturar, no como caída.
- Controles de rastreo maduros: concurrencia, retrasos, límites de profundidad, AutoThrottle y robots.txt.
- Licencia BSD-3-Clause, permisiva; instalación limpia en una máquina actual.
Contras:
- No renderiza JavaScript por diseño: 0 nodos en una página renderizada por el cliente hasta que tú encuentres la API.
- Encontrar la petición subyacente es manual; Scrapy no te señala el endpoint.
- Pila de dependencias considerable (
Twisted,lxml,cryptography,pyOpenSSL,parsel,tldextract): aquí fue suave, pero históricamente puede dar fricción en plataformas poco comunes. - Más código que las herramientas no-code o de extracción automática; las arañas las escribes y mantienes tú.
- Mis pruebas cubrieron maquetas pequeñas y sitios de demostración, no rastreos grandes; la fiabilidad a escala sigue sin demostrarse en esta pasada.
Para quién es y quién debería pasar de largo
Scrapy es para desarrolladores que quieren control a nivel de código y piensan en peticiones, no en páginas. Si tu reacción instintiva ante un sitio JavaScript lento es “aquí dentro hay una API en alguna parte”, esta herramienta está hecha precisamente para ese impulso. Premia a quien se siente cómodo escribiendo selectores, leyendo la pestaña de red y asumiendo de punta a punta la lógica de extracción. Para sitios estáticos, catálogos paginados y cualquier cosa respaldada por un endpoint JSON detectable, es rápido y preciso.
Mejor pásalo por alto —o al menos combínalo con otra cosa— si no quieres pasar tu tiempo escribiendo y manteniendo código de arañas, o si tus objetivos renderizan los datos solo del lado del cliente y no existe una petición reproducible, y prefieres no acoplar tú mismo un navegador headless. Y si el sueño era apuntar una herramienta a una URL y obtener salida estructurada y limpia sin redactar reglas de extracción, eso nunca fue trabajo de Scrapy, ni jamás fingió que lo fuera.
Alternativas y dónde encaja Thunderbit
Prueba Thunderbit para extraer datos web
Empieza por lo que estás aceptando: un framework libre y de código abierto que tú mismo ejecutas y mantienes. Tú te quedas con las spiders, la pila de dependencias y el trabajo de localizar la petición de datos de cada sitio. A cambio, no pagas por solicitud, conservas todo dentro de casa y obtienes control exacto. Para muchos equipos, esa es la decisión correcta, y esta reseña no pretende convencer a nadie de lo contrario.
La diferencia aparece en el problema del renderizado y la deriva de los sitios, y la respuesta de Scrapy es que la resuelvas tú: encuentras la API, reproduces la petición y, si no hay API, conectas un navegador por tu cuenta. Una API gestionada de scraping con IA se encarga de esa capa por ti. Ahí es donde se ubica la pila para desarrolladores de Thunderbit para lectores técnicos: una API de scraping con IA más servidor MCP más CLI, no la extensión de navegador que usa el área comercial y de operaciones. POST /distill convierte una página en Markdown limpio, listo para LLM; POST /extract devuelve JSON estructurado a partir de un esquema que defines; y ambos gestionan el renderizado de JavaScript, anti-bot y contenido dinámico del lado del servidor, incluso en el caso renderizado en cliente donde Scrapy te pide recurrir a un navegador. También hay un servidor MCP para agentes de IA y asistentes de programación (con un thunderbit_suggest_fields gratuito para perfilar una página antes de gastar nada), y una CLI mediante npx @thunderbit/thunderbit-cli para terminal, CI o tareas programadas.
La diferencia no está en la calidad, sino en la propiedad del proceso. Scrapy es un framework de ingeniería explícito: tú mantienes la araña, el pipeline y la estrategia para JS, y obtienes control total sin coste por llamada. La pila de Thunderbit entrega la capa de renderizado y extracción como servicio gestionado, de modo que te ahorras investigar la pestaña de red y pagas por llamada. ¿Proyecto pequeño, centrado en código, y te gusta controlar cada paso? El nivel de control de Scrapy encaja mejor. ¿Vas a escalar a cien sitios y prefieres no reproducir una petición manualmente para cada uno? La ruta gestionada elimina toda esa categoría de trabajo.
Para una visión más amplia, estas comparativas cubren a los vecinos: la comparativa completa de scrapers open source, la reseña de Colly como rastreador Go sin navegador y la reseña de Scrapling sobre selectores adaptativos.
Veredicto
¿Deberías usar Scrapy? Sí, si eres desarrollador, quieres control y compartes esta filosofía: no renderices la página, encuentra la petición que hay detrás. En las pruebas, esa idea funcionó exactamente como promete. Un catálogo JavaScript le dio al fetcher HTTP 0 tarjetas; la API JSON que lo alimentaba entregó sus 8 elementos a la misma araña. La extracción estática acertó 12/12, los selectores del artículo mantuvieron 3/3 párrafos libres de relleno, el grafo de rastreo respetó su límite de profundidad en 11 páginas y un 500 volvió como estado gestionado en lugar de una caída.
Eso sí, hay que calibrar bien las afirmaciones. Scrapy no renderiza JavaScript, y no va a descubrir la API por ti; ese reflejo lo tienes que construir. La pila de dependencias es la de un framework completo y puede dar guerra en plataformas extrañas, aunque aquí se instaló sin problemas. Y yo probé maquetas y páginas de demostración, no un rastreo de mil páginas, así que la historia de escalabilidad es prometedora pero todavía no está demostrada en esta pasada. Dentro de esos límites, Scrapy es la herramienta que mejor se compromete con una idea radical pero silenciosa: la forma más rápida de atravesar una página web suele ser no pasar por la página en absoluto.
Prueba Thunderbit para extraer datos web Get Started Free
Preguntas frecuentes
¿Puede Scrapy extraer páginas renderizadas con JavaScript? No con su fetcher HTTP por defecto: en mis pruebas devolvió 0 nodos tanto en una maqueta JS como en la página pública de Quotes con JS, porque descarga HTML sin ejecutar un navegador. La vía prevista es localizar la petición de datos subyacente y llamarla directamente; en mi prueba, la API JSON detrás de un catálogo JS entregó los 8 elementos. Si no hay una petición reproducible, debes conectar tú mismo un navegador headless.
¿Qué significa exactamente “reproducir la petición”? La mayoría de las páginas dinámicas cargan sus datos desde una API JSON en segundo plano y luego los renderizan en el cliente. En vez de levantar un navegador para ver eso suceder, abres la pestaña de red, encuentras esa llamada a la API y apuntas Scrapy directamente a ella. Es más rápido y estable que renderizar —un contrato de API falla menos que un DOM—, pero requiere trabajo manual y Scrapy no localizará el endpoint por ti.
¿Es difícil instalar Scrapy?
En mi caso fue limpio: pip install Scrapy==2.17.0 terminó sin errores de compilación en un venv nuevo en macOS usando wheels binarios. Pero arrastra una pila considerable (Twisted, lxml, cryptography, pyOpenSSL, parsel, tldextract) y la documentación oficial sigue avisando de fricciones con dependencias según la plataforma en algunos sistemas, así que conviene preverlo si tu entorno es poco común.
¿Qué formatos de salida admite Scrapy? La exportación de feeds cubre JSON, JSON Lines, CSV y XML de serie: apuntas una araña a un archivo y serializa los elementos sin código adicional. En mi ejecución, una misma araña generó JSON y CSV en una sola pasada. Ojo: exporta los campos que tú seleccionas; no convierte automáticamente una página a Markdown.
¿Scrapy es gratis para uso comercial? Sí, usa BSD-3-Clause, una licencia permisiva y favorable para uso comercial. Como siempre, confirma la licencia vigente en el repositorio antes de construir sobre ella, y mantén responsables tus decisiones sobre user-agent, proxies y límites de ritmo; tener capacidad no equivale a tener permiso.
