Comprobador de Códigos HTTP & Redirects

#Comprobador de Códigos HTTP & Redirects

Comprueba códigos de estado HTTP, analiza cadenas de redirección e inspecciona cabeceras de respuesta. Diagnostica errores de 1xx a 5xx, normas RFC, impacto en SEO y soluciones.

Escenarios de ingeniería en producción:
Configurador de código de estado y entorno de petición
▼
Variables de simulación dinámica
Latencia simulada45 ms
TTL de caché3,600s (1.0h)
6 campos analizados
Resolución bidireccional de síntomas:
Healthy request executionNormal page view
Código RFC: 200Idempotente: SÍSeguro: SÍAlmacenable en caché: POR DEFECTO
Diagrama de flujo de redirecciónRTT: 45ms | Score: 100%
100%Puntuación de seguridad1.0hIndicador de TTL de cachéCLICliente45ms200OrigenSAFE
200

OK

RFC 9110 §15.3.1
2xx Clase Cabeceras RFC correctas

Standard successful HTTP response. Action requested was received, understood, and accepted.

Causas principales en producción
  • Normal resource fetch
  • Successful query execution
  • API payload return
Solución y correcciones arquitectónicas
  • Keep payload sizes optimized with gzip/brotli
  • Set explicit Cache-Control headers
Matriz de cabeceras esperadas según RFC para HTTP 200:
Content-Type✓ Presente
Cache-Control✓ Presente
ETag / Validator✓ Presente
Location Header— No requerida
Motor: Canal de evaluación en cliente según RFC 9110 / RFC 9111Seleccionado: 200 OK
Espectro de conformidad RFCMás de 60 códigos de estado

Cobertura exhaustiva de los registros IETF RFC 9110, RFC 9111, RFC 7235, RFC 6585 y RFC 8297.

Aislamiento en memoria del clienteCero envíos al servidor

Las cookies privadas, cabeceras JWT y tokens secretos nunca salen del entorno aislado de su navegador.

Impacto en SEO de GooglebotAuditoría algorítmica profunda

Modela el traspaso de PageRank, riesgos de Soft 404, consumo de presupuesto de rastreo y velocidad de desindexación.

Procesamiento en el cliente

Cálculo de alto rendimiento ejecutado íntegramente en la memoria del navegador.

Privacidad sin envíos al servidor

Todas las cargas útiles permanecen estrictamente locales, sin comunicación con servidores externos.

Exportación lista para producción

Formatos de salida limpios y optimizados, listos para su implementación inmediata.

La evaluación de estados HTTP cumple las normas IETF RFC 9110 (semántica HTTP), RFC 9111 (caché HTTP), RFC 7235 (autenticación HTTP), RFC 6585 y las especificaciones de Google Search Central. Pruebe las cadenas de redirección en entornos de pruebas antes de su despliegue en producción.

Referencia técnica y guía de arquitectura

Comprobador de Códigos de Estado HTTP — Guía de referencia

Comprueba códigos de estado HTTP, analiza cadenas de redirección e inspecciona cabeceras de respuesta. Diagnostica errores de 1xx a 5xx, normas RFC e impacto en SEO.

Comprobador de Códigos de Estado HTTP — Guía de referencia — Arquitectura en memoria del lado del cliente y flujo de datos
Comprobador de Códigos de Estado HTTP — Guía de referencia — Arquitectura en memoria del lado del cliente y flujo de datos

Parámetros clave y controles

Código de Estado HTTP (RFC 9110)Entero de 3 dígitos (100 a 599)

Código numérico de estado de respuesta de 3 dígitos estandarizado por el RFC 9110 del IETF. Clasificado en 1xx (Informativo), 2xx (Éxito), 3xx (Redirección), 4xx (Error del cliente) y 5xx (Error del servidor).

Por defecto: 301
URL de Destino o URI del EndpointIdentificador de Recursos Uniforme RFC 3986

URL del endpoint de destino evaluada para comprobar códigos de estado HTTP, configuración de cabeceras y secuencias de saltos de redirección.

Por defecto: https://example.com/old-page
Perfil de Simulación User-AgentCadena de Cabecera de Cliente HTTP

Cabecera de solicitud User-Agent enviada durante la prueba. Simula bots de rastreo (Googlebot Desktop, Googlebot Smartphone) frente a navegadores web estándar o herramientas de desarrollo.

Por defecto: googlebot-smartphone
Contexto Arquitectónico de DiagnósticoSelector de Modo de Evaluación

Alterna el enfoque de diagnóstico entre microservicios de API REST, rastreadores SEO de motores de búsqueda, peticiones fetch en SPA cliente e infraestructura de proxy inverso o CDN edge.

Por defecto: seo-crawler
Cabeceras de Respuesta HTTP en BrutoTexto de Cabecera HTTP Delimitado por CRLF

Línea de estado de respuesta HTTP en bruto y pares clave-valor de cabeceras copiados desde terminal cURL, la pestaña Red de DevTools del navegador o registros del servidor en producción para su análisis en el cliente.

