What this chapter does to you: "Write good content" is useless advice. This chapter is the specific, measured version: a 2024 Princeton/Georgia Tech/Allen Institute/IIT Delhi research paper (KDD '24) tested concrete content-modification tactics against real generative engines and measured the actual lift each one produced. You've already built the mental model this chapter needs — it's the same one from the RAG chapter in AI Engineering, just pointed at your own content instead of a knowledge base you're building for someone else.

You already know this shape — you've built it before

A live-retrieval GEO system (Perplexity, ChatGPT with browsing, Google AI Overviews) does something structurally identical to RAG: retrieve candidate sources for the query, then synthesize an answer, citing a handful of them. The content that survives that pipeline is the content that reads well after being chunked and retrieved out of context — the same requirement you already internalized when thinking about what makes a good document for your own RAG pipeline. You're not learning a new skill here. You're applying one you already have, to a new target.

The measured findings

The GEO paper tested nine content-modification tactics across ten thousand queries and measured visibility lift in generative engine responses. Three tactics — all in the same family — produced the largest gains:

The common thread across all three: factual density. Content that reads as evidence — numbers, attributed quotes, references to sources — gets selected over content that reads as persuasion. This tracks with why the tactic works mechanically: a generative engine synthesizing an answer is trying to produce something defensible: a citable claim it can attribute is more useful to it than a well-written paragraph making the same claim unsupported.

Answer-first, every time

Systems doing live retrieval evaluate a page's relevance heavily on its opening content — the first ~150-200 words should completely answer the primary query, not build up to it. This directly inverts a lot of conventional content-marketing instinct (hook → story → eventually, the answer). That structure is optimized for a human who's committed to reading the whole piece. It's close to the worst possible structure for a system that's deciding, from the first chunk alone, whether your content is worth citing at all.

Before (narrative-first — common, and now actively costly):

When we started building our onboarding flow, we ran into a problem a lot of teams hit eventually: users were dropping off before ever seeing the product's core value. After weeks of testing, we landed on an approach that changed everything...

After (answer-first):

Reducing onboarding drop-off usually comes down to one change: show the product's core value before asking for any setup. In our testing, moving the "aha moment" earlier cut onboarding drop-off by 34%. Here's how we did it, and why it worked.

The second version gives a retrieval system a complete, citable claim in the first sentence — a number, a mechanism, and a reason — before it ever has to decide whether to keep reading.

Structure content the way you'd structure chunks for retrieval

Because that's precisely what's happening to it. The practical rules:

• One idea per section, under a clear, literal heading — not a clever one. A heading like "The Real Problem" tells a retrieval system nothing; "Why Onboarding Drop-off Happens" is itself almost a complete, extractable answer.
• Self-contained paragraphs. A paragraph that only makes sense after reading the three before it is a paragraph that fails the moment it's retrieved as an isolated chunk — which is exactly what a GEO system does to it.
• Numbers and claims near their source. If you're going to cite a statistic, attribute it inline, right next to the number — "34% (internal A/B test, n=12,000)" is a citable unit; "we saw a big improvement" is not.

llms.txt — cheap, not yet universal

A plain Markdown file at /llms.txt, proposed in 2024 as an robots.txt-adjacent convention: a site title, a short summary, and grouped Markdown links to your most important pages, written for an LLM to parse quickly rather than crawl a whole site to discover.

# Your App

> One-sentence summary of what this is.

## Docs
- [Getting Started](https://yourapp.com/docs/getting-started)
- [API Reference](https://yourapp.com/docs/api)

Honest caveat, because stale certainty is worse than an honest "we don't know yet": no major AI lab has officially confirmed they honor llms.txt. It is not "robots.txt for AI" — it doesn't block or permit crawling, it's a readability aid. Anthropic's own documentation references the convention, which is a real, if partial, endorsement. Given the cost of adding one is a single static file, it clears the bar of "worth doing" even under real uncertainty about its current reach — this is a low-cost bet on a standard that may or may not become load-bearing, not a guaranteed win.

Authority still means something — it's just measured differently

SEO's version of authority is backlinks. GEO's rough equivalent is consistency of mention across independent sources — a claim that appears, worded similarly, across your own docs, a few independent reviews, a forum thread, and a YouTube transcript reads as corroborated fact to a system trying to synthesize a trustworthy answer. A single confident claim on your own domain is weak evidence on its own. The same claim echoed across five places you don't control is strong evidence. This is the mechanical reason "being talked about elsewhere" — digital PR, the trust layer from the last chapter — still matters as much for GEO as backlinks ever mattered for classic SEO. It's the same underlying signal, read by a different kind of system.