Comprobador del estado del servidor

Acerca de Comprobador del estado del servidor

El comprobador de estado del servidor de ToolsPivot te dice si una web responde ahora mismo, con qué código HTTP y en cuánto tiempo. En lugar de un simple «sí o no», hace una petición real desde nuestro servidor y te devuelve el código exacto, la cadena de redirecciones, el certificado SSL y el servidor o CDN que hay detrás. Analiza hasta 20 URLs de una vez, sin registro y sin clave de API. Si solo necesitas una respuesta rápida, el comprobador de webs caídas resuelve el caso más simple.

Qué es el comprobador de estado del servidor de ToolsPivot

Funcionalidad principal

La herramienta hace una petición HTTP real a la URL que introduces y analiza la respuesta completa del servidor. Envía primero una petición HEAD, que pide solo las cabeceras y no el cuerpo de la página, por lo que es rápida y ligera. Si el servidor rechaza HEAD con un 405 o directamente no contesta, reintenta de forma automática con un GET normal. De la respuesta extrae el código de estado, los tiempos, las redirecciones y las cabeceras, la misma información que verías con un analizador de cabeceras HTTP pero interpretada y ordenada.

Usuarios objetivo y casos de uso

Lo usan sobre todo desarrolladores, consultores SEO, administradores de sistemas y responsables de tiendas online. Un autónomo con WordPress lo abre cuando un cliente le dice que la página no carga; una agencia verifica cientos de URLs tras una migración; un técnico de soporte lo consulta antes de abrir una incidencia con el hosting.

Problema y solución

«No me carga la web» puede significar cinco cosas distintas: el dominio no resuelve, el servidor rechaza la conexión, el certificado ha caducado, la aplicación devuelve un 500 o hay un bucle de redirecciones. Un comprobador que solo dice «caída» no las distingue. Aquí ves el código exacto, en qué fase se pierde el tiempo y en qué salto se rompe la cadena.

Principales ventajas del comprobador de estado del servidor

• Diagnóstico en tres estados: distingue entre servidor caído, servidor que responde con error y servidor correcto, en lugar de reducirlo todo a un semáforo de dos colores.
• Código con significado: cada código va acompañado de su explicación según las definiciones estándar de HTTP, sin que tengas que buscar qué implica un 502 o un 429.
• Tiempos desglosados por fase: ves si la lentitud viene del DNS, del handshake TLS o del propio servidor pensando, algo que un test de velocidad de página resume en una sola cifra.
• Cadena de redirecciones completa: recorre los saltos uno a uno y detecta bucles, en vez de mostrarte solo el destino final.
• Aviso de certificado caducado: señala la fecha de caducidad y los días restantes; para un análisis más profundo tienes el verificador de certificados SSL.
• Análisis por lotes: hasta 20 URLs, con filtros por clase de código y exportación a CSV.
• Sin fricción de entrada: no pide cuenta, correo ni clave de API, sirva para una consulta puntual o para una revisión rutinaria.
• Límites declarados: la herramienta indica qué no puede confirmar, para que no interpretes un bloqueo antibot como una caída real.

Funciones clave del comprobador de estado del servidor

• Petición HEAD con reserva GET: cambia a GET cuando el servidor no admite HEAD, evitando falsos errores 405.
• User-agent de navegador real: se identifica como un navegador habitual, lo que reduce las respuestas «prohibido» que algunos filtros antibot devuelven a los verificadores.
• Clasificación 2xx a 5xx: 2xx y 3xx se marcan como en línea; 4xx y 5xx, como servidor activo con problema en la página.
• Tiempo hasta el primer byte y tiempo total: dos métricas que separan la reacción inicial del servidor del tiempo completo de la petición.
• Barra de tiempos proporcional: reparte la petición en resolución DNS, conexión TCP, handshake TLS, espera del servidor y descarga, y dibuja cada tramo a escala.
• Recorrido salto a salto: registra código y URL de cada hop, resuelve destinos absolutos y relativos y corta a los diez saltos.
• Detección de bucles: avisa cuando una URL redirige a otra ya visitada, el patrón típico de una regla mal escrita en el .htaccess; el comprobador de redirecciones www cubre el caso concreto de www frente a dominio raíz.
• Lectura del certificado: muestra emisor, fecha de caducidad y días restantes de la conexión HTTPS, y marca el certificado como caducado cuando procede.
• Identificación de servidor y tecnología: expone la cabecera Server y cualquier X-Powered-By, útil junto a una consulta de registros DNS.
• Detección de CDN por cabeceras: reconoce Cloudflare por CF-Ray, Vercel por x-vercel-id, CloudFront por X-Amz-Cf-Id, además de Varnish, Fastly y Akamai; para saber quién aloja el dominio, el detector de hosting completa la foto.
• Revisión de cabeceras de seguridad: comprueba HSTS, CSP, X-Frame-Options, X-Content-Type-Options y Referrer-Policy, y marca cada una como presente o ausente.
• Modo masivo con filtros: la pestaña de lotes acepta 20 URLs, una por línea, y filtra los resultados por clase de estado o por caídas.

