Glossary
Objective definitions for the terms used across Synviber's GEO scan and docs.
GEO
GEO (generative-engine optimization) is the practice of making a website legible to the AI assistants and agents that increasingly stand between a person and your content.
Where traditional SEO optimizes for a ranked list of blue links, GEO optimizes for being the source an AI assistant actually reads, cites, or quotes when it answers a question. The two failure modes look identical from the outside — a page that never gets cited — but usually have very different causes: either the content technically isn't reachable by a non-JavaScript client at all (thin/empty HTML on first load), or it is reachable but unstructured, so the assistant has nothing but prose to work from. (Source: this site's own /geo-optimization page.)
GEO vs SEO
GEO and traditional SEO both aim to get a site found, but they optimize for different outcomes: a ranked search-results click for SEO, versus being read, cited, or quoted directly by an AI assistant for GEO.
A GEO failure and an SEO failure can look identical from outside — a page nobody finds — while having unrelated causes: a page can rank fine in search yet still fail GEO because its real content only renders after client-side JavaScript runs (see THIN_CONTENT in /docs) or it has no structured data for an assistant to parse (see JSON_LD_MISSING), neither of which a keyword- or backlink-focused SEO audit would surface.
AI crawler
An AI crawler is an automated client, identified by its own User-Agent, that an AI company operates to fetch web content for a generative-AI-related purpose: training a model, building a live search index, or fetching a single page a user asked an assistant to open.
Not every AI crawler serves the same purpose, and blocking one is not automatically bad for GEO — blocking a training-only crawler is a legitimate access-control choice (see the AI crawler purpose table below), while blocking a live-retrieval or user-triggered crawler directly prevents an AI answer engine from citing the site right now (see ROBOTS_BLOCKS_AI_CRAWLER in /docs).
| Bot | Purpose | Note |
|---|---|---|
| GPTBot | Training data collection | OpenAI's crawler for collecting model-training data. |
| ClaudeBot | Training data collection | Anthropic's crawler for collecting model-training data. |
| Google-Extended | Training data collection | Controls use of a site's content to train Google's generative AI models, separate from normal Search indexing. |
| CCBot | Training data collection | Common Crawl's crawler; its archives are widely reused as AI training data by many labs. |
| Bytespider | Training data collection | ByteDance's crawler, used for model-training data collection. |
| Applebot-Extended | Training data collection | Controls use of a site's content for Apple's generative AI training, separate from Siri/Spotlight indexing. |
| PerplexityBot | Live index / search retrieval | Indexes content for Perplexity's live answer engine. |
| OAI-SearchBot | Live index / search retrieval | Indexes content for ChatGPT's search/live-answer feature. |
| ChatGPT-User | User-triggered fetch | Fetches a specific page only when a user asks ChatGPT to open or browse it. |
| Claude-SearchBot | Live index / search retrieval | Indexes content for Claude's live search feature. |
| Claude-User | User-triggered fetch | Fetches a specific page only when a user asks Claude to open or read it. |
| Perplexity-User | User-triggered fetch | Fetches a specific page only when a user asks Perplexity to open or read it. |
| GoogleOther | Live index / search retrieval | Google's generic crawler for miscellaneous product/research fetches, distinct from the main Googlebot search index. |
llms.txt
llms.txt is a plain-text file published at a site's root that summarizes the site and links to its key pages, written for an AI assistant to read directly instead of inferring the same information by crawling and guessing.
This site publishes its own at /llms.txt (a short summary) and /llms-full.txt (the full text of every public page, including this glossary and the GEO issue docs). geo-engine's scorer checks for it directly — LLMS_TXT_MISSING if it's absent, LLMS_TXT_EMPTY if it returns 200 with no content (see /docs).
AI access policy
An AI access policy is a declarative, per-AI-identity rule set — for example, allow an assistant to read a blog and FAQ but not backend API routes — in place of an all-or-nothing robots.txt Allow/Disallow rule.
Synviber's gateway classifies requests by signature (not just User-Agent string) and lets a site owner write one of these policies per AI identity, previewed in a dry-run simulator before it takes effect. (Source: this site's own /product page, "Allow or block rules" module.)
JSON-LD / structured data
JSON-LD is a JSON-based format for embedding schema.org structured data — Organization, WebSite, Product, FAQPage, and similar vocabularies — directly in a page's HTML so a machine reader can extract facts without parsing prose.
geo-engine's scorer checks both for the presence of specific JSON-LD types (JSON_LD_MISSING, SOFTWARE_APPLICATION_SCHEMA_MISSING, FAQ_SCHEMA_MISSING) and for whether a present block's required fields are actually filled in (JSON_LD_INCOMPLETE — e.g. an Organization block needs both `name` and `logo`; a SoftwareApplication block needs both `applicationCategory` and `offers`). See /docs for the full list.
AI traffic analytics
AI traffic analytics is the breakdown of which AI crawlers and agents actually requested a site's pages, by provider and by domain — a record of real traffic, distinct from a GEO scan's point-in-time check of what a site currently exposes.
In Synviber this is the dashboard's AI Traffic page, which reports these per-provider/per-domain totals from the gateway's request logs. A GEO scan, by contrast, evaluates a site's own pages once per scan; it doesn't record live requests the way AI traffic analytics does.
Discovery (GEO layer)
Discovery is Synviber's base 0–100 GEO score, produced by the deterministic checks in geo-engine's scorer — robots.txt, llms.txt, sitemap, structured data, content thinness, and more.
Every issue code cataloged in /docs is a Discovery-layer check. Discovery always runs on a scan; the other three layers below (Retrieval, Citation, Recognition) are opt-in probes run separately.
Retrieval (GEO layer)
Retrieval is an opt-in GEO probe that checks whether a provider's actual search-grounded or browsing mode retrieves the site right now, graded on live grounding/tool-call metadata rather than a static page check.
This is a different question from Citation below: Retrieval asks whether a provider's live search/browsing tooling actually fetches this domain when relevant, not whether a chat answer happens to mention the brand.
Citation (GEO layer)
Citation is an opt-in GEO probe that checks whether AI models mention or cite the brand when asked a live, brand-free question.
This is a different question from Recognition below: Citation tests a live, brand-free prompt to see if the model volunteers the brand; Recognition tests whether the model already knows the brand from training, independent of whether it would cite it unprompted.
Recognition (GEO layer)
Recognition is a GEO probe that checks whether an AI model already recognizes the brand from its training data, with no live fetch involved.
Recognition answers "does this model already know who we are" independent of whether it would cite the brand unprompted (that's Citation) or whether its live search tooling would retrieve the site right now (that's Retrieval).
Composite (GEO score)
Composite is a single weighted-average score across whichever of Discovery, Retrieval, Citation, and Recognition have a score so far, renormalized so a layer that hasn't been run yet doesn't count against the average.
Discovery always contributes once a scan has run; Retrieval, Citation, and Recognition are opt-in and may not have a score yet, in which case only the layers that do have contribute, renormalized. Synviber does not publish the individual layer weights.