GEO - Generative Engine Optimization

AI engines do not rank pages. When they answer a question they choose which sources to read, blend sentences from them into an answer of their own, and often put a few links underneath. The target is therefore not "position three" but being one of the sources named inside that answer. The conditions differ from classic ranking: the model has to find the page, understand what it is about without guessing, and still be correct when it lifts a single paragraph out of its surroundings. Detartech's GEO work is building those three conditions into a site one by one. We did the same on our own site, so most claims on this page can be opened and checked on detartech.com.

How we define GEO

GEO stands for generative engine optimization: making a site usable as a source by answer engines such as ChatGPT, Perplexity and Google AI Overviews. The work has two layers. The first is machine readability: the model and its crawler find the site, can tell what each page is, and never have to guess while parsing content. The second is citability: a paragraph stays correct, complete and attributable once it is pulled off the page. There are things we do not do: hidden instructions for the model, text visitors cannot see, invented authors and dates. Those violate search guidelines and are the fastest way to lose the trust signal you were building. For how answer engines work and the technical roadmap, see our GEO guide.

How we open a site to AI engines

The six headings below cover everything a GEO engagement contains. The first two are discovery and meaning: machine-readable files that let the model find the site, and structured data that removes ambiguity about what a page is. The third is who the source is, the fourth is which crawler may enter and why. The fifth is the text itself: whether a passage can be quoted on its own. The sixth goes past reading, giving agents that act on the site tools they can call directly. Most projects start with the first five.

llms.txt and a machine-readable site map

llms.txt is a markdown index at the root of a site that tells a model which addresses to look at while reading it. What goes inside is not a copy of the navigation menu but addresses that genuinely exist, each with one line saying what it is; one address that does not resolve makes the whole file untrustworthy. The same layer carries JSON endpoints such as a service list, an FAQ file and an API catalog, where a machine gets an answer without parsing a page written for humans. The sitemap error we correct most often is fake freshness, where every page gets today's lastmod on every deploy; that empties the date information across the site within weeks. Rather than wait for a changed page to be crawled, we announce it through IndexNow.

Schema.org structured data

Structured data is the JSON-LD block that tells a machine what a page is. We use Organization for company information, WebSite across the site, Article on blog posts, HowTo on step-by-step instructions, FAQPage on question and answer blocks and BreadcrumbList on navigation paths. The part nobody sees is entity disambiguation: unless the company name, address and outside profiles are tied together with sameAs, a model may read them as two separate entities. One rule is not negotiable: the schema has to match the text visible on the page. Marking up questions that do not appear on the page buys a penalty, not visibility. Every schema goes through a validator before it goes live, because a single malformed field can stop the whole block from being read.

E-E-A-T signals

E-E-A-T stands for experience, expertise, authoritativeness and trustworthiness, the signals search systems weigh when judging whether content can be trusted. Answer engines apply a similar logic and look at who said a sentence before they quote it. So an author page points to a real person, their real expertise and a way to reach them; publication and update dates are honest; and when a claim rests on an outside source, that source is named in the text. On the company side the legal name, address and contact details are kept identical on every page, because a name spelled differently in different places weakens the identity signal. Part of this heading is not our work but yours: without real authors, real experience and verifiable cases, these signals cannot be manufactured.

AI crawler access policy and robots.txt

Here robots.txt is a commercial decision, not a technical detail: which crawler may enter your site, and for what. Three groups have to be separated: crawlers collecting content for model training, crawlers feeding a search index, and crawlers fetching a page on a user's behalf the moment they ask. Closing the training crawler while leaving the answer-time crawler open is a coherent position; closing all three also closes your chance of appearing in answers. We put the decision in writing and spell the rules out crawler by crawler, because a policy left to a wildcard makes it arguable later who was allowed what. And robots.txt is not always the file you wrote: managed blocks inserted by a CDN can sit above your own rules, so we verify the policy from the live file, not the repository.

Citable passage architecture

An answer engine does not take a page whole; it lifts one section out of it. Every block under a heading therefore has to stand on its own: the answer in the first sentence, the definition before the elaboration, a number in the same sentence as its unit and date, and no backward references of the "as explained above" kind. The test is simple: cut the paragraph out of the page and read it alone. Is it still correct and understandable? If not, it will never end up inside an answer. The FAQ block follows the same logic, using the question a buyer actually asks rather than a decorative marketing one. This page itself was built to that rule.

