¿Debo decirles a mis clientes que monitorizo sus sitios?

Sí. Es un servicio del que se benefician, y te da un motivo para pedir que te avisen de las publicaciones con antelación. La mayoría de los clientes reaccionan bien a un «detectamos este cambio el martes» cuando llega antes de que ellos mismos hayan visto un problema.

¿Y si el desarrollador del cliente bloquea las herramientas de monitorización?

Los firewalls y las protecciones contra bots, como las de Cloudflare, pueden bloquear las comprobaciones automáticas, y eso aparece como peticiones fallidas o bloqueadas. Pide al desarrollador que permita el user agent o las IPs de la herramienta. Si se niega, para ese sitio vuelves a las revisiones manuales y a Search Console.

¿Cómo monitorizo un sitio de staging antes de publicarlo?

El staging suele estar protegido con contraseña y en noindex a propósito, así que monitorizar cambios ahí genera falsas alarmas. Es más útil monitorizar producción y lanzar un escaneo SEO manual justo después del lanzamiento, que es cuando más probable es que se haya colado un ajuste de staging.

¿Cuántas alertas debo esperar por cada sitio de cliente?

En un sitio estable, muy pocas. Los e-commerce y los medios con mucha actividad generan más, sobre todo ediciones de title y meta description y URLs nuevas en el sitemap. Si un sitio inunda el canal, mira si hay una plantilla que cambia en cada despliegue, porque eso suele apuntar a un problema real.

← Volver al blog

Cómo monitorizar los cambios en el sitio web de un cliente

Para monitorizar los sitios web de clientes en busca de cambios necesitas una comprobación que se ejecute en todos ellos sin que tengas que acordarte, que compare cada resultado con el anterior y que te envíe una alerta de cambios en una web solo cuando se haya movido algo que afecte a la búsqueda o al tracking. Cuando llevas el SEO o el marketing de clientes, respondes por sitios que no controlas, y sus desarrolladores publican cambios sin contar contigo.

En el trabajo de agencia la historia es conocida. Un desarrollador interno del cliente publica una versión un jueves. El sitio sigue cargando, así que nada parece ir mal. Tres semanas después cae el tráfico orgánico, el cliente pregunta por qué y da por hecho que tú ya lo sabías.

Decide qué cambios merecen un aviso

Si vigilas cada píxel de cada página, recibes tantas alertas que la gente deja de leerlas. El conjunto útil es más pequeño y se divide en dos grupos: lo que decide si las páginas pueden posicionar y lo que decide cuánto rinden.

El primer grupo es la indexación. Una etiqueta <meta name="robots" content="noindex"> o una cabecera X-Robots-Tag: noindex, una línea Disallow nueva en robots.txt o un canonical que apunta a otra URL pueden sacar páginas de Google. El sitemap XML también entra aquí, porque una actualización de plugin o una migración que elimina URLs de él es una de las formas más habituales de que las páginas salgan del índice.

El segundo grupo es on-page y técnico. Los títulos, las meta descriptions y los H1 se reescriben con actualizaciones del CMS y cambios en el plugin SEO más a menudo de lo que esperarías. Importa el tiempo de actividad, y también la caducidad del certificado SSL y del dominio, porque cualquiera de las dos puede dejar un sitio sin servicio de un día para otro. Completan la lista los tags de marketing (GA4, Google Tag Manager, el Meta Pixel) y el banner de consentimiento de cookies, porque un tag que falta rompe los informes del cliente sin producir un solo error.

Los cambios visuales en textos, imágenes o maquetación quedan casi todos fuera de esta lista. Monitorizar cambios de contenido tiene su utilidad en otros contextos, pero los clientes editan esas cosas legítimamente cada semana.

Cómo monitorear cambios en una página web: los métodos comparados

Método	Qué detecta	Qué se le escapa	¿Escala a una cartera?
Revisiones manuales (código fuente, un crawler, Search Console)	Cualquier cosa, si miras la página correcta el día correcto	Los cambios que no se te ocurrió revisar	No, más allá de unos pocos sitios
Herramientas de diferencias visuales como Visualping	Cambios visibles en las URLs concretas que añades	Etiquetas del head, cabeceras, robots.txt; páginas que no añadiste	Mal, funciona por URL
Monitores de uptime como UptimeRobot	La caída del sitio, a menudo el SSL	Todo lo que se rompe mientras el sitio sigue activo	Sí, pero para un solo problema
Monitorización de cambios SEO	Cambios de indexación, metadatos, sitemap y tags en todo el sitio	Cambios en tiempo real si se ejecuta a diario; posiciones	Sí

