How to verify a bot is real (not a spoof)

To verify a bot is real means to confirm that a visitor claiming to be Googlebot, GPTBot, or any other named crawler genuinely belongs to the company it names, rather than a script wearing that name as a disguise. It matters because a user-agent string is simply text a client sends, and anyone can set it to whatever they like. The only dependable way to settle the question is a network-level check called forward-confirmed reverse-DNS, and this lesson explains exactly how it works.

In short, you never trust the label a visitor gives you; you trust what its actual network identity can prove.

What bot verification actually is

Every request to your site arrives with a user-agent string, a short self-description like Googlebot or GPTBot. That string is convenient for identifying friendly crawlers, but it carries no proof. A scraper can send the exact same text, so the presence of Googlebot in your logs tells you what the client claimed, not what it was. Verification is the process of replacing that claim with evidence by checking the visitor’s IP address against the operator’s official network, in both directions, so a match becomes something you can rely on.

Why a faked bot is a real problem

Trusting user-agent strings blindly causes two distinct harms. The first is dirty data. If impostor traffic is counted as genuine AI crawling, you will overestimate how much real interest engines are showing in your site and make decisions on inflated numbers. The second is security and resource cost. Abusive scrapers deliberately impersonate well-known bots precisely because site owners tend to wave through anything labeled Googlebot or GPTBot, which lets bad actors hide among the very traffic you most want to welcome. Verification protects both the accuracy of your analytics and the integrity of your access controls, which is why it sits underneath any serious measure of AI visibility.

How the verification mechanism works

The reliable check is forward-confirmed reverse-DNS, often abbreviated FCrDNS. It works by asking the network itself to vouch for the visitor, in two steps that must agree.

Reading the diagram from left to right, the logic is straightforward. You start from the one thing the visitor cannot fake easily, its IP address, and you let DNS confirm or deny the rest.

1. Take the visitor’s IP and do a reverse-DNS lookup to get a hostname.
2. Confirm the hostname ends in the operator’s official domain, for example googlebot.com or google.com.
3. Resolve that hostname forward back to an IP and confirm it matches the original. Both directions must agree.

If either direction fails to line up, the visitor is not who it claimed to be, regardless of what its user-agent said. The reason this is hard to fake is that an attacker would need to control the operator’s DNS records, not merely set a header.

Forward-confirmed reverse-DNS, step by step.

The verification methods, and where each fits

There is more than one way to confirm a crawler, and they suit different operators.

• Forward-confirmed reverse-DNS is the gold standard and the most broadly applicable, because it works for any operator that runs its bots from properly named hosts. This is the method most major search and AI crawlers expect you to use.
• Published IP ranges are offered by some operators as official lists of the addresses their bots use. Where available, checking the visitor IP against the current published range is fast and unambiguous, though the lists change and must be kept fresh.
• Signed or token-based checks are emerging for certain agents, but support is uneven, so they complement rather than replace the DNS approach today.

In practice, the strongest setup combines reverse-DNS with published ranges where an operator provides them, falling back to FCrDNS for everyone else.

When and where to apply it

You apply verification whenever the answer to “was this really the bot it claimed to be” changes a decision. That includes cleaning your crawler analytics so only confirmed visits count, deciding whether to allow or rate-limit a heavy crawler, and investigating suspicious spikes of traffic from agents that should be modest. It is especially important for AI crawlers, because the names GPTBot and PerplexityBot carry enough goodwill that impersonating them is an obvious move for anyone trying to scrape quietly. The lesson on GPTBot, ClaudeBot and PerplexityBot covers the specific agents most worth verifying.

Best practices for trustworthy verification

1. Verify both directions, every time. A reverse lookup alone is not enough; the forward resolution must return the original IP for the check to count.
2. Match against official domains, not substrings. Confirm the hostname truly ends in the operator’s domain so a lookalike like googlebot.com.attacker.net cannot slip through.
3. Run the check off the request path. DNS lookups take time, so perform them in a background job rather than during the page load to avoid adding latency for real visitors.
4. Record a confidence outcome. Mark each visit as verified or spoofed and keep the result, so your analytics can separate “a bot said it was GPTBot” from “this really was GPTBot.”

Trustworthy bot verification.

An honest limitation, and the workaround

The honest limit is performance and coverage. A naive implementation that runs a DNS lookup on every single request would slow your site, and not every operator publishes the official domains or IP ranges that verification depends on. Neither problem is a dead end. The latency issue is solved by batching lookups into a background process that never touches the front-end request, so verification adds no delay your visitors can feel. The coverage issue is handled by applying the strictest check available per operator, FCrDNS where domains are published, IP-range matching where ranges are published, and treating anything that cannot be confirmed as low-confidence rather than quietly trusting it. You are never left guessing; an unverifiable visitor is simply flagged as such.

Check what you have, then verify at scale

A good first move is to look at the bots already hitting your site and see how many survive scrutiny. Run a sample of your server logs through the free AI Crawler Log Analyzer and it will separate the AI crawlers from the noise and surface visits that look like spoofs. To make this continuous and automatic, CiteTrack performs forward-confirmed reverse-DNS verification in a batched background job for every operator that publishes official ranges, marking the ones that fail as spoofed with a low confidence score, all on your own WordPress site. You can read more in AI crawler analytics, which turns a log full of unverified claims into a record you can actually trust.