Por defecto: HTTP/1.1 301 Moved Permanently Location: https://example.com/new-page Cache-Control: public, max-age=86400
Método de Solicitud HTTP (Verbo)Método de Solicitud RFC 9110

Método HTTP utilizado (GET, HEAD, POST, PUT, DELETE, PATCH, OPTIONS). Determina si los códigos de redirección preservan el cuerpo de la solicitud o lo transforman en un GET.

Por defecto: GET

Consejos profesionales y mejores prácticas

La trampa de reescritura de método 301 frente a 308: por qué POST muta a GET

Históricamente, los principales navegadores web y librerías cliente HTTP convertían por error las solicitudes POST en GET al recibir respuestas 301 Moved Permanently o 302 Found (RFC 7231 §6.4.2). Este comportamiento rompe las operaciones de escritura en API REST y las subidas de archivos. Para garantizar que los métodos HTTP (POST, PUT, DELETE) y el cuerpo de la carga útil (payload) se mantengan estrictamente inalterados en una redirección permanente, los estándares RFC 7538 y RFC 9110 introdujeron HTTP 308 Permanent Redirect. Utiliza siempre 308 para endpoints de API y reserva el 301 para migraciones tradicionales de páginas HTML.

404 Not Found frente a 410 Gone: acelerando la desindexación en Googlebot

Cuando una página se elimina de forma permanente y sin reemplazo, responder con HTTP 410 Gone indica a los rastreadores de motores de búsqueda que la retirada es deliberada e irreversible. Mientras que Googlebot interpreta un 404 Not Found como un estado potencialmente transitorio y continúa rastreando la URL eliminada durante semanas o meses para verificar su desaparición, la documentación oficial de Google Search Central confirma que el código 410 Gone acelera la eliminación de la URL del índice de Google y frena el desperdicio de presupuesto de rastreo (crawl budget) con mucha mayor rapidez.

Caché heurística predeterminada en códigos de error según RFC 9111

Bajo la norma RFC 9111 §6.1, múltiples códigos de estado HTTP se consideran almacenables en caché de forma predeterminada, incluso ante la ausencia total de una cabecera "Cache-Control" explícita. En concreto, 200, 203, 204, 206, 300, 301, 404, 405, 410, 414 y 501 permiten el almacenamiento heurístico por parte de proxies intermedios y redes CDN. Si una API devuelve un error 404 o 405 debido a una conmutación por error (failover) temporal en la base de datos, los proxies perimetrales (edge) pueden almacenar en caché dicha respuesta errónea y servir 404 a solicitudes legítimas posteriores, a menos que se proteja con "Cache-Control: no-store, no-cache".

502 Bad Gateway frente a 504 Gateway Timeout: diagnóstico de fallos upstream

Diferenciar entre 502 y 504 permite aislar la capa exacta del fallo en arquitecturas modernas con proxy inverso (Nginx, AWS ALB, Cloudflare). Un 502 Bad Gateway indica que el proxy inverso logró conectarse al contenedor de la aplicación upstream, pero recibió un reinicio inmediato de la conexión TCP (connection reset), cabeceras de respuesta malformadas o la caída inesperada del proceso (por ejemplo, un cierre por falta de memoria OOM en Node.js). En cambio, un 504 Gateway Timeout indica que el proceso upstream recibió la solicitud y continuó en ejecución, pero no concluyó a tiempo antes de que expirara el límite de tiempo "proxy_read_timeout" del proxy.

Problemas comunes y soluciones

⚠️ERR_TOO_MANY_REDIRECTS (Bucle infinito cíclico 301/302)

Este error se produce cuando la URL A redirige a la URL B y esta, directa o indirectamente, vuelve a redirigir a la URL A. En entornos con Cloudflare y proxies inversos, suele originarse por una discordancia en el modo de cifrado SSL/TLS (por ejemplo, Cloudflare configurado en Flexible SSL conectándose mediante HTTP sin cifrar a un servidor de origen que impone una redirección 301 de HTTP a HTTPS). Se soluciona cambiando el modo SSL de Cloudflare a "Full (Strict)" o armonizando las reglas de reescritura en el servidor web.

⚠️Fallo de preflight CORS en respuestas 401 Unauthorized o 403 Forbidden

Cuando el navegador emite una solicitud preflight OPTIONS de CORS o una llamada fetch autenticada, los filtros de seguridad del backend (como Spring Security, middleware de Express o AWS API Gateway) con frecuencia rechazan la petición con 401 o 403 antes de inyectar las cabeceras "Access-Control-Allow-Origin". El navegador interpreta esto como un error de red CORS genérico en lugar de un desafío de autenticación. Asegúrate de que tu canal de seguridad en el servidor omita la comprobación de autenticación en las solicitudes OPTIONS e inyecte cabeceras CORS en todas las respuestas de error 4xx.

⚠️Aviso de Soft 404 en Google Search Console por contenido inexistente

Un error Soft 404 ocurre cuando el servidor web entrega una página con código de estado HTTP 200 OK, pero el contenido está prácticamente en blanco, muestra un aviso como "Artículo no encontrado" o redirige a la portada. Googlebot clasifica esto como engañoso porque los usuarios llegan a un callejón sin salida mientras el índice de búsqueda lo cataloga como contenido válido. Configura tu servidor web o ruta en Next.js para devolver un código explícito HTTP 404 Not Found o 410 Gone, o implementa una redirección 301 legítima hacia una página de categoría equivalente y relevante.

