> ## Documentation Index
> Fetch the complete documentation index at: https://docs.trybluesky.com/llms.txt
> Use this file to discover all available pages before exploring further.

# What Is Bluesky? AI Answer Engine Optimization (AEO)

> Bluesky detects AI crawler visits, serves citation-optimized page variants, and measures how often your brand appears in AI-generated answers.

Bluesky is an Answer Engine Optimization (AEO) platform that gives you visibility into — and control over — how your brand appears in AI-generated answers. This page explains what Bluesky does, the core concepts behind the Agent Edge Network, and which agents it recognizes, so you can orient yourself before setup.

## What Bluesky does

Most brands have no idea whether AI answer engines are crawling their site, let alone whether those crawls turn into citations. The Agent Edge Network (AEN) closes that gap across three layers.

**Detect** — AEN is an edge drop-in you install in your own app (Next.js, Cloudflare, WordPress, or a snippet for any other stack). It inspects every incoming request and matches AI crawlers against a maintained registry of bots. Each match is verified against the bot's published IP ranges (CIDR) and, when present, a cryptographic Web Bot Auth signature — so you know which bot visited, at what trust level, and with what purpose.

**Serve** — When a request is verified, AEN serves a pre-generated, citation-optimized artifact of the requested page instead of your standard HTML. Artifacts are answer-first markdown paired with `Article` (and, when the page's own headings are questions, `FAQPage`) JSON-LD. They are built offline by pure extraction and restructuring of your existing page — never fabricated — and cached, so nothing is generated on the request path and real users are unaffected.

**Measure** — Agent Analytics surfaces verified crawl hits broken down by purpose class and verification level, plus a served-versus-cited view: of the URLs you served a variant for, how many later appear as citations. A per-page citability score tells you where to focus.

<Note>
  Bluesky never bot-branches traditional search crawlers. Googlebot, Bingbot, and Applebot always receive your standard page — the AEO variant is reserved for verified answer-engine agents. This cloaking firewall is non-negotiable and enforced in code.
</Note>

## Key concepts

<CardGroup cols={2}>
  <Card title="Agent Edge Network" icon="network-wired">
    The edge middleware you install in your own app. It detects AI crawler requests, verifies their identity, and decides whether to serve the variant or pass through, based on your serve mode and path rules.
  </Card>

  <Card title="Verification levels" icon="shield-check">
    Every request is classified **SIGNED** > **IP\_VERIFIED** > **UA\_ONLY**. Only SIGNED and IP\_VERIFIED (verified) requests are ever served the variant. UA\_ONLY is treated as unverified and always gets the normal page.
  </Card>

  <Card title="Optimized artifacts" icon="file-lines">
    Pre-generated page variants: answer-first markdown plus `Article` / `FAQPage` JSON-LD. Built offline by strict, no-fabrication extraction and cached, so serving them adds nothing to the request path.
  </Card>

  <Card title="Citability score" icon="chart-bar">
    A per-page 0–1 heuristic of how citable an artifact is — rewarding a clear title, an answer-first lead, chunkable headings, a freshness date, FAQ structuring, and sufficient content density.
  </Card>

  <Card title="Serve modes" icon="sliders">
    Control rollout: **off** (disabled), **shadow** (serve the normal page but log what would have been served), **canary:\<pct>** (deterministic percentage), or **default** (all verified answer-engine agents).
  </Card>

  <Card title="Agent Analytics" icon="telescope">
    The dashboard showing verified hits by purpose class and verification level, total hits, served URL count, and the share of served URLs that were subsequently cited.
  </Card>
</CardGroup>

### Verification levels explained

The drop-in middleware verifies by published IP ranges and, optionally, Web Bot Auth signatures. A user-agent string alone is never trusted — a scraper can spoof it — so an unverified token match tops out at UA\_ONLY and never reaches the variant.

| Level            | How it works                                                                              | Served the variant? |
| ---------------- | ----------------------------------------------------------------------------------------- | ------------------- |
| **SIGNED**       | Request carries a valid Ed25519 Web Bot Auth signature (RFC 9421 HTTP Message Signatures) | Yes                 |
| **IP\_VERIFIED** | Source IP falls within the bot's published CIDR ranges                                    | Yes                 |
| **UA\_ONLY**     | Only the user-agent token matches a known bot; no IP or signature verification            | No                  |

<Note>
  A further tier, **DNS\_VERIFIED** (reverse-DNS confirmation), exists in the core and is resolved engine-side and asynchronously — it is deliberately off the drop-in middleware's hot path, which is IP-only plus optional signatures.
</Note>

<Tip>
  Aim for as many hits at SIGNED as possible. A signed request is the strongest guarantee that the visitor is a legitimate answer-engine agent and not a scraper mimicking a bot user-agent.
</Tip>

## Which agents Bluesky recognizes

AEN maintains a registry of bots, each tagged with a vendor and a purpose class. By default, only answer-engine agents with a **retrieval** or **user-triggered** purpose are served the variant.

<CardGroup cols={2}>
  <Card title="Answer-engine agents (served by default)" icon="robot">
    OpenAI (OAI-SearchBot, ChatGPT-User), Anthropic (Claude-SearchBot, Claude-User), Perplexity (PerplexityBot, Perplexity-User), and Mistral (MistralAI-User).
  </Card>

  <Card title="Training crawlers (recognized, not served by default)" icon="database">
    OpenAI GPTBot, Anthropic ClaudeBot, Common Crawl CCBot, ByteDance Bytespider, Google-Extended, Amazonbot, and Meta-ExternalAgent.
  </Card>

  <Card title="Search-index bots (always pass through)" icon="magnifying-glass">
    Googlebot, Bingbot, and Applebot are never branched. Google's AI Overviews run on Googlebot and the search index, so branching them would cloak Search itself.
  </Card>

  <Card title="Purpose classes" icon="tags">
    Every recognized bot carries a purpose: TRAINING, RETRIEVAL, SEARCH\_INDEX, USER\_TRIGGERED, or UNKNOWN. Your serve config chooses which purposes are eligible for the variant.
  </Card>
</CardGroup>

<Warning>
  Google's AI Overviews are generated on top of the same search index that Googlebot crawls. Because Googlebot — like Bingbot and Applebot — is a search-index bot, the firewall always passes it straight through. Any answer feature that rides on a traditional search index is reached through those crawlers, so AEN never serves them a variant and can never cloak Search itself.
</Warning>

## How the platform fits together

```
Your site (Next.js / Vercel)
        │
        ▼
  Agent Edge Network          ← drop-in middleware, edge token (aen_...)
        │
   ┌────┴────┐
   │ Detect  │  match UA token → verify: SIGNED · IP_VERIFIED · UA_ONLY
   └────┬────┘
        │
   ┌────┴──────────┐
   │ Decide        │  firewall: search-index bots always pass through
   └────┬──────────┘
        │
  ┌─────┴──────┐   ┌──────────────────────┐
  │ Passthrough │   │ Verified answer agent │
  │ (users,     │   │ (optimized artifact,  │
  │  search)    │   │  per serve mode)      │
  └────────────┘   └──────────────────────┘
                           │
                    Agent Analytics
                    served → cited
```

<Note>
  Ready to connect your site? Provision a domain in Agent Analytics to mint an edge token (`aen_...`), then head to the [Quick Start](/quickstart) to install the middleware.
</Note>