El bloqueo en web scraping casi nunca es personal. El sitio ve demasiadas peticiones, demasiado rápido, desde una IP sospechosa y con un cliente que no parece un navegador. La solución, en la mayoría de los casos, no es un proxy: es bajar el ritmo, identificarte, reintentar con backoff y pedir solo lo que necesitás. Acá explicamos cómo te ve el sitio, qué significa cada error y el código de un scraper que se porta bien.

El problema: funcionaba ayer

El scraper corrió todos los días durante tres semanas. Hoy devuelve un 403. O un 429. O un HTML que dice "Verificá que sos humano". El reporte de precios no salió y alguien pregunta qué pasó.

Lo primero que hace mucha gente es buscar "proxies para scraping" y pagar. A veces funciona. Muchas veces es gastar en infraestructura para resolver un problema de modales. Antes de eso conviene entender qué está mirando el sitio.

Cómo te ve el sitio (la lógica del bloqueo)

Para un servidor, un scraper agresivo se parece a un ataque. Alguien que pide 500 páginas por minuto consume recursos, puede tirar el sitio abajo y no deja nada a cambio. Por eso cada vez más sitios tienen un WAF (Cloudflare, Akamai, DataDome y similares) que mira cada petición y le pone un puntaje de "¿esto es una persona?".

Ese puntaje combina cuatro cosas:

Ritmo: cuántas peticiones hacés por segundo y con qué regularidad.
Identidad: qué dice tu
```
User-Agent
```
y el resto de las cabeceras.
Origen: desde qué IP venís y qué reputación tiene.
Comportamiento: si pedís páginas en un orden que ninguna persona pediría.

Si el puntaje es malo, el sitio te frena. Primero suave (un 429, un captcha) y después fuerte (un 403 permanente para tu IP).

Las 6 razones por las que te bloquean

Vas demasiado rápido. Es la causa número uno. Un
```
for
```
con
```
requests.get
```
sin pausa hace 10 o 20 peticiones por segundo. Ninguna persona navega así.
Tu cliente no parece un navegador. El
```
User-Agent
```
por defecto de
```
requests
```
es
```
python-requests/2.x
```
. Es como entrar a un negocio con un cartel que dice "soy un robot".
Tu IP tiene mala reputación. Las IP de centros de datos (AWS, Google Cloud, DigitalOcean) vienen marcadas de fábrica. Y si otros scrapers usaron esa IP antes, heredás su historial.
Siempre sos el mismo. Mil peticiones desde la misma IP, con las mismas cabeceras, en el mismo orden, con la misma pausa exacta de 1,000 segundos. La regularidad perfecta también es una firma.
Caíste en una trampa. Algunos sitios ponen links invisibles (honeypots) que una persona nunca clickea. Si tu crawler sigue todos los links, cae y queda marcado.
El sitio decidió que no. Hay sitios que bloquean todo tráfico automatizado como política. Lo dicen en
```
robots.txt
```
o en los términos de uso. Ahí no hay técnica que valga: es una decisión del sitio y hay que respetarla.

Diagnóstico: qué significa cada error

Lo que ves	Lo que pasa	Qué probar primero
429 Too Many Requests	Superaste el límite de ritmo. Es un "pará un rato", no un "andate".	Leer la cabecera `Retry-After` , esperar eso y bajar el ritmo general.
403 Forbidden	El sitio decidió no servirte. Puede ser por cabeceras, por IP o por política.	Cabeceras de navegador completas. Si sigue, revisar robots.txt y términos: quizá no quieren scrapers.
Captcha o "Verificá que sos humano"	El WAF tiene dudas sobre vos.	Bajar el ritmo y revisar cabeceras. No resolver el captcha con un servicio: es la forma del sitio de decir "no así".
200 pero el HTML viene vacío o distinto	Te sirvieron una página "sombra" o el contenido carga por JavaScript.	Comparar con lo que ves en el navegador. Si es JS, es un problema de herramienta, no de bloqueo.
Timeouts o conexión cortada	El sitio está sobrecargado o te está frenando a nivel red.	Esperar, reintentar con backoff, bajar la concurrencia.

