What Is Generative Engine Optimization (GEO)? Search Optimization for AI Engines

Generative Engine Optimization (GEO) is the work of making a page readable, parseable and citable by generative search engines: ChatGPT, Claude, Perplexity and Google's AI overviews, to name the 4 that matter most right now. Where classic SEO chases a position in a result list, GEO chases a footnote inside an answer the engine writes for itself. That sounds like a small distinction. It is not, and the technical consequences are large: a page can hold the top organic position and never once surface in a generated answer.

This post covers optimization aimed specifically at AI engines rather than the broader future of search. The question is narrow and technical: how does a page get in front of a model that is composing an answer, in a form that model can actually use?

SEO, AEO and GEO are 3 layers, not 3 names for one job

SEO, AEO and GEO describe 3 different layers of the same work, and none of them substitutes for another.

SEO (Search Engine Optimization) is built around a page appearing and ranking in a list of results. The winning unit is the page, and success is the click.

AEO (Answer Engine Optimization) targets the page being selected as the answer itself. The winning unit shrinks: it becomes a short passage that resolves the question on its own. AEO turned into a separate discipline as voice assistants and featured answer panels spread.

GEO (Generative Engine Optimization) deals with the case where the engine writes the answer from scratch, merges several sources, and lists them as footnotes. The winning unit shrinks a second time, down to a single claim at sentence level. The engine does not take your page; it takes your claim, sets it beside claims from other sources, and produces one piece of text.

GEO sits on top of SEO rather than replacing it. A page that cannot be crawled cannot be cited, so classic technical hygiene is a precondition. The measurable part of that hygiene is defined in the Core Web Vitals documentation: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1, with all 3 thresholds met at the 75th percentile of page loads. A server that answers slowly loses you the classic crawler and the answer-engine crawler in the same request.

How AI engines read a page

AI engines reach a page along 2 routes. The first is crawler bots: clients such as GPTBot, ClaudeBot and PerplexityBot walk sites on a schedule and store the content on their side. The second is a live fetch at question time, where a user asks something and the engine downloads the relevant addresses right then. Both routes end in the same event: an HTTP request hits your server, and the returned text gets processed.

The most common mental error at this point is assuming the model sees the page. It consumes text. Design, visual hierarchy, a warning box marked out in color, a table baked into an image, a diagram with no alt text: none of that exists on the model's side. The more of your meaning you entrust to visual layout, the less of it survives the trip.

The retrieved text then gets split. The engine stores the page as independent chunks rather than one block, and pulls back whichever chunk sits closest to the question. For content that has exactly one consequence: every section has to stand up on its own. A paragraph opening with "as we explained above" turns into noise the moment it is separated from its context, and it loses its chance of being selected.

A second gate sits at the access layer: robots.txt. The behavior of that file was standardized in September 2022 by RFC 9309, which formalizes the protocol Martijn Koster defined in 1994. The rules are specific. A crawler must not use its cached copy for longer than 24 hours, must parse at least the first 500 kibibytes of the file, must treat a 400-499 response as an undefined file and the site as open, and must treat a 500-599 response as a full disallow. AI crawlers arrive under their own user-agent names, and on plenty of sites those names are either blocked outright or swept up unnoticed by a broad rule written years earlier. Bot protection layers produce the same result from a different direction: the page opens for a human and closes for a bot.

With that gate shut, every other piece of GEO work is decoration. The same pipeline governs AI agents operating on the web, which read the raw response rather than a rendered browser window.

The JavaScript problem: a full page in the browser, an empty page for AI

JavaScript-generated content is the most concrete and most overlooked failure mode in GEO, for one reason: the major AI crawlers do not execute JavaScript. If your content is assembled on the client, the page that looks flawless in a browser is close to blank on the engine's side. The response carries a menu, a footer and an empty container waiting to be filled. The text itself is missing.

It shows up in 5 patterns:

• Content fetched by an API call after the page opens, then injected into the document
• Text parked behind tabs, accordions or "read more" toggles
• Lists loaded piece by piece through infinite scroll
• Cookie or region consent layers positioned in front of the content
• Single-page applications rendered entirely on the client

