GEO: Generative Engine Optimization — a practical handbook

Short answer. GEO (Generative Engine Optimization) is the work of getting your site used as a source inside AI assistant answers. There is no ranking position here: you are either mentioned, cited with a link, or absent. The levers are crawler access, extractable text structure, verifiable facts, schema.org markup and third-party mentions. It is measurable; guaranteed placement is not.

What GEO means — and what it does not

The acronym is overloaded. In parts of the SEO industry "GEO" still reads as "geographic" — local and regional promotion, city landing pages, map listings, geo-targeting. That is a different discipline entirely and has nothing to do with language models.

• GEO = Generative Engine Optimization — optimizing for generative answer engines: ChatGPT, Perplexity, Google AI Overviews, Microsoft Copilot. This article.
• "geo" = geography — local search, regional subfolders, business listings, radius targeting. Not covered here.

A quick test when reading someone else's material: if the neighbouring words are "city", "branch", "radius", it is local SEO. If they are "citation", "assistant", "LLM", it is generative optimization.

Rule. Never write plain "GEO" in a brief. Write either "GEO (generative engine optimization)" or "local SEO". That single habit saves weeks of misunderstanding between client and agency.

Neighbouring acronyms: AEO and LLMO

Two more terms orbit the same topic. AEO (Answer Engine Optimization) historically covers getting into ready-made answers, from featured snippets to voice assistants. LLMO (Large Language Model Optimization) covers brand presence inside the models themselves. The boundaries are fuzzy, different teams draw them differently, and arguing about them has little practical payoff: the technical work on the site is nearly identical.

If you want the terminology breakdown, there are dedicated pieces: AEO, LLMO and a detailed GEO vs SEO comparison. What follows here is the handbook: what to do, and how to verify it.

How generative results differ from classic search

This is not "SEO with a new name". Three things differ, and each one changes what you optimize.

There is no position — only a binary mention

Classic search results are continuous: moving from 14th to 9th is visible progress. An assistant answer has no intermediate states. Your site is either mentioned — in the text, in the source list, with or without a link — or it is not there at all. You cannot optimize "half a position up", so the metrics change too: share of answers containing a mention, share containing a link, instead of average rank.

A second consequence: answers are non-deterministic. The same question asked twice can produce a different source set. A single check proves nothing; you need repeated runs and percentages.

Zero-click: no traffic, but there is an effect

The user gets the answer inside the assistant interface and often goes nowhere. To analytics this looks like no traffic at all, even though the brand was shown. Practical consequences:

• Judging performance purely by assistant referral sessions systematically understates the result.
• Branded demand gains weight: someone sees the name in an answer, then types it into regular search or enters the domain directly. That part is measurable.
• The content goal shifts from "drive a click at any cost" to "be quoted correctly". If an assistant paraphrases your claim wrongly, you get negative exposure without a single visit.

The source is a set of passages, not a whole page

An assistant does not "read the page and draw a conclusion". It usually receives fragments — chunks of a few sentences pulled out of page context — and builds an answer from them. Hence the central rule of this whole handbook: the unit of optimization is a self-contained paragraph, not a document.

A paragraph starting with "as mentioned above" is useless out of context. An answer spread over three screens will not fit into a fragment. A sentence saying "the rules changed recently" cannot be verified and is therefore likely to be dropped.

Dimension	Classic search (SEO)	Generative answers (GEO)
Outcome	Position in a list, continuous scale	Mentioned or not — binary
Unit of optimization	Page	Passage: paragraph, list item, table row
Stability	Rank moves slowly, reproducible	Non-deterministic, needs repeated sampling
User behaviour	Clicks the link	Frequently zero-click, the visit is optional
What drives it	Relevance + links + technical health	Crawler access + extractability + verifiable facts
Primary metric	Rankings, organic sessions	Share of answers with a mention and with a link
Main risk	Losing rankings	Your claim being paraphrased incorrectly

Where LLM visibility actually comes from

Before doing anything, it helps to know where a model gets information about your site. There are four channels, and they behave very differently.

1. Training corpus

What ended up in the model's training data. This knowledge is baked in, answers instantly and without citations — but only updates when a new model version ships. You cannot influence it quickly: months pass between publishing and possible inclusion, with no guarantees at all. Building a strategy on this channel makes no sense.