Cómo evitar el bloqueo en web scraping (de la forma correcta)

1. Leé robots.txt y los términos

Entrá a

sitio.com/robots.txt

. Ahí el sitio dice qué rutas no quiere que recorran los bots y a veces un

Crawl-delay

. No es una ley, es una preferencia declarada, y respetarla es el piso. Si dice

Disallow: /

para todos los agentes, el sitio no quiere scrapers y lo más sano es buscar otra fuente o pedir los datos.

2. Bajá el ritmo

Una petición por segundo al mismo dominio es un punto de partida razonable. Para sitios chicos, una cada dos o tres segundos. Y que la pausa no sea exacta:

time.sleep(random.uniform(1, 3))

se parece más a una persona que

time.sleep(1)

Si tenés 10.000 páginas, a una por segundo son menos de tres horas. Casi siempre es tiempo que tenés. Lo que no tenés es un scraper bloqueado para siempre.

3. Presentate como lo que sos

Mandá un

User-Agent

de navegador real y el resto de cabeceras que un navegador manda (

Accept

Accept-Language

). Y si tu scraper es un proyecto serio, mejor todavía: identificalo con un nombre y un contacto (

MiEmpresaBot/1.0 (+https://miempresa.com/bot)

). Muchos sitios tratan mejor a un bot que se presenta que a uno que se disfraza.

4. Reintentá con cabeza

Ante un 429 o un 503, no reintentes de inmediato. Esperá lo que diga

Retry-After

y, si no viene, usá backoff exponencial: 2 segundos, después 4, después 8. Y ponele un tope de reintentos. Un scraper que martilla un servidor caído es la forma más rápida de pasar de "pará un rato" a "andate".

5. Pedí menos

Cacheá lo que ya bajaste. No pidas de nuevo una página que no cambió. Usá

If-Modified-Since

cuando el sitio lo soporta. Bloqueá imágenes y CSS si usás un navegador. Corré fuera del horario pico del sitio. Cada petición que no hacés es una petición que no te pueden bloquear.

6. Buscá la API

Muchos sitios cargan sus datos desde una API interna en JSON. Abrí la pestaña Network del navegador y mirá. Una petición a ese endpoint reemplaza a diez de HTML, es más liviana para ellos y más estable para vos. Y si el sitio tiene una API pública, usala: es la fuente que ellos mismos quieren que uses.

7. Proxies: cuándo sí y cuándo no

Los proxies rotativos sirven para una cosa concreta: repartir un volumen grande y legítimo entre varias IP para no concentrar la carga en una sola. Son infraestructura, no un truco. Tienen sentido cuando ya hiciste todo lo anterior y el volumen igual supera lo que una IP puede pedir con buenos modales.

Nosotros trabajamos con Bright Data, que exige verificación de identidad y uso declarado. Ese filtro es parte del punto: un proxy sirve para escalar lo que ya es legítimo, no para convertir en legítimo lo que no lo es.

Lo que no hacemos (y por qué)

Esta parte es corta y es la más importante.

No salteamos logins ni paywalls. Si el dato está detrás de una contraseña, no es público.
No resolvemos captchas con servicios de terceros. El captcha es el sitio diciendo "así no". Insistir es violar sus términos.
No scrapeamos datos personales. Nombres, mails, teléfonos. GDPR, CCPA y las leyes locales de protección de datos aplican aunque el dato esté "a la vista".
No falsificamos huellas para evadir un bloqueo explícito. Si un sitio te bloqueó la IP después de que respetaste todo lo anterior, es una respuesta. La escuchamos.

Esto no es solo ética: es lo que hace que un proyecto de datos dure años en lugar de semanas. Un scraper que vive de evadir se rompe en cada actualización del WAF.

El código: un scraper que se porta bien

Esto es lo mínimo que tiene cualquier scraper nuestro. Una sesión, cabeceras de navegador, pausa variable y reintentos con backoff que respetan

Retry-After

import random
import time
import requests

CABECERAS = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 "
                  "(KHTML, like Gecko) Chrome/130.0 Safari/537.36",
    "Accept": "text/html,application/xhtml+xml",
    "Accept-Language": "es-AR,es;q=0.9",
}

