Cómo solucionar los errores comunes en Web Scraping

En cualquier sistema de scraping, los errores 403, 503, 429 y 500 forman parte del comportamiento esperado del servidor. Cada uno indica una condición técnica específica: saturación, denegación de acceso, límites de petición o fallos internos.
Este documento explica cómo identificar la causa exacta y aplicar la solución adecuada, siguiendo prácticas estándar de ingeniería y los mecanismos que utilizamos en Octoparse para mantener tareas estables bajo entornos con restricciones.

Diferencias rápidas

Código	Significado en español	Causa típica	Cómo identificarlo	Solución principal
403 – Acceso denegado	El servidor bloquea la entrada	Anti-bot, UA incorrecto, cookies faltantes, IP bloqueada	Navegador sí carga → bloqueo al scraper	Headers completos, cookies, modo navegador
429 – Demasiadas solicitudes	Se excede el límite permitido	Ritmo muy rápido o muchas peticiones desde una misma IP	Funciona al inicio y luego falla	Reducir velocidad, delays aleatorios, rotar IPs
503 – Servicio no disponible	El servidor no puede atender más	Sobrecarga temporal o scraper demasiado rápido	Navegador sí carga → exceso de carga del scraper	Delays, reintentos, Cloud Run
500 – Error interno del servidor	Fallo dentro del sitio	Problema en la web o solicitudes mal formadas	Navegador también falla → culpa del servidor	Backoff, reintentos; si persiste, esperar

Error 403

El error 403 Forbidden indica que el servidor ha recibido la solicitud, pero ha decidido bloquear el acceso.
En web scraping, este error es uno de los más comunes porque forma parte de los mecanismos anti-bot utilizados por muchos sitios.

Un 403 no significa necesariamente que el sitio esté caído. En la mayoría de los casos, significa que el servidor ha detectado alguna característica de la solicitud que considera no válida o no humana.

A continuación se presenta una guía completa para entenderlo, diagnosticarlo y resolverlo.

Diagnóstico inicial

Antes de aplicar soluciones, es necesario determinar el tipo de bloqueo.

Abrir la misma URL en un navegador normal.
Revisar el comportamiento:

Si la página carga sin problemas

Significa que la web permite el acceso, pero bloquea el tráfico del scraper por:

User-Agent incorrecto
Falta de headers
Cookies ausentes
IP bloqueada

Si también aparece 403 en el navegador

El sitio podría tener:

Restricciones geográficas
Control de acceso por login
Limitaciones de permisos

Este tipo de 403 no se resuelve desde el scraper sin credenciales o sin una IP del país correcto.

Causas más frecuentes del 403 en web scraping

User-Agent identificado como bot–Muchos scrapers base usan User-Agents genéricos o vacíos, lo que dispara bloqueos automáticos.

Headers incompletos–Faltan elementos esperados por el servidor, como Accept-Language o Referer.

Ausencia de cookies–Algunos sitios requieren una cookie inicial generada por una visita previa.

IP con mala reputación–IPs de centros de datos suelen bloquearse de forma preventiva.

Protección anti-bot (Cloudflare, Akamai, Firewall de Aplicación)–Estas plataformas detectan solicitudes no humanas y devuelven 403 como respuesta estándar.

1. Cómo resolverlo en Octoparse

Configurar Esperar antes de la acción entre 3 y 5 segundos para reducir la carga sobre el servidor.
Ejecutar la tarea con Ejecutar en la nube, que utiliza IPs rotación y evita bloqueos por patrones repetitivos.
Activar el reintento automático cuando una página no carga, lo que permite reintentar sin intervención manual.

Estas medidas corrigen la mayoría de los errores 503 causados por velocidad excesiva o limitaciones temporales del servidor.

2. Otras soluciones técnicas

Reducir la frecuencia de solicitudes añadiendo 2–4 s entre cada petición.
Rotar IPs para evitar limitaciones aplicadas a una única dirección IP.
Enviar headers completos, especialmente un User-Agent actualizado.
Aplicar reintentos con backoff para recuperarse de caídas temporales.

Ejemplo minimalista en Python:

import requests

# Añadir headers realistas para evitar detección como bot
headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)",
    "Accept-Language": "es-ES,es;q=0.9",
    "Accept": "text/html,application/xhtml+xml"
}

session = requests.Session()
session.headers.update(headers)

response = session.get(url)

if response.status_code == 403:
    print("Acceso bloqueado. Revisar headers, cookies o cambiar IP.")

3. Cuándo no puedes solucionarlo

El servidor está en mantenimiento.
La web presenta una saturación real y no depende del cliente.
El proveedor ha limitado temporalmente todas las solicitudes, independientemente de la configuración.

Error 503

