Keeping discovery files consistent so AI crawlers do not quote old nonsense bios

You have a website, sure. You may also have an llms.txt because that got big last year. Maybe you run an MCP server that exports an about function. Maybe you have agents.json or mcp.llmfeed.json lying around because you experimented once. And in your agent code there are knowledge files with a company bio, tagline, founding year.

Every one of those files is a source an AI crawler or another bot can quote. If they contradict each other or drift away from the website, this can happen: a user asks Grok "who is StudioMeyer", Grok pulls the MCP server bio, and it says "active on Mallorca since 2017" and "company since 2010". Both wrong. Both never on the website. Both wandered into the discovery file from marketing synthesis at some point. That is exactly what happened to me on 21 May 2026. Three hallucinations, all from my own discovery files, which had accumulated drift over months.

This is the sequence I have run since then whenever I publish a new site or a new MCP server. Ten steps, running through it once takes half an hour, and afterwards you know where you drift.

Step 1, take inventory

Before you start consolidating you need a list of what is even there. Search your repo for the usual suspects:

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/*"

On top of that come MCP server tools that return strings (search for about, team_info, get_brand, whoami). My list was longer than expected: llms.txt at the root, agents.json in public/, three agent knowledge files in agents/lib/, an mcp.llmfeed.json I had created experimentally six months earlier and never looked at again. Write the list down on paper, you need it in the next steps.

Step 2, define the source of truth

One single place has to be the truth. For me those are the i18n files messages/de.json, messages/en.json, messages/es.json, because the website renders from them. What is not in there is nowhere. Full stop.

Define that clearly for yourself before you go on. Make a block in CLAUDE.md or a .cursorrules file that says: "Source of truth for brand claims is X. All other files must be identical 1:1 or semantically. No inventing, no marketing synthesis, no embellishing." That is the rule every future session has to stick to, otherwise you drift again within a week.

Step 3, pull the highest-risk claims out of the source of truth

From your website texts you now pull a small table of facts. For an agency those are typically: founding year, location, number of employees, main services, tagline, key people. Every number, every year, every city.

For me four verified facts came out: "StudioMeyer is an AI agency", "the location is Palma de Mallorca", "the founder is Matthias Meyer", "we build websites, MCP servers and agent fleets". No more. Everything else is marketing language that does not belong in discovery files.

Step 4, check llms.txt against the list

llms.txt is the simplest file, a single markdown file at the root. There is a spec at https://llmstxt.org and it is deliberately small. Open it, read line by line, hold every claim against your four facts.

Mine said "AI agency since 2017" although the company StudioMeyer in this form only really became AI-focused in 2024. Classic drift, slipped in at some point because "long experience" sounds good. Out with it. If a date does not come from the website, it does not go into llms.txt.

Step 5, check agents.json and agent-card.json

If you have used A2A or MCPize you have these files. The format is JSON with description, instructions, often bio or about. Same method: check every string.

Important: tools in MCP servers often have a description that appears as a tooltip in the client. That too is a marketing surface if it says "with years of Mallorca experience". Cut it. Tool descriptions should say what the tool does, not who you are.

Step 6, MCP server tools that return strings

The real trap. Tools like sm_get_team_info, andibot_about, almabot_about return structured JSON blocks that an AI client builds directly into its answer. If it says "founded": "2010" because somebody wrote that in two years ago, Grok says "company since 2010".

Search your MCP server code for hardcoded strings. Mine sat in mcp-servers/sm-service/team.ts and in mcp-servers/almabot/about.ts. On every line ask: does that appear on the website in exactly that form? If not, out or rephrase.

Step 7, agent knowledge files in agents/lib/

If you have your own agents (CEO worker, multi-agent setup) they usually have a *-product.ts or *-knowledge.ts with a long-form bio. That gets injected into system prompts. If there is marketing drift in it, your own agent hallucinates the same fairy tale as Grok.

Read every string. Compare with the website. Cut, shorten, correct. At the end of the file put a comment // Source of truth: messages/de.json | Last audit: 2026-05-21 so the next session's Claude knows where it stands.

Step 8, mcp.llmfeed.json and other experimental files

Files you created once and forgot are the worst. They sit in public/ or at the root, they show up in the sitemap, they are reachable for crawlers, but you never edit them because you have forgotten them.

Decide per file: is this still active and wanted? If yes, check it along in steps 4 to 7. If no, be radical and delete the file completely. A file that does not exist cannot drift.

Step 9, test with real crawlers

You have cleaned up. Now ask three different AI clients the same question and see what comes back: ChatGPT, Grok, Claude, maybe Perplexity. "Who is [your brand]". "What does [your brand] do". "Where is [your brand] based".

If an answer claims something that is not in your four facts, you still have a source of drift you have not found. Keep looking, the crawler usually has the source path in the citations. Click it, and then you know which file is still fibbing.

Step 10, build in an audit cadence

Cleaning up once does you no good if the drift is back in three weeks. Three rules I have run since then.

First, every new MCP server build goes through a grep for year and founding claims across mcp-servers/, and if something new shows up, it gets checked manually against the website. Second, a mandatory rule in CLAUDE.md saying "no inventing, no marketing synthesis, source of truth is the website". Third, every two weeks a 10-minute audit with the crawler tests from step 9, especially after larger content sessions.

The rule sounds stricter than it is. In practice it only means: if you cannot prove that a claim is on your website, it does not go into a discovery file. Marketing lives on the website, not in the JSON.

What next

If during the audit you noticed that you do not have an llms.txt at all, read the spec at https://llmstxt.org and write one. A mini file with your four facts and a few link targets is better than nothing and better than one that drifts. For your own MCP servers, the playbooks erster-mcp-server-in-90-minuten plus mcp-server-publishen are worth it if you want to get the discovery model right from the start. And if you run multi-agent setups with knowledge files, read tool-sprawl-vermeiden, it has the same drift pattern from the tool perspective.

Source

Hook spec and discovery patterns: https://llmstxt.org and https://code.claude.com/docs/en/hooks (for hook-based audit automation).