Prepara tu sitio web para agentes de IA: Crawlers, llms.txt, datos estructurados y protocolos de comercio

La pregunta que las empresas se hacen sobre la visibilidad está cambiando. Antes solía ser: "¿Cómo posicionarnos mejor en Google?" Ahora suele ser: "¿Por qué un asistente de IA recomienda a nuestro competidor en lugar de a nosotros?" Para los sitios de comercio, lo que está en juego es mayor: un agente puede comparar productos, precios, disponibilidad, condiciones de entrega y políticas antes de que una persona visite siquiera la página de inicio.

Eso no hace que el SEO tradicional quede obsoleto. Simplemente añade otro lector al sitio web: un software que actúa en nombre de una persona. A un agente no le importa una animación de héroe. Le importa si puede acceder a la página, entender los datos, identificar la fuente canónica y completar la acción solicitada de forma segura.

Hay mucho revuelo en torno a este tema. Algunos proveedores reducen la "preparación para agentes" a publicar un único archivo de texto. El trabajo real es más estructural. Algunos cambios vale la pena hacerlos ahora; otros solo tienen sentido cuando el comercio impulsado por agentes se convierte en un canal de adquisición genuino para el negocio.

Qué cambia realmente lo "agéntico"

Durante años, el recorrido dominante era predecible: una persona buscaba, abría varios enlaces, comparaba las opciones y tomaba una decisión. El sitio web tenía que ganarse el clic y persuadir al visitante después de la llegada.

Los agentes comprimen ese recorrido. Una persona puede pedir "un VPS por menos de treinta dólares al mes, alojado en Europa, con condiciones de copia de seguridad claras" o "un arreglo de condolencias disponible para entrega hoy". El agente puede inspeccionar varias fuentes, rechazar ofertas incompletas y devolver una lista breve. El humano ve primero el resumen y puede visitar solo los candidatos finales.

Esto cambia la pregunta de optimización. El tráfico sigue importando, pero también lo hacen la precisión legible por máquina, la autoridad de la fuente y la preparación para la acción. Una página que se ve excelente pero oculta su precio en una imagen, contradice sus datos estructurados o no tiene una política de entrega clara es difícil de confiar tanto para los agentes como para los clientes.

Paso uno: auditar correctamente el acceso del rastreador

Antes de agregar nuevos protocolos, inspecciona robots.txt, los controles de bots de la CDN, las reglas del firewall y los registros del servidor. Un rastreador no puede usar una página que no puede obtener. Pero no trates a cada agente de usuario relacionado con IA como si sirviera al mismo propósito.

OpenAI documenta controles separados para OAI-SearchBot y GPTBot. OAI-SearchBot se relaciona con mostrar sitios web en la búsqueda de ChatGPT, mientras que GPTBot controla el posible uso del contenido rastreado para entrenar modelos fundacionales. Un sitio puede permitir el primero y denegar el segundo. Estas son decisiones políticas independientes.

El control Google-Extended de Google también necesita una redacción cuidadosa. Es un token de control de robots.txt, no un agente de usuario de rastreador HTTP separado, y Google afirma que no afecta la inclusión ni el ranking en Google Search.

Una política intencional podría verse así:

User-agent: OAI-SearchBot
Allow: /

User-agent: GPTBot
Disallow: /

Ese ejemplo no es una recomendación universal. Los requisitos legales, de licencias, privacidad y comerciales difieren. Lo importante es tomar la decisión deliberadamente en lugar de heredar una regla general antigua de un plugin de seguridad.

Qué verificar

• Las páginas públicas importantes devuelven 200 sin requerir cookies ni JavaScript.
• robots.txt refleja las políticas reales de búsqueda e IA del negocio.
• La CDN no desafía a los rastreadores legítimos con un CAPTCHA interactivo.
• Las URL canónicas son rastreables y no redirigen a través de enlaces de seguimiento innecesarios.
• Los registros del servidor confirman si los bots relevantes llegan a las páginas de productos, servicios y políticas.

La capa de descripción: llms.txt sin afirmaciones mágicas

La propuesta llms.txt describe un archivo Markdown en la raíz de un dominio que ofrece a los modelos de lenguaje un mapa curado de contenido útil. Puede identificar la organización, explicar qué ofrece el sitio y señalar documentación autorizada, políticas, productos o referencias de API.

Es útil porque los sitios web suelen contener muchas páginas con mensajes superpuestos. Un mapa conciso puede dirigir a un agente hacia las fuentes que la empresa considera canónicas. Es especialmente sensato para productos técnicos, servicios con mucha documentación y sitios con API.

Sin embargo, no es un atajo probado para obtener citas de IA. Publicar /llms.txt no repara páginas inaccesibles, datos de producto débiles, precios contradictorios o datos estructurados faltantes. Trátalo como documentación de bajo costo orientada a máquinas, no como un reemplazo del SEO técnico.

Un archivo mínimo puede ser simple:

# Example Company

