OpenAI anunció el 30 de octubre de 2026 que respetará una señal común en robots.txt para expresar preferencias sobre entrenamiento de IA. Su comunicado vincula la iniciativa al trabajo de AI Preferences de la IETF, prevé implementarla en los meses siguientes y mantiene los controles existentes. En esa fecha no publica una instrucción nueva lista para copiar.
Para un editor, la decisión inmediata es preparar el inventario de su configuración. El análisis que sigue explica cómo documentarlo y cómo distinguir objetivos que suelen mezclarse cuando aparece una noticia sobre rastreo.
Tres preguntas que requieren respuestas diferentes
La primera pregunta es qué páginas puede solicitar un rastreador. La segunda es si una página aparece en un buscador. La tercera es qué preferencia comunica el editor sobre entrenamiento. Un mismo archivo puede intervenir en parte de este trabajo, pero esas preguntas no son equivalentes.
La documentación de Google Search Central explica que robots.txt administra el rastreo y que bloquear una URL ahí no es un método fiable para retirarla de los resultados. Para impedir el acceso a información privada hacen falta controles de acceso apropiados. El RFC 9309, que define el protocolo, también aclara que sus reglas no constituyen una autorización de acceso.
La consecuencia práctica es escribir primero el objetivo en lenguaje corriente. “No quiero que un documento privado sea accesible” exige revisar dónde está publicado y quién puede abrirlo. “Quiero comunicar una preferencia de entrenamiento” exige consultar las reglas que el proveedor reconozca para ese uso.
Un inventario sencillo antes de editar
Como propuesta editorial, crea una ficha con la dirección del sitio, una copia del archivo actual, fecha, responsable y explicación de cada bloque conocido. Si no entiendes una regla, márcala para revisión. Eliminarla para simplificar el archivo sin conocer su propósito puede borrar una decisión anterior necesaria.
Comprueba también quién genera el archivo. En algunos sitios la configuración sale del CMS o de una extensión; en otros se mantiene como archivo. La ficha debería identificar el lugar real de edición para que un cambio no desaparezca cuando alguien actualice otra parte del sistema.
| Pregunta de la ficha | Ejemplo ficticio de respuesta |
|---|---|
| ¿Qué se quiere conservar? | Acceso de los buscadores a las guías públicas |
| ¿Qué está pendiente? | Instrucciones de la señal común anunciada |
| ¿Quién decide? | La persona responsable del sitio y su política editorial |
| ¿Cómo se recupera la versión anterior? | Copia fechada y procedimiento de restauración |
Ejemplo ficticio de una decisión editorial
Imaginemos una revista que publica tutoriales y mantiene un área privada para colaboradores. Quiere que sus tutoriales puedan encontrarse, comunicar una preferencia sobre entrenamiento y conservar privados los borradores. La reunión de revisión debería producir tres decisiones separadas, con su responsable y su comprobación.
Para los tutoriales, el equipo revisaría la accesibilidad y las señales de indexación que correspondan. Para los borradores, comprobaría el acceso con una sesión sin permisos. Para la preferencia de entrenamiento, documentaría los mecanismos actualmente reconocidos y la información todavía pendiente de la nueva señal. El anuncio no sustituye ninguna de esas verificaciones.
La ficha podría cerrar así: “Mantener configuración vigente hasta revisar documentación oficial; no publicar borradores fuera del área autorizada; volver a evaluar la preferencia común cuando exista una especificación aplicable”. Es un ejemplo de organización del trabajo, sin introducir una sintaxis técnica inventada.
Qué revisar cuando se publique la implementación
El administrador necesitará identificar la documentación exacta, su fecha y el alcance que declara. Conviene preguntar qué proveedores la reconocen, qué uso cubre y cómo interactúa con las reglas existentes. Si una respuesta no está disponible, debe permanecer como pendiente, en lugar de completarse por analogía con otro rastreador.
Después, el equipo puede preparar un cambio pequeño y revisable. La propuesta debería mostrar el archivo antes y después, explicar cada modificación y definir qué se observará. Una prueba sobre páginas representativas ayuda a detectar un bloqueo accidental; un registro de incidencias permite relacionar un problema posterior con el cambio realizado.
El alcance de esa prueba también debe quedar claro. Que una página siga abriendo en un navegador no demuestra cómo todos los rastreadores interpretan una preferencia. Que un proveedor documente su comportamiento no prueba el comportamiento de terceros. La verificación tiene que corresponder a la pregunta concreta.
Un registro que otra persona pueda mantener
En un sitio pequeño, la misma persona puede editar contenido y administrar la web. Aun así, dejar las decisiones por escrito evita tener que reconstruirlas meses después. Basta con anotar motivo, fuente consultada, versión aplicada y próxima revisión. No hace falta convertirlo en un documento extenso para que sea útil.
Si cambia el tema, el CMS o una extensión relacionada con rastreo, comprueba de nuevo que la configuración publicada coincide con la aprobada. El objetivo de esa revisión es detectar cambios concretos, no hacer modificaciones periódicas sin necesidad.
La guía para crear un brief de contenido puede servir para registrar quién aprueba los materiales y qué fuentes los respaldan. Esa organización editorial complementa la configuración técnica: ayuda a saber qué se publica y bajo qué decisión.
Una incidencia debería incluir la URL afectada, el momento de detección y la configuración observada. Esa información permite distinguir un problema del archivo de una caída del sitio o una restricción de acceso. El registro facilita una corrección concreta y evita modificar varias capas a la vez sin saber cuál produjo el efecto.
Qué aporta el anuncio
Una preferencia compartida podría reducir trabajo si su especificación, adopción e implementación son claras. Esa es una interpretación operativa, no una promesa de resultados de búsqueda ni una garantía sobre todos los usos del contenido. Para evaluar su utilidad habrá que contrastar el diseño final con la configuración real de cada sitio.