Does llms.txt Work? What a Live Implementation Revealed

A practical guide to llms.txt, page-level Markdown, AI crawler measurement, and the GEO evidence—built from a live implementation whose analytics could not observe the event it claimed to count.

llms.txt does not have a demonstrated ranking or citation benefit for open-web AI search. Google Search explicitly ignores it, and none of the other search providers reviewed for this article tells publishers that the file improves visibility.

It does have a smaller, implemented use after a client already knows the site. Maintained coding-agent instructions and tools use compact indexes, targeted Markdown pages, and—in narrower jobs—full-text dumps. If those files can be generated from content you already maintain, they are cheap options. They are not an audience-acquisition strategy.

Provider guidance and client examples in this article were checked on August 25, 2026.

Should you add llms.txt?

Situation Build now Do not infer
Personal blog Keep semantic HTML. Add a generated map and page Markdown only if maintenance is negligible. New readers, rankings, or citations.
Developer documentation Use a compact map plus targeted Markdown. Tell a known skill or client where to start, then test the task. Automatic adoption by every coding agent.
Large or versioned docs corpus Prefer index → page retrieval. Test a full dump separately for bounded migration or synthesis work. One representation winning every task.
Google AI visibility Prioritize crawlable, indexable HTML, internal links, original evidence, and Search Console. Any visibility benefit from llms.txt.

What llms.txt is—and what it is not

`llms.txt` is an open proposal, not a web standard or crawler directive. It describes a Markdown file at the root of a site: /llms.txt. The file gives an agent a compact, contextual map to useful resources.

It does not replace the existing web:

  • robots.txt expresses crawler access preferences. It is not a content map.
  • sitemap.xml enumerates canonical URLs for search crawling. It is not a curated context document.
  • llms.txt points a willing client toward selected resources after the client knows to ask for it.
  • Page-level Markdown is a cleaner representation of one selected page. It can exist at an explicit .md URL or behind HTTP content negotiation.
  • llms-full.txt concatenates a corpus for one-request or local-search workflows. It is a separate product choice, not a required default.

The proposal's current format requires only an H1. A useful file normally adds a short description and grouped links. This is the shape generated from the same metadata that builds gkoreli.com:

# gkoreli.com

> A personal publication by Goga Koreli — essays,
> engineering notes, and OSS Radar.

## Engineering

