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.

Monthly GEO plans

GEO does not end like a one-off project, because answer engines, models and competing content change every month. That is why, after the audit and the first round of implementation, we continue the work on a monthly plan. There are three plans, and each one builds on the previous one. Which one fits depends on whether your team can implement the findings itself and whether you want to connect demand from AI search to sales. The scope of each plan is fixed; the price is set in a quote based on the size of the site, the number of languages and the number of tracked questions.

Monitoring: measure and report

• An initial audit and a recorded baseline that every later measurement is compared against
• A fixed question list specific to your business, measured every month with repeated runs on ChatGPT, Perplexity, Gemini and Google AI Overviews
• Share of voice, plus a list of questions where competitors are cited and you are not (citation gap)
• Tracking of three competitors you choose, on the same questions and in classic search
• Reading server and CDN logs to see which pages AI crawlers fetch and how often
• Traffic from answer engines tracked as a separate segment in GA4 and Search Console
• A monthly report that ranks findings by cost and impact

Monitoring and implementation: measure and fix

Everything in the Monitoring plan, plus implementation of the findings on our side. This is the difference from a service that only delivers reports: a gap found in one report shows up as closed in the next.

• A fixed monthly engineering allocation to implement findings in your repository: structured data, llms.txt, robots.txt policy, sitemap and IndexNow
• Rewriting passages on pages that map to uncited questions so they can be quoted on their own, and fixing internal links
• A monthly technical health check: PageSpeed and Core Web Vitals, broken links, indexing and redirect errors
• One or two guide articles updated or newly written each month

Growth: measure, fix and connect to revenue

Everything in the Monitoring and implementation plan, plus off-site authority and connecting demand from AI search to sales. A large share of the pages answer engines cite are not the brand's own site, so this plan goes beyond your website.

• Creating and updating profiles with real project information on directories and platforms that answer engines cite often
• A process for pitching expert articles and commentary to industry publications
• Google Business Profile management and a process for requesting unincentivised customer reviews
• Tracking sessions from answer engines through to the form, the CRM and the quote; this part is built on our RevOps setup
• A monthly "which engine, how many leads, which quotes" report and a strategy call every quarter

What every plan shares

The monthly report has the same four sections in every plan: what was done this month, AI visibility and search performance, competitor status, and next month's plan. The first month goes to setting up access and recording the baseline; comparisons become meaningful from the second month on. At the end of month twelve the audit is repeated from scratch and the result is put side by side with the baseline from day one. No plan comes with a guarantee of appearing in a particular answer. What you get is a written record, every month, of what was measured, what changed and what was done.

To see which plan fits, you can start with a free preliminary analysis: we run ten questions about your brand on four answer engines and send you, in writing, where you are cited, where competitors appear instead, and the three biggest technical gaps. You can send your request through the quick quote form.

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.