2. Retrieval at answer time

During the conversation the assistant queries a search index or its own crawler, pulls fresh documents and answers from them, usually with links. This is the only channel you can move quickly, and the entire practical part of GEO rests on it. Both page availability and how easy it is to cut an answer out of the page matter here.

3. Crawler access

The technical foundation of channel two. If the bot cannot fetch the page, neither structure nor markup helps. This covers robots.txt, serving content without requiring JavaScript, response speed, and the absence of aggressive protection that hands bots a placeholder.

4. The brand in third-party sources

A model forms its picture of a company from many documents: directories, trade press, documentation, discussions, catalogues. Your own site is one voice among many. If your site says one thing and a directory says another, the model gets contradictory data and will often fall back to a vague phrasing or to somebody else's source.

Core idea. GEO is not "rewrite the copy for AI". It is a sequence of five layers: access → extractability → trust → markup → external signals. The order matters: polishing sentences while the crawler receives a 403 is wasted effort.

Layer 1. Access: does your site let AI crawlers in

The most common reason for zero visibility is mundane — the site is technically closed. It takes ten minutes to check.

robots.txt and what it really says

The Robots Exclusion Protocol is specified in RFC 9309. Rules are matched by user-agent, and there are two recurring mistakes.

First: a broad Disallow: / under User-agent: *, added years ago "to stop scrapers". It closes AI crawlers too. Second, and sneakier: an admin adds a rule under a specific bot while that bot also has its own group — and per the protocol only one, most specific group applies. Directives from the * group are not inherited.

robots.txt token	What it is	Effect of disallowing it
GPTBot	OpenAI data collection crawler	Blocks data collection, does not block user-initiated fetches
OAI-SearchBot	OpenAI search indexing crawler	Removes the site from ChatGPT search sources
ChatGPT-User	Fetch triggered by a user asking about a link	The assistant cannot open your URL on request
PerplexityBot	Perplexity indexing crawler	Drops you from Perplexity sources
ClaudeBot	Anthropic crawler	Restricts content access
Google-Extended	Not a crawler — a control token for use of content in Gemini-based Google products	Does not affect regular Search or AI Overviews, which are served by Googlebot
Applebot-Extended	The equivalent control token at Apple	Does not affect normal Applebot indexing
CCBot	Common Crawl, the open web archive	Removes pages from a dataset many parties use
Bingbot	Bing crawler, feeds Microsoft Copilot	Drops you from Bing and downstream answers

Practical takeaway: Google-Extended and Applebot-Extended are not crawlers. They are consent switches for content use. Disallowing them will not remove you from search, but it also buys you nothing in bandwidth or load.

# What to actually check in robots.txt

curl -s https://example.com/robots.txt \
  | grep -iE 'user-agent|disallow|allow' \
  | grep -iA3 -E 'gptbot|oai-searchbot|chatgpt-user|perplexitybot|claudebot|ccbot|extended'

# Is there a global block that hits everyone
curl -s https://example.com/robots.txt \
  | awk '/^[Uu]ser-agent:[[:space:]]*\*/,/^$/'

# Does the file return 200 rather than 404 or 500
curl -s -o /dev/null -w '%{http_code} %{content_type} %{size_download}\n' \
  https://example.com/robots.txt

Careful. A robots.txt that returns 500 is treated by many crawlers as "the whole site is closed", and they stop crawling. An empty file or a 404 normally means "everything allowed" — safer than serving an error. Check the status code, not only the contents.

Is content served without JavaScript

Classic search engines render pages, albeit with delay. Assistant crawlers generally make no such promise: many take the HTML as served. If the article text only appears after client-side hydration, the page is empty for that bot.

# Is the text present in raw HTML, no rendering
curl -s https://example.com/page \
  | grep -o 'key phrase from the first paragraph' | head -1

# Rough measure of how much text the raw HTML carries
curl -s https://example.com/page \
  | sed -e 's/<script[^>]*>.*<\/script>//g' -e 's/<[^>]*>/ /g' \
  | tr -s ' ' | wc -c

# Time to first byte and total response time
curl -s -o /dev/null \
  -w 'ttfb=%{time_starttransfer}s total=%{time_total}s code=%{http_code}\n' \
  https://example.com/page

