Your GEO configuration step by step from scratch

Why start with infrastructure and not with tools

When someone decides to learn GEO (Generative Engine Optimization) from scratch, the most common mistake is jumping straight into trying out platforms for monitoring mentions in conversational assistants. That path leads to frustration: without an orderly technical foundation, there is no way to know whether a generative model cites your brand on its own merit or by chance. The step-by-step configuration I describe here starts from the opposite premise: first you prepare the documentary and technical groundwork, then you measure.

GEO is not SEO under another name. According to the documentation published by the generative search teams themselves, the systems that build answers (RAG, retrieval-augmented generation) split content into chunks, vectorize them, and retrieve them by semantic similarity before writing. That changes the rules: you are not competing for a position in a list, you are competing to be the retrieved and cited chunk.

Step 1: entity inventory before touching a single tag

Before installing anything, you need to know which entities (people, products, concepts, locations) represent your project. Open a spreadsheet and create four columns: entity, type, canonical source (your own or external URL), and alternative terms people use to name it.

A specific case I often come across: a consultancy with a registered trademark and a trade name different from its domain. Conversational assistants tend to merge both identities if there is no “About” page that explicitly connects them with structured data. That detail, which went unnoticed in classic SEO, in GEO causes services you don’t offer to be attributed to you or makes you be confused with a namesake competitor.

How to validate the inventory

• Ask two or three different assistants (not just one) about your brand and write down the answers verbatim.
• Compare what they say with your inventory: every discrepancy is a configuration task.
• Don’t correct anything yet; just document. The temptation to publish new content before diagnosing is the number one cause of wasted effort.

Step 2: content architecture designed for retrievable chunks

Generative engines retrieve passages, not complete pages. If your content lives in 400-word paragraphs without subheadings, the automatic chunker will cut where it shouldn’t and you will lose context. The practical configuration consists of:

1. One H2 per real question. Each heading should phrase the doubt the way a user would write it, not the way your marketing department would name it.
2. Direct answer in the first two sentences under each heading. The rest of the block expands, qualifies, and provides examples.
3. Self-contained blocks of 80 to 150 words. If a chunk is extracted from its context, it must still make sense on its own.

Here it is worth being honest about a limitation: there is no universal optimal chunk size. Different retrieval systems apply different chunking strategies and are not publicly detailed. Working with semantically closed blocks is a reasonable heuristic, not a guarantee.

Step 3: structured data that connects entities, not just decorates

Most GEO guides mention schema markup as a general requirement. What matters is which types to use and how to link them. A coherent minimum configuration includes:

• Organization with sameAs pointing to verifiable official profiles.
• Person for real authors, with knowsAbout declaring areas of expertise.
• Article or FAQPage depending on the page type, with correct author and dateModified.

The frequent mistake: declaring sameAs toward profiles you don’t control or that don’t mention your brand. That doesn’t reinforce the entity, it dilutes it. Verify each URL before including it.

And a warning that rarely appears in tutorials: structured data does not guarantee that a generative model will cite you. They help with entity disambiguation when the system consumes them, but the behavior of each assistant varies and there is no access to its internal weighting criteria.

Step 4: technical accessibility for generative crawlers

If retrieval bots cannot read your content, none of the above matters. Set up these checks in this order:

1. Review the robots.txt file and confirm that you are not blocking retrieval user-agents by default. Many CMSs include inherited rules that should be audited.
2. Check rendering. If your content depends on JavaScript to appear, verify what a client without script execution sees. The official documentation of the main engines insists that the initial HTML must contain the main text.
3. Measure server response time. Retrieval systems have time budgets; a high TTFB can exclude you from retrieval even if your content is excellent.

A detail from real experience: in a project with a misconfigured CDN, requests from certain user-agents received a challenge page instead of the content. In the browser everything seemed correct because the visitor’s cookie resolved the challenge. Only when making clean requests with curl was the problem detected. Always set up a test without cookies or session.

Step 5: source content that models can cite with confidence

GEO rewards verifiability. Generative systems, when building answers with citations, prefer sources with clear signals of authorship and updating. Your editorial configuration should include:

• An author page with real, verifiable data, without invented credentials.
• Publication and last revision dates visible and consistent with the schema.
• References to primary sources within the text (official documentation, industry studies) without broken links.
• An accessible editorial policy explaining how content is corrected.

This doesn’t work the same for all sectors. In YMYL topics (health, finance, legal) the requirement for documentary backing is much higher and content without sources will rarely be retrieved with confidence. In contrast, in leisure or hobby niches, well-narrated personal experience can compensate for the absence of academic citations.

Step 6: system for measuring mentions in assistants

This is where most people get lost. There is no Search Console for GEO. The realistic configuration consists of building your own tracking panel:

1. Define a fixed set of 20 to 40 prompts representative of your topic, written the way a user would write them.
2. Run those prompts periodically in the assistants you are interested in, from clean sessions (without history that biases the answer).
3. Record three variables per prompt: whether they mention you, whether they cite you with a link, and whether the description is correct.
4. Repeat the measurement at the same cadence and note the date, because models are updated without notice.

An important and rarely mentioned limitation: results are not reproducible. The same prompt can return different answers in two consecutive runs due to the stochastic nature of the models. That is why you need several repetitions per prompt and to analyze trends, not snapshots. Any tool that promises exact AI visibility metrics deserves skepticism.

Step 7: improvement loop with judgment

With the panel data, identify patterns: what type of questions cite you, what content format appears in competitors’ answers, what associated entities recur. Then prioritize small, measurable interventions:

• Rewrite a block to directly answer a question where you don’t appear.
• Add a comparison with your own data where assistants resort to third parties.
• Correct a wrong attribution through explicit content and updated schema.

Don’t expect immediate results. The update cycles of retrieval indexes are not public and vary. Plan monthly reviews, not daily ones.

What this configuration does not solve

Being transparent about the limits saves months of misdirected work. This methodology does not guarantee appearances in assistants, does not control how they describe you, and does not replace classic SEO: they remain different channels with different mechanics. Nor is there solid public evidence on the relative weight of each signal in generative systems; what works today may change when providers adjust their retrieval pipelines.

If your project is small and has limited resources, prioritize steps 1, 3, and 4. They are the ones that correct structural errors that are difficult to reverse later. The rest can be iterated over time, as long as you maintain the discipline of measuring before changing.