1. The Trap
A few months ago, someone asked me what I thought about generative engine optimisation. I gave the usual answer: make your content more quotable, structure it for extraction, get your entity references right. And those things matter. But as I said them, I realised the advice I was giving was only half the picture.
Most GEO advice, the kind that circulates on blogs and in SEO social threads, treats the problem as a content volume problem. Write more pages. Answer more questions. Cover every angle of every topic so that when a model looks for an answer, your site is the one it finds.
This is the same trap we fell into with traditional search. We built content farms. We chased query coverage. We measured success by how many terms we could rank for, not by whether ranking for them did anything.
GEO makes that trap worse. Because a generative model does not need your page. It can synthesise an answer from five sources, three of which are a general encyclopedia, a government site and a forum thread. Your carefully crafted “What is X” article is just one voice in a chorus. And if all you bring is another well written definition, the model has no reason to pick you.
I have seen this pattern on projects I have worked on. Teams that wrote hundreds of pages targeting generative answer surfaces. Pages that were technically excellent. Quotable, structured, fast. And when we checked whether models actually cited them, the answer was almost never.
The problem was not the writing. The problem was the framing. We were asking “can a model answer this question from our content?” when we should have been asking three harder questions.
2. Question One: Visibility
The first question is the most basic one. Can a model retrieve you at all for the questions that matter?
This feels like a table stakes problem, and it mostly is. But I have found that teams skip past it. They assume that if a page is in the index, a model can find it. That is not how retrieval works.
When a generative model answers a question, it does not run a fresh web search. It relies on training data, retrieval augmented generation pipelines, or a combination of both. If your content is not in the corpus the model uses, you do not exist.
For training data inclusion, the requirements are the same as traditional crawlability. Your pages need to be findable by crawlers. They need to render properly. They need to load fast enough that a crawl budget is not wasted on timeouts. And they need to be text heavy enough that a model has something to extract.
For RAG pipelines, the bar is different. Many RAG systems use a curated index. They pull from a specific set of sources. If your domain is not in that set, your content does not get retrieved. This is a distribution problem, not a content problem. You need to be in the places where models look.
I have worked on catalog sites that passed a technical audit and still sat invisible in a long tail of pages. Crawl errors close to zero. A valid sitemap, submitted and accepted. Canonicals pointing at the right URLs. Fast server response. No accidental noindex. Good mobile rendering. And still a slice of the catalog earned almost no impressions. Not because the pages were bad. Because machine retrieval barely reached them. Clean plumbing is not the same as reachability.
Visibility is the gate. If you are not visible, nothing else matters.
3. Question Two: Entity Understanding
The second question is subtler. Does the model know what you are, what you sell and where you operate?
A model that can retrieve your page is not the same as a model that understands your page. Language models build representations of entities. They learn that a brand name refers to a specific company, that a product category maps to a set of attributes, that a location has a geographic context. If your content does not reinforce those connections, the model may include your text without associating it with you.
This is where structured data matters more than most SEO practitioners give it credit for. A JSON-LD block that tells a model your organisation name, your logo URL, your social profiles and your physical address is not just for search engines. It trains the associations that models carry forward.
Consistent naming matters too. If your brand is called “GlobalTours” in one place and “Global Tours Inc.” in another and “GT Experiences” on social media, a model may treat each as a separate entity. The same applies to products. If you sell a “Premium City Walking Tour” on your site and call it a “Guided City Walk” in a press release, a model has to guess they are the same thing.
I have seen this play out in practice. A site that used three different names for the same product category across different sections. Models that cited the site often attributed the information to the wrong entity. The content was visible. It was just not attached to the right thing.
Unambiguous pages help. A page about “London” could be about the city, a tour, a hotel or a flight. If your page title, headings and structured data do not clarify which one you mean, a model may apply your content to the wrong context. Be explicit. Say “London Walking Tours” not just “London.”
4. Question Three: Right to Win
The third question is the one most content strategies ignore. Is there a reason to recommend you over a general answer?
This is where the model acts like a gatekeeper. When a user asks “what is the best time to visit Japan,” a model can synthesise an answer from general travel guides. It does not need your specific opinion. But when a user asks “what is the cancellation policy for a tour booked last week,” the model needs a specific answer from a specific provider. You have the right to win that query.
Right to win comes from ownership. First hand data. Real inventory. A specific segment that only you serve. A real experience that you documented.
The marketplace I work on has a clear right to win on queries about specific travel experiences. When someone asks about a particular tour in a particular city, the model needs information that only the provider and the marketplace have. Availability. Pricing. Real traveller reviews. The general web does not have that data.
But right to win is not automatic. You have to make that data accessible. If your inventory is behind a login wall or a JavaScript render that models cannot parse, you have the data but the model cannot reach it. The right to win exists in your database but not in the model’s corpus.
I have found that the most effective GEO strategies are built on this question. Instead of asking “what can we write about,” ask “what do we own that no one else does.” The answers are usually smaller than you think. A handful of topics where you have unique data, real inventory or genuine expertise. And those handful of topics will outperform a thousand generic pages every time.
5. What to Stop Making
If you apply these three questions to your current content, you will find a lot that does not pass the test. Pages that answer a generic question with no ownership. Pages that are visible but not understood. Pages that a model can retrieve but has no reason to recommend.
The hard part is stopping. We are conditioned to believe that more content is always better. That query coverage correlates with authority. That a page that ranks for nothing is still doing brand building. These beliefs were questionable in traditional SEO. In GEO, they are actively harmful.
A page that answers “what is a walking tour” has no right to win. Every travel site on the internet has that page. Models already have the answer. Adding your version does not move the needle. It just dilutes your crawl budget and your editorial focus.
A page that describes your specific walking tour, with real prices, real availability and real reviews, has a right to win. No one else has that exact data.
I have seen teams cut their content volume by sixty percent and see better model citation rates. Not because the remaining pages were better written. Because the remaining pages had something the model could not get anywhere else.
Stop making content that answers a question. Start making content that documents something you own.
6. A Worked Example
Let me walk through how these three questions apply to a real scenario, generalised so it fits any reader.
Imagine you run a small adventure travel company. You offer guided hiking trips in Patagonia. You want generative models to recommend your trips when users ask about hiking in the region.
Start with visibility. Is your site crawlable? Do your trip pages have clean URLs, clear text content and proper HTML rendering? If a model’s training data or a RAG pipeline indexes your pages, will it find the full description or just a broken JavaScript shell? For many small operators, this is the biggest gap. The content is good. The site is just not built for machine consumption.
Next, entity understanding. Does the model know your company exists as a distinct entity? Do you have an encyclopedia entry, a company profile or even a consistent name across the web? If a user asks about “Patagonia hiking tours,” will a model associate your brand with that category? Structured data on your site helps. So does consistent external mentions. If your brand is mentioned on travel forums, local tourism boards and social media with the same name and URL, the model learns the connection.
Finally, right to win. What do you own? You own specific trip dates. You own real pricing for those dates. You own traveller reviews from people who actually took your trips. You own photos from your actual routes. A model can describe Patagonia hiking in general terms from a dozen sources. But it cannot tell a user what specific trips are available next month, what they cost and whether past travellers liked them, unless your data is accessible.
Most companies skip straight to right to win without checking visibility and entity understanding. They have the data but the model cannot find it. Or the model finds it but attributes it to a competitor. The three questions are a stack. Each one depends on the one before it.
7. How to Test Each Layer
You do not need expensive tools to test these three layers. You can run quick manual checks this week.
For visibility, take your top ten topic pages and paste their URLs into a model’s chat interface. Ask it to summarise what is on each page. If the model gives a generic answer or says it cannot access the URL, you have a visibility problem. Try the same test across a few different models. The results will vary. That is the point.
For entity understanding, ask each model “what does [your brand name] do?” and “where is [your brand name] based?” If the answers are wrong, vague or inconsistent across models, your entity signals are weak. The fix is usually structured data and consistent naming.
For right to win, ask a model a question that your unique data answers. “What specific [product category] are available on [date]?” or “What do recent customers say about [your specific offering]?” If the model defaults to generic advice, your data is not reaching it.
These tests are not scientific. But they give you a directional answer in an afternoon. I have run them on projects and found that the visibility and entity understanding layers were the real bottlenecks, not the content quality. Teams were investing in better writing when what they needed was better structure.
8. Pitfalls
The biggest pitfall in GEO is treating models as a monolith. They are not. A query that triggers a citation from one model may get a synthesised answer from another. Training cutoffs differ. RAG pipelines differ. The same content strategy will produce different results across different interfaces.
I have seen teams optimise for a single model, usually the most popular chat interface at the time, and lose relevance when the next model launch changed the retrieval dynamics. Do not over fit to one interface. Test across at least three.
Results also move between runs. The same prompt on the same model can produce different answers on different days. This is not a bug in the model. It is a feature of the sampling process. But it means that a single positive test is not a strategy. You need repeated testing over time to know whether your changes actually moved the needle.
Another pitfall is confusing citation with recommendation. A model can cite your content in an answer and still recommend a competitor. The citation means you were retrieved. It does not mean the model chose you. Right to win is the layer that turns citation into recommendation.
Finally, do not over interpret a model’s refusal to cite you. Sometimes the model simply does not have your data. Sometimes it does but the retrieval pipeline did not surface it. Sometimes it surfaced it but the model decided a general answer was better. The three questions give you a framework for diagnosing which case you are in. Without the framework, you are guessing.
GEO is not a content volume problem. It is a positioning problem. Visibility, entity understanding and right to win. Ask those three questions before you write a single page, and you will know what to build and what to stop building.