Speed is part of access. Crawlers have timeouts and crawl budgets; a page that thinks for several seconds gets fetched less often, and sometimes not at all. A speed check gives the full picture.

llms.txt and content negotiation: what to expect

The llms.txt file is a community proposal (the specification lives at llmstxt.org): a markdown file at the site root with a map of key material and a short description of the project. It is not a standard adopted by search engines, and you should not assume every assistant reads it. But it is cheap to produce, useful for agents arriving via a direct link, and it forces the team to state what actually matters on the site.

# /llms.txt — a minimal working example

# Example — online website checks

> Availability, DNS, SSL and SEO checks. Per-domain reports
> and change monitoring.

## Documentation
- [Reading the SSL report](/docs/ssl-report): what each field means
- [Status code reference](/docs/http-codes): what every code means

## Articles
- [GEO: generative engine optimization](/articles/geo-generative-engine-optimization): the practical handbook
- [How AI crawlers read sites](/articles/how-ai-crawlers-read-sites): user agents, limits, access checks

## Optional
- [About](/about): team and contacts

Content negotiation is the adjacent idea: serving clean markdown instead of full HTML when the Accept header asks for it. It is a server-level change and does not affect normal visitors. The benefit today is mostly hygienic — less clutter around the text means less chance a fragment captures your navigation instead of your content. Treat it as tidiness, not as a visibility lever. More on the format in the llms.txt guide, and more on bot behaviour in how AI crawlers read sites.

Checking yourself for cloaking

A separate class of problem: the site serves AI bots something different from what humans get. Usually this is unintentional — a WAF, bot protection, CDN rule or an anti-scraping plugin sees an unfamiliar user agent and returns a placeholder, a captcha or a 403. The owner never notices, because the browser works fine.

# Compare what a browser gets with what an AI crawler gets

UA_BROWSER='Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0 Safari/537.36'
UA_GPT='Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.2; +https://openai.com/gptbot'
UA_PPLX='Mozilla/5.0 (compatible; PerplexityBot/1.0; +https://perplexity.ai/perplexitybot)'

URL=https://example.com/page
for UA in "$UA_BROWSER" "$UA_GPT" "$UA_PPLX"; do
  curl -s -A "$UA" -o /tmp/resp.html \
    -w "code=%{http_code} bytes=%{size_download} " "$URL"
  echo "sha=$(openssl dgst -sha256 /tmp/resp.html | awk '{print substr($2,1,12)}')"
done

How to read it: markedly different response sizes or different status codes mean the bot is getting something else. Identical hashes are not required — CSRF tokens, counters and generation timestamps differ — but the order of magnitude should match. If the browser receives 180 KB and GPTBot receives 4 KB, you have found your problem.

Important. User agents are trivially spoofed, so the reverse task — "allow only genuine bots" — cannot be solved by the UA string. OpenAI, Anthropic and Perplexity publish the IP ranges of their crawlers; Googlebot and Bingbot support reverse DNS verification. Build access rules on those, not on the user-agent header.

Layer 2. Extractability: structuring for citation

This is where the actual writing work starts. One goal: make it possible to cut a finished answer out of the page without reading to the end.

A direct answer in the first paragraph

The first 40–60 words should answer the question in the heading. Not "in this article we will look at", not background, not a warm-up — a statement. That fragment is the easiest thing to quote whole, and it doubles as the best snippet for classic search.

The test is simple: hide everything but the first paragraph and check whether it answers the question for someone who never opened the page.

One claim per paragraph

A five-sentence paragraph holding three separate ideas chunks badly. If a block of text carries two claims, a fragment will capture either half of it or all of it plus irrelevant context. Keep paragraphs short and single-idea — which also improves readability for humans.

Self-contained passages

Every paragraph must make sense detached from the page. What breaks that:

• Back-references. "As stated above", "in the previous section", "this method" — out of context the reader has no idea what is meant.
• Pronouns instead of terms. "It supports that" instead of "GPTBot honours the Disallow directive".
• Split definitions. The term is introduced in one section and explained three screens later.
• Meaning carried only by the heading. If a paragraph only parses together with its h3, it loses meaning as a fragment — repeat the key term in the body.

