Buenas prácticas de web scraping en 2026: guía de un profesional
Después de construir y mantener 15 scrapers de producción que dan servicio a más de 3,100 usuarios con tasas de éxito del >99%, estas son las prácticas que realmente importan.
Arquitectura: piensa en pipelines, no en scripts
El error más grande que veo es tratar el scraping como un proceso de un solo paso. Los scrapers de producción son pipelines de datos:
- Descubrimiento de URLs — encontrar qué extraer (sitemaps, páginas de categoría, búsqueda, APIs)
- Ejecución de solicitudes — obtener los datos con reintentos y rotación adecuados
- Parseo — extraer campos estructurados de las respuestas en bruto
- Normalización — limpiar, validar y estandarizar la salida
- Almacenamiento — enviar a datasets, bases de datos o sistemas posteriores
Cada paso debe poder probarse y reintentarse de forma independiente. Cuando Sephora cambia el diseño de su página de producto, solo el paso 3 necesita actualizarse — el resto del pipeline se mantiene estable.
Prioriza siempre las APIs sobre el parseo de HTML
Antes de escribir un solo selector CSS, comprueba si el sitio tiene:
- APIs públicas — endpoints documentados que devuelven JSON
- APIs privadas — llamadas XHR/fetch visibles en las DevTools del navegador
- Endpoints GraphQL — cada vez más comunes, a menudo con introspección habilitada
- JSON embebido —
__NEXT_DATA__,window.__INITIAL_STATE__, o JSON-LD en el HTML
Las respuestas de la API están estructuradas, versionadas y son mucho más estables que los diseños HTML. Mi scraper de Sephora convierte cada URL web en una llamada a la API — no se ha roto ni una sola vez por un rediseño del frontend.
Estrategia de proxies: adapta el nivel a la protección
No todos los sitios necesitan proxies residenciales. Este es mi marco de decisión:
| Nivel de protección | Tipo de proxy | Sitios de ejemplo |
|---|---|---|
| Ninguno / básico | Centro de datos | La mayoría de tiendas Shopify, sitios pequeños |
| Limitación de tasa | Centro de datos rotativo | E-commerce mediano, sitios de contenido |
| Fingerprinting | Residencial | Sephora, Farfetch, grandes marcas |
| WAF avanzado | Residencial + huella TLS | Akamai, Cloudflare Enterprise |
La idea clave: el coste del proxy escala con el nivel de protección. No gastes dinero en proxies residenciales para sitios que solo comprueban la reputación de IP. Mi scraper de Shopify funciona perfectamente con proxies de centro de datos porque la protección por defecto de Shopify es mínima.
La gestión de sesiones lo es todo
La diferencia entre una tasa de éxito del 60% y del 99% suele ser la gestión de sesiones:
- Rota sesiones, no solo IPs — una IP nueva con las mismas cookies resulta sospechosa
- Calienta las sesiones — visita la página de inicio antes de acceder a las páginas de producto
- Respeta los límites de tasa — 5 solicitudes concurrentes superan a 50 que terminan bloqueadas
- Backoff exponencial — reintentos de 1s, 2s, 4s, 8s, no reintentos inmediatos
Mi scraper de Sephora EU gestiona tokens de invitado con renovación automática y backoff exponencial. Mantiene sesiones persistentes que se parecen a patrones de navegación reales.
Normaliza tu salida
Los datos extraídos en bruto son desordenados. Normalízalo todo:
Precios
Almacénalos como enteros (céntimos, no dólares). $29.99 se convierte en 2999. Esto evita errores de precisión de coma flotante que corrompen los datos financieros más adelante en el flujo. Todos mis scrapers de e-commerce usan esta convención.
URLs
Almacena siempre URLs absolutas, nunca rutas relativas. Resuélvelas en el momento de la extracción.
Fechas
ISO 8601 (2026-04-01T00:00:00Z), siempre con zona horaria. Nunca almacenes fechas con formato de configuración regional.
Texto
Elimina los espacios en blanco sobrantes, normaliza Unicode y decide una política de manejo de HTML (eliminar etiquetas o conservar el formato).
Manejo de errores: espera que fallen
Los scrapers de producción fallan constantemente — la cuestión es con cuánta elegancia. Mi enfoque:
1Request fails (network error, timeout, 4xx/5xx)
2 → Retry with exponential backoff (up to 5 attempts)
3 → Rotate session/proxy on retry
4 → Log failure with full context if all retries exhausted
5 → Continue processing remaining URLs (don't crash the batch)
Haz seguimiento de las tasas de éxito por patrón de URL. Si las páginas /category/* caen de repente por debajo del 90% de éxito, es probable que el sitio haya cambiado algo — lo detectarás antes de que los usuarios lo reporten.
Monitoriza y alerta
Un scraper sin monitorización es un scraper esperando a fallar en silencio. Haz seguimiento de:
- Tasa de éxito por ejecución y por patrón de URL
- Recuento de salida — caídas repentinas significan que algo se rompió
- Calidad de los datos — campos nulos, valores inesperados, incumplimientos de esquema
- Coste — uso de proxies, tiempo de cómputo, almacenamiento
Todos mis Apify Actors exponen estas métricas. Cuando las tasas de éxito bajan, recibo una notificación en cuestión de horas — a menudo antes de que ningún usuario se dé cuenta.
Empieza simple, añade complejidad
Todos los scrapers que construyo empiezan como lo más simple que funciona:
- HTTP + Cheerio primero (lo más rápido y barato)
- Añade fingerprinting solo si te bloquean
- Añade renderizado con navegador solo si se requiere JavaScript
- Añade rotación de proxies solo si te limitan la tasa
Mi scraper de Ulta es Cheerio puro — no necesita navegador. Mi Universal Web Printer usa Playwright porque debe renderizar JavaScript. La herramienta adecuada para cada trabajo.
Estos no son principios teóricos — están extraídos de ejecutar scrapers de producción que procesan millones de solicitudes. Si necesitas un scraper a medida construido con estas prácticas, hablemos.