Qué es llms.txt y cómo implementarlo para tu web

¿Qué se supone que hace llms.txt?

LLMs.txt es una convención Markdown propuesta para presentar un mapa seleccionado de páginas importantes en la raíz de un sitio web. La idea es facilitar la identificación y consulta del material seleccionado; publicar el archivo no establece que un servicio de IA en particular lo leerá o lo usará en una respuesta.

Piensa en él como un índice editorial, no como una nueva versión de tu sitio web. Puede dirigir a un visitante hacia documentación, explicaciones de productos, políticas, investigación u otras páginas que representen bien el proyecto. La página en sí sigue siendo la fuente de la información detallada, por lo que su precisión y claridad importan más que una descripción en el índice.

Antes de redactar, decide qué debería ayudar a encontrar el archivo. Un inventario inicial útil podría incluir:

• Páginas principales de producto y organización que expliquen qué hace el proyecto.
• Documentación actual, material de soporte o referencias técnicas.
• Explicaciones públicas de políticas, riesgos y datos importantes del proyecto.
• Páginas que respondan preguntas recurrentes y que sean mantenidas por un responsable.

Excluye páginas obsoletas, duplicadas o demasiado escasas para sostenerse por sí solas. Para equipos Web3, revisa con especial cuidado las descripciones de tokens, redes y productos: una declaración desactualizada en un destino destacado puede generar confusión en lugar de reducirla. Esta distinción práctica es el punto de partida para decidir si llms.txt tiene cabida en tu trabajo técnico.

¿Qué evidencia respalda el uso de llms.txt?

El argumento defendible más sólido para llms.txt es que le da al propietario de un sitio un lugar simple para seleccionar enlaces a material que considera importante. Eso describe el rol previsto del archivo; no es evidencia de que agregarlo hará que un sistema de IA rastree, cite o prefiera esas páginas.

Mantén separados tres tipos de afirmaciones al revisar consejos sobre llms.txt:

• Especificación o propuesta: lo que la convención pide que publique un sitio y cómo se presenta un archivo.
• Trabajo observable en el sitio: si tu archivo es accesible, si sus enlaces se resuelven y si sus descripciones coinciden con las páginas de destino.
• Resultado de la plataforma: si un producto nombrado descubre, consulta o cita una página. Necesitas evidencia directa y actual antes de tratar esto como un resultado del archivo.

Esta separación evita que una implementación ordenada se presente como prueba de visibilidad. Una captura de pantalla de un archivo publicado demuestra que el archivo existe. No demuestra, por sí sola, que un asistente específico lo haya usado. Del mismo modo, una cita observada en una respuesta no establece por qué apareció la página.

Para una revisión cuidadosa, registra la versión del archivo, la fecha de revisión, las URL seleccionadas y cualquier comportamiento observado de la plataforma por separado. Anota el mensaje exacto y el producto al documentar una respuesta, y describe la observación sin asignar una causa que no puedas verificar. Los equipos que trabajan en una detectabilidad técnica más amplia también pueden consultar nuestra guía técnica de AEO para ver cómo encaja llms.txt junto con otros trabajos del sitio.

¿Necesitas llms.txt para tu sitio web?

Puede que tengas un uso razonable para llms.txt si tu sitio tiene un conjunto estable de páginas autoritativas que es difícil de navegar, o si una revisión técnica ha identificado la necesidad de un índice compacto y mantenido. Es menos convincente cuando la información clave del proyecto falta, es contradictoria o está dispersa en páginas que nadie posee.

Usa esta verificación de decisión antes de asignar trabajo de implementación:

• ¿Puedes nombrar la audiencia a la que se pretende ayudar con el archivo?
• ¿Las páginas que incluirías son precisas, públicas y útiles sin el archivo?
• ¿Hay una persona responsable de mantener los enlaces y las descripciones actualizados?
• ¿Puedes explicar cómo sería el éxito sin reclamar un resultado de plataforma que no puedas observar?

Si las respuestas son claras, un archivo conciso puede ser una adición de baja fricción a una revisión más amplia de contenido y técnica. Si las respuestas no son claras, mejora primero las páginas de destino. Un mapa no puede resolver descripciones de productos contradictorias ni proporcionar información que el sitio no publique.

La decisión debe ajustarse a tus prioridades existentes. Por ejemplo, un equipo que prepara una renovación importante de documentación puede incluir llms.txt en ese trabajo, mientras que un equipo con hechos de producto no resueltos debería primero acordar una única fuente precisa para esos hechos. Si el objetivo más amplio es evaluar la detectabilidad en lugar de simplemente publicar un archivo, consulta nuestra guía de seguimiento de visibilidad en IA.

¿Cómo implementar llms.txt sin convertirlo en un sitemap?

Para implementar llms.txt, define su audiencia, selecciona un pequeño conjunto de páginas mantenidas, escribe descripciones claras y verifica cada destino antes de publicar. Mantenlo útil como índice, sin tratarlo como una copia completa de tu sitio.

Una secuencia práctica de redacción es:

• Elige el propósito. Declara internamente si el archivo está destinado a orientar a los lectores hacia documentación de producto, información del proyecto u otro conjunto claro de recursos.
• Haz un inventario de páginas candidatas. Reúne las URL e identifica al propietario de cada página. Prefiere páginas principales sobre comentarios que repiten la misma información.
• Verifica el material fuente. Confirma que cada página sea pública, actual, comprensible y coherente con la redacción preferida del proyecto.
• Escribe descripciones concisas. Explica qué encontrará un lector en cada destino. Evita afirmaciones no respaldadas sobre cómo un modelo de lenguaje lo interpretará o posicionará.
• Publica y verifica. Coloca el archivo en la ubicación raíz prevista, luego ábrelo y prueba cada enlace desde un navegador. Registra quién lo revisará después de cambios relevantes en el sitio.