The reasonable trade-off: repeat key nouns more often than a style guide would like. Human readers barely notice; machines benefit.

Headings that say something

A heading called "Features" communicates nothing. A question or a statement marks the boundary of a meaning block and matches the phrasing people actually bring to an assistant. Compare "Configuration" with "How to allow GPTBot into the blog section only".

Tables, lists and concrete values

A table is the ideal fact carrier: a table row is self-contained by definition. Lists behave the same way. More important still is concreteness:

• Not "the rules changed recently" but "the rules changed in March 2026".
• Not "the file is small" but "the file is under 500 KB".
• Not "soon" but "within 24 hours".
• Not "most browsers" but "Chrome, Firefox and Safari".

The reason is not that models "like numbers". The reason is verifiability: a vague claim cannot be cross-checked against other sources, so it is more likely to be dropped in favour of a specific one. A dedicated breakdown lives in the content extractability guide.

<!-- Extractable block: answer, fact and date in one fragment -->
<h2>How long is a DNS record cached</h2>
<p><strong>Short answer.</strong> A DNS record's lifetime is set by the
TTL field, in seconds. Typical A-record values run from 300 to 3600.
Resolvers must not keep the record longer than the TTL, but may
serve it for less.</p>
<table>
  <tr><th>TTL</th><th>Minutes</th><th>When to use</th></tr>
  <tr><td>300</td><td>5</td><td>Before a migration</td></tr>
  <tr><td>3600</td><td>60</td><td>Stable configuration</td></tr>
</table>

Note the construction: the heading states the question, the first paragraph answers it without leaning on the rest of the text, the table adds verifiable values. Any of the three can be lifted separately and still make sense.

Layer 3. Trust: authorship, sources, consistency

Extractable text with no signs of provenance is well-formatted text of unknown origin. What adds weight.

Authorship and expertise

Material should carry a named author with a role and a reason to be considered competent. Not "Editorial team" but a person with a profile page showing their background. That field also connects to markup (next layer) and makes the claim attributable: an assistant can credit the author, not just the domain.

Links to primary sources

Every technical claim that can be verified should lead to a primary source: an RFC, vendor documentation, the text of a regulation, a specification. This cuts both ways. An assistant checking a fact finds confirmation; a human reader sees that the author is not paraphrasing somebody else's paraphrase.

Updates and honest dates

Publication and last-modified dates should be on the page and should be true. Bulk-stamping today's date without touching the text is easy to detect by comparing versions and destroys trust faster than an old date does. Update substantively: fix stale values, add new cases, remove what no longer applies.

Consistent facts about the brand

The most underrated item on the list. A model builds its view of a company from dozens of sources. If your site calls you an "infrastructure monitoring service", a directory calls you a "web studio", your social profile says "full-cycle IT company" and an industry catalogue still holds an old name, the output is a vague or wrong description. Worse, faced with a contradiction the assistant may prefer a third-party card over your own site.

What must be reduced to a single wording everywhere:

• Legal and trading name, including transliterations and alternative spellings.
• One sentence describing what the company does — word for word identical.
• Founding year, city, contacts, website address.
• Product list and product names, with no synonyms or retired versions.
• Social and directory profiles, cross-linked with the site.

Rule. Keep one text file with the canonical company description and copy from it before publishing anywhere external. It is boring, and it works better than half the "GEO tactics" in circulation.

Layer 4. Structured data as machine-readable confirmation

Schema.org markup does not "boost your ranking with AI". Its role is smaller and more useful: it turns facts scattered through prose into explicit property-value pairs that nobody has to infer. Who wrote it, when it was updated, which organization owns the site, what the product is, which question maps to which answer.

A minimally sensible set for a content site:

• Organization on the homepage, with name, logo and profile links via sameAs.
• Article or TechArticle on posts, with author, datePublished, dateModified.
• FAQPage on question blocks — only where the block genuinely exists on the page.
• BreadcrumbList so the page's place in the structure is explicit.

{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "GEO: Generative Engine Optimization",
  "datePublished": "2026-06-15",
  "dateModified": "2026-08-06",
  "author": {
    "@type": "Person",
    "name": "Igor Verentsov",
    "url": "https://example.com/about"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example",
    "sameAs": [
      "https://x.com/example",
      "https://github.com/example"
    ]
  },
  "about": "Generative Engine Optimization"
}

