La monitorización web automática consiste en que un flujo compruebe tu web cada pocos minutos (que responde, que no da errores, que los formularios envían, que el certificado no caduca, que la velocidad no se ha hundido) y avise al canal del equipo solo cuando algo cambia. Se monta en n8n en una tarde y cuesta menos que un cliente diciéndote «tu web no va».
Es para quien se entera de que la web está caída porque llama un cliente, o de que el formulario lleva una semana sin enviar porque «qué raro que no entren leads». Vas a encontrar qué vigilar, con qué, a dónde avisar, qué reglas evitan que las alertas se conviertan en ruido, qué hacer cuando salta una y cuánto cuesta.
Es uno de los flujos que incluimos siempre en las automatizaciones de marketing y agentes de IA, porque todo lo demás (lead al CRM, respuesta en segundos, informe mensual) depende de que la web esté viva y el formulario funcione. Un flujo que lleva leads al CRM no sirve de nada si el formulario dejó de enviar el martes.
¿Qué hay que vigilar en una web para enterarse antes que el cliente?
Ocho cosas, de más a menos urgente: que la web responde; que no devuelve errores 5xx; que los formularios envían de verdad; que el certificado no caduca; que no aparecen 404 nuevos; que el sitemap responde con código 200; que Google sigue indexando; y que las Core Web Vitals no se han degradado. Las cuatro primeras se vigilan cada cinco minutos; las otras, una vez al día o a la semana.
| Qué | Cómo se comprueba | Cada cuánto | Avisa si |
|---|---|---|---|
| Caída | HTTP Request a la home y a dos páginas más | 5 min | 3 fallos seguidos (15 min) |
| Errores 5xx | Código de respuesta de esas peticiones | 5 min | Cualquier 5xx repetido |
| Formulario | Envío de prueba con un marcador | 1 h | El envío no llega al destino en 2 min |
| Certificado | Fecha de caducidad del TLS | 1 día | Quedan menos de 14 días |
| 404 nuevos | URLs del sitemap y vistas de la página 404 en GA4 | 1 día | URL del sitemap que no da 200; 404 con visitas |
| Sitemap | Código HTTP y XML válido | 1 día | Distinto de 200 o XML roto |
| Indexación | Informe de páginas de Search Console | 1 semana | Caen las indexadas o suben los errores |
| Core Web Vitals | API de PageSpeed Insights | 1 día | LCP, INP o CLS dejan de ser «buenos» |
El del sitemap parece menor y no lo es. En la auditoría de nuestra propia web, el 4 de noviembre de 2026, el sitemap servía el XML correcto pero con cabecera HTTP 404: el servidor trataba las rutas .xml como error. Para una persona, el sitemap estaba bien; para Google, no existía. Ninguna herramienta de «la web está caída» lo habría visto, porque la web respondía. Lo vio una comprobación del código de respuesta.
Los umbrales de velocidad son los de Google: las Core Web Vitals se consideran buenas cuando LCP está por debajo de 2,5 s, INP por debajo de 200 ms y CLS por debajo de 0,1, medidas en el percentil 75 de las visitas reales. Vigilarlas a diario no es para optimizar; es para enterarte de que un plugin nuevo o un vídeo en la home han hundido el LCP antes de que lo haga el informe mensual.
¿Con qué se monta: n8n, PageSpeed Insights y Search Console?
Con un flujo de n8n por frecuencia: uno cada cinco minutos para caída, errores y formulario; otro diario para certificado, 404, sitemap y Core Web Vitals; otro semanal para indexación. El nodo central es HTTP Request, que pide una URL y devuelve código y tiempo; la API de PageSpeed Insights da las métricas de velocidad; la de Search Console, la indexación.
El flujo de cinco minutos, nodo a nodo:
- Schedule Trigger cada 5 minutos.
- HTTP Request a tres URLs (home, una página de servicio, la de contacto), con tiempo de espera de 10 segundos y la opción Never Error activada, para que un 500 llegue como dato y no como ejecución fallida.
- IF: código distinto de 200 o tiempo de respuesta superior a 5 segundos.
- Un contador de estado. Una fila por URL en una Data Table de n8n o en Google Sheets con el último estado y cuántos fallos seguidos lleva. Sin esto no hay forma de aplicar la regla de «tres fallos seguidos» ni de avisar de la recuperación.
- Slack o Telegram solo cuando el estado cambia: de bien a mal al tercer fallo, de mal a bien al primer acierto.
El del formulario es el que menos gente monta y el que más leads salva. Un envío real cada hora, con un correo del tipo monitor+fecha@tudominio y un campo oculto que lo marca como prueba; el flujo que recibe formularios lo reconoce y no lo pasa al CRM ni manda la respuesta automática. Si en dos minutos no ha llegado al Webhook, alerta. Prueba el camino completo (plugin, servidor de correo, Webhook), que es donde fallan las cosas, no solo que la página cargue.
Para los 404, dos fuentes. La primera, el propio sitemap: el flujo diario lo descarga, pide cada URL con una petición HEAD y anota las que no dan 200; una URL que ayer daba 200 y hoy 404 es una página borrada o un slug cambiado sin redirección. La segunda, las visitas: GA4 registra las vistas de la página de error con su título. Si tienes activada la exportación de GA4 en BigQuery, una consulta diaria sobre los page_view cuyo título es el de la página 404 te dice qué URLs rotas está pisando gente de verdad y desde dónde llegan. Esas se redirigen primero.
Para la velocidad, una llamada diaria a la API de PageSpeed Insights por cada URL vigilada. Devuelve datos de laboratorio (Lighthouse) y, si hay suficientes visitas, los datos de campo del informe de experiencia de usuario de Chrome, que son los que cuentan para Google. El flujo guarda LCP, INP y CLS en una tabla y avisa solo si alguna pasa de «bueno» a «necesita mejorar». Cómo arreglar lo que salte está en Core Web Vitals en WordPress.
Para la indexación, la API de Search Console: páginas indexadas y con error, una vez a la semana, comparadas con la semana anterior. Una caída de indexadas tras un despliegue casi siempre es un noindex que se quedó puesto o un robots.txt copiado del entorno de pruebas.
Si la web es una tienda Shopify, se añade una comprobación de negocio: que los webhooks de Shopify (en inglés) siguen llegando. Un flujo que no ha recibido orders/create en seis horas, dentro del horario en que la tienda vende todos los días, es una alerta aunque la web cargue perfectamente: el checkout o la pasarela pueden estar rotos sin que la home se entere.
¿A dónde se avisa y con qué reglas para que no se convierta en ruido?
A un canal que el equipo ya mira: Slack o Telegram para lo urgente, correo para el resumen diario. Y con cinco reglas: avisar solo cuando el estado cambia, exigir repetición antes de avisar, respetar un horario para lo que no es urgente, agrupar lo que llega junto y escalar si nadie reacciona. Sin estas reglas, a la tercera semana nadie abre el canal de alertas.
- Umbrales y repetición. Un fallo aislado a las 3:12 no es una caída: es un reinicio del servidor o un pico. Tres fallos seguidos con cadencia de cinco minutos, es decir, quince minutos caído, sí. Para tiempo de respuesta, media de tres comprobaciones, no un valor.
- Avisar del cambio, no del estado. Un mensaje cuando cae, otro cuando vuelve, con la duración («caída de 23 minutos, 14:02 a 14:25»). Nunca un mensaje cada cinco minutos mientras dure.
- Horario. Caída total y formulario roto avisan a cualquier hora. Core Web Vitals, 404, certificado e indexación esperan al resumen de las 8:30. Nadie necesita saber a las 2:00 que el CLS ha subido.
- Agrupar. Si 40 URLs dan 404 a la vez, un mensaje con las 40, no 40 mensajes. En n8n, un nodo Aggregate antes del envío.
- Escalado. Si una caída pasa de 30 minutos sin que nadie reaccione en Slack, Telegram a la persona de guardia; si pasa de una hora, llamada o SMS. Es el único caso en que usamos SMS.
El formato del mensaje también cuenta: qué ha pasado, desde cuándo, qué URL, qué código, y un enlace al panel del servidor o al informe. Sin «ALERTA» en mayúsculas ni emojis: el canal de alertas tiene que poder leerse en diagonal.
¿Qué se hace cuando salta una alerta?
Lo que diga el protocolo escrito para esa alerta, que existe antes de encender el flujo. Caída: comprobar el hosting y el último cambio, y restaurar si hace falta. Formulario roto: reactivar el plugin o el Webhook y revisar los envíos perdidos. 404 nuevos: redirección 301; certificado: renovar; Core Web Vitals: identificar el cambio del día anterior. Una alerta sin protocolo es una alerta que se ignora.
El protocolo cabe en una tabla con tres columnas: alerta, quién la atiende, primeros tres pasos. Para una pyme con la web en un hosting gestionado, el primer paso de casi todas es el mismo: mirar qué se cambió en las últimas 24 horas (plugin actualizado, tema, DNS, un redactor que borró una página). La causa casi siempre es un cambio reciente, no un ataque.
Lo segundo es dejar rastro. Cada alerta, con la hora en que saltó, la hora en que alguien la vio, la hora en que se resolvió y la causa, en la misma tabla donde el flujo anota el estado. Esa tabla alimenta el informe mensual que se escribe solo con una línea que casi nadie incluye: disponibilidad del mes, incidencias y tiempo medio hasta resolver.
Y lo tercero: hay alertas que no deben arreglarse solas. Es tentador que el flujo reinicie el servidor o desactive el plugin sospechoso. No lo hacemos: una acción automática sobre un sistema en producción sin que una persona lo mire es exactamente el tipo de cosa que entra en qué no automatizar. El flujo avisa y propone; la persona decide.
¿Cuánto cuesta y qué se mide para saber si sirve?
Montarlo cuesta desde 450 € si lo hacemos nosotros, como un flujo más, documentado y con 60 días de soporte; en el pack de tres flujos va incluido como panel de errores y alertas. Las herramientas no suman cuota: n8n en tu servidor no cuesta nada, o entre 20 y 60 € al mes en la nube, y las APIs de PageSpeed Insights y Search Console son gratuitas con una clave de Google.
Hay servicios que vigilan la caída gratis o por poco dinero (UptimeRobot, Better Stack, el propio hosting). Sirven: si solo quieres saber si la web responde, usa uno y no montes nada. Lo que no hacen es lo demás: el formulario de punta a punta, el sitemap con cabecera 404, los 404 que pisa la gente, el webhook de Shopify que no llega y el aviso en tu canal con tus reglas. Eso es lo que se monta en n8n.
Lo que se mide es una sola cosa: cuánto tiempo pasa desde que algo se rompe hasta que alguien del equipo lo sabe. Antes del flujo, apunta las últimas tres incidencias: cuándo empezaron (los registros del servidor lo dicen) y cuándo os enterasteis. Sin vigilancia, lo normal son horas o días, porque el aviso llega por un cliente o por el informe mensual. Con el flujo, el objetivo es menos de 15 minutos para caídas y formulario, y menos de 24 horas para el resto.
La segunda cifra es el número de falsas alarmas por semana. Si pasa de dos, los umbrales están mal y hay que subirlos, porque el canal dejará de leerse. La tercera, cuántas alertas se resolvieron sin que el cliente llegara a notar nada: es la que da nombre al artículo.
Las piezas de este flujo (Schedule Trigger, HTTP Request, tablas de estado, avisos a Slack) son las mismas que usamos en el resto de la guía completa de n8n para marketing; si ya tienes n8n montado para el CRM, este se añade en una tarde.
Hay más sobre esto en la sección de automatización y agentes del blog.
Preguntas frecuentes
¿No basta con el aviso de caída del hosting?
Para la caída, sí. Pero el hosting no sabe si tu formulario envía, si el sitemap devuelve 404 o si el LCP se ha disparado, y te avisa por correo a la cuenta del administrador, que nadie mira. El flujo cubre lo que el hosting no ve y avisa donde el equipo está.
¿Cada cinco minutos no es demasiado para mi servidor?
Tres URLs cada cinco minutos son 864 peticiones al día, menos que una visita normal de un rastreador. Si el hosting mide el consumo por peticiones, el flujo puede pedir solo las cabeceras (HEAD) en vez de la página entera.
¿Qué pasa si se cae el propio n8n?
Si n8n va en el mismo servidor que la web y el servidor cae, el vigilante cae con él. Por eso n8n va en una máquina distinta o en n8n Cloud y, además, un servicio externo gratuito vigila a n8n con un latido: el flujo le avisa cada cinco minutos de que sigue vivo, y si deja de hacerlo, salta la alerta.
¿Vale igual para WordPress y para Shopify?
Las comprobaciones de caída, certificado, 404, sitemap, indexación y Core Web Vitals son iguales. En WordPress se añade la del formulario (los plugins fallan tras actualizaciones); en Shopify, la de los webhooks de pedidos y la del checkout, que es la página que de verdad no puede caerse.
—
Diego lleva las automatizaciones de We Love SEO: conecta formularios, CRM, tiendas e informes con n8n, y documenta lo que falla. Más sobre él en el equipo.
