Cómo comprobar si un sitio web está caído (para todos o solo para ti)
Un sitio web no abre. ¿Está caído para todos o el problema está de tu lado: tu Wi-Fi, tu DNS, tu navegador? Y si es tu propio sitio, ¿por dónde empiezas? Esta guía recorre las comprobaciones en el orden que más tiempo ahorra, desde "¿soy solo yo?" hasta el propio servidor.
Paso 1: ¿está caído para todos o solo para ti?
La forma más rápida de saberlo es mirar el sitio desde otro lugar:
- Ábrelo en tu teléfono con el Wi-Fi desactivado (los datos móviles usan otra red y normalmente otro DNS).
- Prueba con otro navegador o una ventana privada: las extensiones y los datos en caché pueden romper las páginas.
- Usa el verificador de estado de sitios web. Solicita la página desde nuestro servidor, que está en una red y una ubicación distintas a las tuyas, y muestra el estado HTTP, el tiempo de respuesta, el SSL y las redirecciones.
Si el sitio funciona desde nuestro servidor y desde los datos móviles, pero no desde tu red doméstica, el problema es local: router, caché de DNS, VPN, antivirus o firewall corporativo. Reinicia el router, vacía la caché de DNS, desactiva la VPN e inténtalo de nuevo. Si el sitio falla en todas partes, sigue leyendo.
Paso 2: lee el error
El mensaje de error ya reduce las posibles causas:
- "No se puede acceder a este sitio web" / DNS_PROBE_FINISHED_NXDOMAIN: el nombre de dominio no se resuelve a ninguna dirección. Ve al paso de DNS.
- Tiempo de conexión agotado / conexión rechazada: el DNS funciona, pero el servidor no responde: está caído, sobrecargado o un firewall corta la conexión.
- Advertencia de certificado (NET::ERR_CERT_DATE_INVALID y similares): el servidor responde, pero el certificado SSL está vencido, es inválido o corresponde a otro nombre.
- Una página con un código de error (500, 502, 503, 404…): el servidor es accesible y responde; el problema está en la aplicación, la configuración o la URL.
¿Todo el sitio o solo una página?
Antes de meterte con los servidores, revisa el alcance. Abre la página de inicio y dos o tres páginas más, incluido un archivo estático como una imagen o robots.txt. Si los archivos estáticos cargan pero las páginas no, el servidor web está activo y la aplicación (CMS, base de datos, PHP) está fallando. Si solo falla una sección, fíjate en qué la hace especial: un plugin, una API externa, una consulta pesada a la base de datos. Si la página de inicio funciona pero un enlace concreto devuelve 404, es posible que la página se haya movido sin una redirección. Y si todo falla solo en el área de administración, la causa suele ser una sesión, una cookie o una regla de seguridad, y no una caída.
Paso 3: códigos de estado HTTP, 5xx frente a 4xx
Cuando un servidor responde, devuelve un código de estado. El verificador de estado HTTP muestra el código exacto de cualquier URL, incluidas todas las redirecciones del camino.
| Código | Qué suele significar | Causa habitual |
|---|---|---|
| 500 | Error interno del servidor | Error en el código, plugin o actualización fallidos, permisos de archivo incorrectos |
| 502 | Puerta de enlace incorrecta | El servidor web o la CDN no reciben una respuesta válida de la aplicación que está detrás (PHP-FPM, Node, upstream) |
| 503 | Servicio no disponible | Sobrecarga, modo de mantenimiento, límite de procesos alcanzado |
| 504 | Tiempo de espera de la puerta de enlace agotado | La aplicación responde demasiado lento; consultas pesadas, procesos atascados |
| 403 | Prohibido | Permisos, bloqueo de IP, una regla de un WAF o de un plugin de seguridad |
| 404 | No encontrado | URL incorrecta, página eliminada, reglas de reescritura rotas: el servidor en sí está activo |
| 429 | Demasiadas solicitudes | Límite de solicitudes impuesto por el servidor o la CDN |
La regla general: 5xx significa que hay un problema del lado del servidor; 4xx significa que el servidor funciona, pero rechaza o no encuentra esta solicitud en particular. Una página de inicio que devuelve 404 no está "caída" en el sentido habitual: hay algo mal con la URL o con el enrutamiento.
Paso 4: problemas de DNS
Si el dominio no se resuelve, revisa sus registros con la consulta DNS: ¿existe el registro A (o AAAA) y apunta al servidor correcto? ¿Los registros NS son los que te dio tu proveedor de DNS?
Causas comunes:
- El dominio expiró. Los registradores suelen cambiar el DNS a una página de estacionamiento o eliminarlo por completo. Revisa la fecha de vencimiento en WHOIS.
- Los registros se cambiaron recientemente. Después de mover el hosting o cambiar de proveedor de DNS, algunos resolvers siguen devolviendo la dirección anterior hasta que se agota el TTL en caché. El verificador de propagación DNS compara las respuestas de muchos resolvers públicos con las de los servidores autoritativos y muestra quién ya ve el nuevo valor.
- Se cambiaron los nameservers en el registrador, pero la zona en el nuevo proveedor está vacía o incompleta.
Para una guía de todos los tipos de registros, consulta cómo revisar los registros DNS de un dominio.
Paso 5: un certificado SSL vencido
Los navegadores bloquean un sitio con un certificado vencido mostrando una advertencia a pantalla completa, que los visitantes interpretan como "el sitio está caído". La renovación automática suele evitarlo, pero falla sin avisar cuando cambia el DNS, se añade un CDN o el proceso de renovación deja de ejecutarse. El verificador SSL muestra la fecha de vencimiento, la cadena y los nombres cubiertos. Más detalles: revisión de certificados SSL.
Paso 6: caídas del hosting, del CDN y de terceros
A veces el problema no está en tu sitio. Los grandes proveedores de hosting, las plataformas en la nube y los CDN publican páginas de estado (normalmente status.provider.com) con los incidentes en curso. Si usas un CDN como Cloudflare, sus propias páginas de error te indican qué lado falló: un error que menciona tu servidor de origen significa que el CDN funciona, pero no puede conectar con tu hosting.
Revisa también la lentitud, no solo las caídas: la herramienta de tiempo de respuesta desglosa una solicitud en DNS, conexión, TLS y tiempo hasta el primer byte. Un TTFB de muchos segundos apunta a un servidor sobrecargado o a una aplicación lenta, lo que a menudo precede a los errores 502 y 504.
Paso 7: bloqueos por firewalls y WAF
Un sitio puede estar "caído" solo para algunos visitantes. Los firewalls de aplicaciones web, los plugins de seguridad, la protección DDoS del hosting y los bloqueos por país pueden bloquear una dirección IP, un proveedor completo o un país. Señales: error 403 o una página de verificación para unas personas y acceso normal para otras; el sitio funciona con datos móviles, pero no desde la oficina. Si la IP de tu servidor o de tu servidor de correo está en una lista de bloqueo pública, consulta por qué mi IP está en una lista negra.
Para propietarios de sitios: qué hacer ahora y la próxima vez
- Confirma la caída desde fuera (verificador de estado, datos móviles).
- Revisa lo evidente: vencimiento del dominio y del certificado, cuenta de hosting suspendida por una factura sin pagar, disco lleno.
- Consulta los logs: el log de errores del servidor web y el log de la aplicación justo en el momento del fallo. La mayoría de los errores 500 se explican ahí.
- Deshaz el último cambio: una actualización de plugin, un despliegue, una edición de configuración. Primero revierte, después investiga.
- Reinicia los servicios (servidor web, PHP-FPM, base de datos) si están bloqueados, y averigua después por qué ocurrió.
- Contacta a tu proveedor de hosting con datos concretos: hora, URL, código de estado, texto del error.
Para enterarte antes que tus visitantes, configura un monitoreo de disponibilidad que revise el sitio cada pocos minutos desde fuera y te avise por correo o mensajería. Añade alertas separadas para el vencimiento del certificado y del dominio: son las caídas más evitables de todas.
