// blog

Generative Engine Optimization for Docs and Developer Sites

news

Search “generative engine optimization” and you get a wall of marketing-agency content selling visibility dashboards to brands. The one serious research paper everyone cites (arXiv 2311.09735) is written for IR researchers, not practitioners. Almost nobody writes GEO for the people who own docs sites, READMEs, and technical blogs — which is odd, because dev content has structural advantages in AI answers that brand content can’t buy.

This is that missing guide. Core thesis: docs sites are already close to optimal inputs for generative engines, because they answer questions deterministically with code. Most agency GEO advice is noise for this audience. A short list of structural moves does almost all of the work, and we’ve shipped them on atiqlabs.com ourselves — including llms.txt on Astro + Cloudflare Workers.

Tested on: atiqlabs.com — Astro 5.18.2 static output on Cloudflare Workers (compatibility_date = "2026-08-01"), llms.txt deployed 2026-08-22, robots.txt Allow: / with sitemap pointer. Crawler-pickup numbers are pending log data as of this date (more on that in the measurement section — that honesty is deliberate).

Why AI engines treat docs differently than brand sites

A generative engine answering “how do I set cache headers on Cloudflare Workers assets” isn’t synthesizing opinions across ten landing pages. It’s looking for one correct, checkable answer. That changes what gets cited:

The practical consequence: your competitive set in an AI answer is other docs sites and high-signal community content (GitHub issues, Stack Overflow), not SEO-optimized listicles. You’re not out-marketing anyone; you’re being the most machine-checkable source.

What the GEO industry gets wrong for dev sites

Be honest about where the advice comes from. The dominant GEO content pipeline is agencies paraphrasing the same arXiv paper at each other, then attaching it to tool suites: visibility-score dashboards, entity-graph trackers, prompt-panel subscriptions aimed at brand marketers. For a docs site, most of that stack solves problems you don’t have.

Two examples of the mismatch:

None of this means the underlying research is wrong — it means its findings were measured on a distribution you’re not in. Translate rather than adopt.

What the paper actually found, translated

The paper everyone cites — Aggarwal et al., GEO: Generative Engine Optimization (KDD 2024) — tested nine content modifications against GEO-bench, ~10k queries across domains, measuring how often sources appeared in generated answers. Headline claim: the best-performing optimizations boosted source visibility up to 40%. Two things matter when translating that number:

  1. It’s “up to,” on their benchmark, against a baseline of unmodified pages, measured by their own visibility metric — not production ChatGPT/Perplexity traffic.
  2. The strongest interventions were things like adding quotations, statistics, and citations to the page text. Keyword stuffing did nothing. Effect sizes varied sharply by domain, which is the paper’s own argument for treating generic GEO playbooks skeptically.

Practitioner translation: make your pages dense with verifiable specifics — exact values, exact commands, stated limitations. For docs, “verifiable specific” almost always means code. The 40% number is directional evidence that structural specificity helps, not a guarantee you’ll see 40% anything.

The short list that matters

This is nearly all of it. Each item is something we’ve done or evaluated on our own site.

Question-shaped headings that match real prompts

Devs don’t ask AI engines “Cloudflare Workers caching considerations.” They ask “why is my llms.txt served as text/html” or “how do I verify GPTBot fetched my file.” H2s written as the literal question — or containing the exact nouns and error strings devs paste into a prompt box — are retrieval bait in the best sense. Our llms.txt post uses headings like “Hosting specifics on Cloudflare Workers/Pages” and sections organized around failure modes (“Common mistakes”), because that’s how the queries arrive.

Rule of thumb: mine your GitHub issues, support inbox, and Stack Overflow questions about your product; the phrasing there is the phrasing the model will match against.

Code-first answers

Complete, runnable, versioned snippets beat prose explanations every time. “Complete” means: imports included, no ... elisions in the load-bearing part, pinned versions where behavior differs, and expected output shown. We show full curl output with response headers in the llms.txt post precisely because a partial transcript can’t be checked. Version-stamp snippets (“Astro 5.x”) so a model weighing your answer against a 2023 blog post has a reason to prefer yours.

Clean markdown path + llms.txt