Diagnosis is straightforward. Download the page without executing JavaScript, count the text in the body of the HTTP 200 response, and compare it against the text a browser shows. In our own audits we treat a page as at risk once the raw HTML text falls below the 40-60% band of the rendered text, and as practically empty for AI engines once the ratio drops under 20%. The gap between those 2 measurements is a direct measure of what the engines never receive.

Teams miss this because Google's own crawler renders JavaScript. The page shows as indexed in Search Console, it holds a ranking, and everyone concludes the setup is healthy. The generative engines run a separate fetch pipeline, and on that pipeline the same page comes back blank.

The fix is architectural: the main content has to be present in the first HTML response. Server-side rendering (SSR) or static generation (SSG) does that job. Keeping critical text out from behind interactions, publishing important facts as text instead of images, and refusing to park content behind consent walls serve the same end. We covered how rendering decisions are shifting in how generative AI is changing web development.

Here we will be blunt, at the risk of arguing with a large part of the marketing industry. If your content ships client-side only, no amount of content work fixes your GEO. The first ticket belongs to an engineer, and a content retainer sold on top of a client-rendered site is billing for a problem it has no ability to touch.

How citability gets built

Citability is the set of properties that make an engine pick your page as a source while it composes an answer. The selection criterion is not "well written." It is safe to repeat. Text that travels well carries 6 distinct properties.

The answer comes first. The first sentence or two under every heading has to answer that heading's question unaided. Reasoning, detail and exceptions follow. A warm-up paragraph hands the engine nothing.

Headings match real questions. "Our solutions" answers no question anyone has ever asked. "How is GEO measured?" is the exact match for one.

One claim per paragraph, with its own context attached. The chunk that gets quoted will be read without the rest of the page around it.

Claims are bounded and conditional. "The best solution" cannot be verified, so it cannot be repeated. "Under these conditions this method is preferred" is a verifiable statement.

Structure beats prose. Tables, numbered steps and definition lists ease the work for a human reader and a model at the same time.

Terms get defined. Expand an acronym the first time it appears. When the model finds the definition on the page, it stops guessing at your subject.

What schema markup does, and what it does not

Schema markup, meaning the schema.org vocabulary written mostly as JSON-LD, is an extra layer that tells a machine outright what the information on a page is. Whether a date is a publication date or an update date, whether a name belongs to an author or an organization, whether a block is a question-answer pair or a step list: all of it can be inferred from prose, and with schema there is nothing left to infer.

5 types carry most of the practical weight: Article for content pages, FAQPage for a frequently-asked section, HowTo for step-based instructions, Organization for corporate identity, and BreadcrumbList for navigation context. Required and recommended fields are documented per type; Google's FAQPage reference shows with sample code how question and answer fields have to line up. Fields that connect an organization's accounts across platforms help that identity get recognized as a single entity.

Consistency is the rule that decides whether any of this helps. Title, date and author in the schema must match what the page displays. A mismatch weakens credibility instead of strengthening the signal. The update date belongs in the same category: move it when the content actually changed, not on a schedule.

Schema is not a content improvement tool. Marking up a weak page does not turn it citable. It reduces ambiguity, and weak content with reduced ambiguity is still weak content.

How GEO gets measured

Measuring GEO is hard because generative answers are not deterministic. The same question gets answered from different sources in different sessions, and the result shifts with the user, the history and the model version. Measurement therefore resists collapsing into a single number, and splits across 3 layers.

1. The technical compliance layer. This is the only layer verifiable today, and it sits entirely under your control. Does robots.txt allow answer-engine crawlers? How much of the content is actually present in the HTML the crawler receives? Does the page give clear answers? Is a freshness signal stated? Each of those questions gets answered the same way for every page, which makes the layer repeatable.

Measuring it by hand works and turns tedious the moment you repeat it per page. Lekta, the tool TecnoNest built for this job and currently in beta, fetches an address the way AI crawlers receive it and returns a grade between A+ and F. It measures 4 weighted layers: access (25%), whether robots.txt permits answer-engine crawlers; indexability (25%), how much of the content survives in the HTML the crawler gets; answerability (30%), whether the page offers clear statements an engine can quote; recency (20%), whether the page states when it was last verified. Access and indexability together account for 50% of the grade, so half the score comes straight out of technical reachability. The tool runs 2 separate fetches, a plain GET with no JavaScript and a full Chromium render, and reports the content ratio between them. That ratio is the direct measure of the JavaScript gap. When a heading cannot be measured the grade is marked partial, because not knowing is not the same as failing.

