Being visible in ChatGPT search.
ChatGPT’s search mode pulls sources from the web in real time while composing an answer, and mentions the pages it used inside the answer.
ChatGPT works in two different ways, and confusing them leads to a common misunderstanding. When the model answers from its own training data, that data is a fixed corpus collected up to a certain date — your site either entered it or it did not, and you cannot intervene afterwards. Search mode is different: at the moment the question is asked it goes out to the web, fetches pages, and composes an answer from what it reads.
Answer engine optimization targets the second. Entering the training data can be neither planned nor measured; being visible in search mode is something you can directly influence, because its mechanism resembles classic crawling.
Which crawler does what
OpenAI runs different crawlers for different jobs, and robots.txt can address them separately. Knowing the distinction lets you see which decision affects what.
- GPTBot — collects content for model training. Blocking it means your site does not enter future training data.
- OAI-SearchBot — crawls for the search index. Block this and you cannot appear in search mode.
- ChatGPT-User — fetches on demand when a user opens a link or asks about a specific page.
The distinction produces a real decision point in practice: a publisher who does not want to contribute to training data but does want search-mode visibility can block GPTBot while allowing OAI-SearchBot. Treating the two as one and the same means shutting down visibility without realizing it.
On this site the decision went toward maximum visibility: all three agents are explicitly welcomed. A general allow rule already covered them, but writing the groups out one by one both documents the intent and keeps a place ready should one bot ever need restricting.
What search mode prefers
The exact formula of source selection is not published, but observed behavior shows a few tendencies, and they largely overlap with the other answer engines.
Pages that answer directly are preferred. A section that answers a question without a detour or a long introduction stands out over a page that delivers the same information at the end.
Concreteness carries weight. Passages with numbers, dates, measurements and step lists are cited more often than general statements. This is about verifiability: a model can check a concrete claim against other sources; it cannot check a vague one.
Freshness is decisive in fast-moving fields. On topics like prices, versions and regulation, a page with no visible date falls behind. That is why having the publication and update dates both on screen and in machine-readable form matters.
And technical accessibility: if the HTML coming from the server carries no content, the crawler sees an empty shell. Content that exists only client-side is, in search mode, most likely never read.
Content that renders only on the client is content that does not exist for an answer engine.
Measurement and verification
There are two ways to measure visibility, and both are manual. The first is direct testing: ask your target questions in search mode and record which sources get mentioned. The second is indirect but more reliable: look at your server logs to see which pages OAI-SearchBot fetches and how often.
Log reading is especially valuable because it shows behavior, not intent. If a crawler fetches your pages regularly, the access layer works; if it never comes, the problem is not the content but the access — and that must be fixed first.
- Filter the server logs by agent name — which pages, at what frequency, with which response code.
- Look separately at requests returning 404 and 5xx — if the crawler comes but the page is missing or erroring, this is where visibility is lost.
- Measure how quickly a newly published page gets fetched — crawl latency sets the tempo of your content strategy.
- List the pages never fetched — the cause may be missing internal links or a sitemap problem.
None of these measurements needs a special tool; a server log and simple filtering are enough. This is the most concrete data source for answer engine visibility, and most teams never look at it.
The training data debate
Whether to block GPTBot is as much a publishing policy decision as a technical one, and the right answer is not the same for everyone. Blocking keeps your content out of future model versions’ training data; allowing lets it in. Both positions have defensible reasons.
The case for blocking is usually copyright and reciprocity: the cost of producing the content is yours, and the model learning from it returns nothing to you directly. The case for allowing is visibility: the model knowing you comes back as brand mentions even without links, and in some fields being a reference source secures a long-term position.
On this site the decision went toward maximum visibility and is documented explicitly in robots.txt. It is a reversible decision — one line closes training permission while leaving search permission open, and citation is unaffected. What matters is that the decision was made deliberately.
A common misconception: registering
A frequent question is whether there is a way to “register” a site with ChatGPT. There is not. There is no counterpart to the webmaster tools of search engines, no registration panel; visibility depends entirely on crawlability and content.
That may look like a disadvantage, but it actually simplifies things: the to-do list gets shorter. Make sure the crawler can enter, make sure the content comes from the server, write sections that answer questions directly. All three are what classic SEO already asks for.
Another frequent question is whether content can be “taught” to the model. There is no direct channel — but there is an indirect one: the model finding and citing you regularly in search mode strengthens your position as a reference in that field. The way to teach, once again, runs through being visible.
Content form: what works
The content types regularly cited in search mode differ in part from what classic SEO rewards. Long, comprehensive guides are still valuable but no longer sufficient on their own; what decides is whether that guide contains sections that answer the question directly.
The best-performing forms are these: short pages defining a single concept, step-by-step procedures, and comparison tables. What the three share is that a model can lift a single section and use it without context. Long narrative content reads well but cites poorly.
The practical advice is to do both at once: write the deep guide, but keep every section within it complete on its own. A reader should be able to read it start to finish; a model should be able to take a section from the middle. The two do not conflict — they only demand discipline.