Mantener coherentes los discovery files para que los crawlers de IA no citen bios viejas y falsas

Tienes una web, claro. Puede que también tengas un llms.txt porque el año pasado se puso de moda. Quizá corres un servidor MCP que exporta una función about. Quizá tienes por ahí un agents.json o un mcp.llmfeed.json porque un día experimentaste. Y en el código de tus agentes hay knowledge files con la bio de la empresa, el eslogan, el año de fundación.

Cada uno de esos ficheros es una fuente que un crawler de IA u otro bot puede citar. Si se contradicen entre ellos o se desvían de la web, puede pasar lo siguiente: alguien le pregunta a Grok "quién es StudioMeyer", Grok coge la bio del servidor MCP, y ahí pone "activo en Mallorca desde 2017" y "empresa desde 2010". Las dos cosas falsas. Ninguna de las dos estuvo nunca en la web. Las dos acabaron en el discovery file en algún momento por síntesis de marketing. Eso es exactamente lo que me pasó el 21 de mayo de 2026. Tres alucinaciones, todas de mis propios discovery files, que habían ido acumulando desviación durante meses.

Este es el orden que sigo desde entonces cuando publico un sitio nuevo o un servidor MCP nuevo. Diez pasos, recorrerlos una vez lleva media hora, y después sabes por dónde te desvías.

Paso 1, hacer inventario

Antes de empezar a consolidar necesitas una lista de lo que hay. Busca en tu repo los sospechosos habituales:

find . -type f \( \
  -name "llms.txt" -o \
  -name "agents.json" -o \
  -name "agent-card.json" -o \
  -name "mcp.llmfeed.json" -o \
  -name "*-product.ts" -o \
  -name "*-knowledge.ts" \
\) -not -path "*/node_modules/*"

A eso se suman las herramientas de servidores MCP que devuelven cadenas (busca about, team_info, get_brand, whoami). En mi caso la lista era más larga de lo que pensaba: llms.txt en la raíz, agents.json en public/, tres knowledge files de agentes en agents/lib/, y un mcp.llmfeed.json que había creado seis meses antes como experimento y no había vuelto a mirar. Apunta la lista en papel, la vas a necesitar en los pasos siguientes.

Paso 2, definir la fuente de verdad

Un único sitio tiene que ser la verdad. En mi caso son los ficheros de i18n messages/de.json, messages/en.json, messages/es.json, porque la web se renderiza desde ellos. Lo que no está ahí no está en ninguna parte. Punto.

Defínelo claramente para ti antes de seguir. Escribe un bloque en CLAUDE.md o en un fichero .cursorrules que diga: "La fuente de verdad para las afirmaciones de marca es X. Todos los demás ficheros tienen que ser idénticos 1:1 o semánticamente. Nada de inventar, nada de síntesis de marketing, nada de adornar." Esa es la regla a la que se tiene que atener cualquier sesión futura, si no, dentro de una semana vuelves a desviarte.

Paso 3, sacar de la fuente de verdad las afirmaciones de más riesgo

De los textos de tu web sacas ahora una pequeña tabla de hechos. En una agencia suelen ser: año de fundación, sede, número de empleados, servicios principales, eslogan, personas clave. Cada cifra, cada año, cada ciudad.

En mi caso salieron cuatro hechos verificados: "StudioMeyer es una agencia de IA", "la sede es Palma de Mallorca", "el fundador es Matthias Meyer", "construimos webs, servidores MCP y flotas de agentes". Nada más. Todo lo demás es lenguaje de marketing que no pinta nada en un discovery file.

Paso 4, revisar llms.txt contra la lista

llms.txt es el fichero más simple, un único markdown en la raíz. Hay una especificación en https://llmstxt.org y es pequeña a propósito. Ábrelo, léelo línea a línea, y contrasta cada afirmación con tus cuatro hechos.

En el mío ponía "AI agency since 2017", cuando la empresa StudioMeyer en esta forma no se centró de verdad en IA hasta 2024. Desviación clásica, se coló en algún momento porque "mucha experiencia" suena bien. Fuera. Si una fecha no viene de la web, no entra en llms.txt.

Paso 5, revisar agents.json y agent-card.json

Si has usado A2A o MCPize tienes estos ficheros. El formato es JSON con description, instructions, a menudo bio o about. Mismo método: revisar cada cadena.

