"How do I get cited by ChatGPT?" usually gets answered with a listicle: write good content, add schema, make an llms.txt. That advice isn't wrong so much as it's aimed at the wrong layer. It describes what a page should look like, and skips the two questions that actually decide the outcome: can the retrieval system reach your page at all, and is there a passage on it that survives being torn out of context?
This post is the mechanism, in the order it actually runs. We run these checks on our own site, and a couple of them are the reason we found problems that no amount of content work would have fixed.
Citation is a retrieval problem, not a ranking problem
When ChatGPT answers with links, it is not reading the web live for every question. A retrieval step pulls candidate passages out of an index; the model composes an answer from what came back, and attributes the parts it leaned on. Two consequences fall out of that, and both are unintuitive if you come from classic SEO:
- The unit is the passage, not the page. A page can rank well and contribute nothing, because the fact worth quoting lives in an image, a chart with no text equivalent, or a paragraph that only exists after JavaScript runs.
- Retrievable and quotable are different bars. Being in the index is a precondition. Being the cleanest available sentence on the question is what gets you attributed. Most GEO checklists only address the first, and then wonder why traffic didn't move.
Ranking and citation come apart in practice. You can sit at position three for a keyword and never get cited, because the two pages above you happen to state the answer in one self-contained sentence and you bury yours in the fourth paragraph of a section titled "Our Philosophy".
Three bots, three different jobs
This is where the most expensive mistakes get made, because people reason about "OpenAI's crawler" as if it were one thing. OpenAI documents three separate agents, and they do not do the same job:
- GPTBot — bulk crawling for model training. Blocking it changes what future models absorb from your site. It does not remove you from ChatGPT's live citations.
- OAI-SearchBot — builds the search index that retrieval reads. This is the one that decides whether you can be cited at all.
- ChatGPT-User — fetches a specific URL when a user's question triggers a live browse. Block it and the fetch fails at the exact moment someone asks about you.
The common failure: a team decides it doesn't want its content training models, blocks GPTBot, and believes it has made a considered decision. It has — about training. It has said nothing about retrieval. The worse version: someone blocks every OpenAI agent with one wildcard rule and quietly deletes the company from AI answers, then spends a quarter wondering why competitors get cited.
These are separable choices, so make them separately. Our own robots.txt allows all three and blocks /api/ and share links, because share links are user content that has no business in an index. Yours can differ — training and retrieval are genuinely different bargains. Just decide per bot, not per vendor, and re-read the vendor's docs occasionally, because these policies move.
robots.txt is not the gate that actually stops you
Robots is a request, and it's the layer everyone inspects. The layer that actually bites is your CDN or WAF. Edge platforms challenge or block unfamiliar user agents under plenty of default configurations, and the result is silent: robots.txt says Allow, the edge returns 403, and you are uncrawlable while every file in your repo insists you're open for business.
The check takes ten seconds and almost nobody runs it:
curl -s -o /dev/null -w "%{http_code}\n" -A "OAI-SearchBot" https://your-site/
curl -s -o /dev/null -w "%{http_code}\n" -A "ChatGPT-User" https://your-site/
curl -s -o /dev/null -w "%{http_code}\n" -A "PerplexityBot" https://your-site/
200 means reachable. A 403, a 503, or a challenge page means you have a visibility problem that no amount of content work will fix. Run it against production, from outside your own network, for every domain you operate — each domain usually has its own edge configuration, and they drift apart.
If you only do one thing from this post, do this one. It is the check with the highest yield per second spent, and it is invisible to every content audit.
If a fact needs JavaScript, it doesn't exist
Retrieval crawlers commonly parse raw HTML without executing JavaScript. So the test for whether a claim is citable is not what your browser shows — it's this:
curl -s https://your-site/page/ | grep -i "the claim you want quoted"
Nothing in the output means nothing to cite. This has a real design consequence: citation-critical text — your definition, key facts, FAQ answers, pricing and security claims — has to be in the served HTML. A runtime dictionary that swaps text in after hydration is fine as an enhancement; it cannot be the only place the fact exists.
This bites hardest on multilingual sites, and it's the trap we designed around explicitly. If your Chinese copy only lives in a JavaScript i18n dictionary, then as far as a raw-HTML crawler is concerned, your Chinese content is not there at all. Our fix is to inline every language as real markup and let CSS decide which one a human sees. Crawlers get all four languages; readers get one. It costs page weight and it's worth it.
Write passages that survive being torn out of context
This is the part that is actually writing rather than plumbing, and it's where the leverage is once the plumbing works.
A retrieved chunk arrives at the model without your page around it. No heading hierarchy, no preceding paragraph, no nav. Write for that:
- Answer first. The first sentence under a heading should be the answer, not a runway. "X is Y" beats "In today's rapidly evolving landscape…" — which answers nothing and gets quoted never.
- Keep subjects explicit. "It supports OAuth" is unusable once it's been lifted out; "Orkas supports OAuth" survives. Pronouns die in chunking.
- Make each claim self-sufficient. Entity, qualifier, and boundary in one sentence: "With your own provider, model traffic goes directly to that provider and is not proxied through Orkas." That sentence can be quoted alone without becoming a lie, which is exactly why it's quotable.
- Prefer checkable over impressive. Vague superlatives are never cited, because they answer no question anyone asked.
The question is the retrieval key
Users ask questions, and retrieval matches question-shaped text. A heading that is the literal question — "Does Orkas proxy model traffic?" — matches better than a noun phrase like "Model architecture". This, and not schema magic, is why FAQ blocks punch so far above their weight for AI visibility: they are literally question-to-answer pairs, which is the shape of the thing being retrieved.
Structured data makes you parseable, not preferred
JSON-LD does not buy citations. It buys unambiguous classification: what this page is, who published it, which text is a question and which is its answer. Two rules matter more than the rest:
- FAQ schema must match the visible text one-to-one. Schema that claims something the page doesn't say is a trust problem, and search engines treat the mismatch as a spam signal rather than a formatting slip.
- Never fabricate ratings, awards, or counts. An engine that catches one fabricated aggregate rating has earned a reason to discount everything else you assert.
The 1:1 rule is the kind of thing that silently rots — someone edits the visible FAQ, forgets the schema, and six months later they disagree. We enforce it with a test that walks every page in our sitemap, pulls the FAQ out of the JSON-LD, and asserts each question and answer string appears verbatim in that page's visible text. If it drifts, the build fails. Structured data is a claim about your own page; it should be checked like one.
llms.txt: cheap, useful, and oversold
Be honest about what this file is. llms.txt is a proposed convention. No major engine promises to read it, and anyone telling you it's an ingestion channel is guessing.
What it's actually good for is narrower and still worth an hour: one stable place where your canonical facts are stated plainly — what the product is, model and data handling, pricing, the URLs that matter. When a crawler or a human researcher does land on it, they get the un-spun version instead of reconstructing it from marketing pages. It's also a useful forcing function. If you can't state your product's facts in forty lines without adjectives, your pages can't either, and that's a content problem you were going to have anyway.
What it is not: a guarantee, or a substitute for those facts being on the pages themselves.
Contradictions get you dropped
Answer engines cross-check. If your pricing page says one thing, your docs say another, and your homepage FAQ says a third, the engine doesn't adjudicate — it hedges, or it cites someone who was consistent.
So fact consistency across surfaces is most of the actual work, and none of it is glamorous. When a model, pricing, or security fact changes, it has to change everywhere in the same change — page, docs, homepage FAQ, llms.txt — or you have manufactured a contradiction that will outlive the edit. We treat that as a hard rule rather than a habit, because habits lose to deadlines.
Corroboration beats self-assertion
Here's the part that's hardest to accept: your own site is the weakest available source about you. Engines weight corroboration, and they are right to. A claim that appears only on your own domain is a marketing claim. The same claim on GitHub, in a third-party comparison, in a forum thread, in documentation someone else wrote, is a fact.
This is why, once the on-site basics are real, off-site work outperforms another landing page — repos, directories, listicles, genuine discussion. Put crudely: on-site work makes you citable; off-site work makes you cited. Teams reliably over-invest in the first because it's the half they control.
How to measure without lying to yourself
This is where GEO writing usually goes soft, so: you cannot cleanly measure ChatGPT citations. There is no dashboard. What you have is three imperfect signals:
- Server logs. Grep for
OAI-SearchBot and ChatGPT-User. Crawl frequency and which URLs get fetched tell you whether you're in the index and what's being pulled live. This is the most honest signal you own. - Referral traffic from the assistant. Real, but partial — plenty of citations are read and never clicked, which is the entire point of an answer engine.
- Manual spot checks. Ask the ten questions you want to own; record who gets cited. Tedious, directional, and still the only way to observe the answer surface itself.
Treat all three as directional. Anyone selling you a precise "GEO score" is selling you a number they invented.
What we'd actually do first
Ordered by yield, not by how good it looks in a deck:
- 1.
curl -A the retrieval bots against production. If the edge is blocking them, nothing else on this list matters. - 2.
curl | grep your key claims. Move anything JavaScript-only into served HTML. - 3. Rewrite the first sentence under each heading to be the answer, with explicit subjects.
- 4. Make FAQ text and FAQ schema identical, and delete any schema you can't back with visible text.
- 5. Reconcile facts that contradict each other across pages, docs, and
llms.txt. - 6. Then — and only then — go earn off-site corroboration.
Steps 1 and 2 are usually where the missing citations are hiding. They're also the two that nobody writes posts about, because they aren't content marketing.
Wrapping up
Getting cited by ChatGPT is less mysterious than the acronym around it suggests. Be reachable by the retrieval bot. Be readable without JavaScript. Be quotable in one self-contained sentence. Be consistent across your own surfaces. Be corroborated somewhere that isn't your marketing site. The tooling churns; those five hold.
We run these checks on our own site, and we built them into an Orkas workflow that audits a site's search and AI answer visibility and hands back a prioritized fix list. If you want the layer underneath — how a lead agent plans work and dispatches specialists to do it — read multi-agent orchestration in practice.
"Como eu sou citado pelo ChatGPT?" costuma ser respondido com uma lista: escreva bom conteúdo, adicione schema, crie um llms.txt. O problema desse conselho não é estar errado, e sim mirar na camada errada. Ele descreve como uma página deve parecer e pula as duas perguntas que de fato decidem o resultado: o sistema de recuperação consegue alcançar sua página? e existe nela um trecho que sobrevive a ser arrancado do contexto?
Este post é o mecanismo, na ordem em que ele realmente roda. Aplicamos essas verificações no nosso próprio site, e algumas delas revelaram problemas que nenhum trabalho de conteúdo teria resolvido.
Citação é um problema de recuperação, não de ranking
Quando o ChatGPT responde com links, ele não está lendo a web ao vivo a cada pergunta. Uma etapa de recuperação puxa trechos candidatos de um índice; o modelo compõe a resposta com o que voltou e atribui as partes em que se apoiou. Daí saem duas consequências, ambas contraintuitivas para quem vem do SEO clássico:
- A unidade é o trecho, não a página. Uma página pode ranquear bem e não contribuir com nada, porque o fato que valeria citar está em uma imagem, em um gráfico sem equivalente textual, ou em um parágrafo que só existe depois que o JavaScript roda.
- Recuperável e citável são níveis diferentes. Estar no índice é pré-condição. Ser a frase mais limpa disponível sobre a pergunta é o que gera a atribuição. A maioria dos checklists de GEO só trata do primeiro e depois estranha o tráfego não se mexer.
Ranking e citação se separam na prática. Você pode estar na terceira posição de uma palavra-chave e nunca ser citado, porque as duas páginas acima afirmam a resposta em uma frase autossuficiente e você enterrou a sua no quarto parágrafo de uma seção chamada "Nossa Filosofia".
Três bots, três trabalhos diferentes
É aqui que se cometem os erros mais caros, porque as pessoas raciocinam sobre "o crawler da OpenAI" como se fosse uma coisa só. A OpenAI documenta três agentes separados, e eles não fazem o mesmo trabalho:
- GPTBot — rastreamento em massa para treinamento de modelos. Bloqueá-lo muda o que modelos futuros absorvem do seu site. Não remove você das citações ao vivo do ChatGPT.
- OAI-SearchBot — constrói o índice de busca que a recuperação lê. É este que decide se você pode ser citado.
- ChatGPT-User — busca uma URL específica quando a pergunta de um usuário dispara uma navegação ao vivo. Bloqueie-o e a busca falha exatamente no momento em que alguém pergunta sobre você.
A falha comum: um time decide que não quer seu conteúdo treinando modelos, bloqueia o GPTBot e acredita ter tomado uma decisão ponderada. Tomou — sobre treinamento. Não disse nada sobre recuperação. A versão pior: alguém bloqueia todos os agentes da OpenAI com uma regra curinga e apaga silenciosamente a empresa das respostas de IA, e então passa um trimestre se perguntando por que os concorrentes são citados.
São escolhas separáveis, então faça-as separadamente. Nosso robots.txt permite os três e bloqueia /api/ e links de compartilhamento, porque links de compartilhamento são conteúdo de usuário e não têm o que fazer em um índice. O seu pode ser diferente — treinamento e recuperação são barganhas genuinamente distintas. Só decida por bot, não por fornecedor, e releia a documentação do fornecedor de vez em quando, porque essas políticas mudam.
robots.txt não é a porta que realmente te barra
Robots é um pedido, e é a camada que todo mundo inspeciona. A camada que realmente morde é seu CDN ou WAF. Plataformas de edge desafiam ou bloqueiam user agents desconhecidos em várias configurações padrão, e o resultado é silencioso: o robots.txt diz Allow, o edge devolve 403, e você é irrastreável enquanto todos os arquivos do seu repositório insistem que está tudo aberto.
A verificação leva dez segundos e quase ninguém faz:
curl -s -o /dev/null -w "%{http_code}\n" -A "OAI-SearchBot" https://seu-site/
curl -s -o /dev/null -w "%{http_code}\n" -A "ChatGPT-User" https://seu-site/
curl -s -o /dev/null -w "%{http_code}\n" -A "PerplexityBot" https://seu-site/
200 significa alcançável. Um 403, um 503 ou uma página de desafio significa que você tem um problema de visibilidade que nenhum trabalho de conteúdo resolve. Rode contra produção, de fora da sua própria rede, para cada domínio que você opera — cada domínio costuma ter sua própria configuração de edge, e elas divergem com o tempo.
Se você fizer apenas uma coisa deste post, faça esta. É a verificação com maior retorno por segundo gasto, e é invisível para qualquer auditoria de conteúdo.
Se um fato precisa de JavaScript, ele não existe
Crawlers de recuperação normalmente leem HTML bruto sem executar JavaScript. Então o teste para saber se uma afirmação é citável não é o que seu navegador mostra — é este:
curl -s https://seu-site/pagina/ | grep -i "a afirmação que você quer citada"
Nada na saída significa nada a citar. Isso tem uma consequência real de design: o texto crítico para citação — sua definição, fatos-chave, respostas de FAQ, afirmações de preço e segurança — precisa estar no HTML servido. Um dicionário em runtime que troca o texto depois da hidratação é ótimo como melhoria; não pode ser o único lugar onde o fato existe.
Isso morde mais forte em sites multilíngues, e é a armadilha que contornamos de propósito. Se sua versão em chinês só vive em um dicionário i18n de JavaScript, então para um crawler de HTML bruto seu conteúdo em chinês simplesmente não está lá. Nossa solução é embutir cada idioma como marcação real e deixar o CSS decidir qual um humano vê. Crawlers recebem os quatro idiomas; leitores recebem um. Custa peso de página e vale a pena.
Escreva trechos que sobrevivam a ser arrancados do contexto
Esta é a parte que é de fato escrita, e não encanamento, e é onde está a alavanca depois que o encanamento funciona.
Um trecho recuperado chega ao modelo sem a sua página em volta. Sem hierarquia de títulos, sem o parágrafo anterior, sem navegação. Escreva para isso:
- Responda primeiro. A primeira frase sob um título deve ser a resposta, não uma pista de decolagem. "X é Y" ganha de "No cenário atual em rápida evolução…" — que não responde nada e nunca é citado.
- Mantenha os sujeitos explícitos. "Ele suporta OAuth" é inútil depois de extraído; "O Orkas suporta OAuth" sobrevive. Pronomes morrem na fragmentação.
- Faça cada afirmação autossuficiente. Entidade, qualificador e limite em uma frase: "Com seu próprio provedor, o tráfego de modelo vai diretamente para esse provedor e não passa pelo Orkas como proxy." Essa frase pode ser citada sozinha sem virar mentira, e é exatamente por isso que ela é citável.
- Prefira verificável a impressionante. Superlativos vagos nunca são citados, porque não respondem a pergunta nenhuma.
A pergunta é a chave de recuperação
Usuários fazem perguntas, e a recuperação casa com texto em forma de pergunta. Um título que é a pergunta literal — "O Orkas faz proxy do tráfego de modelo?" — casa melhor do que um sintagma nominal como "Arquitetura de modelos". É por isso, e não por mágica de schema, que blocos de FAQ rendem tanto para visibilidade em IA: eles são literalmente pares pergunta-resposta, que é a forma daquilo que está sendo recuperado.
Dados estruturados tornam você analisável, não preferido
JSON-LD não compra citações. Compra classificação sem ambiguidade: o que é esta página, quem publicou, qual texto é pergunta e qual é a resposta. Duas regras importam mais que as outras:
- O schema de FAQ precisa bater com o texto visível um para um. Schema que afirma algo que a página não diz é um problema de confiança, e os buscadores tratam a divergência como sinal de spam, não como um deslize de formatação.
- Nunca fabrique avaliações, prêmios ou contagens. Um mecanismo que pega uma avaliação agregada inventada ganhou um motivo para descontar todo o resto que você afirma.
A regra 1:1 é do tipo que apodrece em silêncio — alguém edita o FAQ visível, esquece o schema, e seis meses depois eles se contradizem. Nós a garantimos com um teste que percorre todas as páginas do nosso sitemap, extrai o FAQ do JSON-LD e verifica que cada pergunta e resposta aparece literalmente no texto visível daquela página. Se divergir, o build quebra. Dados estruturados são uma afirmação sobre sua própria página; devem ser checados como tal.
llms.txt: barato, útil e supervalorizado
Seja honesto sobre o que é esse arquivo. llms.txt é uma convenção proposta. Nenhum mecanismo grande promete lê-lo, e quem lhe disser que é um canal de ingestão está chutando.
Para o que ele serve de verdade é mais estreito e ainda vale uma hora: um lugar estável onde seus fatos canônicos são declarados sem rodeios — o que é o produto, tratamento de modelo e dados, preços, as URLs que importam. Quando um crawler ou um pesquisador humano cai nele, recebe a versão sem verniz em vez de reconstruí-la a partir de páginas de marketing. Também é uma boa função forçante. Se você não consegue declarar os fatos do seu produto em quarenta linhas sem adjetivos, suas páginas também não conseguem, e esse é um problema de conteúdo que você já tinha.
O que ele não é: uma garantia, nem um substituto para esses fatos estarem nas próprias páginas.
Contradições fazem você ser descartado
Mecanismos de resposta fazem verificação cruzada. Se sua página de preços diz uma coisa, sua documentação diz outra e o FAQ da home diz uma terceira, o mecanismo não julga — ele hesita, ou cita alguém que foi consistente.
Então consistência factual entre superfícies é a maior parte do trabalho real, e nada disso é glamouroso. Quando um fato de modelo, preço ou segurança muda, ele precisa mudar em todo lugar na mesma alteração — página, documentação, FAQ da home, llms.txt — ou você fabricou uma contradição que vai sobreviver à edição. Tratamos isso como regra rígida, não como hábito, porque hábitos perdem para prazos.
Corroboração vence autoafirmação
Aqui está a parte mais difícil de aceitar: seu próprio site é a fonte mais fraca disponível sobre você. Mecanismos ponderam corroboração, e fazem bem. Uma afirmação que só aparece no seu domínio é uma afirmação de marketing. A mesma afirmação no GitHub, em uma comparação de terceiros, em um tópico de fórum, em documentação que outra pessoa escreveu, é um fato.
Por isso, uma vez que o básico on-site esteja realmente feito, o trabalho off-site rende mais que outra landing page — repositórios, diretórios, listas, discussão genuína. Dito sem rodeios: o trabalho on-site torna você citável; o off-site torna você citado. Times investem demais no primeiro de forma confiável, porque é a metade que controlam.
Como medir sem mentir para si mesmo
É aqui que textos sobre GEO costumam amolecer, então: você não consegue medir citações do ChatGPT de forma limpa. Não existe dashboard. O que você tem são três sinais imperfeitos:
- Logs de servidor. Procure por
OAI-SearchBot e ChatGPT-User. Frequência de rastreio e quais URLs são buscadas dizem se você está no índice e o que está sendo puxado ao vivo. É o sinal mais honesto que você possui. - Tráfego de referência do assistente. Real, mas parcial — muitas citações são lidas e nunca clicadas, o que é justamente o ponto de um mecanismo de resposta.
- Checagens manuais. Faça as dez perguntas que você quer dominar; registre quem é citado. Tedioso, direcional, e ainda assim o único jeito de observar a própria superfície de resposta.
Trate os três como direcionais. Quem lhe vender uma "pontuação de GEO" precisa está vendendo um número que inventou.
O que faríamos primeiro
Ordenado por retorno, não por como fica bonito em um slide:
- 1. Rode
curl -A com os bots de recuperação contra produção. Se o edge os bloqueia, nada mais nesta lista importa. - 2.
curl | grep nas suas afirmações-chave. Mova o que for só-JavaScript para o HTML servido. - 3. Reescreva a primeira frase sob cada título para ser a resposta, com sujeitos explícitos.
- 4. Deixe o texto do FAQ e o schema do FAQ idênticos, e apague qualquer schema que você não consiga sustentar com texto visível.
- 5. Reconcilie fatos que se contradizem entre páginas, documentação e
llms.txt. - 6. Então — e só então — vá conquistar corroboração off-site.
Os passos 1 e 2 são normalmente onde as citações que faltam estão escondidas. Também são os dois sobre os quais ninguém escreve posts, porque não são marketing de conteúdo.
Concluindo
Ser citado pelo ChatGPT é menos misterioso do que a sigla ao redor sugere. Seja alcançável pelo bot de recuperação. Seja legível sem JavaScript. Seja citável em uma frase autossuficiente. Seja consistente entre suas superfícies. Seja corroborado em algum lugar que não seja seu site de marketing. As ferramentas mudam; esses cinco permanecem.
Aplicamos essas verificações no nosso próprio site e as construímos em um fluxo do Orkas que audita a visibilidade em busca e em respostas de IA de um site e devolve uma lista priorizada de correções. Se quiser a camada de baixo — como um agente líder planeja o trabalho e despacha especialistas para executá-lo — leia orquestração multiagente na prática.
「怎么才能被 ChatGPT 引用？」这个问题通常会得到一份清单式的回答：写好内容、加结构化数据、做一个 llms.txt。这些建议与其说是错的，不如说打错了层。它描述的是一个页面应该长什么样，却跳过了真正决定结果的两个问题：检索系统到底够不够得着你的页面，以及页面上有没有哪一段话，被从上下文里揪出来之后还站得住。
这篇讲的是机制，按它实际运行的顺序讲。这些检查我们在自己站上跑，其中有两条帮我们发现了再多内容功夫也补不上的问题。
引用是检索问题，不是排名问题
ChatGPT 带链接回答时，并不是每个问题都去实时读一遍网络。一个检索步骤先从索引里捞出候选段落；模型再用捞回来的东西组织答案，并给它真正倚重的那部分标上出处。由此推出两条结论，对做惯了传统 SEO 的人来说都不太直觉：
- 单位是段落，不是页面。一个页面可以排得很好却毫无贡献——因为那个值得被引用的事实，藏在一张图里、一张没有文字等价物的图表里，或者一段要等 JavaScript 跑完才存在的文字里。
- 能被检索到和值得被引用，是两道不同的门槛。进索引只是前提。成为关于这个问题「现有最干净的那句话」，才是拿到出处标注的原因。大多数 GEO 清单只处理了第一道，然后困惑于流量为什么没动。
排名和引用在实践中是会分开的。你可以稳坐某个词的第三位却从没被引用过，因为你上面那两个页面恰好用一句自足的话把答案说清楚了，而你把答案埋在一个叫「我们的理念」的小节的第四段里。
三个爬虫，三份不同的工作
最贵的错误就发生在这里，因为人们把「OpenAI 的爬虫」当成一个东西来想。OpenAI 文档里写明的是三个独立的 agent，它们做的不是同一份工作：
- GPTBot——为模型训练做的大规模抓取。挡掉它，改变的是未来的模型从你站上吸收了什么。它不会把你从 ChatGPT 的实时引用里拿掉。
- OAI-SearchBot——构建检索所读的那个搜索索引。决定你到底能不能被引用的，是这一个。
- ChatGPT-User——当用户的问题触发实时浏览时，去抓取某个具体 URL。挡掉它，抓取就恰好失败在有人正在问起你的那一刻。
常见的翻车是这样的：一个团队决定不希望自己的内容被拿去训练模型，于是挡掉 GPTBot，并且认为自己做了个深思熟虑的决定。确实做了——关于训练的。关于检索，他们什么都没说。更糟的版本是：有人用一条通配规则挡掉所有 OpenAI 的 agent，悄无声息地把公司从 AI 答案里删了，然后花一个季度纳闷为什么被引用的都是竞争对手。
这些是可以分开的选择，那就分开做。我们自己的 robots.txt 三个都放行，只挡掉 /api/ 和分享链接——分享链接是用户内容，本来就不该进索引。你的选择可以不一样：训练和检索是两笔性质确实不同的交易。只是要按爬虫决定，而不是按厂商决定，并且隔一阵子重读一遍厂商文档，因为这些策略是会变的。
真正卡住你的那道门，不是 robots.txt
robots 是一个请求，也是所有人都会去检查的那一层。真正咬人的是你的 CDN 或 WAF。在不少默认配置下，边缘平台会对不认识的 user agent 做挑战或直接拦截，而结果是无声的：robots.txt 上写着 Allow，边缘返回 403，于是你实际上无法被抓取，而你仓库里的每一个文件都在坚称大门敞开。
这个检查花十秒钟，却几乎没人做：
curl -s -o /dev/null -w "%{http_code}\n" -A "OAI-SearchBot" https://your-site/
curl -s -o /dev/null -w "%{http_code}\n" -A "ChatGPT-User" https://your-site/
curl -s -o /dev/null -w "%{http_code}\n" -A "PerplexityBot" https://your-site/
200 表示够得着。返回 403、503 或者一个挑战页，就意味着你有一个内容功夫永远补不上的可见性问题。要打到生产环境、从你自己网络之外打、并且每个域名都打一遍——每个域名通常有各自的边缘配置，而它们会随时间跑偏。
如果这篇文章你只做一件事，就做这件。它是单位时间回报最高的检查，而且对任何内容审计都是隐形的。
如果一个事实需要 JavaScript 才出现，它就不存在
检索爬虫通常只解析原始 HTML，不执行 JavaScript。所以判断一条主张能不能被引用，标准不是你浏览器里看到什么，而是这个：
curl -s https://your-site/page/ | grep -i "你希望被引用的那句话"
输出里没有，就等于没有东西可引。这有一个实打实的设计后果：对引用关键的文字——你的定义、关键事实、FAQ 答案、价格与安全主张——必须在服务端返回的 HTML 里。一个在 hydration 之后替换文案的运行时字典，作为增强很好；但它不能是这个事实唯一存在的地方。
这一点在多语言站上咬得最狠，也正是我们刻意绕开的坑。如果你的中文文案只活在一个 JavaScript 的 i18n 字典里，那么对一个读原始 HTML 的爬虫来说，你的中文内容压根不存在。我们的做法是把每种语言都内联成真实标记，再让 CSS 决定人类看到哪一种。爬虫拿到四种语言，读者拿到一种。代价是页面体积，值得。
把话写成能被整段揪走还站得住的样子
这部分才是真正在「写」，而不是在搭管道；管道通了之后，杠杆就在这里。
一个被检索出来的片段，抵达模型时是不带你页面的。没有标题层级、没有上一段、没有导航。就照这个前提去写：
- 先给答案。标题下的第一句话应该是答案，不是跑道。「X 是 Y」胜过「在当今快速演进的格局中……」——后者什么都没回答，也永远不会被引用。
- 主语要写出来。「它支持 OAuth」被摘出去之后没法用；「Orkas 支持 OAuth」能活下来。代词会死在切片里。
- 每条主张都要自足。实体、限定条件、边界，都在一句话里：「使用自己的供应商时，模型流量直接发往该供应商，不经 Orkas 代理。」这句话单独被引用也不会变成假话——这正是它可被引用的原因。
- 宁可可核实，不要显得漂亮。含混的最高级从不会被引用，因为它们没有回答任何人问过的问题。
问题本身就是检索的钥匙
用户是在提问，而检索匹配的是长得像问题的文本。一个直接就是那句问题的标题——「Orkas 会代理模型流量吗？」——比「模型架构」这种名词短语匹配得更好。FAQ 区块对 AI 可见性的收益之所以远超其体量，靠的是这个，而不是什么结构化数据的魔法：它们本身就是一问一答，而这正是被检索的那个东西的形状。
结构化数据让你可解析，不是让你被偏爱
JSON-LD 买不到引用。它买到的是无歧义的分类：这个页面是什么、谁发布的、哪段文字是问题、哪段是它的答案。有两条规则比其余的都重要：
- FAQ 结构化数据必须和可见文本逐字对应。结构化数据声称了页面没说的话，这是个信任问题；搜索引擎会把这种不一致当作垃圾信号，而不是排版失误。
- 永远不要伪造评分、奖项或数量。一个引擎抓到你编造了一个聚合评分，它就有了理由把你说的其他一切都打折。
1:1 这条规则属于会悄悄腐烂的那类——有人改了可见 FAQ、忘了改结构化数据，半年后两者开始互相矛盾。我们用一个测试来强制它：遍历 sitemap 里的每一个页面，从 JSON-LD 里取出 FAQ，断言每一条问题和答案都逐字出现在该页的可见文本里。一旦漂移，构建就挂。结构化数据是你对自己页面下的一个断言，就该按断言来检验。
llms.txt：便宜、有用，且被吹过头了
对这个文件要诚实。llms.txt 是一个提案性质的约定。没有哪个主流引擎承诺会读它，谁告诉你这是一条摄入通道，谁就是在猜。
它真正的用处更窄，但仍然值那一个小时：一个稳定的地方，把你的规范事实平铺直叙地讲清楚——产品是什么、模型与数据怎么处理、价格、真正重要的那些 URL。当爬虫或者真人研究者确实落到这个文件上时，他拿到的是没有话术的版本，而不用从营销页面里去拼。它同时是个不错的倒逼机制：如果你没法用四十行、不带形容词地把产品事实讲清楚，那你的页面也做不到——而这本来就是你早晚要面对的内容问题。
它不是什么：不是保证，也不能替代这些事实出现在页面本身上。
自相矛盾会让你被丢掉
答案引擎会交叉核对。如果你的价格页说一套、文档说另一套、首页 FAQ 说第三套，引擎不会替你裁决——它要么含糊其辞，要么去引用一个前后一致的人。
所以跨页面的事实一致性是真正工作量的大头，而且一点都不光鲜。当一个模型、价格或安全事实变了，它必须在同一次改动里到处都改——页面、文档、首页 FAQ、llms.txt——否则你就制造了一个比这次改动活得更久的矛盾。我们把这条当硬规则而不是习惯来执行，因为习惯是打不过 deadline 的。
外部佐证胜过自我声明
下面是最难接受的一点：关于你自己，你自己的站是现有最弱的信源。引擎会给佐证加权，而且这么做是对的。只出现在你自己域名上的主张，是营销话术；同一条主张出现在 GitHub 上、第三方对比里、论坛帖子里、别人写的文档里，就是事实。
所以一旦站内基本功真的做扎实了，站外的功夫就比再建一个落地页更划算——仓库、目录站、榜单、真实的讨论。说白了：站内功夫让你可被引用，站外功夫让你被引用。团队总是稳定地在前者上投入过度，因为那是他们能控制的那一半。
怎么衡量，而不自欺
GEO 类文章通常在这里开始发虚，所以直说：ChatGPT 的引用你没法干净地衡量。没有仪表盘。你手上只有三个不完美的信号：
- 服务器日志。去 grep
OAI-SearchBot 和 ChatGPT-User。抓取频率、以及哪些 URL 被抓，会告诉你是否在索引里、以及什么正在被实时拉取。这是你拥有的最诚实的信号。 - 来自助手的引荐流量。真实，但只是一部分——大量引用被读到却从没被点击，而这恰恰就是答案引擎的意义所在。
- 人工抽查。把你想拿下的十个问题挨个问一遍，记录谁被引用了。笨、只能看方向，但仍然是唯一能观察到答案界面本身的办法。
这三个都只当方向看。任何人卖给你一个精确的「GEO 分数」，卖的都是他自己编出来的数字。
换我们会先做什么
按回报排序，不是按它在 PPT 里好不好看：
- 1. 用
curl -A 拿检索爬虫打生产环境。如果边缘在拦它们，这份清单上其他事都不重要。 - 2. 用
curl | grep 检查你的关键主张。把任何只靠 JavaScript 才出现的内容，挪进服务端返回的 HTML。 - 3. 把每个标题下的第一句话改写成答案，主语写出来。
- 4. 让 FAQ 文本和 FAQ 结构化数据完全一致；任何拿不出可见文本支撑的结构化数据，删掉。
- 5. 把页面、文档、
llms.txt 之间互相打架的事实对齐。 - 6. 然后——也只有到这时——再去挣站外的佐证。
第 1 步和第 2 步通常就是那些消失的引用藏身的地方。它们也是没人写文章讲的两步，因为它们不是内容营销。
收尾
被 ChatGPT 引用，没有它周围那个缩写听起来那么神秘。让检索爬虫够得着你。不靠 JavaScript 也能读到你。用一句自足的话就能引用你。你自己的各个界面之间不打架。在你的营销站之外的某个地方，有人替你佐证。工具会换来换去；这五条不会。
这些检查我们在自己站上跑，也把它们做进了 Orkas 的一个工作流里——它会审计一个站点的搜索与 AI 答案可见性，并给回一份按优先级排好的修复清单。想看这底下那一层——主 agent 怎么规划工作、怎么派遣专才去干——去读多 Agent 编排实战。
「どうすれば ChatGPT に引用されるのか」という問いには、たいていリスト形式の答えが返ってきます。良いコンテンツを書く、スキーマを足す、llms.txt を置く。この助言は間違っているというより、狙う層がずれています。ページがどう見えるべきかを語り、結果を実際に決める二つの問いを飛ばしているのです。検索システムはそもそもあなたのページに到達できるのか、そして文脈から引きちぎられても成立する一節がそこにあるのか。
この記事は、その仕組みを実際に動く順番で説明します。これらの確認は自社サイトで実行しており、そのうちいくつかは、どれだけコンテンツを磨いても直らなかった問題を見つけてくれました。
引用はランキングではなく、リトリーバルの問題
ChatGPT がリンク付きで答えるとき、質問ごとにウェブをその場で読んでいるわけではありません。リトリーバルの段階がインデックスから候補となる一節を引き出し、モデルは返ってきたものから答えを組み立て、寄りかかった部分に出典を付けます。ここから二つの帰結が出てきます。どちらも従来の SEO の感覚では直感に反します。
- 単位はページではなく一節です。ページの順位が良くても貢献ゼロということがあります。引用に値する事実が画像の中、テキスト等価物のない図表の中、あるいは JavaScript の実行後にしか存在しない段落の中にあるからです。
- 取得できることと引用できることは別の水準です。インデックスにあるのは前提条件にすぎません。その問いについて「今ある中で最も明快な一文」であることが、出典を勝ち取ります。多くの GEO チェックリストは前者しか扱わず、そのあとで流入が動かないことに首をかしげます。
ランキングと引用は実際に乖離します。あるキーワードで 3 位にいながら一度も引用されないことはあり得ます。上の 2 ページがたまたま答えを自己完結した一文で述べていて、あなたは「私たちの理念」という見出しの 4 段落目に答えを埋めているからです。
三つのボット、三つの異なる仕事
最も高くつく間違いはここで起きます。「OpenAI のクローラー」を一つのものとして考えてしまうからです。OpenAI は三つの別々のエージェントを文書化しており、それらは同じ仕事をしていません。
- GPTBot — モデル学習のための大規模クロール。ブロックすると、将来のモデルがあなたのサイトから何を吸収するかが変わります。ChatGPT のライブな引用からあなたを外すことはありません。
- OAI-SearchBot — リトリーバルが読む検索インデックスを構築します。そもそも引用され得るかを決めているのはこれです。
- ChatGPT-User — ユーザーの質問がライブ閲覧を引き起こしたときに、特定の URL を取得します。これをブロックすると、誰かがあなたについて尋ねたまさにその瞬間に取得が失敗します。
よくある失敗はこうです。あるチームが自社コンテンツをモデル学習に使われたくないと判断し、GPTBot をブロックし、熟慮した決定をしたと信じます。確かにしました — 学習について。リトリーバルについては何も言っていません。さらに悪い版はこうです。誰かがワイルドカード一行で OpenAI のエージェントを全部ブロックし、会社を AI の回答から静かに消し去り、そのあと一四半期かけて、なぜ競合ばかり引用されるのかと悩みます。
これらは分離できる選択なので、分けて決めてください。私たちの robots.txt は三つとも許可し、/api/ と共有リンクをブロックしています。共有リンクはユーザーのコンテンツで、インデックスに載る筋合いがないからです。あなたの判断は違ってよいのです。学習とリトリーバルは本当に別の取引です。ただしベンダー単位ではなくボット単位で決め、ベンダーのドキュメントをときどき読み直してください。これらの方針は動きます。
実際にあなたを止めている門は robots.txt ではない
robots はお願いであり、誰もが確認する層です。実際に噛みついてくるのは CDN や WAF です。エッジのプラットフォームは、多くの既定設定で見慣れない user agent にチャレンジをかけたりブロックしたりします。しかもその結果は静かです。robots.txt には Allow と書いてあり、エッジは 403 を返し、リポジトリの全ファイルが「うちは開いています」と言い張る一方で、あなたはクロール不能になっています。
この確認は十秒で終わりますが、ほとんど誰もやりません。
curl -s -o /dev/null -w "%{http_code}\n" -A "OAI-SearchBot" https://your-site/
curl -s -o /dev/null -w "%{http_code}\n" -A "ChatGPT-User" https://your-site/
curl -s -o /dev/null -w "%{http_code}\n" -A "PerplexityBot" https://your-site/
200 なら到達可能です。403、503、あるいはチャレンジページが返るなら、どれだけコンテンツを直しても解決しない可視性の問題を抱えています。本番に対して、自社ネットワークの外から、運用するドメインごとに実行してください。ドメインごとにエッジ設定は別々で、時間とともにずれていきます。
この記事から一つだけ実行するなら、これにしてください。費やす秒あたりの利回りが最も高い確認であり、どんなコンテンツ監査からも見えません。
事実に JavaScript が必要なら、その事実は存在しない
リトリーバルのクローラーは通常、JavaScript を実行せず生の HTML を解析します。したがって、ある主張が引用可能かどうかの判定はブラウザの表示ではなく、これです。
curl -s https://your-site/page/ | grep -i "引用してほしい主張"
出力に無ければ、引用するものは無いということです。ここには実際の設計上の帰結があります。引用に不可欠なテキスト — 定義、主要な事実、FAQ の回答、価格とセキュリティの主張 — は配信される HTML の中になければなりません。ハイドレーション後にテキストを差し替えるランタイムの辞書は、拡張としては結構です。ただし、その事実が存在する唯一の場所であってはいけません。
これは多言語サイトで最も強く噛みつきます。私たちが意図的に回避した罠でもあります。中国語のコピーが JavaScript の i18n 辞書にしか存在しないなら、生の HTML を読むクローラーにとって、あなたの中国語コンテンツは無いのと同じです。私たちの解法は、各言語を実際のマークアップとして埋め込み、人間がどれを見るかは CSS に決めさせることです。クローラーは四言語すべてを受け取り、読者は一つを受け取ります。ページ重量を払う価値はあります。
文脈から引きちぎられても生き残る一節を書く
ここが配管ではなく実際の「執筆」であり、配管が通ったあとのレバレッジはここにあります。
取得された断片は、あなたのページを伴わずにモデルへ届きます。見出しの階層も、前の段落も、ナビゲーションもありません。それを前提に書いてください。
- まず答える。見出しの下の最初の一文は、助走ではなく答えであるべきです。「X は Y です」は「今日の急速に変化する状況において……」に勝ちます。後者は何も答えず、決して引用されません。
- 主語を明示する。「それは OAuth に対応しています」は抜き出された瞬間に使えません。「Orkas は OAuth に対応しています」は生き残ります。代名詞はチャンク化で死にます。
- 各主張を自己完結させる。実体、限定、境界を一文に。「自分のプロバイダーを使う場合、モデル通信はそのプロバイダーへ直接送られ、Orkas を経由しません。」この一文は単独で引用されても嘘になりません。だからこそ引用に耐えます。
- 見栄えより検証可能性。曖昧な最上級は決して引用されません。誰も尋ねていない問いにしか答えていないからです。
問いこそがリトリーバルの鍵
ユーザーは問いを立て、リトリーバルは問いの形をしたテキストに一致します。文字どおりその問いである見出し — 「Orkas はモデル通信をプロキシしますか？」 — は、「モデルアーキテクチャ」のような名詞句より良く一致します。FAQ ブロックが AI 可視性において体格以上の働きをするのは、スキーマの魔法ではなくこれが理由です。FAQ は文字どおり問いと答えの対であり、それこそが取得される対象の形だからです。
構造化データは解析可能にするが、優遇はしない
JSON-LD は引用を買えません。買えるのは曖昧さのない分類です。このページが何で、誰が公開し、どのテキストが問いでどれがその答えか。他より重要な規則が二つあります。
- FAQ スキーマは可視テキストと一対一で一致すること。ページが言っていないことをスキーマが主張するのは信頼の問題であり、検索エンジンはその不一致を書式の不手際ではなくスパムの兆候として扱います。
- 評価、受賞、件数を捏造しないこと。捏造された集計評価を一つ見つけたエンジンは、あなたの他の主張すべてを割り引く理由を手に入れます。
この一対一の規則は静かに腐る類のものです。誰かが可視 FAQ を編集し、スキーマを忘れ、半年後に両者が食い違います。私たちはテストで強制しています。サイトマップ上の全ページを巡回し、JSON-LD から FAQ を取り出し、各問いと各答えの文字列がそのページの可視テキストにそのまま現れることを検証します。ずれればビルドが落ちます。構造化データは自分のページに関する主張です。主張として検証されるべきです。
llms.txt：安価で、有用で、そして過大評価されている
このファイルについては正直でいましょう。llms.txt は提案段階の慣習です。主要なエンジンで読むと約束しているものはなく、これが取り込み経路だと言う人は推測で話しています。
実際の用途はもっと狭く、それでも一時間の価値はあります。正規の事実を飾らずに述べた、安定した一箇所 — 製品が何であるか、モデルとデータの扱い、価格、重要な URL。クローラーや人間の調査者がそこに辿り着いたとき、マーケティングページから再構成する代わりに、粉飾のない版を得られます。良い強制関数でもあります。製品の事実を形容詞なしの四十行で述べられないなら、ページでも述べられません。それは元から抱えていたコンテンツの問題です。
そうでないもの：保証ではなく、事実がページ自体に載っていることの代替でもありません。
矛盾していると外される
回答エンジンは相互検証します。価格ページが一つのことを言い、ドキュメントが別のことを言い、トップページの FAQ が三つ目のことを言えば、エンジンは裁定しません。曖昧にするか、一貫していた誰かを引用します。
ですから面をまたいだ事実の一貫性が実作業の大半であり、どれも華やかではありません。モデル、価格、セキュリティの事実が変わったら、同じ変更の中ですべての場所 — ページ、ドキュメント、トップの FAQ、llms.txt — を変えなければ、その編集より長生きする矛盾を製造したことになります。私たちはこれを習慣ではなく硬い規則として扱います。習慣は締切に負けるからです。
裏付けは自己申告に勝る
最も受け入れがたい点がこれです。あなた自身について、あなたのサイトは最も弱い情報源です。エンジンは裏付けに重みを置きます。それは正しい判断です。自分のドメインにしかない主張はマーケティングの主張です。同じ主張が GitHub に、第三者の比較記事に、フォーラムのスレッドに、誰かが書いたドキュメントにあれば、それは事実です。
だからこそ、サイト内の基礎が本当にできあがったあとは、サイト外の仕事がもう一枚のランディングページより効きます。リポジトリ、ディレクトリ、まとめ記事、本物の議論。身も蓋もなく言えば、サイト内の仕事はあなたを引用可能にし、サイト外の仕事はあなたを引用される状態にします。チームは前者に過剰投資しがちです。自分で制御できる半分だからです。
自分を欺かずに測る方法
GEO の文章はたいていここで緩むので、はっきり言います。ChatGPT の引用はきれいには測れません。ダッシュボードは存在しません。手元にあるのは三つの不完全な信号です。
- サーバーログ。
OAI-SearchBot と ChatGPT-User を grep してください。クロール頻度とどの URL が取得されたかが、インデックスに入っているか、何がライブで引かれているかを教えます。あなたが所有する最も正直な信号です。 - アシスタントからの参照トラフィック。本物ですが部分的です。多くの引用は読まれてもクリックされません。それこそが回答エンジンの本質です。
- 手動の抜き取り確認。取りたい十個の問いを尋ね、誰が引用されるか記録します。地味で、方向性しか分かりませんが、回答面そのものを観察できる唯一の方法です。
三つとも方向性として扱ってください。精密な「GEO スコア」を売る人は、自分で作った数字を売っています。
私たちなら最初に何をするか
スライド映えではなく、利回り順です。
- 1. リトリーバルのボットで本番に
curl -A をかける。エッジがブロックしているなら、このリストの他は無意味です。 - 2. 主要な主張を
curl | grep する。JavaScript 依存のものは配信 HTML に移す。 - 3. 各見出しの下の最初の一文を、主語を明示した答えに書き直す。
- 4. FAQ のテキストと FAQ スキーマを一致させ、可視テキストで裏付けられないスキーマは削除する。
- 5. ページ、ドキュメント、
llms.txt の間で矛盾する事実を揃える。 - 6. そのあとで — そのあとでのみ — サイト外の裏付けを取りに行く。
失われた引用はたいてい 1 と 2 に隠れています。そしてこの二つは誰も記事にしません。コンテンツマーケティングではないからです。
まとめ
ChatGPT に引用されることは、まわりの略語が思わせるほど神秘的ではありません。リトリーバルのボットから到達可能であること。JavaScript なしで読めること。自己完結した一文で引用できること。自分の面どうしで矛盾しないこと。マーケティングサイト以外のどこかで裏付けられていること。ツールは移り変わりますが、この五つは変わりません。
これらの確認は自社サイトで実行し、Orkas のワークフローにも組み込みました。サイトの検索と AI 回答の可視性を監査し、優先順位付きの修正リストを返します。その下の層 — リードエージェントがどう作業を計画し、専門エージェントを派遣するか — を知りたければ、マルチ Agent 編成の実践をお読みください。
