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.
The KDD 2024 GEO study reported visibility gains from some content edits in its experimental setting. That result does not tell us how much search traffic or how many citations this site will receive. It is a reason to test clear, well-supported passages, not a forecast for a new article.
An Ahrefs study of 75,000 brands found a stronger correlation between web mentions and visibility in Google AI Overviews (0.664) than between backlinks and that visibility (0.218). The study is observational: it does not show that acquiring a mention will cause a citation, or that the relationship will be the same for Hatson Tech. Independent coverage can still help people discover and evaluate a company, which makes accurate public documentation and real project evidence useful beyond search.
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. Each article has a canonical URL, and the XML sitemap pairs the English and Turkish versions. Our robots.txt uses a general Allow: / rule; it does not name individual AI crawlers. A robots rule is only one part of access: CDN security settings can still block a crawler, so check actual responses and logs rather than assuming every client can fetch a page.
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 currently carries Article and BreadcrumbList JSON-LD. The article markup identifies its headline, original publication date, author and publisher, and canonical page. Most articles do not yet record a modification date or language in JSON-LD; the language relationship is expressed through reciprocal hreflang links. Structured data helps describe a page, but Google does not require special schema for AI search features, and no engine has confirmed that these properties select citations.
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. 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. We maintain one as a low-cost directory of our pages, without treating it as a proven optimisation.
Our llms.txt starts with a short company description. The site generator then adds page titles and canonical URLs from the current HTML pages, so new published pages can appear in the file without maintaining a second list. It does not currently provide a separate one-sentence description for each article. We keep the file because it is inexpensive to maintain, not because its effect on AI visibility has been demonstrated.
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 implemented inventory. Articles are server-delivered static HTML with canonical URLs. Each article has English and Turkish versions linked by reciprocal hreflang, and the XML sitemap carries those language alternates. Articles use Article and BreadcrumbList JSON-LD; some also have visible FAQ sections and matching FAQPage markup. robots.txt allows all user agents through a general rule. The generator builds the sitemap and llms.txt from the published pages. These are useful discovery and clarity measures, not proof that an AI engine will cite us.
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 treat these files as software that must be checked. The site generator reads published HTML pages to build the sitemap and llms.txt; article JSON-LD remains in each article file. The release check verifies canonical URLs, hreflang pairs and valid JSON-LD, but it cannot verify every editorial claim or guarantee AI citations. That is ordinary custom software engineering applied to a marketing site: state what is implemented, then measure what actually happens.