Importante: las herramientas de los servidores MCP suelen tener una description que aparece como tooltip en el cliente. Eso también es una superficie de marketing si pone "con años de experiencia en Mallorca". Quítalo. Las descripciones de herramienta deben decir qué hace la herramienta, no quién eres tú.

Paso 6, herramientas de servidor MCP que devuelven cadenas

La trampa de verdad. Herramientas como sm_get_team_info, andibot_about, almabot_about devuelven bloques JSON estructurados que un cliente de IA integra directamente en su respuesta. Si ahí pone "founded": "2010" porque alguien lo escribió hace dos años, Grok dice "empresa desde 2010".

Busca en el código de tu servidor MCP cadenas escritas a fuego. Las mías estaban en mcp-servers/sm-service/team.ts y en mcp-servers/almabot/about.ts. En cada línea pregunta: ¿aparece esto igual en la web? Si no, fuera o reformular.

Paso 7, knowledge files de agentes en agents/lib/

Si tienes agentes propios (CEO-worker, montaje multiagente) suelen tener un *-product.ts o *-knowledge.ts con una bio larga. Eso se inyecta en los system prompts. Si ahí dentro hay desviación de marketing, tu propio agente alucina el mismo cuento que Grok.

Lee cada cadena. Compara con la web. Recorta, acorta, corrige. Al final del fichero pon un comentario // Fuente de verdad: messages/de.json | Última auditoría: 2026-05-21 para que el Claude de la siguiente sesión sepa a qué atenerse.

Paso 8, mcp.llmfeed.json y otros ficheros de experimentos

Los ficheros que creaste una vez y olvidaste son los peores. Están en public/ o en la raíz, aparecen en el sitemap, son accesibles para los crawlers, pero no los editas nunca porque te has olvidado de ellos.

Decide fichero a fichero: ¿esto sigue activo y lo quiero? Si sí, revísalo también en los pasos 4 a 7. Si no, sé radical y bórralo del todo. Un fichero que no existe no se puede desviar.

Paso 9, probar con crawlers de verdad

Ya has ordenado. Ahora hazle a tres clientes de IA distintos la misma pregunta y mira qué vuelve: ChatGPT, Grok, Claude, quizá Perplexity. "Quién es [tu marca]". "Qué hace [tu marca]". "Dónde está [tu marca]".

Si una respuesta afirma algo que no está en tus cuatro hechos, todavía tienes una fuente de desviación sin descubrir. Sigue buscando, el crawler suele traer la ruta de la fuente en las citas. Haz clic ahí y sabrás qué fichero sigue contando historias.

Paso 10, montar una cadencia de auditoría

Ordenar una vez no te sirve de nada si en tres semanas vuelve la desviación. Tres reglas que sigo desde entonces.

Primera, cada compilación nueva de un servidor MCP pasa por un grep de años y afirmaciones de fundación sobre mcp-servers/, y si aparece algo nuevo, se revisa a mano contra la web. Segunda, una regla obligatoria en CLAUDE.md que diga "nada de inventar, nada de síntesis de marketing, la fuente de verdad es la web". Tercera, cada dos semanas una auditoría de 10 minutos con las pruebas de crawler del paso 9, sobre todo después de sesiones grandes de contenido.

La regla suena más estricta de lo que es. En la práctica solo significa: si no puedes demostrar que una afirmación está en tu web, no entra en un discovery file. El marketing va en la web, no en el JSON.

Qué sigue

Si en la auditoría te has dado cuenta de que ni siquiera tienes un llms.txt, lee la especificación en https://llmstxt.org y escribe uno. Un fichero mínimo con tus cuatro hechos y unos cuantos enlaces es mejor que nada y mejor que uno que se desvía. Para servidores MCP propios merecen la pena los playbooks erster-mcp-server-in-90-minuten y mcp-server-publishen si quieres montar el modelo de discovery limpio desde el principio. Y si llevas montajes multiagente con knowledge files, lee tool-sprawl-vermeiden, ahí está el mismo patrón de desviación visto desde las herramientas.

Source

Especificación de hooks y patrones de discovery: https://llmstxt.org y https://code.claude.com/docs/en/hooks (para automatizar la auditoría con hooks).