El archivo debería facilitar la navegación, no crear un segundo lugar donde los datos importantes puedan desviarse. Si una página no está lista para el escrutinio, arréglala antes de destacarla. Esto es especialmente importante para detalles de tokens, disponibilidad de productos, auditorías y declaraciones de políticas: un índice puede hacer que dicho material sea más fácil de localizar, pero no puede validar el material en sí.

LLMs.txt vs schema.org: ¿cuál es la diferencia?

LLMs.txt y schema.org abordan diferentes tareas de publicación. LLMs.txt es un índice Markdown propuesto para páginas seleccionadas; schema.org es un vocabulario utilizado para describir información en forma estructurada. Ninguno debe tratarse como un sustituto de una página útil y precisa.

Usa el formato que aborde la tarea real. Si la carencia es que las páginas útiles son difíciles de localizar, un índice puede ayudar a organizarlas. Si la carencia es que al sitio le faltan descripciones estructuradas adecuadas, considera el schema markup y valida que refleje lo que los visitantes pueden ver. Algunos equipos pueden mantener ambos, pero hacerlo crea dos responsabilidades de revisión distintas.

Para la planificación de la implementación, nuestra guía sobre schema markup para búsqueda con IA cubre la pregunta relacionada de datos estructurados. Mantén el alcance fundamentado: publica solo información que tu equipo pueda respaldar y no describas ninguno de los formatos como un control sobre lo que devuelve un producto de búsqueda o respuesta externo.

¿Cómo debería un equipo publicar y mantener el archivo?

Un flujo de trabajo sólido para llms.txt asigna un responsable, verifica el archivo contra el contenido real del sitio y conserva un registro simple de lo que cambió. Esto hace que el archivo sea más fácil de confiar internamente y más fácil de reparar cuando un destino se mueve.

Usa una rutina de revisión breve al publicar:

• Confirma que el archivo esté disponible en la raíz del sitio web prevista.
• Abre cada destino listado y verifica redirecciones, errores o restricciones de acceso.
• Compara cada descripción con la página misma; elimina afirmaciones que el destino no respalde.
• Pide al responsable del producto o de la documentación que apruebe las descripciones sensibles.
• Registra al revisor y los cambios en el sitio que deberían desencadenar otra verificación.

Un registro de cambios ligero puede anotar la fecha, las URL añadidas o eliminadas y el motivo de la edición. No necesita reclamar impacto en el rendimiento. Si el sitio tiene diferentes áreas mantenidas por distintos equipos, acuerda la propiedad antes de añadir una página; de lo contrario, un enlace puede permanecer en el archivo después de que su contenido haya cambiado.

Para evaluar el trabajo, informa lo que se entregó: el inventario revisado, el archivo, sus enlaces verificados y cualquier problema de contenido pendiente. Si observas por separado una respuesta de IA que cita una de esas páginas, registra esa observación en sus propios términos. Nuestra guía de citas de ChatGPT analiza cómo abordar las observaciones de citas sin confundirlas con la prueba de una causa técnica particular.

Lo que llms.txt no puede resolver para un proyecto Web3

Para un proyecto Web3, llms.txt puede organizar enlaces a información, pero no puede determinar si una descripción de token es precisa, si una afirmación está respaldada de forma independiente o si un producto de IA consultará o citará una página en particular. Esos productos controlan su propio descubrimiento y comportamiento de respuesta, y la publicación del archivo no es evidencia de adopción.

Ese límite hace valiosa una revisión editorial. Verifica que una página distinga la información confirmada del proyecto de los planes, etiquete el material técnico y de riesgo con claridad y tenga un responsable que pueda actualizarla. Si incluyes una auditoría, una página de tokenomics o una referencia de red, confirma que la página enlazada sea la fuente principal prevista y que su redacción siga siendo actual. No uses el índice para hacer que una declaración suene verificada cuando el destino no proporciona evidencia para ella.

Una entrega útil tiene límites claros: el archivo está redactado, cada enlace incluido está verificado, las descripciones se revisan contra sus destinos y las preguntas de contenido no resueltas se devuelven al equipo del proyecto en lugar de adivinarse. Bitcoin Insider comienza con una revisión del inventario de páginas y señala esas preguntas antes de redactar. Envíanos la URL de tu sitio web y las páginas que consideres autoritativas; te devolveremos un plan de revisión enfocado para el archivo y su contenido fuente.

Precios

Precios iniciales en USD. Paquetes a medida y descuentos por volumen bajo solicitud. Pago en USDT, USDC, BTC, ETH, SOL, TON o con el token de tu proyecto.

Cómo trabajamos

1. Define el propósitoDecide a quién debería ayudar el archivo y qué información necesitan encontrar. Mantén ese propósito lo suficientemente específico para guiar la selección de páginas.
2. Haz un inventario de páginas autoritativasReúne las URL candidatas e identifica quién es el propietario de cada una. Excluye páginas que estén desactualizadas, duplicadas o que no estén listas para servir como referencia confiable.
3. Redacta y verifica descripcionesEscribe descripciones concisas que coincidan con las páginas de destino. Pide al responsable correspondiente que revise el material sobre productos, detalles de tokens y políticas.
4. Publica y verificaColoca el archivo en la ubicación raíz prevista y ábrelo en un navegador. Prueba cada enlace y registra la revisión completada.
5. Mantenlo actualizado con el sitioAsigna un responsable y revisa el archivo cuando las páginas enlazadas cambien. Mantén el mantenimiento del archivo separado de las afirmaciones sobre la visibilidad en la plataforma.