Los monitores visuales son realmente buenos para vigilar la página de precios de un competidor. Te dicen que han cambiado los píxeles, no que un canonical apunta ahora a staging. Hay más sobre ese equilibrio en nuestra comparativa alternativa a Visualping. Las herramientas de uptime son imprescindibles, pero la mayor parte del daño SEO ocurre en sitios que responden con un 200, que es el hueco que trata el artículo alternativa a UptimeRobot.

Cómo monitorizar los sitios web de clientes cuando son treinta

Añade cada dominio de cliente una sola vez y deja que la herramienta lea el sitemap, así las páginas nuevas quedan cubiertas sin que nadie añada URLs a mano.
Conecta también Search Console en cada propiedad de cliente. No te avisará rápido, pero es donde confirmas qué hizo Google tras un cambio.
Envía las alertas a un canal de Slack por cliente, o por account manager, para que la persona que puede llamar al desarrollador del cliente sea la primera en verlas.
Deja acordado internamente quién responde a cada tipo de alerta. Un noindex en una categoría de producto requiere una llamada ese mismo día; una meta description cambiada puede esperar a la revisión semanal.

Qué hacer cuando salta una alerta

Abre la URL en una ventana privada y comprueba que el cambio es real, no una página en caché ni una redirección por país. Después decide si fue intencionado. Un redactor que mejora un title no necesita nada de ti. Un canonical que ahora apunta a staging.clientsite.com necesita al desarrollador hoy mismo. Envía al cliente la URL, el valor anterior, el nuevo y la fecha, y pregunta qué se ha publicado. Con el tiempo, esa pregunta hace que tu equipo acabe incluido en los avisos de despliegue.

Recibir alertas de cambios en las webs de clientes con Deltio

Deltio se creó para este flujo de trabajo. Añades el sitio de un cliente, lee el sitemap y las páginas una vez al día, los compara con la comprobación anterior y envía una alerta por Slack y email para ese sitio que describe qué ha cambiado y en qué URL. Las comprobaciones cubren noindex, robots.txt, canonicals, title, meta y H1, URLs del sitemap, uptime, SSL y caducidad del dominio, GA4, GTM, Meta Pixel y el banner de cookies. El límite, dicho con franqueza, son los tiempos: con un ciclo diario te enteras de un cambio el día en que se detecta, no minutos después del despliegue.

Puedes probarlo con tu lista de clientes durante 14 días.

Preguntas frecuentes

¿Debo decirles a mis clientes que monitorizo sus sitios?: Sí. Es un servicio del que se benefician, y te da un motivo para pedir que te avisen de las publicaciones con antelación. La mayoría de los clientes reaccionan bien a un «detectamos este cambio el martes» cuando llega antes de que ellos mismos hayan visto un problema.
¿Y si el desarrollador del cliente bloquea las herramientas de monitorización?: Los firewalls y las protecciones contra bots, como las de Cloudflare, pueden bloquear las comprobaciones automáticas, y eso aparece como peticiones fallidas o bloqueadas. Pide al desarrollador que permita el user agent o las IPs de la herramienta. Si se niega, para ese sitio vuelves a las revisiones manuales y a Search Console.
¿Cómo monitorizo un sitio de staging antes de publicarlo?: El staging suele estar protegido con contraseña y en noindex a propósito, así que monitorizar cambios ahí genera falsas alarmas. Es más útil monitorizar producción y lanzar un escaneo SEO manual justo después del lanzamiento, que es cuando más probable es que se haya colado un ajuste de staging.
¿Cuántas alertas debo esperar por cada sitio de cliente?: En un sitio estable, muy pocas. Los e-commerce y los medios con mucha actividad generan más, sobre todo ediciones de title y meta description y URLs nuevas en el sitemap. Si un sitio inunda el canal, mira si hay una plantilla que cambia en cada despliegue, porque eso suele apuntar a un problema real.