El error 503 Service Unavailable indica que el servidor no puede procesar la solicitud en ese momento.
En web scraping, este error suele aparecer cuando el servidor recibe demasiadas peticiones en un intervalo corto o cuando detecta un patrón de acceso no humano.

Un 503 no significa necesariamente que el sitio esté caído; a menudo es una respuesta temporal que se activa para proteger la infraestructura del servidor.

Diagnóstico inicial

Antes de aplicar soluciones, es importante identificar si el problema proviene del scraper o del servidor.

Abrir la misma URL en un navegador.
Analizar el resultado:

Si la página carga con normalidad

El servidor está operativo y el error proviene de:

Frecuencia de solicitudes demasiado alta
IP temporalmente limitada
Falta de variación en el comportamiento
Headers insuficientes

Si también aparece 503 en el navegador

Puede deberse a:

Sobrecarga real del servidor
Mantenimiento temporal
Limitaciones aplicadas por el proveedor de hosting

En este caso, ninguna configuración del scraper resolverá el problema hasta que el servidor recupere su capacidad.

Causas más frecuentes del 503 en web scraping

Frecuencia de solicitudes demasiado elevada
IP bloqueada por comportamiento repetitivo
Falta de headers o User-Agent válido
Acceso simultáneo desde múltiples tareas
Problemas temporales del servidor

1. Cómo resolverlo en Octoparse

Configurar Esperar antes de la acción (2–4 s) para reducir la presión sobre el servidor.
Ejecutar la tarea con Ejecutar en la nube, que distribuye las solicitudes entre varias IPs y reduce bloqueos.
Activar el reintento automático para recuperar páginas que fallan de forma temporal.
Revisar que no haya acciones duplicadas o bucles que generen solicitudes innecesarias.

Estas acciones permiten evitar la mayoría de los errores 503 causados por exceso de velocidad o por saturación temporal del servidor.

2. Otras soluciones técnicas

Reducir la frecuencia de peticiones añadiendo 2–4 s entre cada llamada.
Rotar IPs si el servidor limita direcciones con demasiadas solicitudes.
Enviar headers completos, especialmente un User-Agent actualizado.
Aplicar backoff progresivo en caso de recibir múltiples errores consecutivos.

Ejemplo minimalista en Python:

import requests
import time
import random

resp = requests.get(url)

if resp.status_code == 429:
    # Si el servidor indica cuánto esperar, respetarlo
    wait = int(resp.headers.get("Retry-After", 2))
    
    # Añadir variación aleatoria para evitar patrones
    wait += random.uniform(0.5, 1.5)
    
    time.sleep(wait)
    resp = requests.get(url)

3. Cuándo no puedes solucionarlo

El servidor está en mantenimiento o realmente saturado.
El proveedor limita temporalmente todas las solicitudes sin excepción.
Existen restricciones a nivel de infraestructura que no dependen del cliente.

Error 429

El error 429 Too Many Requests indica que el servidor ha recibido más solicitudes de las que permite en un intervalo de tiempo.
En web scraping, este error aparece cuando la frecuencia de peticiones supera el límite establecido por el sitio o cuando la IP acumula demasiadas solicitudes en un período corto.

A diferencia de otros códigos, el 429 no implica un fallo del servidor. Es una señal de que se ha alcanzado un umbral de uso y que el cliente debe disminuir el ritmo.

Diagnóstico inicial

Antes de aplicar ajustes, es útil observar el comportamiento del scraping:

Si el scraper funciona bien al principio y luego aparece 429

Indica que el servidor ha detectado un aumento de solicitudes por segundo.

Si todas las solicitudes devuelven 429 desde el inicio

Puede tratarse de:

Límite estricto aplicado por IP
IP bloqueada temporalmente
Límite de cuota diario o por sesión

En ambos casos, el problema se relaciona directamente con la velocidad o la cantidad de solicitudes.

Causas más frecuentes del 429 en web scraping

Frecuencia de peticiones demasiado alta
Envío de solicitudes desde una única IP sin variación
Falta de intervalos aleatorios entre solicitudes
Concurrencia excesiva (varias tareas a la vez)
Límites estrictos de servicios protegidos por CDN o APIs

1. Cómo resolverlo en Octoparse

Configurar Esperar antes de la acción entre 2 y 4 segundos para reducir la frecuencia de peticiones.
Habilitar delays aleatorios, lo que evita patrones repetitivos detectados por el servidor.
Ejecutar la tarea en Ejecutar en la nube, donde las solicitudes se distribuyen en IPs diferentes.
Reducir la concurrencia, evitando ejecutar múltiples instancias del mismo flujo al mismo tiempo.

Estas medidas funcionan en la mayoría de los casos en los que el servidor aplica límites temporales por velocidad o saturación.

2. Otras soluciones técnicas

