Cómo monitorizar webs de clientes sin revisarlas a mano (aunque sean 40)

Respuesta corta: para monitorizar webs de clientes sin revisarlas a mano, aunque sean muchas, necesitas tres cosas: comprobaciones automáticas con la frecuencia adecuada para cada riesgo (caídas cada minuto, certificado cada pocas horas, SEO y cookies cada día), avisos separados entre urgentes y «para revisar cuando puedas», y confirmación antes de avisar para no ahogarte en falsas alarmas. Sin eso, te enteras de los problemas por el cliente.

Esta guía es parte de Checklist de entrega de una web al cliente: la checklist sirve el día de la entrega; esto es lo que pasa después.

Por qué revisar a mano no escala

Con cinco webs, entrar una vez a la semana en cada WordPress funciona. Con 40, no. Las cuentas son sencillas: aunque dediques solo diez minutos por web, son casi siete horas a la semana, y aun así solo ves lo que está roto el día que miras. Una caída de un sábado, un certificado que caduca un martes o un noindex que alguien activa un jueves se quedan sin ver hasta la siguiente ronda.

Además, la revisión manual mira lo evidente (¿carga la web?, ¿hay actualizaciones?) y se salta lo invisible: el DMARC, las cookies antes del consentimiento, el debug.log público, el sitemap que se ha vaciado.

Cómo saber si te pasa

Señales de que tu forma de monitorizar webs de clientes no está funcionando:

• Te enteras de las caídas porque te llama el cliente.
• Has tenido algún certificado caducado en el último año.
• Has descubierto un noindex o la casilla «Disuadir» semanas después de publicar.
• No sabes, sin entrar a mirar, cuántas de tus webs tienen plugins con vulnerabilidades conocidas.
• Recibes tantos correos de avisos automáticos que ya no los lees.

El último punto es tan malo como no tener avisos. Un sistema que avisa de todo acaba ignorado.

Qué vigilar y con qué frecuencia

No todo necesita la misma frecuencia. Esta es la tabla con la que trabajamos nosotros:

Cómo monitorizar webs de clientes paso a paso

1. Inventario. Haz una hoja con todas las webs: dominio, hosting, proveedor DNS, CMS, quién tiene acceso, si hay tienda, si el correo va por el mismo dominio. Sin inventario no hay vigilancia.
2. Disponibilidad. Un monitor de uptime externo para todas las webs. Hay opciones gratuitas y de código abierto (Uptime Kuma, por ejemplo, si lo alojas tú). Configura que confirme el fallo con varias comprobaciones seguidas antes de avisar.
3. Certificados y dominios. Que el monitor revise también la caducidad del certificado, y apunta en el inventario cuándo vence cada dominio y quién lo renueva.
4. Search Console de todas las webs. Da de alta todas las propiedades en una cuenta de la agencia (como usuario, con el cliente como propietario) y activa los avisos por correo. Avisan tarde, pero avisan de acciones manuales y problemas de indexación graves.
5. Gestión de WordPress centralizada. Herramientas como ManageWP o MainWP permiten ver actualizaciones pendientes y hacer copias de muchas webs desde un panel. Útiles para el mantenimiento, menos para detectar problemas de SEO, correo o cookies.
6. Correo, cookies y SEO técnico. Es lo que las herramientas anteriores no cubren. O lo revisas cada mes con una lista (y aceptas que entre revisión y revisión pueden pasar cosas), o lo automatizas con una herramienta que lo haga.
7. Separa los canales. Lo urgente (caída, certificado inválido, hackeo, administrador nuevo, noindex en la portada) a un canal que mires siempre: móvil, Slack, Telegram. Lo demás, a un resumen diario o semanal.
8. Define quién responde. Un aviso sin responsable es ruido. Decide quién mira los avisos urgentes, en qué horario y qué hace con cada tipo.

Cómo no ahogarte en avisos

La fatiga de alertas es el motivo número uno por el que estos sistemas acaban abandonados. Reglas que funcionan:

• Confirmar antes de avisar. Un fallo puntual de red no es una caída. Exige varias comprobaciones fallidas seguidas.
• Avisar por cambios, no por estados. Si una web lleva meses con el título corto, no hace falta recordarlo cada día. Avisa cuando algo cambia o empeora.
• Una alerta por problema, no por comprobación. Si una web cae, no quieres 60 correos, uno por minuto. Quieres uno cuando cae y otro cuando vuelve.
• No acusar cuando no hay certeza. Si el cortafuegos del cliente bloquea al monitor, eso no es una caída. Es mejor marcarlo como «no concluyente» que mandar una falsa alarma.
• Agrupar por web. Cinco problemas menores de la misma web, en un solo aviso.
• Poder aplazar lo que no es urgente. Un DMARC en p=none es un riesgo real, pero se puede tratar la semana que viene.

Errores habituales

• Vigilar solo la portada. La portada carga, pero el formulario de contacto lleva una semana sin enviar porque una actualización lo rompió.
• Confiar en que el hosting avisa. El hosting avisa de su servidor, no de tu web. Un WordPress con error crítico puede devolver una página «correcta» para el hosting.
• Monitores desde la misma red que el servidor. Si el monitor y la web están en el mismo proveedor, una caída de red se lleva los dos y no avisa nadie.
• Mandar los avisos al correo de alguien que se va de vacaciones. Mejor a un canal compartido.
• No revisar los avisos aplazados. Lo que se aplaza para «la semana que viene» se acumula. Repásalo en el informe mensual (lo vemos en Qué incluir en el informe mensual de mantenimiento web).

Para agencias: Jeffrey hace esta vigilancia por ti

Hicimos Jeffrey justo para esto: vigilar las webs de los clientes de una agencia con las frecuencias de la tabla de arriba, sin montar seis herramientas distintas.

• Disponibilidad: comprobación cada uno o dos minutos; la caída se confirma con tres fallos seguidos antes de avisar y se cierra sola en cuanto vuelve.
• Certificado: cada seis horas. Aviso si caduca en 14 días o menos; crítico si no es válido o quedan tres días.
• DNS: cada hora; avisa si cambian los servidores DNS o el MX, o si desaparecen el registro A o el SPF.
• Cada día: indexación de la portada, spam inyectado y enlaces ocultos, cambios de título, H1, canonical y sitemap, cookies y rastreadores antes del consentimiento (con un navegador real que no pulsa el banner), debug.log público y una prueba con navegador en móvil y escritorio que detecta errores críticos de WordPress, páginas en blanco y formularios o botones de compra que desaparecen.
• Correo del dominio: SPF, DKIM, DMARC y listas negras de spam, varias veces al día.
• Con el plugin de Jeffrey instalado: aviso inmediato de administradores nuevos, plugins con vulnerabilidades conocidas, la casilla «Disuadir», copias gestionadas y una prueba de funcionamiento tras cada actualización.

Los avisos se separan en urgentes y «para revisar cuando puedas», se agrupan por web y lo no urgente se puede aplazar. Lo que no se puede comprobar con seguridad (un cortafuegos que bloquea, un reto antibots) no se da como fallo.

Cada aviso llega a la vez a la agencia y a NexaTech, y nuestra primera respuesta llega en menos de 4 horas. Puede funcionar con la marca de la agencia, en marca blanca, para que el cliente vea a su agencia y no a nosotros.

Preguntas frecuentes