Skip to main content
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.
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.

Key concepts

Agent Edge Network

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.

Verification levels

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.

Optimized artifacts

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.

Citability score

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.

Serve modes

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).

Agent Analytics

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.

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.
LevelHow it worksServed the variant?
SIGNEDRequest carries a valid Ed25519 Web Bot Auth signature (RFC 9421 HTTP Message Signatures)Yes
IP_VERIFIEDSource IP falls within the bot’s published CIDR rangesYes
UA_ONLYOnly the user-agent token matches a known bot; no IP or signature verificationNo
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.
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.

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.

Answer-engine agents (served by default)

OpenAI (OAI-SearchBot, ChatGPT-User), Anthropic (Claude-SearchBot, Claude-User), Perplexity (PerplexityBot, Perplexity-User), and Mistral (MistralAI-User).

Training crawlers (recognized, not served by default)

OpenAI GPTBot, Anthropic ClaudeBot, Common Crawl CCBot, ByteDance Bytespider, Google-Extended, Amazonbot, and Meta-ExternalAgent.

Search-index bots (always pass through)

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.

Purpose classes

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.
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.

How the platform fits together

Ready to connect your site? Provision a domain in Agent Analytics to mint an edge token (aen_...), then head to the Quick Start to install the middleware.