A technical SEO lead sees a sudden increase in requests carrying an AI crawler’s name. Marketing interprets the activity as renewed interest in the site, while operations suspects an unfamiliar client copying a recognizable user agent. Both teams are looking at the same log column, but neither has established who sent the requests.
A GEO checker review needs an identity step before crawl counts become evidence about a provider. The practical task is to preserve what the request claimed, test the provider-specific evidence available, and keep uncertain traffic separate. That creates a useful starting point for investigating access and visibility without treating a self-reported name as a verified relationship.
Define Identity Evidence in a GEO Checker Review
Request identity has several evidence levels. A user-agent string states what the client claims to be; a provider-published network range can support a more specific origin check. A successfully verified signature supplies another kind of evidence when the provider documents and uses that mechanism.
Google’s request-verification guidance distinguishes crawler and fetcher categories with different verification references. Use the category relevant to the request rather than one convenient list for every Google-related client. A result should name the method and reference used.
Define an identity vocabulary before classifying traffic. Claimed, verified by a documented method, failed verification, and unresolved are more useful than a single bot flag. They preserve the difference between a rejected claim and a record that lacks enough evidence to decide.
Identity evidence supports a specific conclusion, not every downstream inference.
For a synthetic example, imagine a request labeled ExampleSearchBot whose network origin hasn’t been checked. Its correct initial classification is a claimed identity. Counting it immediately as a verified search crawl would make the report more confident than the evidence allows.
Preserve the Request Evidence Before Classification
Keep the original user-agent value, the observed network address, timestamp with timezone, requested host and path, response status, and the collection point. Add the request identifier used by your infrastructure when available. These fields help a reviewer connect the classification to a particular observation.
Record how the network address was obtained. An origin server behind a proxy may see the proxy’s address rather than the originating client’s address. Your infrastructure owner should identify which recorded field can be trusted for this purpose; an arbitrary forwarded header shouldn’t silently become authoritative.
Preserve only the evidence needed for the investigation in approved storage. Remove unrelated account details, tokens, and visitor information from working examples. A public article or shared training document should use synthetic records rather than copied production logs.
| Evidence state | Required support | Permitted interpretation |
|---|---|---|
| Claimed identity | Recorded user-agent value | Client claimed a provider identity |
| Network verification | Provider reference and checked source address | Address matched the documented scope |
| Signature verification | Validated signature under documented rules | Request met that verification method |
| Failed check | Method, inputs, and specific failure | The stated check did not pass |
| Unresolved | Missing input or unsupported method | Identity was not established |
Keep the raw record distinct from the classification. If a provider updates its ranges or your team finds a collection problem, you can review the judgment without altering what the original request contained. Date the classification and the documentation reference used.
Verify the Provider-Specific Request Identity
Follow the provider’s current method for the relevant request class. Google’s guidance describes checking published IP ranges or using reverse DNS followed by forward verification for supported cases. A plausible hostname alone is insufficient when the documented procedure also requires checking that it resolves back to the source address.
Have the infrastructure owner perform the check against the actual observed address. Preserve the lookup result, reference list version or retrieval date, and the rule applied. Don’t place production credentials or full private logs into an external checking service merely to simplify the process.
Treat each provider as a separate verification case. A successful Google-specific check doesn’t establish an OpenAI, Anthropic, or other crawler identity. Where a provider publishes a different method, link that method in your internal register and record its limits.
Don’t infer the request’s product purpose solely from a familiar corporate network. The provider may document multiple crawler or user-triggered categories. Match the observed claim and verification scope before labeling the request as a particular type of discovery activity.
A reproducible record should let a second reviewer answer three questions: which request was checked, which official rule applied, and what result the check produced. When one answer is missing, keep the identity unresolved instead of expanding the conclusion to fill the gap.
Handle Experimental Signed Requests
Signed requests require careful interpretation during an experimental rollout. Google’s Web Bot Auth documentation describes testing cryptographic request authentication with some agents hosted on its infrastructure. It explicitly says not every request from a participating agent is signed.
Separate verified signatures, failed signature checks, and absent signatures. A missing signature is not by itself proof of impersonation under that documented experiment. Keep the established verification methods available where the provider recommends them.
Let a qualified implementation handle the signature protocol rather than treating the presence of a signature header as success. The record should state that verification completed, which method was used, and any validation failure. A header that resembles the expected format remains a claim until checked.
Keep experimental coverage visible in the report. You might identify a subset of signed requests while leaving other traffic subject to network verification or unresolved classification. Don’t present that subset as a complete census of legitimate agent activity.
Build the review around observations rather than a promise of universal coverage. When the provider changes its implementation, revisit the method and preserve the earlier classification date. This lets a later analyst distinguish a behavior change from a change in your verification process.
Separate Identity From Access and Citation Outcomes
A verified identity doesn’t establish successful page access. Inspect the response status, returned content, and relevant infrastructure evidence separately. A genuine client can receive an error, a challenge page, or content different from what your team expected.
Likewise, a successful fetch doesn’t establish indexing or citation. Those outcomes require their own evidence from the relevant search or answer environment. Keep a linked investigation record rather than turning each earlier step into proof of all later steps.
The next question should follow the strongest available evidence.
For example, verified requests returning unexpected content suggest an access investigation. Verified successful requests with no observed citation suggest a different question about the monitored topic and observation window. Unresolved identities should remain outside provider-specific crawl claims until the missing evidence is addressed.
Use the guide to separating search, training, and user-requested access when documenting the intended role of a bot. Purpose classification and identity verification answer different questions, and the report should retain both fields.
Keep negative conclusions narrow. Failure to observe a verified request in your selected logs doesn’t prove the provider never accessed the site through another documented path or time window. State the collection scope and what the absence actually means within it.
Turn Verified Requests Into a Visibility Investigation
Topify provides a broader workflow for reviewing AI-search visibility. Its GEO score checker describes page-level checks including AI bot access and content signals. Use a relevant page as the input, inspect the reported findings, and connect a specific access question to your separately verified request record.
The analyst’s action is to compare that page-level review with the infrastructure evidence, then decide whether to investigate access, content, or missing observations. The combined output is an evidence-backed next step rather than a claim that one score authenticates a crawler. The public tool description doesn’t establish that it verifies every production request, validates Web Bot Auth signatures, or proves a later citation. Keep those tasks with the responsible infrastructure owner and record which conclusions came from the checker, which came from logs, and which remain unresolved. Start with one consequential page before widening the scope.
Assign an owner to each remaining question. Operations may need to inspect a challenge response, while the content team may need to review how the page answers a monitored buyer question. A shared record helps those teams work from the same evidence without collapsing their responsibilities.
Conclusion
Crawler logs become more useful when identity claims and verified observations remain separate. Preserve the original request, apply a current provider-specific verification method, and record unresolved cases honestly. Experimental signatures can add evidence, but their absence doesn’t automatically invalidate a request when the provider documents incomplete signing coverage.
Choose one page from your GEO access review and trace a small set of relevant requests through the identity, access, and visibility steps. Ask another reviewer to follow the classification from its saved inputs. The immediate goal is a defensible investigation boundary: who was verified, what the server returned, and which later outcomes still require separate evidence before the team explains a visibility change.
FAQ
Does a bot name in a log prove its identity?
No. It records a client claim. Use the provider’s documented verification method and preserve the evidence behind the classification.
Must every legitimate agent request be signed?
No universal rule applies. Google’s current Web Bot Auth experiment explicitly doesn’t sign every participating request, so absent signatures require an appropriate fallback or unresolved status.
Can one provider’s IP check verify other providers?
No. Verification references are provider-specific and may also differ by request category. Record the exact scope of the method used.
Does verified crawling prove a citation?
No. Identity, access, indexing, and citation are separate outcomes. Verify each through evidence appropriate to that step.