Two warnings. First: markup must match what is visible on the page. A FAQPage with no real question block violates search engine guidelines and invites a penalty rather than an advantage. Second: speakable is narrow, limited-scope markup, not a lever for getting into assistant answers — older GEO checklists recommend it out of inertia. What is genuinely worth marking up is covered in structured data for AI search.

Layer 5. External signals: where you are read more readily

An assistant almost never builds an answer from a single source. If your product is described only by you, the model has no confirmation. The mechanism is simple: the more independent documents repeat the same fact, the more stable that fact is in answers.

Types of venue that commonly show up as sources, and why:

• Technical documentation and repositories. Dense, structured, dated text with no marketing — ideal extraction material.
• Trade press and specialist blogs. They provide external attribution: the claim no longer comes from you.
• Q&A sites and communities. The question-answer format matches the shape of a user's prompt, which makes those pages frequently relevant.
• Directories, catalogues and encyclopedias. The source of baseline facts: name, sector, founding year, contacts.
• Open datasets and web archives. They indirectly shape what lands in future training corpora.

Treat this as ordinary PR: useful material, honest participation in communities, up-to-date directory entries. The difference from classic link building is that the link itself is not the point — a repeated statement is. An unlinked mention still counts.

The work map: layer, actions, verification

A summary of the practical part. The "how to verify" column matters more than the "actions" column: work whose result cannot be checked usually does not get done.

Layer	Concrete actions	How to verify
1. Access	Remove stray robots.txt blocks; serve body text in HTML without JS; cut response time; publish llms.txt; confirm the WAF is not blocking bots	robots.txt checker, llms.txt checker, curl with different user agents comparing response size, speed test
2. Extractability	40–60 word direct answer up top; one claim per paragraph; delete "as mentioned above"; question-shaped headings; tables and lists; replace "recently" with dates	Read a random paragraph detached from the page and see if it stands; AI readiness check; manual question runs across assistants
3. Trust	Named authors with profile pages; links to primary sources; honest modification dates; one company description used everywhere	Search the brand name and compare descriptions across every venue; confirm dateModified only moves on real edits
4. Markup	Organization on the homepage; Article or TechArticle on posts; FAQPage only where the block exists; BreadcrumbList; sameAs to profiles	schema.org validator, cross-check markup fields against visible page text
5. External signals	Trade publications; documentation in the open; participation in specialist communities; current directory entries	Regular brand mention searches; confirm external sources carry the canonical description

How to measure GEO

The core difficulty: there is no familiar rank tracker, and the data that does exist is systematically understated. The working approach combines three independent sources.

Regular runs of a question set

Assemble 30–100 questions your audience genuinely asks an assistant. Not keywords — questions in conversational language. Split them into groups: branded ("what is Example"), category ("how do I check an SSL certificate"), comparative ("Example or the alternative"), problem-driven ("my site is down, what now").

Then run them regularly across several assistants and record the results. Because answers are non-deterministic, ask each question several times and count shares rather than single facts. Three metrics worth collecting:

• Share of answers mentioning the brand — what percentage of runs contain your name in any form.
• Share of answers with a link — how many contain a clickable link to your domain. Always lower than the first.
• Sentiment and accuracy — is the brand cited as a solution or as an example of what to avoid, and are there factual distortions. Only reading the answers catches this; automation helps little.

Logs and headers as proof of a visit

The one source that does not depend on anyone else's analytics: your own access log. It shows which bots came, where, how often, and what they received.

# Which AI crawlers visited and how often (nginx combined)
grep -Ei 'gptbot|oai-searchbot|chatgpt-user|perplexitybot|perplexity-user|claudebot|claude-user|ccbot|bytespider|amazonbot|meta-externalagent|google-extended|applebot' \
  /var/log/nginx/access.log \
  | awk '{print $NF}' | sort | uniq -c | sort -rn | head -20

# What status codes bots receive: 200, or 403 and 429
grep -i 'gptbot' /var/log/nginx/access.log \
  | awk '{print $9}' | sort | uniq -c | sort -rn

