Respuesta corta: Un monitor de caídas web te dice si la web contesta, no si funciona. Un certificado mal renovado, un DMARC ausente, el dominio en una lista negra, un administrador nuevo, spam que solo ve Google, un noindex olvidado, cookies antes del consentimiento o un pago roto que responde 200 pasan desapercibidos. Para eso hay que vigilar algo más que el código de respuesta.
Primero, lo justo: un monitor de uptime como UptimeRobot hace muy bien su trabajo y casi siempre es lo primero que hay que tener. Esta guía no va contra ellos. Va de lo que queda fuera de su trabajo, porque es justo lo que más llamadas genera en una agencia.
Qué ve un monitor de caídas web (y qué no)
Un monitor de caídas web pide una URL cada pocos minutos y mira la respuesta. Si el servidor contesta con un código correcto, todo bien; si no contesta o da error 5xx, avisa. Muchos permiten además buscar una palabra en la página, y los planes de pago suelen vigilar la caducidad del certificado y del dominio.
Eso cubre el caso más visible: la web está caída. Pero muchos problemas graves no tumban la web. El servidor sigue contestando 200 y el monitor sigue en verde mientras:
- el cliente no recibe correos porque su dominio está en una lista negra;
- Google enseña spam de casinos en los resultados, pero la portada se ve bien;
- la web lleva semanas con «noindex» y va desapareciendo de Google;
- el carrito de WooCommerce da error al pagar.
Cómo saber si te pasa
Repasa los últimos incidentes de tus clientes y pregúntate quién los detectó. Si en la mayoría fue el cliente (o un cliente del cliente), tu vigilancia se queda corta. Señales típicas:
- «Mis correos llegan a spam» o «no me llegan presupuestos».
- «En Google salen cosas raras con mi nombre».
- «Hace un mes que no entra ningún pedido por la web».
- «Chrome dice que mi web es peligrosa».
- «Me han llegado avisos de la AEPD o quejas por las cookies».
Ninguno de estos lo detecta un monitor de disponibilidad, porque la web responde.
Lo que un monitor de uptime no ve: 8 casos
1. SSL mal renovado
El certificado se renueva, pero falta el intermedio, se ha instalado el de otro dominio o se ha quedado el viejo en un servidor del balanceador. Algunos navegadores lo aceptan y otros muestran el aviso de conexión no segura. Hay que comprobar la cadena completa, que el certificado sea para ese nombre y los días que le quedan, no solo que el puerto 443 conteste.
2. Correo sin DMARC o con SPF roto
Cualquiera puede mandar correos en nombre del dominio, o los correos legítimos acaban en spam. La web no se entera. Mira el registro TXT en _dmarc del dominio y el SPF. Lo explicamos en configurar DMARC paso a paso y en SPF mal configurado.
3. Dominio o IP en una lista negra
Si la IP del servidor de correo o el dominio entra en Spamhaus u otra lista, los correos rebotan o desaparecen. Hay que consultar las listas con regularidad. Si ya te ha pasado: cómo salir de una lista negra.
4. Administrador nuevo en WordPress
Un usuario administrador que nadie ha creado es uno de los indicios más claros de que alguien ha entrado. La web sigue igual por fuera. Solo se ve desde dentro de WordPress, comparando la lista de usuarios o recibiendo un aviso cuando se crea o asciende un administrador.
5. Spam que solo ve Google
Hay hackeos que enseñan una página normal a las visitas y otra llena de enlaces a casinos o farmacias a Googlebot. El monitor ve la página normal. Hay que pedir la página como la pediría Google y comparar. La limpieza la contamos en spam de casinos y farmacia en WordPress.
6. Noindex olvidado
Tras una migración o un rediseño, alguien deja marcada en WordPress la casilla «Disuadir a los motores de búsqueda» o un meta robots noindex. La web funciona, pero Google la va quitando del índice. Google explica cómo funciona en su documentación sobre noindex, y nosotros cómo arreglarlo en WordPress no indexa.
7. Cookies antes del consentimiento
Un cambio en el gestor de etiquetas o en el plugin de cookies hace que Google Analytics o el píxel de Meta se carguen antes de que la visita acepte. No hay error ni caída: hay un problema legal. Hay que abrir la web con un navegador real, sin aceptar, y ver qué cookies y peticiones salen.
8. Checkout o formulario roto que responde 200
El caso más caro. La página del carrito responde 200, pero el botón de comprar ha desaparecido tras una actualización, o el formulario de contacto ya no está. Un monitor con palabra clave lo detecta a veces; una prueba con navegador real que recorra la página lo detecta casi siempre.
Cómo cubrir lo que el monitor no ve
- Mantén el monitor de caídas web. Es la primera línea y no hay que quitarlo.
- Vigila el certificado de verdad: validez, cadena, nombre y días restantes, al menos varias veces al día.
- Revisa DNS y correo: NS, MX, SPF y DMARC, y avisa si cambian sin que nadie lo haya pedido.
- Consulta listas negras para el dominio y las IP de correo.
- Comprueba la indexación cada día: meta robots, cabecera X-Robots-Tag y robots.txt.
- Pide la portada como Google y busca spam o enlaces ocultos.
- Abre la web con un navegador real para cookies y para recorrer formularios y compra.
- Si es WordPress, mira desde dentro: usuarios administradores, plugins vulnerables y cambios de plugins.
- Decide quién recibe cada aviso y qué pasa si no responde.
Hacerlo a mano con 50 webs no es realista. Por eso conviene una herramienta que lo junte; tienes una comparativa en herramientas para gestionar webs de clientes. Y si estás montando el servicio desde cero, empieza por nuestra guía de mantenimiento WordPress en marca blanca, donde explicamos qué incluir y cómo contarlo al cliente.
Una regla práctica para priorizar: empieza por lo que hace perder dinero o clientes en horas (caída, certificado, pago roto, lista negra) y deja para la revisión diaria lo que hace daño en semanas (indexación, cookies, cambios de aspecto). Así los avisos urgentes siguen siendo pocos y nadie los ignora.
Errores habituales
- Fiarse del verde. «El monitor está en verde» significa que el servidor contesta, no que el negocio funcione.
- Monitorizar solo la portada. El carrito, el formulario y la página de pago son las que dan dinero.
- Avisos de todo, siempre. Si cada aviso suena igual, se acaban ignorando. Separa lo urgente de lo que puede esperar al día siguiente.
- No mirar el dominio del correo. Es el problema que más tarda en detectarse y el que más enfada al cliente.
Para agencias: lo que Jeffrey vigila además de la caída
Jeffrey no sustituye a tu monitor de caídas web: hace ronda cada 5 minutos y además vigila todo lo anterior en cualquier hosting, sin pedir accesos (pegas los dominios):
- Caídas y certificado: te avisa si la web no responde o da error de forma sostenida, y si el SSL no es válido (caducado, autofirmado, de otro dominio o sin intermedio) o caduca en 14 días o menos.
- Dominio y DNS: caducidad del dominio y cambios importantes de servidores DNS, MX o registros que desaparecen.
- Correo: SPF, DKIM y DMARC, y listas negras del dominio y de las IP de correo.
- Google: web marcada como peligrosa, spam que solo ve Google, web sin indexar y portada cambiada de golpe.
- Cookies: abre la web con un navegador real, sin aceptar, y avisa si se cargan cookies de analítica o publicidad antes del consentimiento.
- Tienda vigilada: pruebas con navegador real de portada, formularios y recorrido de compra en WooCommerce; avisa si aparece un error crítico o desaparece el botón de comprar.
- Con el plugin de Jeffrey instalado: aviso al instante si aparece un administrador nuevo, vulnerabilidades cruzadas cada día y «Disuadir a los motores de búsqueda» activado.
Los avisos urgentes llegan por Telegram y correo con un botón «Lo miro yo»; si nadie lo coge en 10 minutos, escalan. Lo que puede esperar va al parte de las 8:00. Si es urgente y no sabes por dónde empezar, escríbenos y lo miramos.
Prueba Jeffrey 15 días sin tarjeta
Preguntas frecuentes
¿Basta UptimeRobot para una web de cliente?
Para saber si la web responde, sí. Para saber si el correo llega, si Google la indexa, si las cookies cumplen o si el pago funciona, no. No es un fallo de la herramienta: no es lo que mide.
¿Cada cuánto debería comprobar una web?
La disponibilidad, cada pocos minutos. El certificado, varias veces al día. DNS, correo, indexación y cookies cambian menos: una vez al día, o cada pocas horas, suele bastar.
¿Un monitor con palabra clave detecta un checkout roto?
A veces. Si la palabra desaparece, sí. Pero si la página carga y el fallo está al pulsar el botón, solo lo ve una prueba con navegador real.
¿Qué hago si el monitor dice que todo va bien pero el cliente dice que no?
Créete al cliente y comprueba desde fuera de tu red: certificado, DNS, correo y la página concreta que falla. Tienes el protocolo en qué hacer si la web de un cliente se cae.