Web scraping: por dónde empezar

El web scraping es leer una página web con un programa y sacar de ella datos estructurados. Se usa cuando la información existe públicamente pero no hay una forma limpia de consultarla: un catálogo sin API, una documentación que quieres meter en un buscador propio, precios repartidos en cien fichas. La primera decisión, y la que más tiempo ahorra, es comprobar si hace falta scrapear siquiera.

Esta guía cubre esa decisión y las cuatro siguientes, que son las que separan un scraper que aguanta de uno que se rompe al primer cambio de maquetación.

¿De verdad necesitas scrapear?

Antes de escribir una línea, tres comprobaciones en este orden:

¿Hay una API oficial? Casi siempre la respuesta correcta. Una API te da datos estables, con contrato y sin que un cambio de CSS te tire el proceso. Aunque sea de pago, suele salir más barata que mantener un scraper.

¿Hay un feed? RSS, un sitemap.xml, un endpoint JSON que la propia página usa por debajo. Muchísimos sitios sirven sus datos en JSON para su propio frontend: abre las herramientas de desarrollo, mira la pestaña de red y comprueba antes de parsear HTML.

¿Hay una descarga? Datos abiertos, un CSV, un volcado. Los organismos públicos publican mucho más de lo que parece.

Si las tres son que no, entonces sí: scraping. Y ahí empiezan las decisiones.

1. ¿Necesitas un navegador o te basta con HTML?

Es la decisión que más peso tiene en el coste.

Petición HTTP simple. Pides la URL, recibes HTML, lo parseas. Rápido, barato, y funciona con cualquier sitio renderizado en el servidor. Es lo que deberías intentar primero, siempre.

Navegador sin interfaz. Cargas la página en un navegador de verdad, ejecutas su JavaScript y lees el resultado. Necesario cuando el contenido solo aparece después de hidratar. Cuesta entre diez y cien veces más en tiempo y memoria.

La comprobación es de treinta segundos: curl la URL y busca tu dato en la respuesta. Si está, no necesitas navegador. Si no está, mira primero si hay una llamada JSON por debajo antes de resignarte.

2. Cómo señalar el dato para que no se rompa

Un scraper se rompe porque el selector deja de existir. La resistencia se decide aquí:

• Lo más estable: datos estructurados. Muchas páginas ya llevan JSON-LD con el precio, el autor o la fecha, precisamente porque lo ponen para Google. Léelo de ahí antes que del HTML pintado: es contenido declarado, no maquetación. Lo contamos desde el otro lado en datos estructurados: qué marcar y qué no.
• Estable: atributos semánticos y microdatos, <time datetime>, <meta property="og:…">.
• Frágil: clases de utilidad y clases generadas por el compilador de CSS. Un div.css-1x2y3z es una bomba de relojería.
• Lo peor: posiciones. «El tercer div del segundo section» dura hasta el siguiente despliegue.

Regla práctica: si el selector describe qué es el dato, aguanta; si describe dónde está, no.

3. Buenas maneras, que además es lo que funciona

Un scraper agresivo acaba bloqueado, y con razón: le estás costando dinero a alguien. Lo que hace un cliente educado:

• Lee el robots.txt y respétalo. Es una petición, no una barrera técnica, y saltársela es la primera señal de que vas de mala fe. Cómo se escribe está en sitemap.xml y robots.txt.
• Identifícate en el User-Agent, con un nombre y una forma de contactarte. Un administrador que ve tráfico raro y puede escribirte te limita; uno que no, te bloquea.
• Limita el ritmo. Una petición por segundo es mucho más de lo que necesitas casi siempre. Ve en serie antes que en paralelo.
• Respeta el 429 y el Retry-After. Si te piden que esperes, espera, con retroceso exponencial.
• Cachea. La mayoría de los scrapers vuelven a pedir lo mismo un día tras otro. Guarda la respuesta y usa If-Modified-Since.

Lo que esta guía no cubre, a propósito: saltarse CAPTCHAs, iniciar sesión con credenciales ajenas o esquivar sistemas antibot. Ahí es donde empiezan los problemas legales de verdad, y lo desarrollamos en scraping legal: qué se puede y qué no.

4. Dónde guardas lo que sacas

Un scraper produce datos sucios y repetidos. Dos consejos que ahorran reescribir:

Guarda el HTML crudo, no solo lo extraído. El día que descubras que estabas leyendo mal un campo, poder reprocesar sin volver a pedir las páginas vale su peso en oro —y le ahorra el tráfico al sitio de origen—.

Ponle una clave estable a cada fila. La URL canónica normalizada suele servir. Sin eso, la segunda pasada te duplica todo.

Para dónde meterlo, Postgres cubre el 90 % de los casos; lo comparamos en bases de datos con plan gratuito.

5. Qué pasa cuando falla

Va a fallar. La pregunta es si te enteras:

• Cuenta lo que extraes. Si ayer sacabas 400 filas y hoy 12, algo cambió aunque el proceso terminara sin error.
• Falla ruidosamente ante un campo vacío obligatorio. Un precio a null que se guarda en silencio contamina la base entera.
• Guarda el código de estado. Una tanda entera de 403 es un bloqueo, no un error de parseo.

Por dónde seguir

Si el proyecto es pequeño, empieza con peticiones HTTP, un parser y una tabla. Si necesitas convertir páginas en texto limpio para un modelo de lenguaje, hay servicios que ya lo hacen y te ahorran todo lo anterior: está en scraping para alimentar un RAG. Y las opciones con plan gratuito, en herramientas de scraping gratis.

Preguntas frecuentes

¿Es legal hacer web scraping? Depende del qué, del dónde y del cómo, y no hay una respuesta única. Extraer datos públicos y no personales para uso propio se considera aceptable en general; los conflictos aparecen con los términos de servicio, los datos personales y el contenido protegido por derechos de autor. Lo desarrollamos en el artículo dedicado, y para un caso concreto hay que consultar con un abogado.

¿Qué lenguaje conviene para scrapear? El que ya uses. Python tiene el ecosistema más grande y Node encaja mejor si vas a necesitar un navegador sin interfaz. La elección del lenguaje es lo que menos influye en si el scraper aguanta.

¿Cada cuánto se rompe un scraper? Cada vez que el sitio cambia de maquetación, y eso no avisa. Con selectores semánticos o datos estructurados puedes pasar meses; con clases generadas, semanas. Por eso importa más el punto 5 que el 2: no evitar que se rompa, sino enterarte el mismo día.

¿Puedo scrapear un sitio que requiere iniciar sesión? Con tu propia cuenta y para tus propios datos, normalmente sí. Con credenciales que no son tuyas, no: además de violar los términos de servicio, en muchos países entra en el terreno del acceso no autorizado a un sistema.

¿Un navegador sin interfaz es siempre más fiable? No, y además es más caro y más frágil de operar. Solo aporta cuando el contenido necesita JavaScript para existir. Si el dato ya está en el HTML de la primera respuesta, un navegador solo añade latencia y consumo.