Evita que recibas 100 correos distintos después de un deploy de todo el sitio, y que un sitio muerto te interrumpa cada día durante meses.
Para quién es
- Equipos que necesitan gestionar su carga de notificaciones
- Responsables técnicos que necesitan saber cuándo se ejecutan los escaneos
Prerequisitos
- Al menos una URL activa
- Un correo de notificación verificado
Paso a paso
- Elige la frecuencia
manual solo se ejecuta cuando lo lanzas a mano o por la API. hourly, daily y weekly son programados. Cada URL se reparte en su propio minuto; no se escanea todo el sitio a la vez.
- Notificaciones agrupadas
Los cambios que ocurren cerca en el tiempo dentro del mismo proyecto se recogen en una sola notificación en la ventana por defecto de 10 minutos (configurable entre 2 y 60 minutos).
- Las notificaciones críticas no esperan
Un cambio en robots.txt, un cambio de meta o cabecera que bloquea la indexación y una pérdida de disponibilidad (estado HTTP) se envían de inmediato sin agrupar. Dos casos más de la misma clase: que una etiqueta de medición (GA4, GTM, Meta Pixel) desaparezca de la página y que un formulario se pierda — ambos paran el trabajo sin cambiar nada en pantalla.
- Los motores de respuesta de IA se vigilan aparte
Bloquear los rastreadores de entrenamiento en robots.txt (GPTBot, ClaudeBot, CCBot, Google-Extended) es una decisión legítima y no genera alarma. Bloquear los motores de respuesta (OAI-SearchBot, Claude-SearchBot, PerplexityBot) genera una notificación crítica: la página desaparece de las respuestas de IA. Una regla de «bloquear todos los bots de IA» de un plugin de seguridad hace exactamente eso.
- Certificado y caducidad del dominio
Para cada sitio vigilado se revisan el certificado TLS y la fecha de caducidad del dominio; se avisa con 30, 14, 7 y 1 días de antelación, y un certificado caducado se considera crítico. Un certificado que no se puede comprobar se reporta como «desconocido», no como «caduca mañana».
- Política de fallos consecutivos
El primer escaneo fallido no notifica. Dos fallos consecutivos sí notifican. Cinco fallos consecutivos pausan la URL automáticamente. Cuando el sitio se recupera llega una notificación de «vuelve a estar accesible» y la URL continúa sola.
- Canales
Correo y webhooks. Si Slack está conectado, cada cambio llega con la dirección de la página, la clase, la severidad, la diferencia de píxeles y el enlace de evidencia para enviar al cliente, y el botón «Revisado» o «Ignorar» del mensaje hace avanzar el baseline igual que en la bandeja de entrada. Cada petición que llega desde Slack se verifica por firma; si no hay secreto de firma configurado, ningún botón funciona.
Salidas operativas
- Correos de cambios agrupados por proyecto
- Notificación inmediata para cambios críticos
- Registros de URLs pausadas y vuelven a estar accesibles
- Días que faltan para la caducidad del certificado y del dominio
- Etiquetas de medición presentes en la página y las que han desaparecido
Disponibilidad por plan
- Free: sin webhooks, sin escaneos hourly, 10 disparos al día
- Pro: 2 webhooks, 5 URLs hourly, 150 disparos al día
- Agency: 10 webhooks, 3 URLs hourly, 100 disparos al día
Límites y guardrails
- La cuota diaria de disparos cuenta los escaneos manuales, de API y de baseline; los escaneos programados no la consumen
- Una notificación que no se puede entregar se abandona tras 5 intentos y no se reintenta indefinidamente
- No hay SMS ni push móvil
Resultado esperado
- El número de notificaciones se mantiene en un nivel que puedes leer
- Los incidentes críticos te llegan en minutos
- Un sitio muerto no te interrumpe todos los días
Rutas de troubleshooting
- Si no llega ninguna notificación, revisa la carpeta de spam y si la URL está pausada
- Si un escaneo no se ejecutó a la hora que esperabas, comprueba que la frecuencia no sea manual
- Si se cae un webhook, revisa que tu endpoint devuelva 2xx