If a model fetches your page, the fight against nav chrome, cookie banners, and hydration scripts is friction you chose. Serve clean HTML that degrades to readable text without JS, and ship /llms.txt as a curated map. We documented the whole implementation — file structure, Cloudflare content-type gotchas, verification commands — in our llms.txt post. One honest caveat from that post applies here too: no major crawler is documented as prioritizing llms.txt yet, so it’s cheap optionality, not a proven ranking lever.

On llms.txt vs schema: it’s not either/or, and neither substitutes for the other. Schema.org structured data (TechArticle, SoftwareSourceCode, FAQPage) tells crawlers what a page is; llms.txt tells a model what your site contains and why each piece matters. Do schema where it earns its keep (article metadata, code samples marked up as software source), do llms.txt because it costs an afternoon. Neither rescues a site whose actual content is thin — Google’s own guidance makes the same point from the other direction.

Crawlability basics — including for AI crawlers specifically

Google’s official guidance on AI features and your website is blunt: there are no additional technical requirements to appear in AI Overviews or AI Mode beyond normal indexing eligibility, and foundational SEO remains the base. Concretely for a docs site:

Freshness with honest date stamps

Show lastUpdated on docs pages, keep a changelog for breaking changes, and update stale snippets even when nothing else changed. Date stamps are dual-use: humans trust them and models weight them. Just don’t fabricate them — a 2026 date on 2023 content is detectable and poisons the well.

Measurement without enterprise tools

Here’s the uncomfortable part the tool vendors gloss over: citation measurement is primitive, and everything below has limits we’ve hit ourselves.

Referrer and log analysis for AI crawlers. Watch access logs for these user agents:

User agentOperatorRole
GPTBotOpenAITraining crawl
OAI-SearchBotOpenAISearch/answer grounding
ChatGPT-UserOpenAIReal-time user-initiated fetch
ClaudeBotAnthropicTraining crawl
Claude-User / Claude-SearchBotAnthropicUser-initiated / search fetch
PerplexityBot / Perplexity-UserPerplexityIndex crawl / user-initiated fetch
Googlebot + Google-ExtendedGoogleSearch indexing vs. training use
Applebot-ExtendedAppleTraining/opt-out control

A quick log slice:

grep -Ei 'gptbot|oai-searchbot|chatgpt-user|claudebot|claude-user|claude-searchbot|perplexity(bot|-user)|google-extended' access.log \
  | awk '{print $7}' | sort | uniq -c | sort -rn | head

What this tells you: which AI systems fetch which pages, how often, and whether they ever hit /llms.txt. What it doesn’t tell you: whether a fetch turned into a citation. On our own site, post-deploy log history isn’t yet long enough to report fetch counts by UA — we say so in the llms.txt post rather than inventing numbers, and the same standard applies here. Anyone quoting their llms.txt “AI traffic lift” without UA-level log evidence is selling something.

Manual citation panels. Keep a fixed set of 10–20 realistic prompts in your domain. Run them monthly across ChatGPT, Perplexity, and AI Overviews; record whether you’re cited and linked. Cheap, direct, and the only method that measures the thing you actually care about. Limits: tiny sample, non-deterministic outputs (same prompt can cite different sources run-to-run), personalization and location leakage, and your own browsing history contaminating results — use fresh sessions or an incognito profile, and expect variance.

Search Console. AI Overviews and AI Mode traffic lands in the Performance report under the “Web” search type — there is currently no dedicated AI-only report, so you can’t fully isolate AI-driven impressions from classic search there. Directionally useful for spotting pages gaining impressions without corresponding classic rankings; not proof of AI citation.

Treat all three as triangulation, not ground truth. The field has no reliable citation analytics yet, and pretending otherwise is the industry’s biggest credibility gap.

What we’d skip, and why

For a docs site, we’d spend zero time on:

The meta-point: docs GEO is mostly just excellent docs plus crawl hygiene. That’s good news — it means the work compounds into ordinary SEO and reader experience instead of evaporating into a subscription.


Claims labeled directional (including the arXiv 40% figure and everything in the measurement section) are exactly that — grounded in published sources or first-hand setup, not proven on production traffic. Where we lack data, we’ve said so. If you want help making your site machine-readable end to end — llms.txt, structured data, crawler access — see our services or get in touch.

Building your own AI infrastructure?

Talk to us