Generative Engine Optimization

For a long stretch, a search result page was ten blue links. People clicked one of them and landed on some site, and marketing's job was to climb that list. Pushing a site higher up the results is called search engine optimization (SEO). A better rank meant more visitors and more visitors meant more signups, so reporting a rank as a result made sense.

Then the top of the results page stopped being a link and became a sentence. A model reads several pages, writes a fresh answer, and attaches a handful of sources underneath. When the answer is complete there, the user clicks nothing.

In marketing meetings the change first showed up like this: rank unchanged, traffic down, and no vocabulary for the cause. Every old metric looked fine, which left nothing to act on.

Generative engine optimization (GEO) is the name given to that gap. It marks the shift from asking about position to asking about citation — not where the site ranks, but whether the model read your sentences and credited your name while composing its answer. In practice the term trades places with answer engine optimization, the broader name above it. If you separate them at all, answer engine optimization leans on the outcome that questions get answered, and generative engine optimization leans on the fact that a model writes the answer.

A model produces an answer in two steps: it finds and reads documents that match the question, then composes what it read into sentences. The work splits along the same seam.

Getting read is about building a path in.

1. llms.txt — a text file at the root of the site listing what the site covers and which documents are worth reading. On a site with 300 help articles, without this file a model picks up a handful of arbitrary pages.
2. Structured data — markup that tells a machine which block on a page is a question and which is the answer, which line is a price and which is a publication date. To a reader the paragraph looks identical; to a machine it now carries labels.

Getting composed in is about rewriting sentences, and two standards govern it.

1. Answer extractability — whether a single paragraph still works as an answer once it's lifted out. A paragraph opening with "the second of the three points above applies here" needs what came before it, so it can't be lifted. One opening with "meeting notes are written up the same day the meeting ends" stands on its own.
2. Citability — whether the material is arranged in a way that makes it usable as a source. Do figures carry a date, do claims carry evidence, is the author identifiable. Given two documents holding the same fact, a model credits the one that can be checked.

The two halves don't work separately. Open the path and leave the documents as they were and the model reads without citing; rewrite the documents while the path stays closed and nothing reads the new sentences.

The term comes up most in the meeting where a content plan gets set. The list used to be keywords; now it's questions. Instead of "collaboration tool," the list carries something like "what's the simplest way to share meeting notes with a team," and the article answers that question inside one paragraph.

Product help documentation draws the same discussion. Feature articles are usually written in screen order, so a middle paragraph makes no sense on its own. The work that follows is turning the first sentence of each paragraph into its conclusion.

Reporting changes what gets counted. The summary block at the top of a results page is the AI overview, and the number of times your name appears there as a source is the most direct result. Some of those appearances bring no click at all, so the figure has to be read next to the older metrics rather than instead of them.

Teams also spend a meeting deciding whether to say this or answer engine optimization. Either name points at the same files and the same sentences, so picking one and moving on is the better use of the time.

"Rank is flat but traffic is down 20 percent. This looks like a GEO problem."

Answers are completing on the results page, so the clicks aren't coming.

"This article is weak for GEO — the conclusion only exists in the final paragraph."

Rewrite the opening sentences so a middle paragraph still answers something.

"Let's ship llms.txt first, then fix the top ten help articles."

Open the path, then rewrite the documents that matter most.

At Pagedeck, Ravi went through 40 help articles. Most followed the order of the screen, so they read fine from the top but a single paragraph pulled from the middle meant nothing. He rewrote the opening sentence of each paragraph as its conclusion and moved the titles from feature names to the questions users actually ask. "Sharing settings" became "how to share a document with someone outside your company."

Three months later two things had changed. Pagedeck's help pages were credited as a source on more questions in AI overviews, and the share of support tickets asking those same questions had fallen. The documents had simply gotten better for human readers too.

The most common error is reading this as a replacement for search engine optimization. The names sit side by side and the results page did change, so the assumption is natural. But the documents a model reads are largely the documents already in the search index — a site that search can't find isn't reachable for the model either. Treat one as a replacement and drop the older work, and the material available to be read shrinks, which pulls both results down together.

Planting text aimed at the model is the other frequent error. That means stuffing keywords at the bottom of a page, or hiding a line in invisible text telling the model to recommend this product. It can work briefly, it doesn't last, and once found it risks the whole site being treated as low quality. What needs fixing is the paragraph that answers a question when a person reads it, not a hidden string.