Any request can put GPTBot in its user-agent. Rankly checks whether that claim is actually true, so you can trust your numbers and catch agents pretending to be someone they are not.

The three tiers

Every agent request is placed in one of three tiers:

Verified

Identity proven. The request carried a valid signature, or its IP belongs to the vendor’s published range and reverse DNS confirms it.

Unverified

Recognized as a known bot by its user-agent, but identity could not be proven, often because the true client IP wasn’t available. Not necessarily fake.

Spoofed

Claimed a trusted vendor but failed every proof. The IP doesn’t belong to that vendor and there was no valid signature. Likely an impersonator.
The difference between unverified and spoofed matters: unverified means “we couldn’t confirm,” spoofed means “we checked and the claim is false.”

How the check works

Rankly proves identity two independent ways. Passing either one makes a request verified.
1

Published IP range and reverse DNS

Most vendors publish the IP ranges their crawlers use. Rankly checks the request’s client IP against those ranges, and for vendors that support it (Google, Bing, Apple, DuckDuckGo) confirms ownership with forward-confirmed reverse DNS. A match with the right user-agent is a verification.
2

Signed requests (Web Bot Auth)

A growing number of agents sign their requests using Web Bot Auth (RFC 9421, Ed25519 signatures in the Signature and Signature-Input headers). Rankly verifies the signature against the vendor’s published public key. A valid signature is the strongest proof of identity.
If a request claims a vendor but fails both checks, it is marked spoofed and broken out in the dashboard’s forensics so you can see who is impersonating trusted crawlers.

Why the client IP matters

Verification depends on seeing the true client IP. Integrations that sit at the edge (Cloudflare Worker, Fastly, Akamai) capture it directly. If your site sits behind a proxy and your logs only record the proxy’s IP, the check can’t run and the request falls back to unverified.
On Google Cloud behind a proxy, log the real IP into a jsonPayload field named cfConnectingIp, clientIp, or xForwardedFor, and Rankly reads it automatically. See the Google Cloud guide, or use the Cloudflare Worker, which captures the real IP at the edge.

Catching disguised bots

Verification answers “is this really the vendor it claims to be?” Rankly also runs a separate, proprietary check for bots that disguise themselves as a normal browser to slip past detection entirely.

The humanity check

How Rankly separates real browsers from headless bots wearing a browser’s clothes, and flags disguised traffic.

Robots.txt compliance

For AI and search crawlers, Rankly also checks whether each request respected the site’s robots.txt. A bot that fetches a path its own vendor’s rules disallow is flagged as a robots.txt violation, so you can see which crawlers ignore your rules.

Robots.txt violations

How Rankly detects bots fetching paths they were told not to.