How assistants get company facts
An assistant's answer about a company comes from three places, usually combined.
- Training data: text the model saw during training, which may be years old and is not updated by your current website.
- Retrieval at answer time: a live web search or an index built by a crawler. OpenAI publishes its crawler user agents (GPTBot for training, OAI-SearchBot for search, ChatGPT-User for user-initiated fetches); Anthropic publishes ClaudeBot, Claude-SearchBot and Claude-User; Google's Google-Extended token controls use of crawled content for its models. Each can be allowed or blocked in robots.txt, with different consequences.
- Tools: structured sources the assistant can query, including registries, knowledge graphs and, increasingly, servers exposed through the Model Context Protocol (MCP) or ordinary APIs.
The practical consequence is that an assistant describes your company from whatever is easiest for it to read and most consistent across sources. Inconsistent names, addresses or founding dates across your website, registries and third-party profiles produce hedged or wrong answers. Consistency across sources is the first lever, and it is also what a diligence reader wants.
Structured data that machines can read
Publish a single, accurate, machine-readable description of the legal entity and keep it consistent with the registry.
- schema.org Organization markup on the home or about page, with legalName, name, address, foundingDate, numberOfEmployees, and identifiers: leiCode, taxID, iso6523Code, vatID where applicable. Google documents these properties for its own features, and the vocabulary is readable by any crawler.
- sameAs links to the authoritative profiles: the registry entry, the LEI record, Wikidata if an item exists, and official social accounts. This is how a machine confirms that the website and the registered entity are the same thing.
- A plain company facts page in text: registered name in the registered script, registration numbers, addresses, officers, group entities, certifications with issuers and expiry dates. Machines read prose better than infographics.
- Consistent NAP data (name, address, phone) across every profile you control.
An OpenDossier machine-readable profile does the same thing from the evidence side: it publishes the verified claims with their sources in a format assistants and tools can read, so that an answer can cite the registry rather than a marketing page.
llms.txt, profiles and tools
llms.txt is a proposal, published at llmstxt.org, for a Markdown file at /llms.txt that points assistants to clean, canonical versions of your key pages. It costs little to publish. Adoption by the major assistants is not confirmed by their operators at the time of review, so treat it as a low-cost convenience, not a guarantee, and keep the canonical facts on ordinary HTML pages as well.
Machine-readable profiles matter more. A dossier page that carries each fact with its source and date, in both HTML and JSON, gives a retrieval system something it can quote and attribute. Assistants that cite sources prefer pages where the claim and the citation sit together.
Tools are the next layer. An MCP server or a documented API that returns your verified profile lets an assistant, or an agent run by a prospective customer, fetch the current facts rather than a cached page. OpenDossier exposes dossiers this way with the evidence chain intact, so that a question such as who is the registered contracting entity is answered from the registry record and dated.
None of this changes what a model already believes from training; it changes what it can find and verify when it looks.
Monitoring what assistants say
Measure answers, not mentions. A sensible monthly routine:
- Write ten to twenty questions a buyer might ask: who owns the company, where is it registered, what certifications does it hold, has it been involved in litigation, who are its competitors, what does it do.
- Ask them of each major assistant, with and without web search where the product allows, and record the answers and the cited sources verbatim with the date.
- Score each answer for factual accuracy against your dossier, note which source was cited, and log errors by type: wrong entity, stale fact, missing fact, invented fact.
- Track share of voice only as a secondary metric: how often you appear in category questions compared with named competitors.
The error log tells you where to act. A wrong entity usually means a same-name company with better-structured pages; a stale fact usually means an old third-party profile the assistant prefers; an invented fact usually means no authoritative page exists for that question at all. Each has a different fix, and the fix is always to improve the source, not to argue with the assistant.
Correcting the record honestly
When an assistant is wrong about your company, trace the cited source and correct it there.
- Registry errors: file the correction with the registry; assistants and diligence readers both treat the registry as authoritative.
- Third-party profiles (data aggregators, directories, review sites): use the platform's correction or claim process; keep the correspondence.
- Wikipedia and Wikidata: follow their conflict-of-interest rules; propose changes with sources on talk pages rather than editing your own article.
- Press: request a correction from the publisher with evidence; a published correction is itself a citable source.
- Your own pages: fix inconsistencies and publish the facts page described above.
Where the underlying record is accurate but unwelcome, such as a real court case, the honest route is context: a dated right-of-reply in your claimed OpenDossier profile, an explanation on your own site, and evidence of what changed. Assistants that retrieve both the record and the reply tend to describe both, which is the fair outcome.
What not to do
Some practices are both ineffective and, in several jurisdictions, unlawful.
- Fake or purchased reviews and testimonials, including AI-generated ones, are prohibited by the FTC rule in the US and banned practices under UK consumer law. They also create a regulatory record that will appear in your own dossier.
- Hidden text, cloaking or content served only to crawlers violates search-engine spam policies and, when found, damages trust in everything else you publish.
- Instructions embedded in pages to manipulate assistants (prompt injection) are detectable and are treated as adversarial by model operators.
- Fabricated awards, partners or certifications are discoverable through the issuers' own registers; a certificate that cannot be found at the certification body is worse than none.
- Impersonating registries or third parties with look-alike pages.
The approach that works is the same one a diligence analyst rewards: accurate facts, consistent across sources, each with an authority behind it, and a visible willingness to correct errors. GEO done honestly is simply good record-keeping made machine-readable.
Sources
- schema.org: Organization
- Google Search Central: Organization structured data
- llms.txt proposal
- Model Context Protocol
- OpenAI: overview of crawlers
- Anthropic: web crawling and how site owners can block the crawler
Reviewed 26 October 2026. Rules and fees change; confirm with the authority before relying on them.