Generative Engines Retrieve Passages, Not Pages
A classic search engine returns a ranked list of documents and the click is the product. A generative engine does something structurally different: it rewrites your question into one or more retrieval queries, pulls back a few dozen candidate passages, reranks them, and then writes an answer constrained to the text it retrieved, with citations attached. The unit of competition is the passage, not the page. You are no longer trying to occupy position three; you are trying to be one of the five to ten chunks a model decides to quote. That shift changes what counts as good content at the paragraph level, and which engineering work on your site actually pays.
It helps to hold the pipeline in your head. The query is expanded and often rewritten, so the phrasing you optimised for may never be issued. Retrieval runs against an index, usually a commercial search API rather than the engine's own crawl. A reranker narrows the candidate set. Generation happens over the surviving passages, and a citation is emitted because a sentence traces back to one of them. Your page therefore competes twice: once to be retrieved, and once to be selected as the passage worth quoting. The same logic governs AI agents that browse on a user's behalf, which is why agent traffic behaves the same way.
The commercial consequences follow from the shape of the output. An answer cites a handful of sources, so the distribution is far more winner-take-most than a page of ten blue links. Many answers resolve the user's question outright, which means brand impressions with no session in your analytics. When a click does arrive it tends to be late-funnel, because the model has already done the comparison work. None of this makes traffic irrelevant, but it does mean a site can be losing sessions while gaining influence, or gaining sessions while being quoted by nobody. Measuring only one will mislead you, which is why we treat visibility and traffic as separate instruments.
GEO, SEO and AEO: What Actually Changes
Three acronyms describe roughly one job. Search engine optimisation aims at ranked document retrieval. Answer engine optimisation was the name people used when the target was featured snippets and voice assistants. Generative engine optimisation, GEO, aims at being cited inside a synthesised answer. The honest summary is that most of GEO is competent SEO plus extractability. If a crawler cannot fetch your HTML, if your canonical tags contradict each other, if your internal linking leaves half your library orphaned, no amount of writing for models will save you. The foundation is identical, and any vendor telling you GEO replaces SEO is selling a rebrand, not a technique.
What genuinely differs is worth listing precisely. First, self-containment: a passage that opens with a pronoun referring to the previous paragraph becomes useless the moment it is chunked out of context. Second, the missing rank: there is no position to track, only a probability of appearing, so measurement becomes sampling rather than reading a number. Third, query mismatch: retrieval frequently runs on a rewritten query, which strips most of the leverage out of exact-match keyword work. Fourth, entity clarity: the engine needs to know what your company is, where it operates and what it sells, and it assembles that from consistent descriptions across many sources, not a title tag.
It is equally worth naming the parts that are theatre. Stuffing pages with the phrase artificial intelligence does nothing. Writing in a flat, robotic register because you imagine a model prefers it does nothing, and it costs you the human readers who sign contracts. Paying a retainer for a GEO audit that is a crawl report with a new cover page does nothing. We would tell a buyer to spend the first budget on the render layer and on rewriting the twenty highest-intent pages for extractability, and to treat anything sold as a proprietary GEO score with suspicion until the vendor explains, in detail, which prompts they run and how often.
What Earns a Citation
The most reliable structural change is putting the answer first. Each section should open with a passage that answers its heading directly, in plain declarative sentences, before the context and the caveats. Retrieval systems split documents into chunks that typically land between 200 and 800 tokens, and the split does not respect your rhetorical build-up. A useful test: take any paragraph, read it with no heading and no neighbours, and ask whether it still states something complete. If it needs the paragraph above it to make sense, it will be retrieved and discarded. Definitions deserve the same treatment, written as a single sentence that could stand as a dictionary entry.
There is empirical support for these specifics. The KDD 2024 paper on generative engine optimisation, by researchers at Princeton, Georgia Tech and IIT Delhi, reported visibility gains of up to 40 percent from content changes, roughly 41 percent from adding statistics to a passage, and up to 115 percent for lower-ranked sources that cited authoritative references. Read those numbers as direction rather than as a promise: they were measured on a constructed benchmark, and the size of the effect depends heavily on the query and on how weak the starting position was. The direction is nonetheless consistent with what a retrieval pipeline rewards, which is passages dense with checkable specifics.
Off-site signals appear to work differently from the link graph. Ahrefs, in August 2025, looked at roughly 75,000 brands and found brand mentions correlated 0.664 with AI visibility, against 0.218 for backlinks. Correlation is not causation and the metric being predicted is itself noisy, but the result is at least consistent with a system that retrieves text from a broad corpus rather than walking a graph. The practical implication is unglamorous: being described, by name, on pages you do not control matters more than acquiring a link from them. Conference talks, public documentation, comparison pages, forum answers, job listings and vendor directories all feed the same corpus.
Two smaller factors round out the list. Structured data gives the engine an unambiguous statement of what the page is, when it was written and who wrote it, which matters when several sources disagree and recency breaks the tie. And engines increasingly read more than prose: multimodal models can parse a chart or a screenshot, so any figure locked inside an image should also exist as text, in a caption or a table, rather than only as pixels a model may not transcribe correctly. Neither factor will rescue a page with nothing to say, and both are cheap enough that skipping them is hard to justify.
The Crawl and Render Layer, Where Most Sites Lose
Before any of the content work matters, an automated client has to be able to read the page. AI crawlers vary in capability, and most of the ones that fetch pages to ground an answer issue a plain HTTP request and parse the returned HTML. They do not run your bundle, wait for hydration, or execute a data fetch on the client. A single-page application that ships an empty root element and paints its text after JavaScript executes therefore looks, to a large share of these clients, like a blank document. The test takes a minute: request the URL without a browser, strip the tags, and count the words that came back.
hatsontech.com is a static site. Every article is a complete HTML document on disk, so the first response contains the body, the headings, the internal links and the schema blocks. There is no client-side rendering anywhere in the article template, no lazy-loaded text, and no content hidden behind an interaction. That decision was not made for GEO; it was made because a marketing site with no server-side state has no business shipping a framework runtime. GEO made the payoff visible. If you are on a framework, the equivalent is server-side rendering or static generation for content routes, verified by looking at the raw response rather than at the browser.
Three supporting pieces sit alongside it. Every page carries a canonical URL, so parameterised and duplicated variants collapse to one address against which citations can accumulate. The XML sitemap lists both language versions of every article and uses alternate link entries to pair them. And robots.txt names GPTBot, ClaudeBot and PerplexityBot in explicit allow blocks rather than relying on default-allow, which costs nothing and removes the ambiguity of an implicit permission. One caveat we would flag to anyone: check the edge as well. Bot protection at the CDN layer will happily return 403 to a crawler your robots.txt just welcomed, and nothing in your robots file will tell you it is happening.
Bilingual Content and the hreflang Trio
Every article on the site exists twice, at an English URL under insights and a Turkish URL under the Turkish path, and the two point at each other. The annotation is a reciprocal trio: an alternate entry for Turkish, one for English, and an x-default entry that points at the Turkish version. x-default declares the fallback for a visitor or crawler whose language preference does not match either target. Pointing it at Turkish is a deliberate statement that the Turkish page is the primary edition, which is accurate for a company whose main market is Türkiye. The same pairing is repeated in the sitemap, so the relationship is discoverable without crawling both pages.
Language targeting carries more weight in generative answers than on a classic results page. A model answers in the language it was asked in, retrieval is generally issued in that language, and the corpus available in Turkish for a technical subject is far thinner than the English one. That asymmetry is exploitable. Ask an engine, in English, how vision systems are deployed for quality control on a production line and it will choose among thousands of credible pages. Ask the same question in Turkish and the candidate pool collapses to a few dozen, many of them thin restatements. A serious Turkish page competes against far weaker company for the same slot.
Two implementation rules follow. First, do not machine-translate and publish: a translated summary reads as a translated summary, and a passage that drops the numbers keeps none of the properties that earn a citation. Our Turkish articles carry the same figures, the same section structure and the same technical depth as the English, written rather than converted. Second, keep the languages on separate URLs with their own canonical tags; do not swap content by cookie or by IP geolocation on a single address. A crawler arriving from an unexpected region will index whichever version it happens to receive, and you lose control over what is attributed to which page.
Structured Data in Practice
Every article carries BlogPosting JSON-LD. The properties doing real work are headline, datePublished and dateModified, author and publisher, inLanguage, articleSection, and the main entity reference pointing back at the canonical URL. What this buys you is disambiguation. When an engine holds several candidate passages that contradict each other, publication date is one of the few machine-readable tie-breakers available, and language plus section tell it what kind of document it holds. The markup does not make a weak page strong. It makes a strong page unambiguous, which is a smaller and more defensible claim than most schema advice makes, and it is the only claim we would argue for.
BreadcrumbList states the hierarchy, from the site root through the article index to the article itself, so a machine does not have to infer structure from a URL. FAQPage is the more interesting one, because its payload is literally a list of question strings paired with self-contained answer strings. That is a pre-chunked question and answer set, handed over without requiring anyone to segment your prose correctly. Search engines have reduced how often they render FAQ rich results, and we would not add the markup for the rich result alone. We add it because writing six answers that survive being read in isolation is a useful discipline regardless of who consumes them.
The honest caveat: no major engine has confirmed that schema is an input to citation selection, so treat it as a low-cost disambiguation layer rather than a lever. Two rules keep it from turning into a liability. Never mark up a claim that does not appear in the visible text, because divergence between schema and body is a quality signal in the wrong direction and, occasionally, grounds for a manual action. And generate the markup from the same source of truth as the page body, so the two cannot drift. It is the same discipline as preparing data for a retrieval system: one source, one transformation, no hand-maintained copies.
The llms.txt Question, Answered Honestly
llms.txt is a proposed convention: a Markdown file at the root of a domain listing the URLs you consider important, each with a one-line description, so a language model can orient itself without crawling everything. It is not an adopted standard. No major engine has confirmed that it reads the file, and the claim that it improves AI visibility has no public evidence behind it. Anyone selling llms.txt generation as a service, or listing it as a priced deliverable in a GEO proposal, is charging you for a file you can write by hand in an afternoon. We say this as people who wrote one anyway.
Ours is hand-authored and structured in the obvious way. A title line naming the company, a short paragraph describing what it builds, then sections that mirror the site: solutions, products, articles in English, articles in Turkish. Under each section, one line per entry: a link followed by a single-sentence description of what the page covers. Nothing clever. The whole file was a few hours of work, and the only real cost was writing descriptions that do not repeat the title. That constraint was worth more than the file. Three articles could not be described in one honest sentence, which told us they had no single thesis.
So the recommendation is conditional and unexciting. Write one if it costs you an afternoon and you can regenerate it from the same index that produces your sitemap, because the downside is a stale file and the upside is optionality if adoption arrives. Do not buy a tool for it, do not let it displace render-layer or extractability work, and do not report it to a stakeholder as a completed optimisation. Cheap insurance is an accurate description. A ranking factor is not, and we would rather be the ones who told you than have you find out from an invoice. A file existing is not evidence that anything reads it.
Should You Block AI Crawlers in robots.txt?
The blocking decision is real, and it is not the same decision for everyone. Disallowing GPTBot and similar clients in robots.txt reduces the chance that your text is used in training, at least for operators that respect the file. The complication is that the same operators often run separate crawlers whose job is retrieval for a live answer, and the naming and the separation between those two purposes have shifted more than once. Blocking broadly to protect content from training can therefore also remove you from the answers, which is exactly the outcome most business-to-business sites are trying to avoid. Read the current operator documentation before writing the rules, not a blog post.
The split is usually clear once you ask what the content is for. If the content is the product, such as a subscription research archive or a paywalled trade publication, the case for blocking is strong, and the correct enforcement is authentication rather than a text file. If the content is marketing, as ours is, blocking is self-defeating: you published an article so it would be read and quoted, then instructed the most efficient quoting mechanism to skip it. The confusion comes from mixing this up with data governance. Whether your customer records leave your network is a separate question, answered by on-premise and sovereign deployments, not by robots.txt.
Whatever you decide, be clear about what robots.txt actually is. It is a published request that well-behaved clients honour, with no enforcement behind it. If a document genuinely must not be fetched by an automated client, it belongs behind authentication, rate limiting or a signed URL, and the robots directive is a courtesy notice on the door. Verification is the other half: agent identification strings are trivially forged, so confirm real crawler traffic against the IP ranges operators publish, and review your access logs for the clients you claim to allow. We check ours periodically, and we have twice found edge rules doing something we did not intend.
Measuring Something That Resists Measurement
Four measurements are worth the effort, in descending order of reliability. Citation rate: for a fixed set of prompts, how often does your domain appear as a source. Share of voice: among the sources cited for those prompts, what fraction are yours versus each named competitor. AI-referred traffic: sessions arriving with a referrer belonging to an assistant, tagged and segmented separately from organic. Branded query lift: whether searches for your company name grow while nothing else in the marketing mix changed, which is the closest available proxy for impressions you never see. Each answers a different question, and none substitutes for another.
Now the honest part: this is difficult to measure well, and anyone presenting a clean dashboard is hiding the variance. Answers are non-deterministic, so the same prompt issued twice in an hour can return a different source set. There is no equivalent of a rank tracker, because there is no rank. Referrer data is thin and sometimes absent entirely. The workable approach is sampling: fix a prompt set of 30 to 80 questions, run it on a schedule, record which domains appear, and treat the output as an estimate with wide error bars. Run-to-run swings of several percentage points are normal and should not be narrated as a trend.
One external figure is worth carrying into the business case, carefully. Seer Interactive reported in June 2025 that visitors referred from ChatGPT converted at 15.9 percent against 1.76 percent for organic search. That is one agency's client base, the absolute volumes are small, and the selection effects are obvious: a user arriving after a model has already answered their comparison questions is deep in the funnel by construction. Do not project revenue from it. Do use it to explain, to a finance stakeholder, why a channel delivering a small number of sessions can still deserve engineering attention, and why measuring session counts alone will systematically undervalue the work.
What We Run on hatsontech.com
Here is the full inventory, so you can judge the cost. The site is static HTML with no client-side rendering, so the first response contains every word. Every page has a canonical URL. Every article exists in English and Turkish with a reciprocal hreflang trio and x-default on the Turkish edition. Every article carries BlogPosting and BreadcrumbList JSON-LD, and the newer ones add FAQPage built from six written question and answer pairs. The XML sitemap pairs the language versions using alternate link entries. robots.txt names GPTBot, ClaudeBot and PerplexityBot in explicit allow blocks. And there is a hand-written llms.txt listing every article with a one-line description.
The engineering was a few days, almost all of it in the templating layer, and it is now free at the margin because every new article inherits it. The article on agents running on a factory floor required no GEO work; it was written, and the machinery came with it. Just as important is what we did not do. We did not buy a visibility monitoring platform, we did not sign a GEO retainer, and we did not rewrite older articles into a flatter register on the theory that models prefer it. We are an AI engineering company rather than a marketing agency, and we treat this as a build problem.
If you are starting, the order of operations matters more than any individual tactic. Fix the render layer first, because everything downstream of it is worthless without it. Then canonicals, hreflang and structured data, which are template work and therefore paid for once. Then rewrite your twenty highest-intent pages so that each section opens with a self-contained answer and carries at least one checkable number. Then stand up measurement, so you can tell whether anything moved. Then, if you still have an afternoon spare, write llms.txt. A vendor proposing the reverse order, with llms.txt and a dashboard first and the render layer never, has told you what they can deliver.
We build this the same way we build everything else: as software, with the output verified rather than assumed. The static generator that produces the site also produces the sitemap, the schema blocks and the llms.txt entries from a single index, which is why they cannot drift apart, and a verification script fails the build when a canonical, an hreflang pair or a JSON-LD block is wrong. That is ordinary custom software engineering applied to a marketing site. We are not going to claim citation counts we cannot verify, and we would be sceptical of anyone who does. What we can say is what is implemented, why, and what each piece cost.