Cada código de respuesta HTTP explicado en lenguaje sencillo, con cuándo usarlo y cómo afecta al SEO. Busca, filtra o enlaza directamente a un código.
La petición se ha recibido y el proceso continúa. Los navegadores gestionan estos códigos automáticamente.
El servidor ha recibido las cabeceras de la petición y el cliente puede enviar el cuerpo.
Cuándo usarlo: Se envía en respuesta a una petición con Expect: 100-continue, para que el cliente compruebe que una subida grande será aceptada antes de transmitirla.
El servidor acepta cambiar al protocolo indicado en la cabecera Upgrade del cliente.
Cuándo usarlo: Se usa al actualizar una conexión HTTP/1.1 a WebSocket (Upgrade: websocket).
WebDAV: el servidor ha aceptado la petición, pero aún no ha terminado de procesarla.
Cuándo usarlo: Evita que un cliente agote el tiempo de espera en operaciones WebDAV largas. Hoy se usa poco.
Permite al servidor enviar cabeceras Link (preload / preconnect) antes de que la respuesta final esté lista.
Cuándo usarlo: Envíalo mientras el backend aún genera la página, para que el navegador empiece a cargar antes el CSS, las fuentes o los scripts críticos.
La petición se ha recibido, entendido y aceptado.
La petición se ha completado correctamente. El cuerpo contiene el recurso solicitado o el resultado de la acción.
Cuándo usarlo: La respuesta de éxito por defecto para GET, y para POST/PUT cuando devuelves un cuerpo.
Impacto en SEO: El único estado que permite indexar una página con su contenido. Asegúrate de que las páginas “no encontrado” no devuelvan 200 (un “soft 404”).
La petición se ha completado y se ha creado un nuevo recurso.
Cuándo usarlo: Devuélvelo tras un POST (o PUT) que crea algo; incluye una cabecera Location que apunte al nuevo recurso.
La petición se ha aceptado para su procesamiento, pero el procesamiento aún no ha terminado.
Cuándo usarlo: Tareas asíncronas: pon el trabajo en cola y devuelve una URL donde el cliente pueda consultar el resultado.
La respuesta ha sido modificada por un proxy de transformación y difiere de la respuesta 200 del servidor de origen.
Cuándo usarlo: Lo envían los proxies que alteran el contenido; los servidores de origen normalmente no deberían enviarlo.
La petición se ha completado y, a propósito, no hay cuerpo en la respuesta.
Cuándo usarlo: Peticiones DELETE, endpoints de autoguardado y respuestas preflight de CORS, cuando no hay nada que devolver.
La petición se ha completado y el cliente debe restablecer la vista del documento (por ejemplo, vaciar un formulario).
Cuándo usarlo: Poco frecuente; indica al navegador que reinicie el formulario que envió la petición.
El servidor solo envía el rango de bytes solicitado mediante una cabecera Range.
Cuándo usarlo: Streaming de vídeo, descargas reanudables y gestores de descargas.
WebDAV: el cuerpo es un documento XML con códigos de estado independientes para varias subpeticiones.
Cuándo usarlo: Operaciones WebDAV por lotes en las que cada elemento puede tener éxito o fallar por separado.
WebDAV: los miembros de un enlace ya aparecían antes en la misma respuesta 207.
Cuándo usarlo: Evita repetir el mismo recurso dentro de una respuesta Multi-Status.
El servidor ha respondido a un GET aplicando manipulaciones de instancia (codificación delta).
Cuándo usarlo: Codificación delta de HTTP (RFC 3229); casi nunca se ve en la práctica.
Hace falta una acción adicional, normalmente seguir una cabecera Location hasta otra URL.
El recurso tiene varias representaciones y el cliente (o el usuario) debe elegir una.
Cuándo usarlo: Poco frecuente; la negociación de contenido suele hacerse automáticamente.
Impacto en SEO: Google puede elegir cualquiera de las opciones; es mejor usar un único 301 hacia la versión canónica.
El recurso tiene una nueva URL permanente, indicada en la cabecera Location.
Cuándo usarlo: Cambios de dominio, paso de HTTP a HTTPS, slugs modificados o fusión de páginas duplicadas.
Impacto en SEO: La forma estándar de mover una página: los buscadores transfieren las señales de posicionamiento e indexan la nueva URL. Los navegadores pueden cambiar POST por GET con un 301; usa 308 si hay que mantener el método.
El recurso se encuentra temporalmente en otra URL.
Cuándo usarlo: Redirecciones de corta duración, como páginas de mantenimiento, pruebas A/B o flujos de inicio de sesión.
Impacto en SEO: Google lo trata como temporal y normalmente mantiene indexada la URL original. Si el cambio es permanente, usa 301.
El cliente debe obtener el resultado desde otra URL usando GET.
Cuándo usarlo: El patrón “Post/Redirect/Get”: tras enviar un formulario por POST, redirige a una página de confirmación.
Impacto en SEO: Se trata como una redirección temporal.
La copia en caché sigue siendo válida; no se envía cuerpo.
Cuándo usarlo: Respuesta a peticiones condicionales (If-None-Match / If-Modified-Since) cuando el recurso no ha cambiado.
Impacto en SEO: Mejora la eficiencia del rastreo: Googlebot reutiliza su copia en caché y ahorra presupuesto de rastreo.
Obsoleto. Originalmente indicaba al cliente que accediera al recurso a través de un proxy.
Cuándo usarlo: No lo uses: los navegadores lo ignoran por motivos de seguridad.
Igual que 302, pero el cliente debe repetir la petición con el mismo método y cuerpo.
Cuándo usarlo: Redirecciones temporales de peticiones POST/PUT; los navegadores también muestran “307 Internal Redirect” en las actualizaciones HSTS.
Impacto en SEO: Temporal: la URL original normalmente sigue indexada.
Igual que 301, pero el cliente debe mantener el mismo método y cuerpo.
Cuándo usarlo: Cambios permanentes de endpoints de API o destinos de formularios donde un POST debe seguir siendo POST.
Impacto en SEO: Google trata 308 igual que 301 y transfiere las señales a la nueva URL.
La petición contiene un error o no puede completarse: el cliente debe cambiar algo antes de reintentar.
El servidor no puede procesar la petición porque está mal formada (sintaxis incorrecta, JSON no válido, cookie demasiado grande…).
Cuándo usarlo: Errores de validación que no puedes expresar con más precisión; incluye un mensaje de error en el cuerpo.
Impacto en SEO: Las páginas que devuelven 4xx se eliminan del índice.
Se requiere autenticación y falta o no es válida. A pesar del nombre, significa “no autenticado”.
Cuándo usarlo: Token o credenciales ausentes o caducados. Debe incluir una cabecera WWW-Authenticate.
Impacto en SEO: Los rastreadores no pueden iniciar sesión, así que las páginas tras un 401 no se indexan, lo que es lo deseable para áreas privadas.
Reservado para uso futuro; algunas APIs lo usan cuando hace falta un pago o una mejora de cuota.
Cuándo usarlo: Errores de facturación no estándar (por ejemplo, una suscripción caducada).
El servidor ha entendido la petición, pero se niega a autorizarla. Volver a autenticarse no servirá.
Cuándo usarlo: El usuario ha iniciado sesión pero no tiene permiso, o el acceso está bloqueado por IP, WAF o permisos de archivo.
Impacto en SEO: No se indexa. Comprueba que tu cortafuegos o protección contra bots no devuelva 403 a Googlebot por error.
El servidor no encuentra el recurso solicitado.
Cuándo usarlo: La URL nunca existió o se eliminó sin sustituto. Muestra una página 404 personalizada y útil.
Impacto en SEO: Normal e inofensivo para páginas que realmente no existen; Google las elimina con el tiempo. Redirige (301) las URL que tengan enlaces entrantes o un sustituto claro.
El método HTTP no está permitido para esta URL (p. ej., POST a una página de solo lectura).
Cuándo usarlo: Devuélvelo con una cabecera Allow que indique los métodos permitidos.
El servidor no puede generar una respuesta que coincida con las cabeceras Accept de la petición.
Cuándo usarlo: Negociación de contenido estricta; muchas APIs simplemente devuelven su formato por defecto.
Igual que 401, pero el cliente debe autenticarse en un proxy.
Cuándo usarlo: Lo envían proxies corporativos o de reenvío con una cabecera Proxy-Authenticate.
El servidor agotó el tiempo de espera esperando a que el cliente terminara de enviar la petición.
Cuándo usarlo: Conexiones inactivas o muy lentas; los clientes pueden reintentar.
La petición entra en conflicto con el estado actual del recurso.
Cuándo usarlo: Conflictos de edición, claves únicas duplicadas o discrepancias de versión en bloqueo optimista.
El recurso se eliminó de forma permanente y no volverá.
Cuándo usarlo: Contenido borrado a propósito, anuncios o campañas caducados.
Impacto en SEO: Google trata 410 como 404, pero puede eliminar la URL un poco más rápido.
El servidor requiere una cabecera Content-Length.
Cuándo usarlo: Subidas sin longitud cuando no se acepta la codificación por fragmentos (chunked).
Una condición de las cabeceras de la petición (If-Match, If-Unmodified-Since) se evaluó como falsa.
Cuándo usarlo: Concurrencia optimista: rechaza una actualización porque el recurso cambió desde que el cliente lo leyó.
El cuerpo de la petición supera el tamaño permitido por el servidor (antes “Payload Too Large”).
Cuándo usarlo: Subidas de archivos por encima de tu límite, por ejemplo con client_max_body_size de nginx.
La URL es más larga de lo que el servidor puede interpretar.
Cuándo usarlo: Normalmente es un error: cadenas de consulta enormes o bucles de redirección que siguen añadiendo parámetros.
El formato del cuerpo (Content-Type) no está soportado.
Cuándo usarlo: Una API que espera application/json recibe datos de formulario o XML.
La cabecera Range pide bytes que están fuera del archivo.
Cuándo usarlo: Reanudar una descarga desde más allá del final de un archivo que se ha reducido.
El servidor no puede cumplir el requisito de la cabecera Expect.
Cuándo usarlo: Rechazar subidas con Expect: 100-continue.
Una broma del Día de los Inocentes de la RFC 2324 (Hyper Text Coffee Pot Control Protocol): el servidor se niega a preparar café porque es una tetera.
Cuándo usarlo: Solo como huevo de Pascua. Algunos servicios lo devuelven para rechazar peticiones automatizadas o no deseadas, pero no tiene un significado estándar.
La petición llegó a un servidor que no puede generar una respuesta para este host.
Cuándo usarlo: Reutilización de conexiones HTTP/2 entre nombres de host cuyo certificado o configuración no coincide.
La sintaxis es válida, pero el contenido no supera la validación semántica.
Cuándo usarlo: Errores de validación de formularios o APIs (campo obligatorio ausente, correo no válido). Es habitual en APIs de Rails y Laravel.
WebDAV: el recurso está bloqueado.
Cuándo usarlo: Un archivo está reservado o bloqueado por otro usuario.
WebDAV: la petición ha fallado porque dependía de una petición anterior que falló.
Cuándo usarlo: Operaciones por lotes en las que un fallo cancela el resto.
El servidor no procesará una petición que podría reproducirse (datos tempranos de TLS 1.3 / 0-RTT).
Cuándo usarlo: Proteger peticiones no idempotentes enviadas en datos tempranos de TLS frente a ataques de repetición.
El cliente debe cambiar a otro protocolo, indicado en la cabecera Upgrade.
Cuándo usarlo: Obligar a los clientes a usar una versión más reciente del protocolo.
El servidor exige que la petición sea condicional (por ejemplo, incluir If-Match).
Cuándo usarlo: Evitar “actualizaciones perdidas” rechazando PUT/PATCH incondicionales.
El cliente ha enviado demasiadas peticiones en un periodo de tiempo (limitación de frecuencia).
Cuándo usarlo: Límites de API y protección contra fuerza bruta. Incluye una cabecera Retry-After.
Impacto en SEO: Googlebot reduce su ritmo de rastreo cuando recibe 429 (y 503). Los 429 persistentes pueden provocar que se eliminen URL.
Una cabecera (a menudo Cookie) o todas las cabeceras juntas son demasiado grandes.
Cuándo usarlo: Suele deberse a cookies acumuladas; borrar las cookies del sitio lo soluciona para los usuarios.
El recurso está bloqueado por motivos legales: censura, órdenes judiciales o normativa regional. El número hace referencia a Fahrenheit 451 de Ray Bradbury.
Cuándo usarlo: Contenido retirado por una solicitud de retirada o restringido geográficamente por ley.
Impacto en SEO: Se trata como otros códigos 4xx: no se indexa.
El servidor no ha podido completar una petición aparentemente válida.
Error genérico: el servidor se ha encontrado con una situación inesperada.
Cuándo usarlo: Excepciones no controladas, scripts que fallan o reglas de .htaccess rotas. Revisa los logs del servidor.
Impacto en SEO: Las caídas breves se toleran; si los errores 5xx persisten durante días, Google reduce el rastreo y acaba eliminando URL.
El servidor no admite la funcionalidad requerida (a menudo, un método desconocido).
Cuándo usarlo: Un método que el servidor no reconoce en absoluto, a diferencia de 405 para uno conocido pero no permitido.
Una puerta de enlace o proxy ha recibido una respuesta no válida del servidor upstream.
Cuándo usarlo: Tu servidor de aplicaciones (PHP-FPM, Node, Gunicorn) se ha caído o ha devuelto datos basura detrás de nginx, un balanceador de carga o un CDN.
Impacto en SEO: Igual que otros 5xx: un fallo temporal es aceptable; los errores persistentes perjudican el rastreo y la indexación.
El servidor no puede atender la petición temporalmente: sobrecargado o caído por mantenimiento.
Cuándo usarlo: Mantenimiento programado o sobrecarga. Añade Retry-After para indicar cuándo volver.
Impacto en SEO: El código correcto para caídas planificadas: Google mantiene la página indexada y vuelve a intentarlo más tarde. No lo mantengas más de uno o dos días.
Una puerta de enlace o proxy no recibió a tiempo respuesta del servidor upstream.
Cuándo usarlo: Consultas lentas a la base de datos o APIs upstream que superan el timeout del proxy.
Impacto en SEO: Los timeouts persistentes reducen el ritmo de rastreo y pueden provocar la desindexación.
El servidor no admite la versión de HTTP usada en la petición.
Cuándo usarlo: Versiones de protocolo muy antiguas o muy nuevas que el servidor no puede manejar.
Error de configuración del servidor: la variante elegida también está configurada para negociar, creando un bucle.
Cuándo usarlo: Un error de configuración en la negociación de contenido.
WebDAV: el servidor no puede almacenar la representación necesaria para completar la petición.
Cuándo usarlo: El disco o la cuota del usuario están llenos.
WebDAV: el servidor ha detectado un bucle infinito al procesar la petición.
Cuándo usarlo: Algunos hosts (p. ej., cPanel/CloudLinux) también lo devuelven cuando una cuenta alcanza sus límites de recursos.
Se requieren extensiones adicionales en la petición (RFC 2774, ya histórica).
Cuándo usarlo: En la práctica, no se usa.
El cliente debe autenticarse para acceder a la red.
Cuándo usarlo: Portales cautivos en Wi-Fi de hoteles, aeropuertos o cafeterías.
No forman parte de la especificación HTTP, pero son habituales en los logs de servidor y en las páginas de error.
nginx cierra la conexión sin enviar ninguna respuesta.
Cuándo usarlo: Configurado en nginx para descartar en silencio peticiones maliciosas o no deseadas.
nginx lo registra cuando el cliente cierra la conexión antes de que el servidor responda.
Cuándo usarlo: Lo verás en los logs cuando los usuarios abandonan la página o cuando el timeout del cliente es más corto que el tiempo de respuesta.
Cloudflare ha recibido una respuesta vacía, desconocida o inesperada del servidor de origen.
Cuándo usarlo: Caídas del origen, cabeceras demasiado grandes o reinicios de conexión. Revisa los logs de errores del origen.
Impacto en SEO: Se trata como un error 5xx.
El servidor de origen ha rechazado la conexión de Cloudflare.
Cuándo usarlo: El servidor web está parado o un cortafuegos bloquea los rangos IP de Cloudflare.
Impacto en SEO: Se trata como un error 5xx.
Cloudflare no pudo completar una conexión TCP con el origen.
Cuándo usarlo: Origen sobrecargado, registro DNS incorrecto o un cortafuegos que descarta paquetes.
Impacto en SEO: Se trata como un error 5xx.
Cloudflare se conectó al origen, pero este no respondió en 100 segundos.
Cuándo usarlo: Peticiones de larga duración; muévelas a tareas en segundo plano.
Impacto en SEO: Se trata como un error 5xx.
Falló el handshake TLS entre Cloudflare y el origen.
Cuándo usarlo: El origen no tiene un certificado válido o no soporta SNI/las versiones de TLS que usa Cloudflare.
Impacto en SEO: Se trata como un error 5xx.
Cloudflare (en modo Full Strict) no pudo validar el certificado del origen.
Cuándo usarlo: Certificado del origen caducado o autofirmado; instala uno válido o un certificado Origin CA de Cloudflare.
Impacto en SEO: Se trata como un error 5xx.
Tus datos nunca salen de tu ordenador. Todo se procesa localmente en tu navegador.
404) o una palabra (redirect, timeout, rate limit) en el buscador./http-status-codes#429) para documentación o revisiones de código.Un código de estado HTTP es el número de tres dígitos que el servidor envía al inicio de cada respuesta para indicar cómo ha ido la petición. Tu navegador, los clientes de API y los rastreadores de los buscadores lo leen antes que cualquier otra cosa. El primer dígito define la clase: 1xx informativo, 2xx éxito, 3xx redirección, 4xx error de cliente y 5xx error de servidor. Las definiciones vigentes están en la RFC 9110 (HTTP Semantics, 2022), con algunas extensiones como 429 (RFC 6585) y 451 (RFC 7725).
| Código | Significado | Causa habitual |
|---|---|---|
| 200 | OK | Todo funcionó |
| 301 / 308 | Redirección permanente | La página o el dominio se han movido |
| 302 / 307 | Redirección temporal | Flujos de inicio de sesión, mantenimiento, pruebas A/B |
| 304 | No modificado | La caché del navegador sigue siendo válida |
| 401 / 403 | No autenticado / prohibido | Falta el token, permisos insuficientes, bloqueo del WAF |
| 404 | No encontrado | URL incorrecta o página eliminada |
| 429 | Demasiadas solicitudes | Se ha superado el límite de peticiones |
| 500 | Error interno del servidor | Error o fallo en la aplicación |
| 502 / 504 | Puerta de enlace incorrecta / tiempo agotado | El backend tras un proxy o CDN ha fallado o ha tardado demasiado |
| 503 | Servicio no disponible | Mantenimiento o sobrecarga |
Los buscadores solo indexan las páginas que devuelven 200. Las redirecciones permanentes (301, 308) transfieren las señales de posicionamiento a la nueva URL, mientras que las temporales (302, 307) mantienen la URL antigua en el índice. Con el tiempo, 404 y 410 eliminan una página: es algo normal para contenido que ya no existe, pero las URL que tienen enlaces entrantes deben redirigirse. Un soft 404 (una página de error que devuelve 200) desperdicia el presupuesto de rastreo y Google Search Console lo marca. Ante una caída temporal, devuelve 503 con una cabecera Retry-After: Google mantiene tus páginas indexadas y vuelve más tarde, mientras que los errores 5xx prolongados o las respuestas 429 hacen que Googlebot rastree menos y acabe eliminando URL.
Location después de crear un recurso, y 204 cuando no haya nada que devolver.Retry-After para los límites de peticiones.Comprueba qué estado devuelve una URL real con el HTTP Header Checker, sigue las cadenas de redirección con el Redirect Checker o envía tus propias peticiones con el API Tester.
También se busca como: códigos de respuesta http, lista de códigos http, error 404, redirección 301, error 500, 503, 429 demasiadas solicitudes, 418 tetera.
Retry-After. Indica a los rastreadores que la caída es temporal, así que los cortes breves de mantenimiento no afectan a tu posicionamiento.Sugiere una mejora para «Códigos de estado HTTP» o pide una herramienta nueva — llega directamente a nuestro buzón.
Las aplicaciones web instaladas se abren en su propia ventana; las herramientas basadas en el navegador siguen funcionando sin conexión a Internet. Más información
Busca entre todas las 500+ herramientas gratuitas —no pasa nada si cometes algún error ortográfico— o dinos qué quieres que creemos a continuación.