Grok and social sourcing: when posts become citations

The short answer: A post becomes a Grok citation when the model's X search tool retrieves it, which happens through a first-party pipe into X rather than through any crawler. Two separate source layers feed an answer: X posts, and ordinary web pages found by a web search tool. They behave differently, they are priced differently, and only one of them is an ordinary web page that an outside crawler can fetch.
That last point is the one most teams get wrong. A thread that Grok quotes back to you is not an asset you can count on reaching engines that have to crawl x.com to see it.
Two tools, two layers, one answer
xAI's developer documentation splits retrieval into named tools. One is web_search. The other is x_search. The model decides which to call, and it can call both inside a single answer, so the citation list you get back is usually a mix of article URLs and post URLs.
The parameters show what the X layer can actually do, as documented on 12 October 2026. x_search accepts allowed_x_handles and excluded_x_handles, each capped at 20 handles in the API and 10 through one SDK, plus from_date and to_date as plain YYYY-MM-DD bounds, plus flags that let the model look inside images and videos attached to posts. You cannot set an allow list and an exclude list in the same request. There is no engagement threshold in the documented parameter set, no follower floor, no verified-only switch.
Read that as a constraint, not a feature list. The handle filters exist because an application developer usually knows whose posts they want. A consumer question typed into Grok carries no such filter, so the retrieval is doing topical and semantic matching across posts, and whatever your account posted last week competes on the text of the post. That reading is an inference from the parameter list, not something xAI states.
The web layer is narrower than people expect. web_search takes allowed_domains and excluded_domains with a maximum of five domains each. That is a developer control, but the number is a useful hint about how tightly the tool is meant to be scoped.
The crawler asymmetry nobody puts on a slide
Here is the mechanism behind the difference, and it takes thirty seconds to verify yourself. Our method was simply to fetch two files and read them: one read of each on 8 October 2026, repeated on 12 October 2026, both times unchanged. That is a reading of two files on two days, not a survey of crawler behaviour.
Open https://x.com/robots.txt. On both dates that file carried a shared group for Googlebot and Bingbot, a group for facebookexternalhit, explicit Disallow: * blocks for Google-Extended, FacebookBot, Discordbot and four meta-* product tokens, and then this, applying to everything else that reads the file:
`` User-agent: * Disallow: / ``
No GPTBot. No ClaudeBot. No PerplexityBot. They are not blocked by name, they are blocked by the wildcard, which is the same outcome with less ceremony. Grok reaches the same posts through the documented x_search tool, which is an API call into X rather than a crawl, and a robots file governs crawlers that choose to read it.
So the asymmetry is structural. A post can be a citation inside Grok while being unreachable by crawling to any agent that reads that file and honours it, not because those agents dislike social content, but because the wildcard rule refuses them. Whether a given assistant sees your posts by some other route, a licensing deal or a third party quoting them, we cannot see from outside, and this file does not tell us. If x.com shows up rarely in another engine's source list, that rule is a plausible part of the reason rather than a proven one, and we have not measured the frequency. The rest of the picture sits in how each AI engine picks the sources it cites, and the contrast with an engine that leans on a conventional index is sharpest against how Google AI Overviews chooses its sources.
The reverse direction is worth checking too. https://grok.com/robots.txt on the same two dates allowed the general wildcard agent across most of the site, then listed GPTBot, ChatGPT-User, PerplexityBot, ClaudeBot, Google-Extended and Applebot-Extended together and cut them down to a handful of marketing pages with a trailing Disallow: /. Everyone is fencing their own yard.
What a citation in the list actually means
The citations documentation is unusually honest about something that breaks a lot of reporting. The citations array returns every URL the agent encountered, and the docs state plainly that not every URL in that list is referenced in the final answer. The agent may look at a source, decide it is not relevant enough, and the URL still appears for transparency.
If you are counting rows in that array and calling the total your citation count, you are counting things the model read and rejected. Inline citations are the stricter signal: those arrive as url_citation objects with start_index and end_index character offsets into the answer text, which means you can tell exactly which sentence a source was attached to. Two very different numbers, and only one of them is evidence.
There is also a cost signal that tells you something about retrieval volume. The X Search documentation, read on 12 October 2026, prices X retrieval at $5 per 1,000 posts fetched and $10 per 1,000 user profiles fetched, with the per-item pricing stated as in effect from 21 September 2026, and reports x_posts_fetched and x_users_fetched per request, un-deduplicated across searches. Posts are counted when threads are pulled in, including parents and quoted posts. Fetching a thread is not free, which is a reason to expect the retrieval to stay bounded rather than sweeping, though the documentation does not say how many posts a typical answer pulls and we cannot measure it from the consumer product.
Why engagement is the wrong target
Teams reach for the obvious lever: make the post perform, and it will get cited. The documented retrieval surface gives that no support. No engagement parameter is exposed, and the counting rules show that a post can be pulled in as part of a thread rather than on its own merits. How often that happens is not something the documentation reports, and we have not been able to measure it.
What does travel is the text. A post that states a claim in full, with the entity named and the number present, can be lifted into an answer intact. A post that says "we just published something big, link in replies" cannot, because the useful sentence lives on the other side of a click the retrieval may never make. That is the same discipline that decides whether a page gets used, and the same reason transcripts matter in YouTube, transcripts and video citations.
One more thing that follows from the handle filters. Named accounts are addressable in a way that anonymous commentary is not. If your company posts under a handle that matches your organisation name on your own site and in your schema, an engine resolving the entity has less work to do. If your staff post under handles that connect to nothing, that signal is wasted.
How to check this on your own brand
Nothing here needs tooling. Run the same question five times in Grok, on different days, and record for each run whether an x.com URL appeared at all, whether it was yours, and whether the sentence attached to it was correct. Then run the identical question in an engine that has no X access and compare the source mix. The gap between those two lists is your social exposure, and it is the part of your visibility that lives on one engine only.
If the X citations vanish one week, treat it as a retrieval question before a content question: date bounds, deleted or protected posts, an account rename that broke every permalink. The general method for that is in diagnosing a drop in AI citations.
The self-check has ten of these tests written out, including the robots file reading that starts this section, and none of them need a subscription.
Honest limits
We do not know how xAI ranks candidate posts. The documented parameters are filters, not the ranking function, and no public description of that function exists. We also cannot say how far back the X layer reaches in practice, because from_date and to_date bound a request without revealing coverage.
Two further limits are worth stating plainly. The robots evidence here is two file reads on two days in October 2026, so it describes what those files said then, not a measured account of which assistants fetch x.com or by what other arrangements they might obtain posts. And the pricing and parameter facts are taken from xAI's own documentation, which describes the API surface available to developers; we have not verified that the consumer Grok product retrieves on exactly the same terms.
And we have not found a reliable way to attribute business outcomes to a Grok citation in the client analytics we have looked at, where referrers from these surfaces are sparse to the point of being unusable. That is what we have seen in our own work, not a claim about how referrers behave on every setup.
FAQ
Does posting more on X increase Grok citations? Volume alone is weak. The documented retrieval exposes handle and date filters, not engagement thresholds, so a small number of clear, self-contained, claim-complete posts is a better bet than frequency for its own sake.
Can other AI engines see my X posts? Not by crawling, on the evidence we can see. The robots file at x.com, read on 8 and 12 October 2026, blocks the general wildcard agent and names several AI-related agents explicitly, so a crawler that honours it will not fetch your posts. Other routes, such as someone quoting you on an open page, remain open, and we cannot see what licensing arrangements exist.
Is a Grok citation worth as much as a web citation? It is worth something different. A web page you own can be cited by more than one engine and stays under your control. An X post is retrieved through a first-party tool, and disappears from the record if the account or post goes away.
Should we delete old posts to clean up what Grok sees? Rarely. Deleting removes the post from retrieval, but it also removes any correct claim it carried, and the incorrect third-party post that worried you stays exactly where it was. Correcting in public usually beats deleting in private.
Sources
All seven sources below were opened and re-read on 12 October 2026.
- xAI developer documentation, X Search tool parameters and pricing: docs.x.ai/developers/tools/x-search
- xAI developer documentation, Web Search tool parameters: docs.x.ai/developers/tools/web-search
- xAI developer documentation, Citations: docs.x.ai/developers/tools/citations
- xAI developer documentation, Tools overview: docs.x.ai/developers/tools/overview
- X robots exclusion file, read directly on 8 and 12 October 2026: x.com/robots.txt
- Grok robots exclusion file, read directly on 8 and 12 October 2026: grok.com/robots.txt
- RFC 9309, Robots Exclusion Protocol: www.rfc-editor.org/rfc/rfc9309.html