⚠️503 Service Unavailable sin cabecera Retry-After con impacto negativo en SEO

Al detener una aplicación por mantenimiento programado, responder con un 503 Service Unavailable simple sin la cabecera "Retry-After" (RFC 7231) hace que los rastreadores de motores de búsqueda interpreten la caída como una interrupción no planificada. Respuestas 503 prolongadas sin Retry-After provocan pérdidas temporales de posicionamiento. Configura siempre la página de mantenimiento para emitir "Retry-After: 3600" (en segundos) o una cadena de fecha HTTP conforme a RFC 1123, indicando con precisión a Googlebot cuándo debe reanudar el rastreo.

Preguntas frecuentes (FAQ)

¿Cuál es la diferencia entre las redirecciones HTTP 301 y 302?▼

Una redirección HTTP 301 Moved Permanently indica que el recurso solicitado se ha trasladado de forma definitiva a una nueva URL permanente. Los motores de búsqueda como Google transfieren entre el 90 % y el 99 % de la autoridad de enlace (PageRank link equity) al nuevo destino y reemplazan la URL antigua en el índice. Además, los navegadores almacenan las redirecciones 301 en su caché local de manera persistente. Por el contrario, una redirección HTTP 302 Found señala un traslado meramente temporal; los motores de búsqueda conservan la URL original en el índice y los navegadores no almacenan en caché la redirección por defecto.

¿Cuál es la diferencia entre 401 Unauthorized y 403 Forbidden?▼

El código HTTP 401 Unauthorized indica que la solicitud carece de credenciales de autenticación válidas. Según la especificación RFC 7235, el servidor debe incluir una cabecera "WWW-Authenticate" que detalle el mecanismo requerido para autenticarse (como autenticación Basic o token Bearer). Si se aportan credenciales correctas, la solicitud puede prosperar. En cambio, HTTP 403 Forbidden señala que el servidor reconoce la identidad del cliente, pero el usuario autenticado no posee los permisos o privilegios necesarios para acceder al recurso. Reenviar credenciales no modificará el resultado.

¿Cómo influyen los códigos de estado HTTP en el SEO y el posicionamiento en Google?▼

Los códigos de estado HTTP dan instrucciones directas a Googlebot sobre cómo rastrear e indexar un sitio web. Un código 200 OK indica contenido óptimo e indexable. Las redirecciones 301 y 308 consolidan la autoridad de enlace y actualizan las URLs canónicas sin mermar el posicionamiento. Los códigos 404 y 410 ordenan a los rastreadores eliminar páginas inactivas, acelerando el 410 la desindexación para preservar el presupuesto de rastreo (crawl budget). Los errores de servidor 5xx (en especial 500 o 503 prolongados) alertan de inestabilidad en la infraestructura, lo que induce a Googlebot a reducir la frecuencia de rastreo y disminuye temporalmente la visibilidad en resultados de búsqueda.

¿Cuál es la diferencia entre 502 Bad Gateway y 504 Gateway Timeout?▼

Ambos códigos se manifiestan en un proxy inverso intermedio o en una CDN (como Nginx, Cloudflare o AWS ALB). Un 502 Bad Gateway significa que el proxy logró contactar con el servidor backend upstream, pero este devolvió una respuesta no válida, corrupta o truncada (por ejemplo, la caída instantánea del proceso o un reinicio de conexión TCP). Por su parte, un 504 Gateway Timeout refleja que el proxy estableció conexión con el backend, pero este demoró su respuesta más allá del límite de tiempo configurado (como proxy_read_timeout).

¿Qué códigos de estado HTTP se almacenan en caché por defecto según RFC 9111?▼

De acuerdo con el RFC 9111 §6.1, los códigos de estado definidos como almacenables en caché por defecto (salvo anulación expresa mediante cabeceras Cache-Control) son: 200 OK, 203 Non-Authoritative Information, 204 No Content, 206 Partial Content, 300 Multiple Choices, 301 Moved Permanently, 404 Not Found, 405 Method Not Allowed, 410 Gone, 414 URI Too Long y 501 Not Implemented. El resto de códigos requieren directivas explícitas como "Cache-Control: public" o max-age para ser conservados en cachés compartidas.

¿Por qué las solicitudes POST pasan a ser GET tras una redirección 301 o 302?▼

Históricamente, los primeros navegadores web implementaron las redirecciones 301 y 302 transformando las peticiones POST en GET para evitar el reenvío involuntario de formularios al seguir la cabecera Location. Aunque el RFC 7231 documentó posteriormente esta práctica generalizada pero no estándar, las especificaciones HTTP modernas formalizaron HTTP 307 Temporary Redirect y HTTP 308 Permanent Redirect (RFC 9110), las cuales prohíben estrictamente alterar el método HTTP o el cuerpo de la solicitud durante la redirección.

Herramientas y utilidades relacionadas

Todas las herramientas →