WebMCP and agents that use the site

Agents no longer only read sites, they act on them. WebMCP is the approach in which a site offers a visiting agent callable tools instead of text to be parsed. On our own site those tools are not declared a second time by hand: the browser agent takes the tool list from the site's own MCP endpoint, so the two surfaces cannot drift. Every registered tool is read-only, and the contact and quote forms stay exposed as declarative form tools, which keeps a human in front of the form before submission. An RFC 9727 API catalog separately tells machines which interfaces exist. To be honest, WebMCP today runs only in Chrome and only as a trial; we do not sell it as a traffic promise but as a layer that builds tomorrow's interface today. Details are in our WebMCP article.

How GEO differs from SEO and where they overlap

SEO competes for a place in a list of ten blue links; GEO competes to be one of the few sources a model reads while composing an answer. The overlap is wider than people assume: crawlability, page speed, correct HTML, a clean sitemap, sane internal linking and content that carries actual information are shared ground. A site Googlebot cannot see is largely invisible to AI crawlers too, so we do not sell GEO as a replacement for SEO. Divergence starts in two places. The unit: SEO optimizes a page, GEO optimizes a passage, so the decisive factor is not keyword density but whether one paragraph is complete on its own. The outcome: an AI answer can satisfy a user without a click, so session count alone stops being a measure of success. Technical work and content architecture on the classic search side are a separate service, described on our SEO page.

How we measure visibility

We split measurement into four layers. Crawling: server and CDN logs show which AI crawler fetched which addresses, how often and with what status code, which is a record rather than an estimate. Citation: a fixed list of questions specific to your business is run against answer engines at set intervals, and we record whether the brand appears and whether it was linked. Referral: traffic arriving from answer engines is tracked as its own segment in analytics. Conversion: we track whether those sessions filled a form or asked for a quote. We state the limit of the second layer up front: answers vary by user, session, region and model version, so what we measure is not a rank but a trend read across repeated runs. How the dashboard is built and which indicators we follow is in our article on measuring AI visibility.

The factors that determine the outcome

An answer engine's response to the same question is not fixed: it varies by user, session, region and the model version running at that moment. A change can reach the crawlers that fetch a page at answer time within days; the same change entering the trained model itself depends on that model's release cycle. Because of this variability, we treat measurement as a recurring exercise rather than a one-off check: a fixed question list runs on a schedule, and the result reads as a trend across repeated runs rather than a single snapshot. Markup does not change this mechanic either, it only makes it easier for the model to read information that is already there; if a paragraph carries nothing that twenty other pages do not, no schema makes it citable on its own.

How a GEO engagement runs

The work starts with an audit of what is actually live: robots.txt, the sitemap, llms.txt, whether the schemas validate, whether we can reach crawler logs, and which questions will be measured. The output is a written list ordered by cost and impact, deliverable on its own. Implementation comes second: files and markup go into your repository and onto your own domain, not into an intermediary on our servers. We run in two-week cycles, each ending with the changes that went live reported alongside the measurement result. Measurement comes third: a baseline before implementation, the same question list repeated afterwards. Nothing switches off when the engagement ends. llms.txt, the schemas and the robots rules stay on your site, and the question list and measurement sheet are handed over.

What can be verified from outside

Every item below is live right now and can be verified from outside.

• detartech.com, machine-readable layer: llms.txt, an RFC 9727 API catalog, ai/service.json and .well-known/ai.txt are published. The same page is also returned as markdown rather than HTML to a client that asks for it.
• detartech.com, agent interface: WebMCP tools are registered from the tool list of the site's own MCP endpoint and are all read-only. The contact and quote forms are exposed as declarative form tools, so a human stays in front of the form before submission.
• SanalRandevu: llms.txt, robots.txt rules naming 18 AI crawlers one by one, Organization, WebSite and HowTo structured data, and fast indexing through IndexNow are all published.
• bebekistiyorum.com: a content archive of more than 1200 URLs in 4 languages was optimized for AI-assisted search such as ChatGPT and Perplexity alongside classic search.