¿Cómo restaura un agente SEO sin riesgo un robots.txt que falta?

Qué es y por qué importa

robots.txt dice a los rastreadores qué pueden leer. Sin él, cada rastreador adivina, y desaparecen las reglas de las que dependía el sitio, como mantener /admin o /api fuera de la búsqueda.

Cómo se detecta

Se activa cuando /robots.txt responde pero falta o está vacío. Gravedad: aviso.

Cómo se corrige

El agente restaura primero el último robots.txt confirmado del historial, lo que recupera exactamente las reglas del sitio. Escribir un robots.txt nuevo requiere la política del propietario para los rastreadores de IA (permitir o bloquear); sin ella, el agente se detiene y pregunta.

El cambio llega al sitio como una pull request que añade o edita un archivo en la raíz web del repositorio, abierta por la app de GitHub de Umbodi. Los bloques generados van entre delimitadores que gestiona el agente, así que las líneas escritas a mano nunca se reescriben.

Cuándo puede actuar el agente sin nadie presente

El valor se deriva de los datos del propio sitio, así que el cambio se marca como mecánico y no se aplica umbral de puntuación. Aun así, solo se aplica si el propietario activó la acción sin supervisión y puso el dial de autonomía de esta categoría en automático; fusionar requiere un permiso aparte.

Una propuesta de cada diez se reserva como grupo de control —elegida por un hash fijo por proyecto, no a mano— y nunca se aplica sin supervisión, para medir el efecto de las correcciones frente a las no hechas.

Cómo se verifica la corrección

Tras fusionar la pull request y aparecer el despliegue en producción, el agente lee el archivo en vivo y lo compara con el propio diff de la fusión: cada línea añadida debe estar, y un cambio que solo quitaba líneas debe haberlas eliminado. Si no, el archivo se relee hasta cinco veces, unas dos horas y media, y después el agente revierte su propia fusión.

Cuándo se detiene en su lugar

Se detiene, y dice por qué, cuando el archivo en vivo lo genera el código del sitio en lugar de servirse desde el repositorio —una pull request no cambiaría nada—, cuando el archivo del repositorio ya dice lo mismo, cuando un cambio de robots.txt requiere una política que el propietario no ha elegido, o según las mismas reglas de fusión y despliegue que las páginas. Nunca revierte sobre un archivo que no puede obtener.

El recibo de este sitio

Plantamos este defecto en nuestro propio sitio y dejamos que el agente lo encontrara. Cada etapa es una marca de tiempo leída de los recibos, no una afirmación escrita en esta página.

• Plantado por nosotros el 2026-10-08 10:41 UTC · artifact-muzep6m8 · commit 1873349d
• Decidido por el agente 2026-10-08 10:55 UTC · receipt ab6a3e66-ad4c-4309-a3a1-6b288fdf7179
• Pull request (repositorio privado) #870
• Verificado en el sitio en vivo tras el despliegue 2026-10-08 11:16 UTC · receipt 354126c8-d07f-49e4-b5ac-b11bf0b5d88d
• Propuesta c515cd88-e194-400b-bd87-4404519d62fc

file deleted (66 lines)

+ # Umbodi — https://umbodi.ai
+ # The admin surfaces are gated by is_platform_admin() server-side; these rules keep them out of the
+ # index as well, because an admin screen appearing in search results is a disclosure of shape even
file created (77 lines)

Este recibo se registró antes del 11 de octubre de 2026, cuando la comprobación tras el despliegue solo confirmaba que el archivo cambiado cargaba. El defecto se volvió a comprobar en el sitio en vivo el 11 de octubre con la propia regla de auditoría, y está corregido.

Última verificación 2026-10-08 11:16 UTC

Qué demuestra esto y qué no

Que toda la cadena se ejecutó sin ninguna decisión humana dentro: el agente encontró el defecto, decidió la corrección, la publicó, la fusionó y verificó el sitio en vivo.

No demuestra ningún cambio de posición ni de citas. Umbodi nunca lo deduce de una corrección: la posición se mide aparte, en Google, y se informa tal como se mide. Un recibo también muestra que el camino funciona en este sitio, no en todos.

Preguntas sobre este defecto.