Construí Gitae porque me encontraba una y otra vez con la misma pregunta práctica: ¿el sitio web está realmente caído o el problema está solo de mi lado?
Una sola pestaña del navegador es una herramienta de diagnóstico bastante pobre. La página puede no cargar porque el servidor de origen esté caído, pero también por DNS, un problema con el certificado HTTPS, routing, una regla de firewall, un puerto cerrado o filtrado, el ISP, una ruta VPN, el estado del navegador o una caché local. El síntoma visible es el mismo. La acción correcta no.
Eso es lo que quería resolver con Gitae: no limitarme a mostrar un indicador verde o rojo, sino ayudarme a reducir el problema a la capa que merece investigarse a continuación.
El problema real detrás de «el sitio está caído»
Muchos comprobadores sencillos responden una pregunta muy concreta: ¿esta URL respondió desde un lugar determinado en un momento determinado? Eso es útil, pero todavía no es diagnosticar una caída.
Si DNS está mal, reiniciar la aplicación no ayudará. Si HTTPS falla por el certificado, cambiar el contenido de la página no sirve. Si un puerto TCP no es accesible, el servidor puede seguir funcionando. Y si la web abre desde un servidor externo pero no desde mi propia conexión, el problema puede estar en algún punto del camino entre mi red y el destino, no necesariamente en el servidor de la aplicación.
Por eso planteé Gitae con un modelo más útil: un sitio web es una cadena de dependencias y cada comprobación aporta evidencia sobre una parte de esa cadena.
Una vista externa, no un oráculo
Las comprobaciones de Gitae se ejecutan desde mis propios servidores VDS en Moscú y Helsinki. Eso me da puntos de observación fuera del ordenador y de la red donde detecté el problema.
Si la web falla localmente pero responde desde ambos VDS, es una señal útil de que el origen no es inaccesible para todo el mundo. Entonces tiene más sentido revisar DNS local, la ruta del ISP, VPN, navegador, firewall u otro problema dependiente del camino de red. Si también falla desde las sondas remotas, aumenta la razón para investigar servidor, DNS, certificado, routing o una incidencia de red más amplia.
Pero una comprobación remota no es automáticamente «más fiable» que una local. Dos ubicaciones no representan todo Internet. Una web puede funcionar desde Moscú y Helsinki y fallar desde otro país, proveedor, edge de CDN o red. Para mí, el resultado remoto es otro punto de observación, no un veredicto global.
Qué comprueba Gitae hoy
- Website check — comprueba si una URL responde desde un servidor externo.
- SSL check — revisa el estado del certificado HTTPS/TLS y problemas relacionados.
- DNS check, nslookup y dig — ayudan a ver cómo resuelve un dominio y qué registros DNS devuelve.
- Reverse DNS e IP check — muestran información de IP y datos PTR/reverse-DNS.
- Domain info y domain age — ofrecen metadatos básicos del dominio.
- Port check — prueba si un puerto es accesible desde la ubicación de la sonda.
- Find your IP — muestra la IP pública que ve el servicio.
- Ping y traceroute — aportan señales de red sobre latencia, pérdida de paquetes y ruta.
- Hosting check y CMS detection — muestran señales de infraestructura y tecnología que pueden ayudar a identificar el entorno.
Intento tratar todos esos resultados como señales. Un registro PTR no demuestra quién posee un servidor. Detectar un CMS por fingerprints públicos no demuestra el stack exacto. Y un puerto inaccesible desde una sonda puede estar filtrado en algún punto en vez de estar cerrado para todo el mundo.
Cómo interpreto los resultados
El valor aparece al combinar varias comprobaciones, no al leer cada una de forma aislada.
Si DNS devuelve la dirección esperada, el certificado HTTPS es válido y la web responde desde los dos VDS, pero yo sigo sin poder abrirla localmente, investigaría mucho más el camino local antes de tocar el servidor. Si DNS es inconsistente o la prueba remota también falla, hay más motivos para mirar la infraestructura.
Ping y traceroute también requieren prudencia. ICMP puede filtrarse o limitarse. Un hop que no aparece en traceroute no significa automáticamente que ese nodo esté roto, y un host que no responde a ping puede servir HTTPS con normalidad. Son útiles porque añaden contexto, no porque produzcan un diagnóstico definitivo.
Mi regla principal aquí es: una comprobación correcta no demuestra que todo el sistema esté sano y una comprobación fallida no explica por sí sola la causa.
Disponibilidad y SEO no son lo mismo
La disponibilidad también importa para SEO, pero conviene separar conceptos. Una caída técnica no es lo mismo que un problema de ranking. Crawling no es indexing, e indexing no es traffic.
Si un crawler no puede alcanzar el sitio por errores de DNS, red o servidor, no puede obtener correctamente ese contenido en ese momento. Google documenta que los errores de red y DNS durante el crawling se tratan de forma similar a errores de servidor 5xx, y que una indisponibilidad prolongada puede afectar al rastreo y a URLs ya indexadas. Eso no significa que cada caída breve cause automáticamente una pérdida SEO, ni que una herramienta de diagnóstico pueda demostrar que un cambio posterior de tráfico fue causado por esa caída.
Para los usuarios la lógica es más simple: si no pueden acceder, no pueden usar el sitio. Según el proyecto, eso puede significar sesiones, leads, conversiones o ingresos perdidos. El diagnóstico técnico, sin embargo, no calcula ese impacto de negocio.
Un orden práctico para investigar un sitio «caído»
- Confirmar el síntoma desde otra red. No asumir que el navegador local representa a todo Internet.
- Comprobar DNS. Verificar resolución y registros esperados.
- Comprobar HTTPS/TLS. Revisar certificado y errores de conexión.
- Comprobar el puerto necesario. Probar su alcance desde la sonda.
- Comparar señales de red. Usar ping y traceroute como apoyo, no como oráculo.
- Revisar IP, reverse DNS, hosting y CMS. Pueden ayudar a confirmar que se está llegando a la infraestructura esperada.
- Solo entonces reducir el área de investigación. Decidir si la evidencia apunta más a aplicación, servidor, DNS, ruta de red o entorno local.
No es un protocolo universal de incident response. Es una forma de evitar el error que quería eliminar: cambiar la capa equivocada solo porque la única información inicial era «el sitio no abre».
Primero utilidad real, luego monetización
Gitae no está monetizado por ahora. Lo construí primero para mí porque quería comprobar una web desde fuera de mi propio equipo y pasar directamente a DNS, certificado, puertos y red sin saltar entre herramientas desconectadas.
Mi objetivo actual es mejorar la utilidad del diagnóstico y ver si el proyecto puede conseguir tráfico orgánico mediante SEO y demanda real. Si alcanza incluso un tráfico moderado, quiero añadir monitorización automática con alertas instantáneas por mensajería. Sería extender la misma idea desde el diagnóstico manual a la detección: saber que algo dejó de estar disponible y dar al propietario suficiente información para empezar a investigar rápido.
La idea central sigue siendo simple
«Online» y «offline» son síntomas, no explicaciones.
DNS, HTTPS/TLS, routing, puertos, hosting, la aplicación y la propia red del usuario pueden producir un problema de disponibilidad aparentemente simple. Gitae no identifica mágicamente todas las root causes y esas ubicaciones VDS externas no muestran lo que ve todo Internet. Lo que sí puede hacer es reunir varias señales independientes en un mismo lugar.
Eso es lo que quería para mí: una herramienta que me lleve de «el sitio no abre» a una pregunta mucho más útil: «¿qué capa debería investigar ahora?»