2. The server log layer. Whether AI crawlers actually arrive, which addresses they pull and which status code they receive is visible in server logs. That is a record, not an estimate. What to look at is specific: how many bot requests got 200, how many got 403, how many 404 and how many 500. A bot you believed you had allowed shows up as blocked here first.

3. The outcome layer. Tracking whether your brand and domain appear in generated answers takes a fixed question list, asked to the engines on a schedule with every answer recorded. In our own work we run a fixed list of 20-30 questions and repeat it every 4 weeks; the trend becomes readable only after 3 measurements, which is 3 months of data. A single measurement carries no meaning. What carries meaning is the movement of the same questions over time. Alongside that, referral traffic arriving from AI products should be tracked in site analytics as its own channel.

What GEO will not do for you

Most GEO efforts fail because nobody wrote down what does not work, rather than because nobody knew what to do. The honest frame: GEO is not magic. Technical compliance removes obstacles, and it guarantees nothing about getting cited.

A page that is not a source does not get cited. The engine finds the same information in dozens of places. It needs a reason to pick you: an original measurement, an observation from the field, a clearly stated method. Explaining what everyone already knows, only tidier, is not a reason.

Publishing model output verbatim produces nothing. Handing a model text that a model wrote gives it back what it already had. A page that adds no distinguishing information cannot be distinguished in the source pool.

Keyword repetition fails here completely. The engine looks for a transferable claim, not a string match. Repeating the same term 20 times does nothing beyond making the text worse to read.

Schema markup does not rescue content. This came up above and it is worth stating twice: markup does not bring into existence information that was never written.

Being cited does not always bring a click. In generative engines the user takes the answer where it stands and leaves without visiting the source. Brand visibility and session count are separate metrics, and reading them in the same table produces wrong conclusions.

Results fluctuate. A page cited one week goes uncited the next. That is not the work failing. That is the reason measurement should never be a one-off: asking the same question in 5 separate sessions gives a far more reliable picture than a single attempt.

GEO is not a short campaign. It is continuous work in which content and technical infrastructure get put in order together, and the order matters, because the technical layer gates everything above it. To work out which layer that work should start from in your organization, the headings on our solutions page are a reasonable place to begin, or get in touch and we will run the first audit with you.

Frequently Asked Questions

Is GEO replacing SEO?

No. GEO is a layer built on top of SEO. A page that cannot be crawled, opens slowly or is technically broken will not be cited by generative engines either. Classic technical SEO hygiene is a precondition for GEO; what gets added on top of it is citability and access without JavaScript execution.

Are AEO and GEO the same thing?

They are close relatives and not the same thing. AEO (Answer Engine Optimization) targets your page being selected as the direct answer to a question. GEO targets being cited as a source inside an answer the engine assembles and rewrites from several sources. In AEO your answer is shown as it stands; in GEO it is blended with other information and you receive a footnote. The content requirements converge on the same 3 items: a clear answer, a section that stands alone, and a verifiable claim.

What do I have to do for my brand name to appear in ChatGPT?

3 gates open in order. Access first: robots.txt and your bot protection layer must not block crawlers such as GPTBot. Readability second: your content has to be present in the HTML that arrives without JavaScript execution. Citability third: your pages have to offer clear, bounded statements an engine can repeat safely. None of the 3 guarantees a citation on its own, and missing any one of them is a hard stop.

My site runs on React or Next.js. Is that a GEO problem?

The library is not the deciding factor; the rendering mode is. If content arrives in the first HTML response through server-side rendering (SSR) or static generation (SSG), there is no problem. If content is assembled only on the client, the page that looks perfect in a browser stays empty for AI engines. The check takes 1 command: download the page without executing JavaScript and compare the returned text against what the browser shows.

Should I allow AI crawlers in robots.txt?

This is a choice with a clear consequence: block them and you will not appear as a source in generative answers. For organizations that do not want their content used by models, blocking is a coherent decision. For organizations chasing visibility, blocking invalidates the entire GEO effort. Crawlers can be named individually in the file, so a single blanket rule covering all of them is not required.