Durante años se acusó al SEO de escribir para robots.
La ironía es que ahora los robots hablan con nosotros, leen páginas, consultan herramientas, combinan datos y pueden ejecutar acciones. Ya no se limitan a ordenar enlaces. Empiezan a mediar entre una persona y casi cualquier capacidad digital.
Una persona puede decir:
Revisa mis movimientos del último trimestre, detecta gastos anómalos y muéstrame en un gráfico qué debería mirar primero.
El agente no necesita únicamente encontrar una página que explique qué es un movimiento bancario. Necesita descubrir qué sistema puede consultar, qué cuentas tiene autorización para leer, cómo solicitar un periodo temporal, qué estructura devolverá cada transacción, qué moneda utiliza y qué parte de la información debe convertirse en una explicación, una tabla o un gráfico.
Ahí aparece una nueva frontera del SEO.
No porque las páginas hayan dejado de importar. Al contrario: el contenido visible sigue siendo el lugar donde una empresa explica qué sabe, qué ofrece, qué límites tiene y por qué merece confianza. Pero una explicación ya no alcanza cuando el usuario espera que el agente haga algo.
La capacidad necesita dos representaciones:
- Una representación visual y conversacional para que una persona pueda comprenderla, evaluarla y controlarla.
- Una representación estructurada, tipada e invocable para que un agente pueda seleccionarla y utilizarla de forma fiable.
La segunda representación se parece al SEO de los datos llevado hasta su consecuencia operativa: una API, una herramienta o un servidor MCP que no solo describe qué existe, sino también qué puede hacerse.
La frase es deliberadamente provocadora. Los datos estructurados no son una API y una API no es SEO. El salto conceptual está en otra parte: ambos reducen ambigüedad para que un sistema automático pueda descubrir significado, elegir una opción y actuar sin tener que adivinar.
En resumen
El SEO no murió con los agentes. Se dividió en dos capas complementarias.
La primera es el SEO que ya conocemos: contenido útil, texto accesible, arquitectura clara, títulos descriptivos, enlaces, autoridad, datos estructurados y acceso para crawlers. Su función es ayudar a encontrar y comprender una fuente.
La segunda es una capa emergente que propongo llamar SEO operativo: contratos de herramientas, APIs, schemas, permisos, resultados estructurados y errores accionables que permiten a un agente descubrir una capacidad, seleccionarla, invocarla y comprobar su resultado.
Una página responde:
¿Qué es esto, para quién sirve y por qué debería confiar?
Una herramienta responde:
¿Qué puedo hacer, con qué parámetros, bajo qué permisos y qué devolveré?
Y una interfaz generada responde:
¿Cómo puede una persona entender, explorar, corregir o aprobar lo que acaba de ocurrir?
El futuro no enfrenta contenido, API e interfaz. Los obliga a compartir la misma verdad.
El SEO siempre fue una interfaz entre dos formas de leer
El SEO suele reducirse a rankings, keywords o tráfico. Esa reducción oculta su función más útil: traducir una página para que sea comprensible al mismo tiempo por personas y sistemas automáticos.
Una persona interpreta jerarquía visual, tono, ejemplos, reputación y contexto. Un crawler necesita enlaces accesibles, texto disponible, HTML semántico, títulos descriptivos, relaciones entre URLs y señales que pueda procesar de manera consistente.
Google define el SEO como el conjunto de prácticas que ayudan a los buscadores a descubrir y comprender contenido. También insiste en que esa optimización aporta valor cuando se aplica a contenido creado principalmente para personas, no cuando el contenido existe para manipular al sistema.
Ese equilibrio es importante porque anticipa el problema actual.
Cuando añadimos datos estructurados a una página, no creamos una segunda realidad secreta para el robot. Añadimos pistas explícitas sobre la realidad que la persona también puede ver. Google exige que el marcado represente el contenido principal, sea relevante y no describa información oculta o engañosa.
La regla puede generalizarse:
La representación para máquinas debe ser una expresión más precisa de la misma capacidad que se promete a las personas.
En la web clásica, esa representación ayuda a clasificar y presentar información. En un sistema agéntico, además puede convertirse en el contrato que habilita una acción.
El cambio no es que el agente lea la web: es que puede continuar después de leerla
Un buscador tradicional encuentra una página y entrega el siguiente paso a la persona. La persona abre el resultado, interpreta la interfaz y ejecuta la acción.
Un agente puede encadenar más partes del proceso:
- Entender la intención expresada en lenguaje natural.
- Buscar fuentes o herramientas relevantes.
- Comparar información y restricciones.
- Elegir una capacidad.
- Preparar parámetros.
- Solicitar autorización cuando corresponde.
- Ejecutar una consulta o acción.
- Transformar el resultado en una explicación o una interfaz.
- Pedir confirmación antes de un cambio sensible.
- Mantener evidencia de lo realizado.
La visita a la página deja de ser siempre el objetivo final. Puede convertirse en una etapa de descubrimiento, confianza o documentación dentro de una tarea mayor.
Esto no elimina la web. Cambia el destino de parte de su tráfico: de clics hacia páginas a delegaciones hacia capacidades.
La interfaz deja de ser únicamente el lugar donde ejecutamos el trabajo y pasa a ser el lugar donde definimos, supervisamos y verificamos una delegación. El SEO vive una transformación paralela: deja de optimizar solo la entrada a una página y empieza a participar en la legibilidad de aquello que el agente puede hacer después.
El modelo de doble representación
Una capacidad digital madura necesitará dos representaciones coordinadas.
1. Representación visual y conversacional
Es la forma en que una persona comprende la capacidad y su resultado.
Puede adoptar muchas superficies:
- Una página editorial que explica un servicio.
- Una conversación que resume un análisis.
- Una tabla que conserva precisión.
- Un gráfico que revela una tendencia.
- Un mapa que permite explorar relaciones espaciales.
- Un formulario para editar múltiples opciones a la vez.
- Un diff que muestra qué cambió.
- Un panel de aprobación que separa lectura de escritura.
Esta representación no es un envoltorio decorativo. Organiza el significado, reduce carga cognitiva y permite verificar lo que el agente interpreta o ejecuta.
La conversación es excelente para expresar intención, pedir una síntesis y refinar el objetivo. Es peor para comparar veinte valores, detectar una anomalía entre cientos de filas o revisar los detalles de una acción irreversible. Por eso la interfaz agéntica no será solo voz o chat. Será una combinación dinámica de lenguaje, controles y visualizaciones.
2. Representación estructurada e invocable
Es la forma en que un agente descubre y utiliza la capacidad sin depender de interpretación visual frágil.
Incluye, según el sistema:
- Un nombre estable y orientado a una acción.
- Una descripción que explica cuándo debe utilizarse.
- Un schema de entrada con tipos, límites y valores permitidos.
- Un schema de salida que conserva estructura y significado.
- Identificadores estables para continuar el flujo.
- Autorización y alcance de acceso.
- Declaración de efectos sobre datos o sistemas externos.
- Errores accionables que permitan corregir parámetros.
- Versionado, disponibilidad y límites operativos.
- Metadatos para distinguir lectura, escritura y acciones destructivas.
OpenAI recomienda tratar nombres, descripciones y documentación de parámetros como product copy: son los textos que ayudan a ChatGPT o Codex a decidir si una herramienta corresponde a la intención del usuario. MCP formaliza esa superficie mediante name, description, inputSchema, outputSchema y structuredContent.
Esta capa no intenta que el agente “vea mejor” un botón. Intenta evitar que necesite buscar el botón.
Datos estructurados no es lo mismo que API
Conviene detenerse aquí porque la metáfora puede inducir a error.
Los datos estructurados de una página son principalmente descriptivos. Indican qué tipo de entidad aparece, quién es su autor, cuándo fue publicada, qué propiedades contiene o cómo se relaciona con otros elementos.
Una API o herramienta es operativa. Define una interacción posible con un servicio: qué recibe, qué devuelve, qué permisos verifica, qué estado puede cambiar y qué errores puede producir.
| Capa | Pregunta principal | Resultado esperado |
|---|---|---|
| Contenido visible | ¿Qué significa y por qué importa? | Comprensión humana, confianza y contexto. |
| Datos estructurados | ¿Qué entidad o información describe esta página? | Clasificación y pistas explícitas para sistemas. |
| API o herramienta | ¿Qué capacidad puede ejecutarse y bajo qué contrato? | Consulta o acción repetible. |
| Interfaz de resultado | ¿Cómo se comprende, explora o aprueba lo obtenido? | Evidencia visual y control humano. |
Por eso “la representación estructurada es el SEO de los datos hecho API” funciona como tesis editorial, no como definición técnica.
La analogía correcta es esta:
El SEO reduce la ambigüedad para descubrir y comprender contenido. Un contrato de herramienta reduce la ambigüedad para seleccionar e invocar una capacidad.
El salto es de semántica descriptiva a semántica operacional.
De la palabra clave a la intención ejecutable
El SEO moderno lleva años alejándose de la repetición literal de palabras clave. Una página útil debe resolver una intención, demostrar conocimiento y ofrecer una respuesta satisfactoria.
Las herramientas para agentes llevan esa lógica a un nivel más estricto.
Una descripción como “Obtiene datos financieros” es demasiado amplia. No explica:
- Si consulta saldos o movimientos.
- Si trabaja con una cuenta o con todas.
- Qué periodo acepta.
- Si devuelve importes netos o brutos.
- Qué monedas puede combinar.
- Si los datos son en tiempo real.
- Si solo lee o también modifica.
- En qué casos no debe utilizarse.
Una descripción orientada a intención sería más parecida a:
Utiliza esta herramienta cuando el usuario quiera analizar gastos ya registrados en una o varias cuentas autorizadas. No la utilices para iniciar transferencias, modificar categorías ni estimar movimientos futuros.
El equivalente técnico puede incluir un contrato como este:
{
"name": "finance.get_spending_summary",
"description": "Analiza gastos registrados en cuentas autorizadas dentro de un periodo. Solo lectura; no inicia pagos ni modifica transacciones.",
"inputSchema": {
"type": "object",
"properties": {
"account_ids": {
"type": "array",
"items": { "type": "string" }
},
"date_from": { "type": "string", "format": "date" },
"date_to": { "type": "string", "format": "date" },
"currency": { "type": "string" }
},
"required": ["account_ids", "date_from", "date_to"]
},
"outputSchema": {
"type": "object",
"properties": {
"totals_by_category": { "type": "array" },
"anomalies": { "type": "array" },
"source_period": { "type": "object" }
},
"required": ["totals_by_category", "anomalies", "source_period"]
}
}El ejemplo no representa una API bancaria real. Muestra el tipo de precisión semántica que un agente necesita para no confundir análisis con acción.
La descripción atrae la intención correcta. El schema evita parámetros improvisados. La autorización delimita las cuentas. La salida estructurada permite continuar. La UI convierte el resultado en algo que una persona puede revisar.
El catálogo de herramientas es una nueva página de resultados
Un agente conectado puede tener decenas o cientos de herramientas disponibles. Ante una petición, debe decidir cuál usar, cuál descartar y si necesita combinar varias.
Ese problema se parece a una búsqueda en miniatura.
OpenAI propone evaluar metadatos con un conjunto de prompts directos, indirectos y negativos. Después recomienda medir precisión y recall:
- Precisión: cuando se activó una herramienta, ¿era realmente la correcta?
- Recall: cuando la herramienta era necesaria, ¿el agente la encontró y utilizó?
Estas métricas pertenecen tanto a recuperación de información como a diseño de producto.
La comparación con SEO ayuda a ver el paralelismo, siempre que no se confundan las capas:
| SEO documental | Descubrimiento de herramientas |
|---|---|
title y H1 describen la página | name y title identifican la acción |
| Meta description resume relevancia | description explica cuándo invocar |
| Encabezados desarrollan el tema | Parámetros documentan alcance y límites |
| Enlaces internos conectan contenido | Relaciones y secuencias conectan herramientas |
| Schema.org aporta pistas explícitas | JSON Schema define entradas y salidas |
| URL canónica estabiliza la referencia | ID y versión estabilizan el contrato |
| Robots y sitemap controlan descubrimiento | Registro, permisos y disponibilidad controlan exposición |
| Search Console revela rendimiento | Evals y analítica revelan selección y fallos |
No estamos ante “SEO para engañar al modelo”. Estamos ante arquitectura de información para que el modelo no tenga que adivinar.
Descubrir, comprender, invocar y verificar
El recorrido completo de una capacidad agéntica puede resumirse en cuatro verbos.
Descubrir
El agente necesita localizar una fuente o herramienta candidata.
En la web, esto sigue dependiendo de rastreo, indexación, enlaces, sitemaps, texto accesible y permisos de crawler. Google afirma que las prácticas SEO existentes continúan aplicándose a AI Overviews y AI Mode, y que no hace falta un archivo especial ni un schema exclusivo para aparecer en esas experiencias.
OpenAI distingue OAI-SearchBot, utilizado para mostrar sitios en las funciones de búsqueda de ChatGPT, de GPTBot, relacionado con el entrenamiento. Esto confirma que la accesibilidad para sistemas de búsqueda sigue siendo una decisión técnica concreta, no una abstracción.
Comprender
Encontrar una URL no basta. El agente debe identificar qué afirma la fuente, con qué evidencia, en qué fecha y bajo qué contexto.
Aquí importan el contenido original, la autoría, las definiciones claras, las tablas, la semántica HTML, las fechas, las referencias y la coherencia entre texto visible y datos estructurados.
El contenido de calidad no es un residuo previo a la era agéntica. Es la base con la que el agente construye una respuesta, compara fuentes o decide si una capacidad es apropiada.
Invocar
Cuando existe una acción repetible, el agente necesita un contrato más estricto que una página.
OpenAPI define una descripción estándar para que personas y sistemas puedan descubrir y entender capacidades HTTP. MCP expone herramientas con schemas de entrada y salida. Los resultados estructurados permiten encadenar pasos sin volver a extraer información desde prosa o píxeles.
La invocación añade dimensiones que el SEO clásico no necesitaba resolver directamente:
- Identidad.
- Autorización.
- Alcance.
- Efectos laterales.
- Idempotencia.
- Límites de uso.
- Errores y recuperación.
- Confirmación humana.
Verificar
El agente puede haber llamado a la herramienta correcta y aun así producir una conclusión equivocada.
Un JSON válido no garantiza que sus valores sean verdaderos. OpenAI advierte que Structured Outputs puede respetar un schema y todavía contener errores dentro de los valores. Un schema asegura forma; la evidencia, la validación y la revisión sostienen el significado.
Por eso la última capa vuelve a ser humana: mostrar fuentes, periodo, filtros, supuestos, anomalías, cambios y acciones pendientes de aprobación.
Lo que los agentes nos mostrarán también es UX y también es SEO
El agente no solo necesita leer mejor. También necesita decidir cómo devolver lo que encontró.
Una respuesta hablada puede ser suficiente para:
Este mes gastaste un 18 % más en software que tu promedio de los últimos seis meses.
Pero una persona puede necesitar comprobar:
- Qué suscripciones componen ese aumento.
- Qué meses se compararon.
- Si el importe incluye impuestos.
- Qué cuenta originó cada cargo.
- Qué categorías fueron inferidas.
- Qué movimientos quedaron sin clasificar.
- Qué acción recomienda el sistema y por qué.
Ahí aparece la interfaz generada o seleccionada por el agente.
MCP Apps permite que herramientas entreguen gráficos, formularios y dashboards dentro de una conversación. OpenAI recomienda añadir UI cuando las personas necesitan inspeccionar, comparar, editar, confirmar o navegar información estructurada. También propone separar las herramientas que recuperan o procesan datos de las que renderizan la presentación final.
Esa separación es fundamental.
La herramienta de datos debería devolver una representación precisa y reutilizable. El agente puede analizarla, combinarla o filtrarla. Solo después elige una vista adecuada: gráfico, tabla, mapa, formulario, diff o tarjeta de confirmación.
La UI deja de ser necesariamente una pantalla fija por la que todos entran. Se convierte en una vista contextual de evidencia, construida para la pregunta concreta.
El contenido, los datos y la interfaz siguen relacionados:
- El contenido explica la capacidad antes de usarla.
- El schema permite ejecutarla sin ambigüedad.
- Los datos estructurados conservan precisión durante el flujo.
- La interfaz permite comprender y controlar el resultado.
- La conversación conecta todo con la intención original.
Un ejemplo: “revisa mis cuentas y muéstrame qué necesito ver”
Imaginemos que una persona pronuncia esa frase frente a su ordenador.
Un sistema bien diseñado no debería empezar abriendo pestañas al azar y leyendo números de la pantalla como única estrategia. Podría seguir un flujo como este:
- Identificar que la petición es de análisis, no de transferencia.
- Mostrar qué fuentes financieras están conectadas y pedir alcance si hay varias.
- Invocar una herramienta de solo lectura para recuperar cuentas autorizadas.
- Consultar movimientos con fechas, monedas e identificadores estables.
- Normalizar categorías sin modificar el registro original.
- Calcular tendencias y marcar anomalías con criterios explícitos.
- Conservar el periodo y las fuentes dentro del resultado estructurado.
- Elegir una representación visual adecuada.
- Resumir por voz los dos o tres hallazgos principales.
- Permitir abrir cada categoría o movimiento desde el gráfico.
- Separar cualquier acción posterior —por ejemplo, cancelar una suscripción— en una herramienta de escritura con confirmación propia.
La persona recibe una experiencia simple: una conversación y un gráfico.
Debajo existe una arquitectura compleja: herramientas enfocadas, permisos, schemas, fuentes, cálculos, estados y trazabilidad.
El buen diseño no consiste en ocultar esa complejidad por completo. Consiste en mostrar la parte necesaria en el momento correcto.
La misma fuente de verdad debe alimentar página, herramienta e interfaz
El riesgo más grande de este modelo es crear tres versiones incompatibles del negocio:
- La promesa comercial en la página.
- El contrato técnico en la herramienta.
- El comportamiento real del sistema.
Propongo llamarlo triángulo de paridad semántica.
| Vértice | Qué debe expresar | Fallo típico |
|---|---|---|
| Promesa visible | Qué resuelve, para quién, con qué límites y evidencia. | Marketing promete tiempo real, pero los datos se actualizan una vez al día. |
| Contrato estructurado | Entradas, salidas, permisos, efectos, errores y alcance. | La descripción dice “solo lectura”, pero el endpoint puede modificar estado. |
| Comportamiento real | La operación y el resultado que el sistema ejecuta. | El output omite moneda, zona horaria o fuente y produce una visualización engañosa. |
La coherencia no debería mantenerse copiando texto manualmente entre CMS, documentación y código. Conviene derivar las representaciones desde una fuente de verdad compartida siempre que sea posible:
- Catálogo canónico de capacidades.
- Tipos de datos versionados.
- IDs estables.
- Políticas de autorización centralizadas.
- Ejemplos de uso verificables.
- Definiciones de negocio compartidas.
- Tests de contrato.
- Evals de selección de herramientas.
- Comprobaciones de paridad entre contenido y comportamiento.
El SEO, el diseño y la ingeniería dejan de ser fases separadas. Participan en la misma arquitectura semántica.
Qué es el SEO operativo
SEO operativo no es un estándar existente. Es un marco para nombrar una responsabilidad que está apareciendo.
Lo defino así:
El SEO operativo es el diseño de contenido, metadatos, schemas y contratos para que una capacidad digital pueda ser descubierta, comprendida, seleccionada, invocada y verificada por agentes sin perder claridad, confianza ni control humano.
No reemplaza el SEO técnico ni editorial. Los extiende cuando una página representa una capacidad ejecutable.
Una empresa no necesita convertir cada artículo en una herramienta. Una opinión, una investigación o una historia pueden permanecer como contenido. La capa operativa tiene sentido cuando existe un resultado repetible y autorizable:
- Consultar disponibilidad.
- Calcular una tarifa.
- Recuperar un pedido.
- Analizar movimientos.
- Crear una reserva.
- Preparar un presupuesto.
- Actualizar un registro.
- Generar un informe.
- Abrir una incidencia.
- Programar una reunión.
La pregunta práctica es:
Después de comprender esta página, ¿hay una capacidad concreta que el usuario querrá delegar?
Si la respuesta es sí, probablemente convenga diseñar su representación invocable.
La matriz de madurez: página, contrato y acción
Podemos clasificar una capacidad según las representaciones disponibles.
| Representación humana | Contrato invocable | Estado de la capacidad |
|---|---|---|
| Sí | No | Comprensible, pero la persona todavía debe ejecutar manualmente. |
| No | Sí | Operable por integración, pero opaca y difícil de evaluar o gobernar. |
| No | No | Capacidad invisible o dependiente de conocimiento interno. |
| Sí | Sí | Capacidad delegable: se puede comprender, invocar y verificar. |
La última categoría no es automáticamente buena. También necesita autorización, seguridad, observabilidad y recuperación. Un agente no debería poder actuar solo porque encontró un endpoint.
Como explico en Controlar agentes IA como Codex en el entorno de trabajo, las instrucciones y anotaciones no sustituyen los controles técnicos. Los permisos deben aplicarse en el servidor, las acciones sensibles deben separarse y la persona debe conservar capacidad de revisión y revocación.
Cómo cambia el trabajo de SEO, UX/UI y desarrollo
SEO deja de terminar en la página
El profesional SEO seguirá trabajando con intención, arquitectura, contenido, semántica, indexación, enlaces, autoridad y medición.
Pero, para productos agénticos, también tendrá que colaborar en:
- Taxonomías de capacidades.
- Nombres y descripciones de herramientas.
- Diferenciación entre operaciones similares.
- Ejemplos positivos y negativos de activación.
- Coherencia entre promesa, schema y resultado.
- Descubrimiento en catálogos de herramientas.
- Evals de precisión y recall.
- Versionado semántico de capacidades.
Es una evolución natural. Redactar una descripción de herramienta no está tan lejos de redactar un título y una meta description: ambas condensan significado para ayudar a un sistema a elegir. La diferencia es que una mala elección de herramienta puede modificar datos, enviar un mensaje o gastar dinero.
UX/UI diseña la evidencia y el control
El diseñador ya no trabaja únicamente en la interfaz previa a la acción. Diseña también lo que ocurre después de delegar:
- Cómo se expresa el alcance.
- Cómo se muestran las fuentes.
- Cómo se comparan resultados.
- Qué visualización corresponde a cada tipo de dato.
- Cuándo basta una respuesta textual.
- Cuándo hace falta un formulario o dashboard.
- Cómo se presenta una confirmación.
- Cómo se interrumpe o revierte una tarea.
- Cómo se distingue una inferencia de un dato observado.
La interfaz puede ser efímera y generada para una petición específica, pero sus principios no pueden improvisarse cada vez.
Desarrollo convierte funciones internas en contratos de producto
No conviene exponer cada endpoint interno como una herramienta. OpenAI recomienda empezar por el objetivo del usuario y agrupar operaciones coherentes, separando lecturas de escrituras y acciones con distinto riesgo.
El trabajo incluye:
- Modelar inputs y outputs explícitos.
- Devolver IDs estables.
- Evitar blobs de texto cuando el resultado necesita reutilización.
- Diseñar errores que permitan corregir y reintentar.
- Aplicar autorización real.
- Declarar y probar efectos laterales.
- Mantener compatibilidad y versionado.
- Separar procesamiento de datos y renderizado.
En Un LLM predice tokens; un agente ejecuta tareas explico que el valor del agente no aparece solo en el modelo, sino en el sistema que lo rodea. El contrato de herramientas es una de esas capas decisivas.
Cómo medir este nuevo SEO
El ranking por sí solo no describe la visibilidad agéntica.
Conviene medir tres niveles.
1. Descubrimiento documental
- Páginas rastreables e indexadas.
- Cobertura de sitemap.
- Impresiones y clics.
- Tráfico desde buscadores y asistentes.
- Consultas donde la fuente aparece.
- Frescura y accesibilidad del contenido.
- Coherencia del marcado estructurado.
2. Selección e invocación
- Precisión de selección de herramienta.
- Recall ante prompts relevantes.
- Activaciones falsas en prompts negativos.
- Validez de argumentos.
- Porcentaje de llamadas exitosas.
- Reintentos por errores de schema o negocio.
- Tiempo hasta completar la tarea.
- Uso correcto de lectura frente a escritura.
- Coste de ejecución.
3. Comprensión y control humano
- Tiempo necesario para verificar el resultado.
- Capacidad de localizar la fuente de un dato.
- Errores de confirmación.
- Acciones revertidas.
- Correcciones solicitadas.
- Comprensión de límites y permisos.
- Satisfacción con la representación visual.
- Incidentes o acciones no deseadas.
La unidad de éxito deja de ser solamente una visita. Puede ser una tarea completada de forma correcta, comprensible y reversible.
Lo que no conviene hacer
Crear contenido “para agentes” que no ayuda a personas
Google mantiene una posición clara: las prácticas SEO sirven cuando se aplican a contenido útil y centrado en personas. La llegada de agentes no justifica producir páginas vacías, definiciones repetidas o texto diseñado únicamente para aparecer en una respuesta generativa.
Tratar llms.txt como una solución mágica
Algunos sitios publican índices legibles por modelos y pueden resultar prácticos como documentación. Pero Google afirma que no hace falta crear nuevos archivos “AI text” ni un markup especial para sus funciones de IA. Un archivo auxiliar no reemplaza contenido accesible, enlaces, arquitectura, permisos de crawler ni una API bien diseñada.
Copiar la API interna sin pensar en el objetivo
Una herramienta con veinte modos y parámetros ambiguos obliga al modelo a adivinar. Las capacidades deben diseñarse desde el resultado que la persona espera, no desde la comodidad del backend existente.
Devolver solo prosa cuando el dato será reutilizado
Un párrafo puede ser agradable de leer, pero pierde IDs, tipos, unidades y relaciones. La respuesta estructurada debería conservar la precisión; la conversación puede sintetizarla después.
Mostrar un gráfico sin exponer su procedencia
Una visualización convincente puede ocultar filtros, periodos o datos excluidos. La UI debe permitir rastrear el resultado hasta sus fuentes y supuestos.
Confiar en el schema como garantía de verdad
El schema valida forma, no necesariamente significado. Hace falta validación de negocio, evidencia, tests y revisión proporcional al riesgo.
Permitir que la descripción sustituya la autorización
Decir que una herramienta es de solo lectura no la convierte técnicamente en solo lectura. Las restricciones deben imponerse en permisos, endpoints y políticas reales.
Una arquitectura práctica para capacidades legibles por agentes
Una organización puede empezar con siete capas.
- Página canónica: explica la capacidad, el público, los límites, ejemplos, fuentes y evidencia.
- SEO técnico: asegura texto accesible, semántica, enlaces, canonical, sitemap, rendimiento y políticas de crawling.
- Datos estructurados: describen entidades y contenido visible sin inventar una realidad paralela.
- Catálogo de capacidades: mantiene nombres, descripciones, propietarios, estado y versión.
- Contrato invocable: expone herramientas o APIs con schemas, autorización, efectos y errores.
- Resultado estructurado: conserva IDs, unidades, fuentes y campos reutilizables.
- Renderizado de evidencia: transforma el resultado en conversación, tabla, gráfico, formulario o panel de aprobación según la tarea.
A estas capas hay que añadir observabilidad, seguridad y gobierno. Cada llamada debería poder responder quién solicitó la acción, qué herramienta se utilizó, con qué argumentos, qué datos devolvió y qué parte fue inferida por el modelo.
La web no desaparece: se convierte en documentación viva de capacidades
La predicción de que los agentes eliminarán las webs confunde navegación con significado.
Quizá visitemos menos páginas para ejecutar tareas rutinarias. Pero las organizaciones seguirán necesitando lugares canónicos donde explicar:
- Qué ofrecen.
- Cómo funciona.
- Qué datos utilizan.
- Qué límites aplican.
- Qué evidencia respalda sus afirmaciones.
- Quién es responsable.
- Qué cambia entre versiones.
- Cómo se revoca el acceso.
- Qué puede hacer el agente en nombre del usuario.
La página se vuelve aún más importante como fuente de verdad pública, incluso cuando el agente es quien la consulta primero.
La diferencia es que el contenido ya no debería vivir aislado del producto. La definición visible, el schema y el comportamiento necesitan evolucionar juntos.
La conclusión incómoda: el SEO se acerca al diseño de producto
El SEO nació como disciplina de descubrimiento. Con los agentes, parte de ese descubrimiento conduce directamente a una acción.
Eso obliga a ampliar la pregunta.
Ya no basta con:
¿Puede un buscador encontrar y entender esta página?
También tendremos que preguntar:
¿Puede un agente descubrir esta capacidad, distinguirla de otras, invocarla con los parámetros correctos y devolver un resultado que una persona pueda verificar?
Ahí el SEO toca arquitectura de información, API design, documentación, UX, seguridad y analítica de producto.
No porque todos esos trabajos se conviertan en SEO. Sino porque todos participan en la misma batalla: hacer que una intención humana llegue a la capacidad correcta con la menor ambigüedad posible.
La web para personas y la interfaz para agentes no son dos mundos separados.
Una explica.
La otra ejecuta.
Y ambas deben decir la verdad.
Preguntas frecuentes
- ¿El SEO desaparecerá cuando los agentes respondan y actúen por nosotros?
- No. Los agentes todavía necesitan descubrir fuentes, interpretar contenido, comprobar autoridad y recuperar información fiable. A ese SEO documental se suma una nueva capa operativa: describir capacidades mediante herramientas, APIs y schemas que puedan seleccionarse e invocarse sin adivinar.
- ¿Los datos estructurados de una página son lo mismo que una API?
- No. Los datos estructurados describen el significado de una página o entidad. Una API o herramienta expone una capacidad ejecutable, con entradas, salidas, autorización, errores y posibles efectos sobre el estado. La relación entre ambas es una analogía semántica, no una equivalencia técnica.
- ¿Qué significa SEO operativo para agentes?
- Es un marco propuesto en este artículo para diseñar contenido, metadatos y contratos de herramienta de modo que una capacidad pueda ser descubierta, seleccionada, invocada y verificada por un agente, manteniendo una representación clara y útil para las personas.
- ¿Una empresa necesita convertir toda su web en una API?
- No. El contenido editorial, institucional o explicativo puede seguir siendo únicamente documental. Conviene exponer una capa invocable cuando existe una capacidad repetible y autorizable, como consultar disponibilidad, calcular una propuesta, recuperar movimientos, crear una reserva o actualizar un registro.
- ¿Las interfaces visuales siguen siendo necesarias si el agente puede hablar?
- Sí. La conversación sirve para expresar intención y recibir síntesis. Las interfaces visuales siguen siendo superiores para comparar, explorar datos densos, editar opciones, revisar evidencia, confirmar acciones y conservar un registro persistente.
- ¿Cómo se mide la visibilidad de una capacidad para agentes?
- Además de indexación, impresiones y tráfico, hay que medir selección de herramientas, precisión y recall de activación, validez de argumentos, éxito de tarea, reintentos, tiempo de verificación humana, errores de confirmación y capacidad de recuperación.