- [The Agentic Product Engineer](https://gkoreli.com/the-agentic-product-engineer.md):
  How software work changes when agents become part of the loop.

## Site indexes

- [Post Index](https://gkoreli.com/posts.json): Post metadata as JSON.

The exact live file is at `gkoreli.com/llms.txt`. It is longer because the blog currently generates one entry for every post.

Generate the map and alternate representations from the same canonical source. Do not create a second body of machine-only prose that can drift away from what people read. Validate every advertised URL during the build.

The August 2026 proposal also recommends advertising page Markdown and the covering index from HTML:

<link rel="alternate" type="text/markdown" href="/article.md">
<link rel="describedby" href="/llms.txt">

The same relations can be sent in an HTTP Link header. The client audit for this article did not find a mainstream client in the inspected set that follows these relations for llms.txt. Treat them as cheap, reversible proposal metadata—not as a ranking signal or proven interoperability layer.

Check delivery with:

curl -sS -D - https://example.com/llms.txt -o /dev/null
curl -sS -D - https://example.com/article.md -o /dev/null
curl -sS -D - -H 'Accept: text/markdown' https://example.com/article -o /dev/null

Check the status, redirects, content type, and content parity. If one canonical URL serves both HTML and Markdown, it also needs correct cache variation such as Vary: Accept. A successful response proves delivery by the server. It does not prove that the body entered a model context or changed an answer.

I built llms.txt for a blog nobody read

In March 2026, gkoreli.com had one article, 11 views, four visitors, and no referrers. The architecture decision record reduced the problem to one sentence: “The blog is invisible.”

The model I wrote down joined three stages into a loop:

  1. sitemaps and structured data would help discovery;
  2. llms.txt and Markdown would help agents consume the work;
  3. AI-agent tracking would show which agents read which pages.

Then I built the whole layer:

  • /llms.txt, a generated site map;
  • /llms-full.txt, every article concatenated into one file;
  • one .md endpoint per article;
  • /posts.json, a structured catalog;
  • static HTML, canonical URLs, sitemaps, and BlogPosting metadata;
  • an “AI Reads” number on the public analytics dashboard.

By late August, the public API showed 97 ai_fetches as of August 24. The blog still did not have the recurring audience I wanted, but the number appeared to establish that machines were reading it.

Then the collaborative audit reached the code that produced the number.

It was measuring another event.

“AI Reads” could not see direct resource requests

My application analytics does not record the original GET for an article, llms.txt, or a Markdown endpoint. An HTML page loads, runs an analytics script, and sends a later browser beacon. Abridged, the path looks like this:

fetch('/api/event', {
  method: 'POST',
  headers: { 'Content-Type': 'text/plain' },
  body: JSON.stringify({
    path: location.pathname,
    referrer: document.referrer || undefined,
  }),
  keepalive: true,
})

The analytics Worker classifies the user agent on that POST, writes a page-view row to D1, and counts rows marked AI under the API field ai_fetches.

That path can observe a browser or render-capable client that executes JavaScript. It cannot observe a normal direct request for /llms.txt, /llms-full.txt, a page's .md representation, or HTML fetched without running the beacon.

Those resources are static assets. Only /api/* runs Worker-first in the deployed configuration, so the requests I wanted to study bypass both the application Worker and the browser script.

"The system was asking a browser page-view service to answer a server retrieval question."

The classifier had a second problem. Its categories were Human, Bot, and AI. But providers document different purposes: search crawling, potential training collection, and user-directed fetching. In the current code, OAI-SearchBot and Claude-SearchBot fall into the generic bot bucket, while Claude-User and Perplexity-User can fall into the human bucket. GPTBot and ChatGPT-User both become AI even though they perform different jobs.

The honest description of the existing metric is: browser analytics events whose beacon user agent matched the current AI regex. It is not a count of AI crawlers reading the site's files. The official crawler roles for OpenAI, Anthropic, and Perplexity also change over time, so the classifier needs a dated purpose model—not a longer permanent regex.

The first edge snapshot mostly found the investigation

The static requests were not invisible to Cloudflare. They were invisible to my D1 page-view model.

The audit queried Cloudflare's edge request aggregates in one-day slices and reconstructed roughly seven days before the live endpoint checks. Every nonempty group reported sampleInterval: 1; the data was still grouped evidence, not raw request records.

The historical window contained:

  • three requests for /llms.txt, likely two Chrome request sequences because one sequence returned 301 and then 200;
  • three requests for article Markdown presenting curl/8.7.1;
  • zero requests for /llms-full.txt;
  • zero user agents naming a known AI provider.

The CLI requests might have come from me, another person, or an agent using a shell. The aggregate cannot attribute them. When the research process later fetched the live files with curl, the next snapshot was consistent with—and dominated by—those checks, but had no request IDs that could prove each row's origin.

The path worked, but at this traffic level the investigation mostly measured its own requests.

The best cross-domain evidence points in the same sparse direction. Ahrefs studied 137,210 domains in its Web Analytics customer base for May 2026. About 38,000 served a valid llms.txt; 97% of those files received no requests. The customer base is technically and SEO skewed, the study measured the root index rather than page Markdown, and a request still did not prove model use. It does establish that automatic requests were rare in that sample.

“Does llms.txt work?” hides eight different questions

Arguments about the file drift because “works” can refer to different systems.

Stage Actual question Evidence that fits
Search activation and discovery Does the system search, and how does it learn that this site or file exists? product traces, links, sitemaps, explicit instructions
Crawling and index eligibility May a provider crawl and index this page? status, crawler controls, noindex, canonicals, provider tools
Retrieval and selection Why is this source chosen for this query? query fit, index state, search/citation telemetry
Navigation and representation Once inside the site, which page and format does the client request? index-following traces, .md requests, content negotiation
Context and citation Which candidates receive attention, and which are named or linked? controlled candidate tests, provider citation telemetry
Absorption and fidelity Which facts or reasoning enter the answer, and are they supported? claim-to-source comparison, human-audited attribution
Referral Did a person click through? sanitized referrer and campaign attribution
Outcome Did the visit create a useful read, return, signup, or other declared result? first-party audience or product telemetry

A request is an attempt. A successful response shows server delivery. Neither proves that the content entered a model context. A citation does not prove a person visited. Clean Markdown can improve consumption without changing source selection.

I had assigned llms.txt an early discovery job. The proposal is better understood as navigation and consumption after a client has a reason to enter.

Google Search ignores it. A Google agent uses it.

Google's two positions make sense once the stages are separated.

Google Search says llms.txt neither helps nor harms visibility or rankings in Search and its AI features. The documented path remains ordinary Search eligibility: crawlable and indexable pages, useful original material, internal links, and Search Console.

A maintained Gemini API development skill uses a different path. When its preferred documentation MCP is unavailable, it tells the coding agent to fetch Google's documentation index, find the relevant page, and fetch that page's Markdown.

Other maintained workflows give the artifacts similarly narrow roles:

These are maintained instructions and design choices, not comparative task results. They suggest the boundary: a large documentation tree can favor a small map followed by one page, while a bounded migration corpus can justify a cached dump searched locally.

An MCP adapter could retrieve this blog

The most direct reproduction used LangChain's `mcpdoc`, an MCP documentation server that exposes configured sources as tools.

On August 25, the reproduction instantiated mcpdoc==0.0.10 with https://gkoreli.com/llms.txt, called the tools directly, fetched the live index, fetched /the-agentic-product-engineer.md, and refused an off-origin URL. The server checks an allowed origin; it does not prove that every accepted same-origin URL appeared in the index.

This established a working retrieval path through an agent-facing adapter. It did not run a model through an MCP host, prove that an agent would choose the tools correctly, or improve a scored task.

This is the same distinction I ran into with the ghx sidecar: capability proof is not product adoption. Publishing the files does not cause anyone to configure the adapter. But the transport path is no longer hypothetical.

Page Markdown may matter more than the famous filename

The conversation centers the root file because it has a name. The destination may be more valuable than the map.

Some coding-agent fetchers already ask ordinary URLs for Markdown through the HTTP Accept header. In a February 2026 protocol snapshot, the tested versions of Claude Code, Cursor, and OpenCode preferred Markdown; Codex, Gemini CLI, GitHub Copilot, and Windsurf did not.

The delivery mechanisms differ. Cloudflare's managed Markdown-for-Agents conversion is opt-in on Pro, Business, and Enterprise plans and relies on correct content negotiation. Vercel documents an application/docs pattern for returning Markdown from a canonical URL. This blog instead emits explicit static .md files at build time, a simpler choice for its Free-plan static architecture.

The audit compared one post, /the-agentic-product-engineer, in both forms on August 25 using cl100k_base:

Representation Bytes Tokens
HTML response 27,554 7,683
Markdown response 10,756 2,476

The Markdown representation used 67.8% fewer tokens.

That is a representation result, not a task result. A client may make more requests, omit useful content, retry, or verify against HTML. cl100k_base is not every current model's tokenizer. The smaller response is enough to justify a test, not a universal performance claim.

The design resembles map-first progressive disclosure: use the map to decide what deserves a full read. A giant dump reverses that economy unless the task genuinely spans the corpus.

How to test llms.txt by stage

The measurement must match the job.

  1. Delivery test: fetch the index and targets. Check status, content type, redirects, parity, and broken links. This tests serving.
  2. Request test: inspect origin or edge evidence for the index and follow-on page requests. Keep your own checks separate. This tests traffic presented by a client, not use.
  3. Task test: give fresh agent sessions the same exact question under HTML navigation, index + targeted Markdown, and a full dump. Freeze the site snapshot, model/client, tool budget, and scoring. This tests usefulness after the entry point is supplied.
  4. Citation test: use provider telemetry or a controlled answer/source comparison. This tests source selection or use, depending on the setup.
  5. Referral test: count human visits from AI products separately. This tests audience movement.

The benchmark protocol in the research folder is drafted but not frozen or run. Its current proposed quality boundary allows the alternate representation to trail HTML by no more than one scoring point across the full question set. It calls a condition more efficient only if median fetched bytes or input tokens fall by at least 20% without increasing unsupported claims. Disagreement between agent implementations must remain visible rather than being averaged into one universal verdict.

The request baseline has a separate proposed gate. Collect daily edge snapshots across a clean month before routing sparse traffic through a Worker and D1. Exact request logging becomes worth the operational and privacy cost only if unexplained target traffic averages at least one request per day, the same material client appears at least three times, or a declared intervention needs request-level traces.

Those thresholds are editorial choices, not field standards. The protocol remains a draft until they are reviewed and frozen.

For live search evidence, the providers expose different surfaces:

Evidence surface What it can establish What it cannot establish
Google's limited-rollout generative-AI report a site link impression in supported Google features grounding query, answer influence, click, conversion
Bing AI Performance a covered Bing AI Performance surface displayed a page as a citation; sampled grounding phrases placement, authority, role in an individual answer, reader action
Repeated prompt panel presence, citation, stance, and accuracy in the declared sample audience size, stable universal rank, causal lift
Edge or origin evidence a client attempted a request and bytes may have been delivered model-context use, citation, referral
UTM or referrer analytics an attributable visit reached the site unclicked exposure, native-app visits without a referrer, causality

Those are not five versions of one “AI visibility” score. Each is a different event.

What GEO covers beyond llms.txt

llms.txt is one possible navigation input. Generative engine optimization is the wider problem of whether and how a source enters, appears in, and influences a generated answer.

There is no common web protocol called GEO or AEO. The terms overlap:

  • SEO covers established search eligibility, relevance, ranking, result presentation, and traffic.
  • AEO is often used for visibility in direct-answer surfaces.
  • GEO is often used for selection, citation, prominence, or influence inside generated answers.

Those labels are less useful than the eight events named earlier in this article. A July 2026 critical survey of 45 GEO studies reaches a similar pipeline model. It is a preprint synthesis, not a new causal experiment. Its useful addition is answer absorption: a system can retrieve and cite a page while using little of what made the page valuable.

What production systems actually expose

As of August 25, 2026, three production paths are concrete.

First, automatic search-index-backed inclusion generally begins with that provider's crawl and index rules. User-directed fetch is a separate path. Google explicitly requires an indexed, snippet-eligible page for AI Overviews and AI Mode; no special AI file or schema is required. Its limited rollout also gives some verified properties a site-level generative-AI include/exclude control, separate from ordinary Search and Google-Extended.

Second, one question can become several searches. Google documents query fan-out, ChatGPT documents targeted query rewrites, and Claude documents progressive searches. That is not permission to publish a page for every imagined query. Google warns that mass-producing guessed variants can become scaled-content abuse. Peer-reviewed RAG studies show the reason for restraint: adaptive decomposition can improve diverse coverage under a retrieval budget, while over-searching can add noise and harm abstention. Those are controlled RAG results, not observations of a provider's hidden queries.

Third, the source of truth may not be an article. Merchant Center, Business Profiles, Bing Places, and IndexNow carry supported product, local, and freshness data. One emerging production example is Pinterest's 2026 first-party preprint: it reports a 20% production traffic lift from a bundle of query modeling, visual representations, indexable collections, and internal-link graphs. That is product and search architecture at Pinterest scale, not a portable paragraph recipe.

The newest traffic evidence is less comfortable. A February Wikipedia natural experiment and an August preregistered browser field experiment both suggest that some generative answer surfaces substitute for outbound publisher clicks. Their estimates depend on different designs and assumptions. Neither isolates the effect of one publisher being cited, changes a publisher page, or tests a GEO remedy.

What controlled GEO research can—and cannot—show

The KDD 2024 GEO paper found that citations, relevant quotations, statistics, and clearer writing could change measured visibility inside generated answers. Its main benchmark began with Google's top five results already supplied to GPT-3.5 Turbo. Its Perplexity arm uploaded source files and required answers from them. It tested influence after selection, not organic entry.

The 2026 peer-reviewed frontier keeps that boundary:

  • FeatGEO, ACL 2026 optimizes document-level features across a supplied candidate set and outperforms token-level rewrites. It does not test organic entry into that set.
  • MAGEO, ACL Findings 2026 freezes retrieval and learns engine-specific strategies. Its engine specificity argues against one cross-platform checklist.
  • Mind Reader, ACL 2026 tests generated query variants and reasoning coverage on controlled GEO-Bench and PC-GEO benchmarks, not live provider fan-out.
  • Competitive GEO, SIGIR 2026 ran 252,000 paired supplied-candidate trials and found topical relevance and list position stronger than formatting-only changes.
  • AutoGEO, ICLR 2026 found that learned document-level rules transferred across several constructed fixed-candidate engines. When every candidate adopted the rules, the target's relative advantage fell near baseline while overall answer utility generally improved. A copied tactic can become hygiene rather than an edge.

The gap between source evidence and answered material is also peer-reviewed. A NAACL 2025 study found that source sets exposed by commercial answer systems contained knowledge for roughly 63–67% of core subquestions, while final answers covered only 42–54%. An April 2026 absorption preprint gives that wider distinction a useful measurement frame, but its page-feature associations are observational rather than editing rules.

Measurement also needs repetition. A peer-reviewed live audit of 4,706 queries found only 18% overlap in Google AI Overview source URLs after roughly two months, compared with 45% for organic results. Even at temperature zero where the system exposed that control, 9–27% of ternary answer decisions flipped within five minutes. One screenshot is not a rank.

The distilled August 2026 position

Established enough to act on: satisfy the documented eligibility rules for the surface you want; keep canonical pages connected; separate request, citation, absorption, referral, and outcome; and repeat live measurements. In controlled post-retrieval experiments, topical relevance outweighs formatting-only tricks. Original evidence is still the most defensible reader-first investment, but these experiments do not establish its organic selection effect.

Emerging: provider-specific controls and reports, query-family tests, absorption and fidelity audits, explicit user preference through Google Preferred Sources, and corpus-specific feeds or product architecture. These are different directions, not one GEO standard.

Still unproven: that GEO replaces SEO; that one file, schema, heading pattern, quotation tactic, or manufactured mention causes organic selection; that one prompt screenshot measures a rank; that a controlled gain transfers across engines, competitors, time, and the open web; or that generative visibility reliably creates publisher traffic.

What I will do for this blog

The workflow is smaller than a GEO program:

  1. Start with a real reader question and publish something the existing result set cannot supply: code, data, a reproduction, a correction, or a primary-source synthesis.
  2. Keep the canonical page eligible and internally connected. Use a supported feed or profile only when the facts are actually product, local, image, or video data.
  3. Put claims beside their evidence and limitations. Use headings, tables, definitions, and procedures when they help the reader—not as a citation spell.
  4. For a declared test, freeze the prompt set and execution conditions. Record provider, interface, locale, account state, date, and whether search was observed. Repeat runs and preserve raw answers, sources, nulls, and disagreements.
  5. Read each provider report by its own definition, then connect attributable referrals to a human outcome without claiming causality from one update.

I am not building or buying an ongoing GEO visibility dashboard for this blog now. I will use provider-native reports when they have enough data, preserve attributable referrals, and run a small frozen prompt panel only when its result can change a decision. More instrumentation earns its cost when repeated signal or reader contact makes manual evidence the bottleneck. Until then, llms.txt can support navigation after entry; it cannot substitute for the reason the source enters the system.

The smaller job each artifact earned

The audit's current recommendation for this blog is deliberately bounded:

Artifact Decision now Evidence that changes it
Semantic HTML Keep as the canonical human/search document and agent fallback. None of the agent-specific null results removes this job.
Small generated llms.txt Keep while it stays synchronized and costs almost nothing. Repeated client use or measured navigation benefit earns more investment; drift or complexity removes it.
Page-level Markdown Keep as the strongest candidate for durable agent utility. Quality-preserving task efficiency across more than one agent/client strengthens the case.
llms-full.txt Leave on probation; it was 375,443 bytes for 18 posts in the August snapshot. Keep it only if cross-post synthesis or repeated local search offsets the payload.
Public ai_fetches label Rename or explain before treating it as evidence. It can never become crawler evidence without observing the original resource request.
Exact D1 request ledger Do not build for sparse observed traffic yet. Build only when exactness changes a declared decision.

Preserve the automatic options. Test the task claims. Add instrumentation when its answer changes a decision.

Practical llms.txt answers

Does llms.txt improve Google rankings or AI Overviews?

No. Google says the file is not used by Search and neither helps nor harms visibility or rankings. Ordinary Search eligibility, helpful original content, internal links, and supported Search Console evidence still apply.

Do ChatGPT, Claude, Perplexity, or coding agents read it?

There is no provider-wide answer. No reviewed search provider promises organic visibility from the file, while explicitly configured agent skills and tools implement the pattern in bounded documentation workflows. Provider search crawlers, training crawlers, user-directed fetchers, and coding-agent skills are different clients with different jobs.

Does it replace robots.txt or a sitemap?

No. robots.txt expresses crawler access preferences. A sitemap enumerates canonical crawl targets. llms.txt is a proposed contextual map for a client that chooses to read it. Keep the established mechanisms.

Does every site need llms-full.txt?

No. A full dump is useful when a repeated, cross-document task benefits from one corpus or lazy local search. It is wasteful when the client needs one page. Give the dump its own benchmark and size ceiling.

Should I publish .md versions of every page?

Only when they stay synchronized with canonical content and serve a named client or test. Explicit .md URLs are simple for static builds. Content negotiation keeps one canonical URL but requires correct conversion and caching. Semantic HTML remains the baseline web representation.

How do I know whether an AI system used the file?

You usually cannot prove the whole chain from one metric. Edge or origin evidence can show a request and response. A controlled task can show whether supplied content affected an answer. Provider telemetry can show citations or visibility. Referrer data can show a human visit. Keep those outcomes separate.

I still want readers

Pretending not to care about traffic would be as false as pretending llms.txt creates it.

The file can give an agent a smaller door after something else creates the reason to enter. For developer documentation, maintained skills and explicitly configured tools already implement that path. For this personal blog, the generated map and Markdown remain cheap options; the full dump and custom telemetry have to earn their cost.

If you maintain a client that discovers or follows these files, the useful response is a trace: client and version, initial URL, requested paths, and task result. A zero-request observation window is useful too. If a provider changes its policy, first-party documentation matters more than a screenshot.

That evidence can give the file a larger job. Until then, the smaller one is enough.

Evidence ledger

Evidence checked: August 25, 2026. Provider behavior, proposal text, and client code are volatile; the stage model and measurement boundaries are the stable part of this article.

Term / claim Source Evidence date
Original discovery → consumption → measurement model and March baseline gkoreli.com ADR-0006 at the audited implementation baseline Mar 2026
Current browser beacon, classifier, D1 metric, and Worker-first routing Browser beacon, event write, classifier, `ai_fetches` query, and Worker-first routing Aug 2026 audit
First-party edge snapshot method and grouped result Companion research artifact Aug 2026
llms.txt v2 proposal, format, and link relations Live proposal and audited repository baseline Aug 10, 2026
Google Search ignores llms.txt; ordinary Search eligibility still applies Google Search Central, AI features and your website Updated Jul 10, 2026; accessed Aug 25
Google AI Overviews/AI Mode eligibility and query fan-out AI features and your website Accessed Aug 25, 2026
Google's limited-rollout site-level generative-AI inclusion control Search generative AI control Accessed Aug 25, 2026
User-selected Preferred Sources in Google generative features Preferred Sources Updated Aug 20, 2026; accessed Aug 25
Maintained Google coding-agent skill uses index → page Markdown Pinned Gemini Live API skill Accessed Aug 25, 2026
MCP documentation adapter and direct tool reproduction LangChain `mcpdoc` at `8d01c08` and reproduction artifact Aug 25, 2026
Index → targeted Markdown instructions with eval assertions Pinned Prismatic skill Accessed Aug 25, 2026
Cached full-dump migration workflow Pinned tldraw migration skill Accessed Aug 25, 2026
Current Streamlit full-dump fallback Pinned Streamlit vendored skill Accessed Aug 25, 2026
Coding-agent Markdown negotiation snapshot Checkly protocol test Feb 2026
Managed negotiated Markdown Cloudflare Markdown for Agents Updated Jul 13, 2026; accessed Aug 25
Application/docs content-negotiation pattern Vercel, Making agent-friendly pages with content negotiation Feb 3, 2026
Cross-domain root-index request study Ahrefs study of 137,210 domains May 2026 data
OpenAI search, training, and user-directed crawler roles OpenAI crawler documentation Accessed Aug 25, 2026
ChatGPT search eligibility and referral guidance OpenAI publisher FAQ Updated Aug 2026; accessed Aug 25
ChatGPT targeted query rewrites and citations ChatGPT search guidance Updated Aug 2026; accessed Aug 25
Anthropic search, training, and user-directed crawler roles Anthropic crawler guidance Apr 7, 2026; accessed Aug 25
Claude progressive searches and source-bearing citations Anthropic web search tool Accessed Aug 25, 2026
Perplexity search and user-directed crawler roles Perplexity crawler documentation Accessed Aug 25, 2026
Bing citations, cited pages, and grounding-query telemetry Bing AI Performance Feb 2026
Google Generative AI page/impression reporting Search Console report announcement Jun 2026
Production-scale multimodal collection-page and linking intervention Pinterest GEO production preprint Feb 2026 preprint
Early field evidence on generative answers and publisher referrals Wikipedia natural experiment and preregistered browser field experiment Feb and Aug 2026 preprints
Original GEO benchmark GEO, KDD 2024 KDD 2024, peer-reviewed
Fixed-candidate cross-engine citation optimization FeatGEO, ACL 2026 Jul 2026, peer-reviewed
Frozen-retrieval document optimization MAGEO, ACL Findings 2026 Jul 2026, peer-reviewed
Latent-demand and reasoning-coverage optimization Mind Reader, ACL 2026 Jul 2026, peer-reviewed
Relevance and position versus formatting-only changes Competitive GEO, SIGIR 2026 SIGIR 2026, peer-reviewed
Competitive saturation of learned document rules AutoGEO, ICLR 2026 ICLR 2026, peer-reviewed
Retrieved core questions versus answered core questions Sub-question coverage, NAACL 2025 NAACL 2025, peer-reviewed
Query decomposition under a retrieval budget Adaptive query decomposition, EACL 2026 EACL 2026, peer-reviewed
Noise and abstention costs from unnecessary retrieval Over-searching, EACL 2026 EACL 2026, peer-reviewed
Live cross-engine and repeated-run source volatility Characterizing Web Search, ACL Findings 2026 Jul 2026, peer-reviewed
Citation selection versus answer absorption Cross-platform measurement preprint Apr 2026 preprint
Forty-five-study GEO evidence synthesis Critical survey of GEO, 2023–2026 Jul 2026 preprint