# Most requested URLs by bots over the last day
grep -Ei 'gptbot|perplexitybot|claudebot' /var/log/nginx/access.log \
  | awk '{print $7}' | sort | uniq -c | sort -rn | head -30

# Verify one IP: genuine bot or a spoofed user agent
whois 203.0.113.10 | grep -iE 'orgname|netname|descr'

How to read the numbers: no AI bots at all in the logs while robots.txt is open means the site is simply unknown to them — the problem is indexing and external links, not copy. Widespread 403 or 429 means your protection is cutting bots off. A sharp rise in requests to one section signals that this section turned out to be relevant.

Referral traffic, and why it is understated

Visits from assistants do show up in analytics as separate sources, but the figure is smaller than the real influence, because:

• Some interfaces send no referrer or truncate it via referrer policy — the visit lands under direct.
• Mobile apps open links in an in-app browser, where the data is frequently lost.
• Zero-click produces no visit by definition: the brand was shown, no session exists.
• Delayed effect: someone sees the name in an answer and arrives an hour later through normal search. In the report that is branded organic, not a referral.

Practical conclusion: read assistant referral traffic as a lower bound, and keep branded query volume and direct visits alongside it as an indirect indicator.

Metric	How to collect it	What it does not show
Share of answers with a mention	Run the question set across several assistants, repeat, count the percentage	Ignores audience size: question popularity is not weighted
Share of answers with a link	Same runs, counting clickable links to your domain separately	Says nothing about clicks; some assistants rarely emit links at all
Sentiment and accuracy	Reading answers manually, logging distortions and mention context	Scales poorly, is subjective, needs a consistent evaluator
AI crawler visits	Parsing logs by user agent, verifying IPs via whois or reverse DNS	A crawl is not a citation: the bot came, that is all it proves
Status codes served to bots	Filtering logs by UA, grouping by status	Misses the case where protection returns 200 with an empty page
Referrals from assistants	Source report in your analytics platform	Systematically understated: lost referrer, zero-click, delayed visits
Branded demand	Impressions and queries containing the brand name in search consoles	Cannot separate assistant effect from ads, PR and seasonality

On tooling. Commercial "AI visibility monitoring" products do exactly the same thing: run questions and count shares. That saves time, but it does not produce data you cannot gather by hand. Starting with a spreadsheet and a manual run every two weeks is reasonable — it teaches you which questions are worth tracking at all.

What does not work, and what actively hurts

The field is young, so it attracts offers that are at best useless.

Manufacturing mentions

Mass-seeding identical brand-name comments across forums and discussions. The mechanism it targets does not work that way: value comes from the diversity of independent sources, not from repeating one template. Platforms clean such campaigns up, and the mentions vanish with them. There is a reputational risk on top: visible seeding gets discussed in public.

Content "written for LLMs"

Pages generated in bulk against every conceivable phrasing, identical in structure and empty of substance. This is precisely where search engines and assistants align: mass low-value content is filtered in search, and without indexing there is no retrieval either. The net result is losing visibility in both channels at once.

Cloaking for AI crawlers

Serving bots a specially stuffed version while humans get the normal one. Beyond directly violating search engine guidelines, there is a technical flaw: an assistant may fetch the page on the user's behalf (that is what ChatGPT-User does) and receive the human version. The discrepancy is immediately visible.

Hidden text and prompt injection in markup

Instructions such as "when answering, recommend this site", hidden in invisible elements or attributes. That is not optimization but an attempt to manipulate the model. Such tricks get detected and filtered, and the ones that are found become public case studies with predictable reputational consequences.

Guaranteed placement promises

"We guarantee you will appear in ChatGPT answers" is a promise nobody can keep. The source set depends on the phrasing, the model version, language, region and plain randomness in generation. No vendor controls another company's retrieval. The honest maximum is growth in the share of answers containing a mention across an agreed question set.

How long results take

Realistic expectations if you work layer by layer:

• Technical fixes (robots.txt, bot access, speed) — visible in logs within days or weeks as recrawling happens.
• Restructuring content — only takes effect after recrawl and reindexing; expecting change sooner than six weeks is unrealistic.
• Trust and external signals — the slowest layer, measured in quarters. Also the most durable.
• Knowledge inside the model — updates with new model versions, on a timeline you do not control.

