Formato nuevo
Cómo proteger un sitio del scraping: captcha, límites, honeypot y sentido común
Los scrapers cosechan precios, copy, reseñas y catálogos. No puedes «cerrar» del todo un sitio ante un recolector motivado, pero puedes hacer la recogida mucho más cara y recortar daño al servidor y al SEO.
Abajo: capas prácticas de defensa y errores habituales. Qué es el scraping y dónde termina la recogida ética viven en una pieza vecina; aquí — el lado del dueño del sitio. Sin instrucciones para derrotar la protección.
Por qué proteger
El scraping agresivo copia contenido, saca precios para dumping, inunda formularios y carga el servidor. A veces la meta es analytics de competidores (precios), a veces rellenar clones a automático.
Prioridad: disponibilidad del sitio para personas y buscadores, integridad de datos, menos robo de contenido único.
Captcha y scoring conductual
El captcha clásico en cada paso molesta. Más moderno — scoring de riesgo (bot/humano) y un challenge solo cuando hay sospecha. Cookies/sesión reducen chequeos repetidos para usuarios que vuelven.
Recuerda: existen servicios de pago que resuelven captchas — un captcha solo no detiene a un recolector decidido. Combínalo con límites de requests.
Honeypot, IP y límites
Honeypot: un elemento oculto que un bot clica o rellena. El evento es una señal de log y un motivo para endurecer reglas para esa IP o sesión.
Señales de IP (hosting vs ISP de consumo, PTR de crawlers conocidos) ayudan pero se rompen con proxies. Rate limit es más fiable: muchas URLs/s desde una dirección → throttle o ban temporal. Aparte distingue un pico de tráfico de un DDoS.
Cuándo cortar el acceso:
- RPS anómalo desde una IP/subred
- tráfico que salta patrones humanos típicos
- crawl masivo del catálogo sin referrer / UA raro
- ataques a formularios y al área de admin
Servicios y la capa legal
CDN/WAF con bot management (Cloudflare y equivalentes) asumen parte de la carga: límites, JS challenge, reglas geo/ASN. Tools antibot de pago encarecen el scraping pero no dan garantías absolutas — nombres y planes cambian; elige según tráfico y presupuesto.
En los términos de uso, prohíbe la recogida automatizada. Eso no sustituye la tech, pero apoya reclamaciones cuando se copia contenido. También protege copy y fotos únicas con monitorización de clones.
Mínimo práctico:
- rate limit en catálogo y API
- monitorización de 5xx y anomalías en logs
- honeypot en formularios
- captcha/challenge por riesgo
- no cortar crawlers de búsqueda
- backups y chequeos de integridad del catálogo
FAQ
¿Captcha en cada página es un buen plan?
Suele no: pega al UX y a la conversión. Mejor scoring de riesgo y un challenge solo ante comportamiento sospechoso.
¿Puedo bloquear todos los bots?
No. Necesitas crawlers de búsqueda «buenos» y servicios de preview. Corta tráfico anómalo, no todo el tráfico robótico.
¿Ayuda robots.txt?
Para robots bien educados — sí. Un scraper malicioso lo ignora; no es la única defensa.
¿Qué es un honeypot?
Un cebo oculto (link/campo) que un humano no ve pero un bot tonto toca. Ayuda a detectar — no es bala de plata.
¿CDN y WAF son obligatorios?
Con alta carga y ataques frecuentes — útiles (límites, bot management). Un sitio pequeño a menudo necesita rate limit + monitorización de logs.
¿Existe protección al 100%?
No. La meta es bajar el daño y el coste para el atacante, más medidas legales y contractuales sobre el contenido.
¿Captcha en cada página — y los scrapers siguen machacando el catálogo?
Montamos rate limits, challenges por riesgo y allowlist de crawlers — subimos el coste del scrape sin matar el SEO.
Hablar del proyecto