Reducir la velocidad de peticiones, especialmente si el scraping es secuencial.
Introducir jitter aleatorio, para romper patrones fijos de ritmo.
Rotar IPs, ya que muchos límites se aplican por dirección IP.
Implementar reintentos con backoff, que permiten recuperar solicitudes después de un límite temporal.

Ejemplo minimalista en Python para 429:

import time
import requests

response = requests.get(url)

if response.status_code == 429:
    time.sleep(2)       # esperar antes de reintentar
    response = requests.get(url)

Esto refleja el comportamiento típico para recuperar solicitudes después de un límite temporal.

3. Cuándo no puedes solucionarlo

El sitio impone límites estrictos por día, hora o API y no admite más solicitudes.
La IP está permanentemente limitada por abuso previo.
Existen reglas anti-bot que no permiten el acceso sin variación de IP ni encabezados avanzados.

En estos casos, disminuir la velocidad no será suficiente; se requiere rotación de IPs o esperar a que se restablezcan los límites.

Error 500

El error 500 Internal Server Error indica que el servidor encontró un problema al procesar la solicitud.
A diferencia de errores relacionados con bloqueos o límites (403, 429), el 500 suele deberse a fallos internos del propio servidor, aunque también puede aparecer cuando el scraper envía solicitudes demasiado rápidas o mal formadas.

En web scraping, este error puede ser temporal o recurrente, dependiendo de la estabilidad del sitio y del volumen de tráfico que reciba.

Diagnóstico inicial

Antes de tomar medidas, es importante verificar si el error proviene del servidor o del scraper.

Abrir la misma URL en un navegador.
Observar el resultado:

Si la página carga con normalidad

El problema se origina en el scraper:

Solicitudes demasiado rápidas
Falta de headers
IP detectada como tráfico anómalo
Estructuras de solicitud no compatibles con el servidor

Si también aparece 500 en el navegador

El servidor está experimentando un fallo real:

Caída temporal
Error interno de la aplicación
Sobrecarga del hosting
Problemas en la base de datos del sitio

En este caso, no existe una solución inmediata desde el scraper: es necesario esperar.

Causas más frecuentes del 500 en web scraping

Sobrecarga del servidor por demasiadas solicitudes simultáneas
Acceso desde una única IP con patrones repetitivos
Solicitudes sin headers esenciales
Errores internos del propio sitio (no relacionados con el scraper)
Respuestas inestables en sitios con infraestructura limitada

1. Cómo resolverlo en Octoparse

Configurar Esperar antes de la acción entre 3 y 5 segundos para reducir picos de carga generados por el scraper.
Activar el reintento automático, permitiendo que el flujo recupere páginas afectadas por fallos temporales.
Ejecutar la tarea mediante Ejecutar en la nube, que usa IPs optimizadas y mayor estabilidad de red.
Comprobar que el flujo no envíe peticiones duplicadas o innecesarias.

Estas medidas resuelven la mayoría de errores 500 que no se originan en el propio servidor.

2. Otras soluciones técnicas

Reducir la frecuencia de solicitudes cuando los primeros intentos funcionan pero luego aparecen fallos.
Enviar headers completos, especialmente un User-Agent actualizado, Accept y Accept-Language.
Rotar IPs en caso de recibir bloqueos del servidor tras cierto volumen de tráfico.
Implementar reintentos con backoff, lo que otorga al servidor tiempo adicional para recuperarse.

Ejemplo minimalista en Python para 500:

import requests
import time

def fetch(url):
    for intento in range(3):
        resp = requests.get(url)

        # Si el servidor falla internamente
        if resp.status_code != 500:
            return resp

        # Backoff progresivo: 1s → 2s → 4s
        time.sleep(2 ** intento)

    return resp

Este patrón permite recuperarse de errores 500 temporales sin sobrecargar al servidor.

3. Cuándo no puedes solucionarlo

El sitio presenta un fallo real en su infraestructura.
El servidor está en mantenimiento o saturado.
El proveedor del sitio devuelve 500 de manera sistemática por problemas internos.

En estas situaciones, ninguna configuración del scraper podrá solucionarlo.
La única opción es esperar a que el servidor restablezca su funcionamiento.

Resumen

En general, comprender la naturaleza de cada error —403, 429, 503 y 500— permite diagnosticar problemas de forma más rápida y precisa durante un proceso de web scraping.
Aunque cada código responde a causas distintas, la metodología siempre es la misma: identificar si el problema proviene del servidor o de la configuración del scraper y aplicar la solución adecuada en cada caso.

Trabajar con herramientas que manejan automáticamente headers, cookies, rotación de IPs, controles de velocidad y reintentos reduce de manera significativa la aparición de estos errores y permite mantener procesos más estables y reproducibles.
Con una configuración correcta, la mayoría de estas situaciones se resuelven sin intervención manual y sin comprometer la continuidad del scraping.