¿Cuánto cuesta hacer scraping de 1 millón de páginas en 2026?
Proxies, cómputo y tiempo de ingeniería por tu cuenta frente a 299 $ fijos por 1.000.000 de créditos: el coste real, revisado en agosto de 2026.
“Cuánto cuesta raspar un millón de páginas” suena a un solo número. No lo es. Son al menos tres números (ancho de banda, cómputo, tiempo de ingeniería) que nadie suma hasta que llega la factura de un plan de proxies para hobby junto a la factura de AWS.
Aquí va la descomposición honesta para las dos rutas, hacerlo tú mismo (DIY) o usar una API, a 1.000.000 de páginas al mes.
La ruta DIY: lo que de verdad aparece en la factura
Ancho de banda. Raspar a cualquier escala real significa proxies residenciales o móviles, porque las IPs de datacenter se bloquean rápido en cualquier sitio que le preste atención al tema. Dos tarifas actuales de pago por uso, revisadas en agosto de 2026: Bright Data lista proxies residenciales a 4,00 $/GB de pago por uso (una tarifa con descuento sobre un precio de lista de 8,00 $/GB), y Oxylabs lista proxies residenciales desde 6,00 $/GB de pago por uso.
Una página HTML simple, sin contar imágenes ni scripts, ronda los 50-150KB según el sitio. Suponiendo una media de 100KB para 1.000.000 de páginas estáticas: son unos 100GB, así que entre 400 $ y 600 $ solo en ancho de banda de proxy, antes de que corra una sola línea de código de parsing.
Si las páginas necesitan un navegador real (contenido renderizado con JS, scroll infinito, contenido detrás de una SPA), una sesión headless descarga el peso completo de la página, scripts y assets incluidos, no solo el HTML. Eso ronda habitualmente 1-3MB por página. A 1.000.000 de páginas son 1-3TB, o aproximadamente 4.000 $-18.000 $ en ancho de banda de proxy con las mismas tarifas. Este es el número que sorprende a la gente: el renderizado con JS no añade un poco a la factura, la multiplica, porque la unidad ahora es el peso completo de la página en vez del HTML.
Cómputo. Las peticiones estáticas son baratas de correr en paralelo: una flota modesta de workers procesando 1.000.000 de peticiones HTTP simples al mes ronda los 50 $-200 $ en cómputo cloud. Las instancias de Chrome headless son un animal distinto: cada una ocupa memoria y CPU reales durante los segundos que tarda en renderizar una página, así que una flota dimensionada para 1.000.000 de páginas renderizadas con JS al mes es más realista en 500 $-2.000 $, según lo agresivo que puedas ser agrupando y reciclando contextos de navegador.
Tiempo de ingeniería. Esta es la línea que nadie mete en la hoja de cálculo, y la que nunca llega a cero. Las medidas anti-bot cambian, los selectores se rompen cuando un sitio se rediseña, y los pools de proxies necesitan monitorización por tasa de baneos. Incluso unas conservadoras 10-15 horas al mes de un ingeniero a 75-150 $/hora son 750 $-2.250 $, y esa estimación asume que nada se rompe lo bastante como para necesitar un fin de semana.
Sumando todo, un job estático de 1.000.000 de páginas por tu cuenta cae en torno a 1.200 $-3.000 $ al mes una vez que cuentas honestamente ancho de banda, cómputo y mantenimiento. Un job renderizado con JS cae más cerca de 5.000 $-20.000 $, con el ancho de banda haciendo la mayor parte del daño.
La ruta API: un solo número, sin línea de mantenimiento
En FastAF, /scrape cuesta 1 crédito por una página estática, 5 créditos con dynamic=true (renderizado JS), 10 con premium=true (red residencial/anti-bot), y 25 con ambos.
1.000.000 de páginas estáticas = 1.000.000 de créditos = el pack Pro, 299 $ fijos por 1.000.000 de créditos, 5 solicitudes concurrentes. Esa es toda la factura. Sin factura de proxy, sin flota de navegadores headless que dimensionar, sin guardia on-call para cuando un sitio cambie su markup.
1.000.000 de páginas con renderizado JS (dynamic=true) = 5.000.000 de créditos. Eso es un pack Business (3.000.000 de créditos, 799 $) más dos packs Pro (598 $), 1.397 $ a precio de lista, o un acuerdo de volumen a medida dimensionado para eso (mejor preguntar directamente que apilar packs).
| Escenario | Créditos necesarios | Coste en FastAF | Estimación DIY (ancho de banda + cómputo + tiempo) |
|---|---|---|---|
| 1M páginas, estático | 1.000.000 | 299 $ (Pro) | ~1.200 $-3.000 $/mes |
| 1M páginas, renderizado JS | 5.000.000 | ~1.397 $ (Business + 2x Pro) o a medida | ~5.000 $-20.000 $/mes |
import requests
API_KEY = "faf_live_..."
def scrape(url, dynamic=False, premium=False):
resp = requests.get(
"https://api.fastaf.co/v1/scrape",
params={"url": url, "dynamic": str(dynamic).lower(), "premium": str(premium).lower()},
headers={"Authorization": f"Bearer {API_KEY}"},
timeout=60,
)
resp.raise_for_status()
return resp.text
page = scrape("https://example.com/product/123", dynamic=True)
print(page[:500])La parte que cambia las cuentas en ambos sentidos
Las solicitudes fallidas son el detalle que toda la comparación de arriba asume calladamente que no pasa, y no debería asumirse. En FastAF, los créditos se reservan cuando empieza una solicitud y se devuelven si no vuelve con un resultado: un intento bloqueado no te cuesta nada. Si haces tus propias cuentas DIY de arriba y tu tasa de bloqueo es del 15-20% en un objetivo difícil, el coste efectivo de ancho de banda y cómputo por página utilizable es un 15-20% más alto que el precio de etiqueta, y eso es antes del tiempo de ingeniero dedicado a perseguir el bloqueo.
La versión corta
Para páginas estáticas a volumen real, hacerlo tú mismo son unos cientos de dólares en proxies más un trabajo de mantenimiento que nunca desaparece del todo; la ruta API es un pack Pro de 299 $ fijos sin nada que mantener. Para páginas renderizadas con JS la brecha se hace mucho más ancha en ambas direcciones, porque el peso de página (DIY) y el coste en créditos (API) escalan juntos. Haz tus propias cuentas de peso de página y volumen con estos mismos números antes de comprometerte con una ruta: precios tiene la tabla completa de créditos, y el nivel gratuito te da 500 créditos sin tarjeta para probar contra tus páginas reales primero.