Alerta cuando cambia el robots.txt

Una alerta de cambios en robots.txt te avisa cuando alguien ha editado las reglas de rastreo de un sitio, para que un Disallow: / que se ha colado se revierta antes de que le cueste el rastreo. El robots.txt es un archivo de texto plano capaz de impedir que Googlebot solicite cualquier URL de un dominio, y cuando eso ocurre nada en el sitio parece roto.

La secuencia típica es esta. Un despliegue copia la configuración de staging a producción, el Disallow: / se publica y el sitio sigue cargando con normalidad para los visitantes y para los controles de uptime. Las impresiones en Search Console empiezan a bajar una o dos semanas después, y solo entonces alguien abre el archivo. Esta guía trata de enterarse antes. Para leer y validar el archivo en sí, empieza por cómo revisar el robots.txt.

Qué cambios en el robots.txt merecen una alerta

Muchas ediciones del robots.txt son inofensivas, como un plugin que añade una regla para su propia ruta de administración. Estas son las que conviene atender el mismo día.

Cambio	Efecto	Urgencia
Disallow: / bajo User-agent: *	Bloquea todas las URLs para todos los rastreadores	Trátalo como una incidencia
Nuevo Disallow en una carpeta de contenido como /blog/ o /products/	Saca una sección entera del rastreo	El mismo día
Nuevo grupo User-agent: Googlebot	Googlebot sigue solo ese grupo e ignora las reglas de *	El mismo día, lee qué contiene
El archivo empieza a devolver un 5xx	Google pausa el rastreo y luego tira de una copia en caché	El mismo día
Archivo eliminado o que devuelve 404	Google trata el sitio como sin restricciones y desaparece la línea Sitemap:	Revisar, rara vez urgente
Línea Sitemap: eliminada o apuntando a una URL antigua	Las páginas nuevas se descubren más despacio	Baja
Reglas añadidas para GPTBot, ClaudeBot, PerplexityBot o Google-Extended	Bloquea rastreadores de IA, sin efecto en la Búsqueda de Google	Confirmar que era intencionado

La fila de Googlebot pilla a la gente en los dos sentidos. Alguien añade para Googlebot un grupo con un único Disallow: /search y, como Googlebot pasa a ignorar el grupo *, las reglas de /cart/ y /checkout/ que antes se le aplicaban dejan de hacerlo. Copia el conjunto completo de reglas en el grupo nuevo, o quedará más permisivo de lo que pretendías.

La fila de los rastreadores de IA a veces responde a una decisión de la empresa y otras a una opción por defecto activada por un plugin de seguridad o de SEO sin que nadie la aprobara. En cualquier caso, el cliente debería saberlo.

Una página bloqueada puede seguir indexada

El robots.txt controla el rastreo y el noindex controla la indexación. Una URL bloqueada en robots.txt puede seguir apareciendo en los resultados, normalmente sin descripción, porque Google la conoce por los enlaces pero nunca pudo descargarla. Search Console las muestra como "Indexada, aunque bloqueada por robots.txt".

La trampa está en combinar las dos cosas. Si pones noindex en una página y además la bloqueas en robots.txt, Google nunca la rastrea, nunca lee el noindex y la URL puede seguir indexada. Para sacar una página de los resultados, déjala rastreable y sirve un noindex. La guía sobre la etiqueta noindex cubre esa mitad.

Qué te dice Search Console, y cuándo

El informe de robots.txt de Search Console (Ajustes > robots.txt) muestra las versiones que ha descargado Google, cuándo lo hizo y si la descarga fue bien o tuvo problemas de análisis. Es útil para diagnosticar cuando ya sabes que algo va mal, pero no te manda un email cuando cambia una línea. La primera señal automática suele ser un aumento de "Bloqueada por robots.txt" en el informe Páginas, que solo aparece después de que Google haya vuelto a rastrear URLs con las reglas nuevas. Google además guarda el robots.txt en caché hasta 24 horas, así que incluso su propia descarga puede ir un día por detrás de la edición.

Montar tú mismo una comprobación básica

Si tienes pocos sitios y acceso a un servidor, un pequeño script ejecutado cada hora con cron cubre lo básico:

#!/bin/sh
URL="https://example.com/robots.txt"
DIR="/var/lib/robots-watch"
mkdir -p "$DIR" && touch "$DIR/last.txt"
STATUS=$(curl -s -o "$DIR/new.txt" -w "%{http_code}" "$URL")
if [ "$STATUS" != "200" ]; then
  echo "robots.txt returned $STATUS" | mail -s "robots.txt error" you@example.com
  exit 1
fi
if ! cmp -s "$DIR/new.txt" "$DIR/last.txt"; then
  diff "$DIR/last.txt" "$DIR/new.txt" | mail -s "robots.txt changed" you@example.com
fi
mv "$DIR/new.txt" "$DIR/last.txt"

Revisa el código de estado además del contenido, y eso importa porque un 5xx persistente es tan grave como una regla mala. Los puntos débiles aparecen cuando crece la lista de sitios. Necesitas una entrada por sitio y un envío de correo que funcione, no te enteras de los cambios de noindex o de sitemap del mismo despliegue y nadie se da cuenta si el cron deja de ejecutarse.

Recibir la alerta de cambios en robots.txt con Deltio

Deltio descarga el robots.txt de cada sitio que añades dentro de su revisión diaria, lo compara con la versión de la revisión anterior y envía una alerta a Slack y por email para ese sitio cuando ha cambiado. En la misma pasada revisa el noindex, los canonical, los títulos y las URLs del sitemap, de modo que un despliegue de staging que rompe varias cosas a la vez llega como un solo conjunto de alertas. En alertas de cambios SEO tienes todo lo que se vigila.

La frecuencia es el límite, y conviene decirlo claro. Con una revisión diaria, una edición hecha justo después de una revisión se notifica al día siguiente, mientras que un script cada hora como el de arriba la detectaría antes. Teniendo en cuenta la caché que aplica Google al archivo y lo que tarda en volver a rastrear, una alerta el mismo día o el siguiente suele llegar antes de que el daño se vea en Search Console.

Un buen primer sitio es el que más te preocupa, ya sea el que más despliegues acumula o el de los desarrolladores que menos te cuentan. Todos los planes incluyen una prueba gratuita de 14 días.