sesion = requests.Session()
sesion.headers.update(CABECERAS)


def pedir(url, reintentos=4):
    espera = 2
    for intento in range(reintentos):
        r = sesion.get(url, timeout=15)
        if r.status_code == 200:
            return r
        if r.status_code in (429, 503):
            pausa = int(r.headers.get("Retry-After", espera))
            print(f"{r.status_code} en {url}: espero {pausa}s")
            time.sleep(pausa)
            espera *= 2
            continue
        if r.status_code == 403:
            raise RuntimeError(f"403 en {url}: revisar robots.txt y términos")
        r.raise_for_status()
    raise RuntimeError(f"Sin respuesta tras {reintentos} intentos: {url}")


urls = ["https://books.toscrape.com/catalogue/page-1.html",
        "https://books.toscrape.com/catalogue/page-2.html"]

for url in urls:
    respuesta = pedir(url)
    print(url, len(respuesta.text), "bytes")
    time.sleep(random.uniform(1, 3))

Fijate el 403: el script no insiste. Lanza un error y te obliga a mirar por qué. Esa es la diferencia entre un scraper que se porta bien y uno que fuerza la puerta.

Recurso: la plantilla con todo esto resuelto

La plantilla SCRAPER que entregamos en el tutorial del primer scraper ya trae esta sesión, las cabeceras, el backoff, la pausa variable y la paginación. Si todavía no la tenés, comentá SCRAPER en el reel de esta nota y te la mandamos por mensaje.

¿Y a escala?

Todo lo de arriba resuelve un scraper sobre un sitio. El problema cambia de naturaleza cuando son 30 sitios, 200.000 páginas por día y cada sitio actualiza su WAF cuando quiere. Ahí el bloqueo deja de ser un error y pasa a ser una variable operativa: alguien tiene que mirar los logs todas las mañanas, ajustar ritmos por dominio, rotar infraestructura legítima y avisar cuando un sitio cambió de política.

En AUTOScraping ese trabajo es DataFactory. Vos definís qué datos necesitás y con qué frecuencia. Nosotros mantenemos los scrapers, absorbemos los bloqueos y te entregamos los datos limpios en tu base, en Sheets o por API. Si un sitio deja de permitir el acceso, te lo decimos y buscamos una fuente alternativa, no un atajo. Somos Bright Data Solution Partner y operamos dentro del marco legal.

Si tu equipo pasa más tiempo arreglando scrapers que usando los datos, esa es la señal.

Preguntas frecuentes

**¿Es ilegal que me bloqueen o que yo evite el bloqueo?**Bloquearte es un derecho del sitio. Evitar el bloqueo con buenas prácticas (ritmo, cabeceras, cache) es legítimo. Evadir una medida explícita (saltear un captcha, un login o un bloqueo de IP) puede violar los términos de uso y, según la jurisdicción, la ley. Si hay datos personales, siempre aplica la normativa de protección de datos.

**¿Un proxy residencial me asegura que no me bloqueen?**No. Reparte la carga, nada más. Si el ritmo o las cabeceras están mal, te bloquean igual, solo que desde más IP.

**¿Cuántas peticiones por segundo son seguras?**No hay un número universal. Una por segundo al mismo dominio es un punto de partida conservador. Si el sitio responde rápido y sin errores, podés subir de a poco. Si aparecen 429, bajá.

**¿Qué hago si el sitio tiene

Disallow: /

en robots.txt?**Tomarlo en serio. Buscar si el sitio tiene una API pública, un feed o un dataset, o escribirles y pedir acceso. Scrapearlo igual es ir contra la preferencia declarada del sitio.

**¿El bloqueo puede ser porque el sitio cambió el HTML?**Puede parecerlo: el scraper devuelve vacío. Pero eso no es bloqueo, es que los selectores quedaron viejos. Se diagnostica comparando el HTML que recibís con el que ves en el navegador.

Por qué te bloquean cuando scrapeás (y cómo evitarlo legalmente)