Verificador de Estado Web
Un verificador de estado web envía una petición HTTP a una URL e informa del código de estado que devuelve el servidor. Los códigos 200–399 cuentan como activo; 400–599 o un tiempo de espera agotado cuentan como caído. Comprobar aquí https://example.com devuelve 200 OK en unas pocas decenas de milisegundos, así que el sitio nos responde a nosotros, no solo a ti.
Códigos de estado HTTP y lo que informa este verificador
| Código | Frase de motivo | Veredicto aquí | Qué significa para tu comprobación |
|---|---|---|---|
| 200 | OK | Activo | El servidor respondió con normalidad. No hay nada que arreglar. |
| 301 | Moved Permanently | Activo | Redirección permanente. Esta herramienta no la sigue, así que verás el 301 junto con la cabecera Location. |
| 302 | Found | Activo | Redirección temporal, a menudo hacia una página de mantenimiento, de inicio de sesión o de enrutamiento geográfico. |
| 304 | Not Modified | Activo | La copia en caché sigue siendo válida. Solo se devuelve cuando la petición incluye validadores. |
| 403 | Forbidden | Caído | El servidor respondió, así que el host es accesible y esto no es una caída. Un WAF, un filtro antibots o una lista de IP permitidas rechazó a este cliente; el veredicto sigue siendo Caído porque 403 es un código 4xx. |
| 404 | Not Found | Caído | El host respondió, así que es accesible: solo falta la ruta que pediste. Prueba a continuación el dominio a secas. |
| 429 | Too Many Requests | Caído | Límite de peticiones: demasiadas en poco tiempo. Si la respuesta incluye una cabecera Retry-After, espera hasta el momento que indique —un número de segundos o una fecha HTTP— antes de volver a probar. |
| 500 | Internal Server Error | Caído | La aplicación falló en el origen. Consulta el registro de errores del origen. |
| 502 | Bad Gateway | Caído | Un proxy o una CDN no pudo alcanzar el origen, a menudo durante un despliegue. |
| 503 | Service Unavailable | Caído | Sobrecarga o mantenimiento programado. Temporal por definición; comprueba Retry-After. |
| 504 | Gateway Timeout | Caído | El origen tardó en responder más de lo que el proxy estaba dispuesto a esperar. |
| 0 | Sin respuesta | Caído | No respondió nada: fallo de DNS, conexión rechazada, certificado TLS no válido o tiempo agotado: 8 segundos para establecer la conexión y 15 segundos en total. |
Los veredictos siguen las clases de estado del RFC 9110: 200–399 se informa como activo y 400–599 como caído. El veredicto describe la URL que has escrito, no la máquina que hay detrás: con un 403 o un 404 el servidor ha respondido, así que el host es accesible y ninguno de los dos casos es una caída. Un 304 cuenta como activo porque el recurso existe; un 404 cuenta como caído porque la URL solicitada no existe.
¿El sitio está caído o solo me pasa a mí?
La comprobación de arriba se ejecuta en nuestro servidor, no en tu navegador, y eso es justo lo que hace útil la comparación. Si esta página informa de un 200 OK mientras tu navegador muestra un error de conexión, la avería es local: un resolver DNS con un registro muerto en caché, una VPN o un proxy corporativo, una entrada en tu archivo hosts o un problema de enrutamiento de tu operador. Si fallan las dos, el origen o su CDN están realmente caídos y no hay nada que arreglar en tu equipo.
¿Por qué se caen los sitios web?
Casi todas las caídas pertenecen a seis familias, y el código de estado te dice ante cuál estás:
- Certificado TLS caducado o que no coincide con el nombre: la conexión falla antes de que empiece HTTP, por eso ves el estado 0.
- Registros DNS cambiados o caducados: el nombre de host ya no se resuelve, de nuevo estado 0.
- El proceso de la aplicación se ha caído o se ha quedado sin memoria: 500 desde el origen, 502 desde el proxy que tiene delante.
- Más tráfico que capacidad, o una ventana de mantenimiento planificada: 503, normalmente con Retry-After.
- Una base de datos lenta o un arranque en frío que supera el tiempo de espera del proxy: 504.
- Un incidente del proveedor en una CDN, una región de nube o un registrador, capaz de tumbar a la vez miles de sitios sin relación entre sí.
¿Qué hago si mi web está caída?
Trabaja de fuera hacia dentro, en este orden:
- Lanza la comprobación aquí para confirmar que el fallo no es solo de tu red.
- Lee el código. 0 apunta a DNS o TLS; 5xx, al origen; 403, a una regla de cortafuegos; 404, a un vhost o una ruta equivocados.
- Abre la lista de cabeceras de respuesta: Server, Location y Retry-After identifican la capa que te respondió.
- Consulta las páginas de estado de tu proveedor de hosting y de tu CDN antes de abrir un ticket de soporte.
- Repite la comprobación después de cada cambio y exporta el CSV para que el ticket lleve marcas de tiempo en lugar de capturas de pantalla.
¿Cómo de rápido debería responder un sitio web?
El tiempo de respuesta que se muestra es el viaje de ida y vuelta que necesitó nuestro servidor para una única petición HEAD: resolución DNS, conexión TCP, handshake TLS y la primera respuesta del servidor. No incluye imágenes, CSS, JavaScript ni el renderizado, así que es mucho menor que una cifra de carga de Lighthouse. Estas son las bandas de color que usa esta página:
| Tiempo de respuesta | Color | Lectura |
|---|---|---|
| < 500 ms | Verde | Saludable. Típico de un nodo de CDN o de una caché caliente. |
| 500–1500 ms | Amarillo | Aceptable, pero conviene vigilarlo: normalmente es un viaje hasta el origen sin caché en el borde. |
| > 1500 ms | Rojo | Lento. Revisa la CPU del origen, las consultas a la base de datos, los arranques en frío y el enrutamiento intercontinental. |
Acerca de Verificador de Estado Web
Un verificador de estado web responde bien a una pregunta muy concreta: ¿respondió el servidor y qué dijo? Esta herramienta abre una única petición HTTP HEAD a la dirección que escribes, concede 8 segundos para establecer la conexión y 15 segundos para la petición completa, e informa de cuatro datos — el código de estado numérico, el tiempo de ida y vuelta en milisegundos, el Content-Type y la cabecera Server — más la lista completa de cabeceras de respuesta que devolvió el origen.
Dos decisiones de diseño hacen que la lectura sea inequívoca. Primero, no se siguen las redirecciones. Si example.com responde 301, ves 301 y su cabecera Location en lugar del estado de otra página tres saltos más allá; eso es justo lo que quieres al verificar una regla de HTTP a HTTPS o de non-www. Segundo, el veredicto sigue las clases de estado definidas en el RFC 9110: de 200 a 399 se informa como activo, de 400 a 599 como caído, y un estado 0 significa que la petición nunca llegó a completarse — el DNS no resolvió, la conexión fue rechazada, el certificado TLS no validó o el origen agotó el tiempo.
La comprobación se ejecuta desde nuestro servidor y no desde tu navegador, y por eso resuelve la duda de si el sitio está caído para todos o solo para ti. Si tu equipo no puede cargar una web pero esta página informa de un 200 OK, el fallo es local: tu resolver, tu operador, una VPN, un proxy corporativo o una entrada obsoleta en el archivo hosts. Si fallan los dos, el problema está en el origen o en su CDN.
El modo masivo acepta hasta 10 direcciones, una por línea, y las comprueba en orden con una pausa de 300 ms entre peticiones, de modo que una sola ejecución no agote la cuota de 60 comprobaciones por minuto. Los resultados vuelven como una lista compacta que puedes descargar en CSV o copiar como tabla separada por tabuladores directamente en una hoja de cálculo o en una incidencia. Cada comprobación genera además un enlace que vuelve a ejecutarse solo cuando alguien lo abre, así que el aviso de caída llega con la prueba adjunta y no con una captura de pantalla.
Una advertencia que conviene recordar: las peticiones salen de una IP de centro de datos con el user agent FreeWebTools Status Checker/1.0. Los sitios con filtrado agresivo de bots pueden respondernos 403 mientras atienden con normalidad a los navegadores, así que lee un 403 como «ha rechazado a este cliente» y no automáticamente como «caído».
Casos de uso
Cómo comprobar si un sitio web está caído
Deja seleccionada la pestaña URL única y escribe la dirección que quieres probar, por ejemplo example.com; si falta el prefijo https://, se añade automáticamente.
Haz clic en Comprobar estado. Una petición HTTP sale de nuestro servidor y el mensaje de resultado indica El sitio está ACTIVO para los códigos 200–399, o El sitio está CAÍDO para 400–599 y tiempos de espera agotados.
Lee las cuatro casillas: Código de estado, Tiempo de respuesta, Tipo de contenido y Servidor. Los tiempos por debajo de 500 ms se muestran en verde y por encima de 1500 ms en rojo.
Abre la lista Encabezados de respuesta para ver todo lo que envió el origen, incluido Location en un 301 y Retry-After en un 429 o un 503.
Cambia a la pestaña Comprobación masiva para pegar hasta 10 URL, una por línea, y guarda el resultado con Descargar CSV o Copiar como tabla.
Usa Copiar enlace para compartir y envía una dirección que repite exactamente la misma comprobación cuando alguien la abre.
Consejos Pro
- Comprueba por separado el dominio a secas y la versión www. example.com y www.example.com suelen apuntar a hosts distintos, y puede que solo falle uno de ellos.
- El estado 0 no es un 500. Significa que no respondió absolutamente nada, así que revisa la resolución DNS y la caducidad del certificado TLS antes de culpar a la aplicación.
- Los tiempos de respuesta por debajo de 500 ms salen en verde, de 500 a 1500 ms en amarillo y por encima de 1500 ms en rojo. La cifra es solo el viaje al servidor: sin imágenes, CSS ni JavaScript.
- Si aquí obtienes 403 pero el sitio carga en tu navegador, un WAF está filtrando las IP de centros de datos o nuestro user agent FreeWebTools Status Checker/1.0. Eso no es una caída.
- El modo masivo está limitado a 10 URLs y la API permite 60 comprobaciones por minuto y dirección IP. Divide las listas largas en lotes en lugar de reintentar hasta provocar un 429.
Solución de problemas
La comprobación devuelve el código de estado 0 y ninguna cabecera.
No respondió nada. Puede que el nombre de host no se resuelva, que la conexión fuera rechazada, que el certificado TLS esté caducado o emitido para otro nombre, o que la petición agotara el tiempo: 8 segundos para establecer la conexión y 15 segundos en total. Revisa primero el DNS y el certificado, y prueba después la versión http:// para aislar un fallo de TLS.
Indicamos 403 Forbidden pero el sitio carga bien en el navegador.
Una regla de WAF o antibots está bloqueando las IP de centros de datos o el user agent FreeWebTools Status Checker/1.0. El sitio está activo: solo rechaza a los clientes automatizados. Añade la comprobación a la lista de permitidos o confírmalo desde una conexión doméstica.
La comprobación masiva se detiene a mitad con un aviso de límite de peticiones.
La API permite 60 comprobaciones por minuto y dirección IP. Espera sesenta segundos y vuelve a lanzar las URLs restantes, o divide la lista en lotes más pequeños. La ejecución ya separa sus peticiones 300 ms.
Una página que funciona en el navegador devuelve 404 aquí.
Probablemente estés probando una ruta que no existe en ese host, o el dominio resuelve a un host virtual por defecto. Prueba primero el dominio a secas y añade la ruta cuando la raíz responda 200.
Preguntas frecuentes
Escribe la dirección en el campo de arriba y pulsa «Comprobar estado». La herramienta envía una única petición HTTP desde nuestro servidor e informa del código de estado, del tiempo de respuesta y de todas las cabeceras de la respuesta. Un código entre 200 y 399 significa que el sitio está activo; de 400 a 599, o un estado 0, significa que está caído. El tiempo de respuesta que ves es el viaje de ida y vuelta que necesitó nuestro servidor, no tu navegador: resolución DNS, conexión TCP, handshake TLS y la primera respuesta, a menudo unas pocas decenas de milisegundos con un origen cercano.
Este comprobador se ejecuta desde nuestro servidor, no desde tu navegador, así que comparar los dos resultados localiza el fallo. Si nosotros informamos de un 200 OK y tú sigues sin poder cargar la página, el problema está de tu lado: caché DNS, VPN, proxy, caché del navegador o archivo hosts. Si nosotros también obtenemos un 502 o un tiempo agotado, el fallo está en el lado del sitio y no en el tuyo, aunque un bloqueo geográfico o una regla de cortafuegos contra nuestra IP se vería igual desde aquí.
503 Service Unavailable significa que el servidor es accesible pero ahora mismo se niega a atender la petición, normalmente por sobrecarga o por mantenimiento programado. Es temporal por definición y a menudo llega con una cabecera Retry-After que indica cuándo volver a intentarlo. Los buscadores interpretan un 503 breve como «vuelve más tarde» y no como un fallo permanente.
En la práctica: certificados TLS caducados o que no coinciden y registros DNS rotos (ambos aparecen como estado 0), una aplicación que ha fallado o se ha quedado sin memoria (500), un proxy que no alcanza el origen en mitad de un despliegue (502), tráfico por encima de la capacidad o mantenimiento (503), una base de datos más lenta que el tiempo de espera del proxy (504) e incidencias generales de CDN o de nube del proveedor.
Confirma primero aquí que el fallo no es local a tu red. Luego lee el código: 5xx significa revisar los registros del origen y el gestor de procesos, 0 significa comprobar el DNS y la caducidad del certificado, 403 apunta a una regla de cortafuegos o de WAF, y un 404 en el dominio a secas, a un host virtual equivocado. Consulta la página de estado de tu proveedor antes de abrir un ticket.
Sí. Cambia a la pestaña «Comprobación masiva» y pega hasta 10 URLs, una por línea. Se comprueban por turnos con 300 ms de separación entre peticiones, y los resultados aparecen como una lista con veredicto, código de estado y tiempo de respuesta. Después puedes descargar la tanda entera en CSV o copiarla como tabla separada por tabulaciones.
No, y es deliberado. Las redirecciones no se siguen para que un 301 o un 302 se muestre exactamente como lo envió el servidor, junto con su cabecera Location, que es justo lo que necesitas al comprobar una regla de HTTP a HTTPS o de non-www. Para recorrer una cadena de redirecciones salto a salto, usa nuestro Verificador de redirecciones.
Porque la petición llega desde una IP de centro de datos con el user agent FreeWebTools Status Checker/1.0. Los servicios antibots, los WAF y las reglas de cortafuegos de las CDN responden habitualmente a los clientes automatizados con 403 Forbidden o una página de desafío, mientras atienden con normalidad a los navegadores reales. Por eso un 403 de esta herramienta significa «ha rechazado a este cliente», no siempre «caído».
Es el tiempo, en milisegundos, que necesitó nuestro servidor para completar una única petición HEAD, incluidas la resolución DNS, la conexión TCP y el handshake TLS. No incluye imágenes, CSS, JavaScript ni el renderizado, así que es mucho menor que una puntuación de carga de Lighthouse. Compara unas mediciones con otras y cuenta con 100–300 ms extra si el origen está lejos.
No. El endpoint rechaza los nombres localhost, 127.0.0.1, 0.0.0.0 y ::1, cualquier IP de un rango privado o reservado como 192.168.x.x o 10.x.x.x, direcciones de metadatos de nube como 169.254.169.254 y puertos sensibles como el 22, el 3306 y el 6379. El nombre de host se resuelve una vez y se rechaza si esa dirección IPv4 es privada; la comprobación es solo IPv4, así que tómala como una protección frente a la falsificación de peticiones del lado del servidor (SSRF), no como una garantía. Para hosts internos, usa curl desde dentro de la red.
Fuentes y estándares
Las cinco clases de estado y el significado de cada código proceden de la especificación HTTP y del registro de la IANA que aparecen abajo. Las páginas de MDN y de Google Search Central son documentación, no especificaciones, y el 429 Too Many Requests está definido en el RFC 6585, no en el RFC 9110. El veredicto activo/caído es nuestra propia lectura de esos límites de clase: esta página considera activo el rango 200–399 y caído el 400–599, así como cualquier petición que no llegue a recibir un código de estado.
- RFC 9110, HTTP Semantics, sección 15: la definición normativa de cada clase de estado.
- Registro de códigos de estado HTTP de la IANA: la lista autorizada de códigos asignados.
- MDN, códigos de estado de respuesta HTTP: notas prácticas sobre cada código.
- Google for Developers, «How HTTP Status Codes Affect Google's Crawlers»: qué significa cada código para el rastreo y la indexación.
- Google for Developers, «Debug Network and DNS Errors for Google's Crawlers»: qué ocurre cuando una petición no recibe ningún código de estado.
- RFC 6585, Additional HTTP Status Codes, sección 4: la definición del 429 Too Many Requests y de su indicación Retry-After.