Cómo funciona el comprobador de estado del servidor de ToolsPivot

1. Pega la URL completa, con http:// o https://, en el campo principal, o cambia a la pestaña de análisis masivo si tienes varias.
2. La herramienta resuelve el host a su IP y valida que no apunte a un rango privado, de loopback o reservado antes de conectar. Si necesitas ver esa resolución por separado, el conversor de dominio a IP hace ese paso concreto.
3. Lanza la petición HEAD con user-agent de navegador y, si el servidor la rechaza, repite con GET.
4. Recorre la cadena de redirecciones salto a salto hasta el destino final, revalidando cada URL de destino.
5. Lee las cabeceras y el certificado de la respuesta final y clasifica el resultado como en línea, con error o inalcanzable.
6. Revisa el desglose de tiempos, la cadena de saltos y las cabeceras detectadas, y exporta el lote a CSV si lo necesitas.

Cuándo usar el comprobador de estado del servidor

Úsalo cuando una web deja de comportarse como esperas y necesitas saber si el problema está en el servidor, en la configuración o en tu conexión. Es la primera comprobación razonable antes de escribir al soporte del hosting, porque llegas con un código concreto en la mano.

• Después de una migración: verifica que las URLs antiguas devuelven 301 al destino correcto y no encadenan saltos innecesarios.
• Antes de una campaña: comprueba tiempos de respuesta y certificado días antes de un pico de tráfico como el Black Friday o las rebajas de enero.
• Cuando un cliente reporta una caída: confirma en segundos si el servidor responde y con qué código, antes de escalar la incidencia.
• Al renovar un certificado: valida que el nuevo certificado se está sirviendo de verdad y no queda el anterior en caché de la CDN.
• Tras tocar el .htaccess o Nginx: detecta bucles de redirección que un navegador con caché puede ocultarte.
• En auditorías técnicas: revisa una lista de URLs clave y cruza los resultados con un detector de enlaces rotos para separar errores de servidor de enlaces mal escritos.
• Cuando sospechas de un bloqueo: un 403 desde nuestro servidor con carga correcta en tu navegador apunta a un filtro por IP o por país.

Con un WAF agresivo o un geobloqueo activo, no saques conclusiones precipitadas: el resultado describe lo que ve nuestro servidor, no lo que ve un visitante desde Madrid o Barcelona.

Casos de uso

Tienda online con pasarela de pago

Contexto: una tienda con PrestaShop y pasarela Redsys empieza a perder pedidos un viernes por la tarde.

• Comprobación de la home y de la URL de checkout por separado.
• La home devuelve 200 y el checkout, 503 intermitente.
• El desglose de tiempos muestra una espera de servidor larga, no un problema de red.

Resultado: el diagnóstico apunta al backend saturado y no a la pasarela, lo que acorta la conversación con el hosting.

Migración de dominio de una agencia

Contexto: una agencia traslada 18 landing pages a un dominio nuevo y valida las redirecciones antes de avisar a Google.

• Carga de las 18 URLs antiguas en la pestaña de análisis masivo.
• Revisión de la cadena de saltos de cada una hasta el destino final.
• Exportación del lote a CSV para adjuntarlo al informe del cliente.

Resultado: tres URLs con doble salto se corrigen a una sola redirección 301 antes del lanzamiento.