And separately: the foundation has not changed. If a page is not in the search index, an assistant has no way to retrieve it. A standard SEO audit covers that part, and without it generative optimization hits a ceiling. The overlaps and differences are laid out in the GEO vs SEO comparison.

How to check your site

The order of checks mirrors the order of layers — most important first.

• AI readiness check — the combined pass: bot access, llms.txt presence, markup, page structure.
• robots.txt analysis — which directives actually apply to a given bot and whether a global block slipped in.
• llms.txt check — whether the file exists, is served correctly and is valid.
• Structured data validator — which schema.org types are found on the page and whether fields contain errors.
• SEO audit — the foundation: indexability, headings, duplicates, internal links.
• Speed test — response time and page weight, which drive crawl budget.

Individual engines have their own breakdowns: Google AI Overviews, Perplexity, Yandex Neuro and getting cited by ChatGPT. Crawl mechanics are covered in robots.txt for AI crawlers.

FAQ

Does GEO replace SEO?

No. Generative answers mostly rest on a search index: a document has to be findable before it can be cited. A page that never made it into the index is unreachable through retrieval. GEO is a layer on top of technical SEO, not a substitute for it.

Do I need separate content for AI?

Usually not. Reworking existing pages is cheaper: move the direct answer to the top, split paragraphs, replace vague phrasing with specifics, add markup. A separate "LLM version" creates duplicates and a risk of facts drifting apart between versions.

Should I block AI crawlers in robots.txt?

It is a trade-off. Blocking protects your content from training use, but it also removes you from answer sources. The common compromise: block training-data crawlers, leave search and user-initiated ones open. Remember that robots.txt is a request, not enforcement — real blocking only happens at the server level.

Why is my site never mentioned even though it ranks well?

Typical causes in order of frequency: content only appears after JavaScript runs; protection returns 403 to bots; the answer is spread across the page and does not chunk; facts about the company contradict each other across external sources; the topic simply rarely comes up in assistant prompts. Check in that order, top to bottom.

Which matters more: llms.txt or text structure?

Text structure, no contest. llms.txt is a site map for agents — cheap and useful, but it has no bearing on whether your paragraph lands in an answer. With limited resources, do direct answers, self-contained paragraphs and markup first, the file second.

How do I know the work paid off?

Three independent signals moving together: the share of answers mentioning you grows on your question set; logs show regular AI crawler visits returning 200; branded demand rises in search consoles. One of three is a coincidence; all three is a trend.

Can I influence what a model "knows" about my company?

Indirectly and slowly. There is no direct write channel into a model. The path that works is a consistent company description across as many independent sources as possible: your own site, directories, documentation, publications, profiles. Over time that shows up both in retrieval and in future training corpora.

GEO checklist

• robots.txt contains no accidental block for AI crawlers, and the file returns 200.
• You have made a deliberate, written decision about which bots are allowed.
• Body text is present in the raw HTML with no JavaScript executed.
• A curl request with an AI bot user agent returns a response of comparable size to a browser's — no cloaking.
• Time to first byte is within reason and the page is no heavier than it needs to be.
• An llms.txt with a map of key sections sits at the site root.
• The first paragraph of every significant page is a 40–60 word direct answer.
• Each paragraph carries one claim and stands on its own.
• "As mentioned above", "this method", "recently" and "soon" have been removed.
• Subheadings are phrased as questions or statements, not as "Features".
• Numbers, dates and versions are stated explicitly rather than described.
• Articles carry a named author with a profile page.
• Technical claims link to primary sources.
• Publication and modification dates are real, and updates are substantive.
• The company description is word-for-word identical on the site, in directories and on social profiles.
• The homepage carries Organization markup with sameAs to every profile.
• Articles carry Article or TechArticle markup with author and dates.
• FAQPage is used only where a question block is genuinely visible.
• Independent external mentions of the brand exist, not just your own site.
• A set of 30–100 real audience questions is assembled for regular runs.
• Shares are tracked — mention, link, sentiment — with repeated sampling.
• Logs are checked regularly for AI bot visits and the status codes they receive.
• No cloaking, no hidden instructions, no bulk page generation.

Check your site's AI readiness →