Web scraping que sigue funcionando cuando la web cambia
Extraemos datos de webs que no te dan una API: agendas, catálogos, precios, anuncios, boletines. Cada fuente con la estrategia que necesita, un test que la llama de verdad cada pocos días y una alerta el día que cambia de diseño, antes de que alguien eche en falta un dato.
El web scraping es la extracción automatizada de datos publicados en webs que no ofrecen una API ni un fichero de descarga. En Soamee construimos scrapers a medida en Node.js y TypeScript: para cada fuente elegimos entre su API interna, su feed RSS, el HTML que devuelve el servidor o un navegador headless con Playwright, y pasamos todos los resultados por el mismo normalizador, así que llegan a tu base de datos con un formato común y sin duplicados. Cuando una web bloquea las peticiones automáticas (403, CAPTCHAs, cortes por IP) integramos Bright Data: Web Unlocker, Scraping Browser o proxies residenciales. Cada fuente tiene un test contra la web real que corre cada pocos días y una alerta por email con el diagnóstico cuando falla.
Del inventario de fuentes al dato limpio en tu base de datos
Un scraper que funciona hoy se escribe en una tarde. El trabajo está en que siga funcionando dentro de seis meses, con treinta fuentes que cambian cada una a su ritmo.
Inventario y viabilidad por fuente
Antes de escribir código revisamos cada web: si tiene API pública o interna, si es un WordPress con /wp-json abierto, si carga los datos por XHR, qué dice su robots.txt y si bloquea peticiones automáticas. Sale una ficha por fuente con estrategia, riesgos y frecuencia.
Una estrategia por tipo de fuente
API, RSS, HTML estático o navegador headless detrás de una misma interfaz. Añadir una fuente suele consistir en escribir su configuración (URL, selectores, mapeo de campos) y su test, sin programar un scraper desde cero.
Normalización y deduplicación
Fechas en español como «del 10 al 28 de junio», precios escritos como texto, HTML incrustado, la misma categoría con cinco nombres. Todo pasa por un normalizador y se guarda con clave única por fuente e identificador externo, así que reejecutar actualiza en vez de duplicar.
Webs con protección anti-bots
Para las fuentes que devuelven 403 o CAPTCHA integramos Bright Data: Web Unlocker para peticiones HTTP, Scraping Browser para páginas que necesitan JavaScript y proxies residenciales cuando el problema es la IP. Solo en esas fuentes; el resto sale directo y no consume desbloqueo.
Colas, reintentos y planificación
Cada fuente es un trabajo en una cola BullMQ sobre Redis, con su frecuencia, tres reintentos con espera exponencial y un registro por ejecución: cuántos elementos encontró, cuántos eran nuevos y cuánto tardó.
Smoke tests y alertas
Un test por fuente que llama a la web real cada tres días en CI, más tests unitarios sobre una captura guardada de la respuesta. Si una ejecución falla, llega un email con el código HTTP, un fragmento de la respuesta y qué revisar primero.
Cuatro estrategias, de la más estable a la más frágil
Usamos la primera de la lista que la fuente permita. Cada escalón hacia abajo cuesta velocidad y estabilidad, así que solo bajamos cuando la fuente nos obliga.
| Estrategia | Cuándo la usamos | Coste | Qué se rompe |
|---|---|---|---|
| API pública o interna | La web carga sus datos desde un JSON: portales de datos abiertos, WordPress con REST API, plugins de eventos, endpoints visibles en la pestaña Network | ~200 ms por petición | Cambios de esquema, poco frecuentes |
| RSS / Atom | La fuente publica un feed y bastan título, enlace y resumen | ~200 ms por feed | La fecha del feed es la de publicación, no la del evento ni la de la oferta |
| HTML estático | El contenido viene en el HTML que devuelve el servidor | Una petición por listado, más una por ficha si falta algún campo | Los selectores CSS, en cada rediseño |
| Navegador headless | Contenido renderizado con JavaScript, scroll infinito, botones de «cargar más» o bloqueo a clientes HTTP | 3-5 s por página y 100-200 MB de RAM por navegador | Tiempos de espera y el binario del navegador en cada entorno |
Lo que tenemos funcionando
Cifras de una plataforma de agregación que mantenemos, con fuentes públicas muy distintas entre sí: portales de datos abiertos, WordPress, Drupal, webs en React y páginas hechas a mano.
fuentes, cada una con su smoke test contra la web real
estrategias de extracción detrás de una misma interfaz
entre cada pasada de los smoke tests en CI
reintentos con espera exponencial antes de dar una ejecución por fallida
La avería más frecuente es un rediseño de la fuente. El smoke test la detecta en tres días como mucho. Para las webs que bloquean peticiones automáticas trabajamos con Bright Data.
Integración con Bright Data →De la lista de URLs al primer dato en tu base de datos
Primero una fuente de cada tipo, para que los problemas reales salgan pronto. Después, el resto en tandas.
Ficha por fuente
Revisamos cada web, elegimos estrategia y apuntamos lo raro: formatos de fecha, paginación, bloqueos, campos que solo están en la página de detalle.
Piloto por estrategia
Implementamos una fuente de cada tipo con su test unitario, su smoke test y su documento. Ahí aparecen los problemas que el inventario no ve.
Resto de fuentes
Con el modelo validado, cada fuente nueva suele ser configuración más un test. Las que necesitan navegador o desbloqueo van en una tanda aparte.
Operación
Planificación, alertas, informe de ejecuciones y mantenimiento cuando una fuente cambia. Si prefieres operarlo con tu equipo, te lo dejamos documentado fuente a fuente.
Preguntas frecuentes sobre web scraping
¿Es legal hacer web scraping en España? +
Extraer datos publicados sin restricción de acceso es una práctica habitual, pero hay tres límites que revisamos en cada fuente: los términos de uso de la web, el derecho sui generis sobre bases de datos (no se puede extraer una parte sustancial de una base de datos ajena para reutilizarla) y el RGPD cuando hay datos personales. No entramos en zonas con login sin permiso del titular. Si el caso es dudoso, recomendamos una revisión legal antes de empezar.
¿Qué pasa cuando la web cambia de diseño? +
El smoke test de esa fuente falla en la siguiente pasada, como mucho a los tres días, y llega una alerta con el error. A las fuentes por API o RSS los rediseños casi nunca les afectan. En las de HTML o navegador headless suele bastar con actualizar los selectores en la configuración de la fuente, sin desplegar código.
¿Cuándo hace falta Bright Data? +
Cuando la web devuelve 403 a cualquier cliente automatizado, muestra CAPTCHAs o corta por IP. Ahí un navegador headless propio no basta, porque el bloqueo depende de la IP y de la huella del navegador. Lo activamos solo en las fuentes que lo necesitan; las demás siguen saliendo directas.
¿Con qué frecuencia se actualizan los datos? +
Cada fuente tiene la suya: cada hora para precios o disponibilidad, una vez al día para agendas o catálogos que cambian poco. También es una cuestión de cortesía con la web de origen: pedir cada cinco minutos algo que cambia una vez al día solo genera carga.
¿En qué formato recibo los datos? +
En tu base de datos, normalmente PostgreSQL, con un esquema común para todas las fuentes, o a través de una API REST. También podemos generar exportaciones CSV o JSON periódicas o enviar los cambios por webhook.
¿Puedo usar los datos para alimentar un modelo de IA? +
Sí, y es uno de los usos más habituales: los datos normalizados sirven de base para un buscador semántico, un RAG o un agente. Aplican los mismos límites legales que a cualquier otro uso, y guardamos la URL y la fecha de origen de cada registro para poder citar la fuente.
También te puede interesar
Pásanos la lista de fuentes
Mándanos las URLs de las que necesitas datos y qué campos te interesan. Te devolvemos una ficha por fuente con la estrategia, los riesgos y la frecuencia que recomendamos.
Cuéntanos qué fuentes necesitasCuéntanos tu reto. Te proponemos solución.
Sin compromiso. En menos de 24 h recibes una propuesta con alcance, plazos y presupuesto. Sin letra pequeña.