How to Get Cited by ChatGPT: What Actually Decides Whether You Get Quoted

"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.