Incidencia de seguridad en una pyme

Contexto: el responsable de sistemas de una pyme detecta tráfico anómalo y quiere una foto rápida de la exposición de su web.

• Comprobación de cabeceras de seguridad presentes y ausentes.
• Verificación de la fecha de caducidad del certificado.
• Contraste con un analizador de seguridad web para el análisis en profundidad.
• Consulta de la IP del servidor en una búsqueda en listas negras.

Resultado: se documenta la falta de HSTS y CSP y se prioriza su despliegue en el siguiente sprint.

Cómo interpretar el código de estado que devuelve tu web

El código de estado te dice qué ha hecho el servidor con tu petición, no si la web «funciona bien» a ojos de un visitante. Un 200 confirma la entrega, pero no que el contenido sea el correcto: una página de error servida con 200 es uno de los fallos más frecuentes en auditorías SEO.

Lectura rápida por familias:

• 2xx: el servidor ha respondido y entregado contenido; es el resultado esperado en páginas activas.
• 3xx: hay redirección; revisa el destino y evita cadenas de más de un salto.
• 4xx: el servidor está vivo y rechaza la petición; el 404 y el 403 concentran la mayoría de los casos.
• 5xx: el servidor ha fallado al procesar; el 500 apunta a la aplicación y el 502 o el 504 a la comunicación entre capas.

Si una página que debería estar indexada devuelve 404 o 410, la consecuencia inmediata es su salida del índice; puedes confirmarlo con un comprobador de indexación antes de dar el problema por resuelto.

Por qué un ping no sirve para saber si tu web funciona

Un ping comprueba que una máquina responde en la red, no que tu web esté sirviendo páginas. Un servidor puede contestar al ping mientras Apache o Nginx están caídos, con lo que verías «todo bien» y tus visitantes seguirían viendo un error. La situación contraria también es habitual: muchos proveedores y CDN bloquean el protocolo ICMP por seguridad, así que un ping fallido no significa nada sobre el estado real del sitio.

Por eso esta herramienta trabaja sobre HTTP real y no sobre ICMP: la petición recorre el mismo camino que recorrería un navegador, incluidas las capas de TLS y de aplicación, donde se producen la mayoría de los fallos que afectan a usuarios. Si sospechas de tu propia conexión, un test de velocidad de internet descarta esa parte.

Qué mide cada fase del tiempo de respuesta

El tiempo total se reparte entre cinco fases, y saber cuál domina cambia el diagnóstico. La resolución DNS traduce el dominio a IP; la conexión TCP establece el canal; el handshake TLS negocia el cifrado; la espera del servidor es lo que el backend dedica a generar la respuesta; y la descarga transfiere los datos.

La métrica de referencia es el tiempo hasta el primer byte. Google recomienda, como guía orientativa, que la mayoría de los sitios se mantengan en 0,8 segundos o menos, un umbral razonable para contrastar tus resultados. Cuando la fase dominante es la espera del servidor, el problema suele estar en la aplicación, la base de datos o la caché; cuando dominan DNS o TCP, mira hacia la red y la distancia geográfica al servidor.

Seguridad y límites de la comprobación

Una herramienta que consulta cualquier URL que le indiques es un objetivo clásico de abuso, así que valida cada destino antes de conectar. Resuelve el host a su IP y rechaza direcciones privadas, de loopback, de enlace local o reservadas, incluida la de metadatos de nube 169.254.169.254. Después fija la conexión a esa IP validada, admite solo los esquemas http y https, revalida cada destino de redirección y aplica topes de tiempo, tamaño y número de saltos.

Sobre lo que la herramienta no puede hacer, conviene ser claro. Comprueba desde una única ubicación, la de nuestro servidor, así que confirma si el sitio responde desde aquí pero no puede certificar una caída regional o un geobloqueo, algo que requiere nodos distribuidos. Un 403 o un 429 de un servicio antibot puede significar que se ha bloqueado al verificador, no que el sitio esté caído. Y la detección de servidor, CDN y cabeceras de seguridad es siempre orientativa, porque esas cabeceras se pueden ocultar o falsear en un proxy intermedio.

Preguntas frecuentes