> A short, factual description of the business and its market.

## Products
- [Product catalog](https://example.com/products)

## Policies
- [Delivery](https://example.com/delivery)
- [Returns](https://example.com/returns)

## Support
- [Contact](https://example.com/contact)

Escríbelo a mano o revisa cuidadosamente el resultado generado. Un generador de sitemaps sabe qué URLs existen; no sabe qué páginas son comercialmente importantes, legalmente autoritativas o seguras para que un agente confíe en ellas.

¿Qué hay de agents.md?

agents.md es útil en repositorios de software como convención para dar instrucciones de proyecto a agentes de codificación. En sitios web comerciales públicos, no es un estándar de descubrimiento universalmente adoptado comparable a robots.txt o Schema.org.

Una empresa aún puede publicar documentación de acción orientada a máquinas, pero no debe asumir que agentes externos descubrirán u obedecerán automáticamente un /agents.md raíz. Las capacidades de acción se describen mejor a través del protocolo o API que realmente las expone, con autenticación, permisos y comportamiento de error definidos allí. Si mantienes un archivo agents.md, trátalo como documentación complementaria, no como la base de la integración.

La capa de datos: los datos estructurados deben coincidir con la realidad

La capa de descripción le dice a una máquina dónde mirar. Los datos estructurados le ayudan a interpretar lo que encuentra. Para páginas de comercio, eso generalmente significa tipos apropiados de Schema.org como Product, Offer, AggregateRating y BreadcrumbList, utilizando campos que realmente coincidan con la página renderizada y el estado del backend.

La frase clave es coincidir con la realidad. Precio, moneda, disponibilidad, condición, información de entrega y totales de reseñas no deben discrepar entre el HTML visible, JSON-LD, feeds y el proceso de pago. Un agente que ve hechos contradictorios no puede recomendar o realizar transacciones de manera confiable.

Los datos estructurados tampoco se limitan a tiendas. Las empresas de servicios pueden aclarar detalles de la organización, áreas de servicio, preguntas frecuentes, puntos de contacto y relaciones entre páginas. El objetivo no es agregar cada propiedad posible, sino hacer que los hechos importantes sean explícitos, actuales e internamente consistentes.

Una lista de verificación confiable de datos de producto

• Identificadores de producto estables y URL canónicas
• Precio actual y moneda
• Disponibilidad específica de variantes
• Imágenes precisas y texto alternativo descriptivo
• Términos de entrega, devolución y cancelación
• Recuento de reseñas que coincida con las reseñas visibles
• Datos coherentes en HTML, schema, feeds y API

La capa de acción: MCP, ACP, UCP y AP2

Las páginas estructuradas ayudan a un agente a comprender una oferta. Los protocolos y las API le permiten realizar acciones controladas. Estas tecnologías se superponen, pero no son intercambiables.

MCP: herramientas y contexto, no un sistema de comercio por sí mismo

Model Context Protocol es un protocolo general para conectar aplicaciones de IA con herramientas y fuentes de datos. Una implementación de comercio puede exponer herramientas para búsqueda de productos, verificación de existencias, creación de carritos o consultas de soporte, pero MCP en sí mismo no define el ciclo de vida comercial completo. La empresa sigue siendo propietaria de la autenticación, autorización, validación, reglas de precios y registros de auditoría.

ACP: infraestructura de comercio para ChatGPT

OpenAI describe el Agentic Commerce Protocol como una infraestructura entre comerciantes y compradores en ChatGPT. Su modelo de integración de comerciantes cubre el descubrimiento de productos y los flujos de comercio, dejando al comerciante la responsabilidad de los datos de catálogo autorizados y la gestión de pedidos. Es relevante cuando ChatGPT es un canal de ventas intencional, no simplemente porque un sitio quiera aparecer en respuestas de IA.

UCP: un ciclo de vida comercial más amplio

El Universal Commerce Protocol define los componentes básicos para el comercio agéntico en descubrimiento, carrito, pago, vinculación de identidad, pedidos y soporte posventa. Su especificación está diseñada para funcionar con transportes establecidos y estándares relacionados, incluidos MCP y AP2.

La documentación actual de comercio agéntico de Shopify describe experiencias basadas en UCP y servidores MCP compatibles con UCP para flujos de descubrimiento, carrito, pago y pedidos. Se trata de una capacidad de la plataforma, no de un permiso para asumir que cada tienda está automáticamente configurada, habilitada y expuesta en todos los canales de agentes. Los comerciantes aún deben verificar su configuración real y la calidad de los datos.

AP2: autorización de pago verificable

El Protocolo de Pagos para Agentes (AP2) se centra en la capa de autorización: cómo un usuario puede proporcionar una intención verificable para un pago mediado por un agente. Complementa los protocolos comerciales; no reemplaza el proceso de pago del comerciante, los controles de fraude, el procesador de pagos ni el sistema de pedidos.

¿Qué es realista en Shopify, WooCommerce y construcciones personalizadas?

Shopify

Shopify avanza rápidamente en el comercio agéntico y proporciona componentes documentados para el descubrimiento de productos y los flujos de transacciones. Los comerciantes deben asegurarse primero de que los datos de producto, inventario, mercado, envío y políticas dentro de Shopify estén completos. El soporte de la plataforma solo es valioso cuando el catálogo subyacente es confiable.

WooCommerce

WooCommerce le da al propietario del sitio control sobre la raíz web y la infraestructura REST, por lo que publicar llms.txt, mejorar el esquema o construir una integración dedicada es técnicamente sencillo. La parte más difícil es operativa: conflictos de plugins, almacenamiento en caché, reglas de seguridad, datos de variantes y extensiones que cada una cree que posee el mismo campo.

Para un catálogo pequeño, un acceso correcto para los rastreadores, esquema, feeds y páginas de políticas puede aportar más valor que un protocolo de transacción personalizado. Un endpoint personalizado se vuelve razonable cuando el volumen de productos, la frecuencia de pedidos o un canal de socio estratégico justifica su costo de mantenimiento.

Plataformas personalizadas

Una aplicación personalizada ofrece el mayor control: consultas de catálogo en vivo, herramientas creadas para un propósito específico, permisos precisos y observabilidad consistente. También crea la mayor responsabilidad. Cada endpoint necesita autenticación, límites de tasa, validación de entrada, idempotencia, registros de auditoría, estados de fallo seguros y una política de versionado.

La mejor arquitectura personalizada no permite que un agente escriba directamente en la base de datos. Expone acciones de negocio limitadas como search_products, check_inventory, create_cart o request_quote, y aplica las mismas reglas que utiliza la aplicación orientada a humanos.

Un orden de implementación sensato

Si estuviéramos preparando un sitio existente para agentes, trabajaríamos en este orden:

1. Auditar el acceso. Revisar reglas de robots, desafíos de CDN, redirecciones, páginas canónicas y registros del servidor.
2. Corregir los datos fuente. Hacer que precios, disponibilidad, identificadores, políticas y datos de contacto sean consistentes.
3. Validar los datos estructurados renderizados. Probar páginas reales de productos y servicios, no solo plantillas.
4. Crear un llms.txt curado. Apuntar a los agentes hacia páginas autoritativas y comercialmente importantes.
5. Documentar acciones. Definir qué puede leer o hacer un agente, incluyendo autenticación y comportamiento ante fallos.
6. Agregar protocolos solo para un canal real. Construir integraciones ACP, UCP, MCP o de pago cuando la oportunidad de distribución justifique la propiedad en producción.
7. Monitorear continuamente. Rastrear acceso de crawlers, errores de herramientas, datos obsoletos, acciones abandonadas y resultados completados.

Note qué no está primero: el archivo o protocolo de moda. La preparación para agentes comienza con páginas y datos confiables. Los extras orientados a máquinas amplifican esa base; no pueden sustituirla.

Cómo Auditar si el Trabajo Está Dando Resultados

No mida el éxito solo por si existe /llms.txt. Rastree resultados que conecten el trabajo de implementación con la visibilidad y los ingresos:

• Solicitudes de crawlers de IA y calidad de respuesta en registros del servidor
• Menciones y citas para preguntas representativas de clientes
• Tráfico de referencia desde búsqueda de IA y productos asistente
• Errores en feeds de productos y fallos de validación de esquema
• Éxito de herramientas de agente, latencia y tasas de abandono
• Leads, carritos, pedidos e ingresos asistidos
• Recomendaciones incorrectas causadas por datos obsoletos o ambiguos

Esto también crea un ciclo de retroalimentación. Si los agentes preguntan repetidamente por información que el sitio no expone claramente, no es solo un problema de IA. Los clientes humanos probablemente también tienen dificultades para encontrarla.

El Resultado Final Honesto

La web agéntica es real, pero la mayoría de las empresas no necesitan todos los protocolos hoy. Sí necesitan un sitio web en el que máquinas y personas puedan confiar: páginas canónicas accesibles, datos estructurados precisos, políticas explícitas y datos de backend consistentes.

Empiece por ahí. Añada llms.txt como documentación curada, no como una promesa de posicionamiento. Trate agents.md como una convención opcional, no como un estándar web universal. Construya integraciones de transacciones solo cuando exista un canal compatible y un caso de negocio.

La base poco glamorosa es lo que hace posible todo lo demás. Mejora la búsqueda, la accesibilidad, las integraciones, la confianza del cliente y los futuros flujos de trabajo de agentes al mismo tiempo.

Si desea ver lo que un agente puede entender y hacer realmente en su sitio web hoy, DigiForge puede auditar el acceso de rastreadores, los datos estructurados, la documentación orientada a máquinas, los feeds de productos y la preparación para transacciones. Obtendrá un plan de implementación priorizado, no un montón de archivos de moda.

Inicie una auditoría de preparación para agentes