AI Visibility Verification: Measuring Machine Retrieval
There is a problem with much of the discussion around AI Visibility: too much is inferred, and too little is actually measured.
Asking Google AI Mode, ChatGPT, Claude or another AI system about a business is useful. Seeing that business cited, described correctly or recommended is even more useful. We use those observations ourselves.
But from an engineering standpoint, they begin near the end of the process.
Before an AI or search system can understand, cite or recommend a business, it first has to discover and retrieve the underlying information successfully. We therefore wanted a way to measure that part of the process directly — not merely assume it was happening because a page existed or appeared in search.
So Sydney Business Web has built a passive machine-retrieval observatory using Cloudflare Workers and Cloudflare's analytics infrastructure.
It sits at the network edge, observes selected search and AI retrieval activity, classifies what is being requested and records measurement data while allowing the original request to continue to the website normally. It does not manufacture special content for machines, alter what they receive or attempt to turn every bot request into an impressive-looking metric.
Can identifiable search and AI systems reach the information we have engineered for them — and can we collect defensible evidence of what they actually retrieve?
“AI Visibility” is not one measurable event.
A business appearing in an AI-generated answer is an important outcome — but it tells us very little about the individual technical events that made that outcome possible. Effective AI visibility verification therefore requires us to separate those stages and measure what can genuinely be observed, rather than treating a final AI answer as proof of everything that happened before it.
Outcome observation
We ask an AI system about a business and observe the answer. Does it identify the organisation correctly? Does it understand the services? Does it cite or recommend the business?
Valuable — but downstreamRetrieval evidence
We observe identifiable machine requests at the network edge: what information is requested, whether the request succeeds, what class of resource is retrieved and how often meaningful documents are revisited.
Directly instrumentedInterpretation
Retrieval does not prove that an AI system subsequently used, understood or cited the information. But combined with external outcome testing, it gives us a much stronger evidence chain than either measurement provides alone.
Evidence must stay honest“The page exists, therefore machines can use it.”
A page can exist while crawler access is challenged, retrieval fails, the wrong resource is returned, requests terminate with errors, or the content is simply not revisited when expected. Publication is not proof of retrieval.
Observe the retrieval event itself.
Instrument the path, identify qualifying machine traffic, distinguish meaningful information retrieval from supporting assets, measure successful and failed responses, preserve attribution confidence — and keep synthetic testing separate from production evidence.
That is the gap this project is intended to close. For us, AI visibility verification means moving beyond the assumption that machines can retrieve our information and building evidence that shows when meaningful retrieval actually occurs.
Measure the machine request without changing what the machine receives.
Our first technical requirement for AI visibility verification was deliberately conservative: the measurement layer must observe retrieval activity without becoming part of the content strategy itself. The existing website remains the website. The observatory measures selected requests at the network edge and then allows the original request to continue normally.
Search or AI request
A crawler, retrieval agent or other machine client requests information from Sydney Business Web in the ordinary way. No special machine-only content is created for that request.
Passive retrieval measurement
Selected machine traffic is identified and classified at the Cloudflare edge. The system can distinguish useful retrieval observations from ordinary human browsing and supporting website traffic while preserving the original request path.
Existing website response
The request continues to the normal Sydney Business Web application and receives the same response it would have received without the observatory. The measurement layer is not designed to rewrite, embellish or manufacture content.
Qualifying observations are written separately to a structured analytics dataset for later analysis of crawler identity, resource type, retrieval success, frequency, response behaviour and attribution confidence.
Observation should not materially alter the transaction being measured.
Measurement failure must not become website failure.
Human browsing and machine retrieval are not treated as the same analytical event.
A crawler identity claim is recorded with appropriate confidence rather than automatically accepted as fact.
Built on Cloudflare's edge infrastructure
This implementation sits on top of Cloudflare Workers and Workers Analytics Engine. Workers provide a programmable execution layer at Cloudflare's network edge, while Analytics Engine provides a separate environment for collecting and analysing custom telemetry.
It is an exceptionally elegant combination for this particular engineering problem. We can add a narrowly focused observational layer in front of an existing production website without replacing WordPress, moving the origin or building an entirely separate application stack.
Full credit therefore goes to Cloudflare for the underlying infrastructure. Our work is in how we are applying that infrastructure to the specific problem of AI visibility verification and machine-retrieval evidence.
A bot hit is not automatically meaningful retrieval.
The usefulness of AI visibility verification depends almost entirely on what we choose to count. A raw request total may look impressive while telling us very little. We are therefore interested in the nature of the retrieval event: who appears to be requesting information, what they requested, whether it was successfully returned and whether the resource itself carries meaningful information.
Count evidence according to its significance — not according to how impressive the raw number looks.
Machine identity
We classify requests that present themselves as recognised search crawlers, AI retrieval agents or related machine systems. That identity is treated as an attribution claim, with confidence strengthened where supporting infrastructure signals are available.
Resource requested
We distinguish information-bearing resources such as web documents and machine-readable files from supporting assets such as stylesheets, scripts, images and fonts. This prevents a page load from being inflated into a misleading collection of equally significant retrieval events.
Retrieval success
A request is only useful evidence if we understand what happened to it. Successful responses, failed retrievals and other response conditions can therefore be separated rather than hidden inside a single crawler total.
Frequency and recrawl behaviour
Once sufficient data has accumulated, repeated retrieval can be examined over time. That allows us to study which meaningful resources are revisited, by which machine families, and at approximately what intervals — without pretending that recrawl frequency alone proves downstream AI use.
Ten requests do not necessarily equal ten useful observations.
A machine retrieving an HTML article is analytically different from that same client subsequently retrieving the stylesheet, logo and font used to display it. Both events may be technically real, but they do not carry the same evidential weight.
Meaningful information resources
Web documents, structured or machine-readable resources, sitemaps, feeds and other information-bearing responses can provide evidence that a machine system is retrieving material capable of contributing to discovery, interpretation or later representation.
Assets and ancillary requests
Images, stylesheets, scripts, fonts and other supporting resources may still be useful operational data, but they should not automatically be counted as equivalent evidence of meaningful machine retrieval.
“I am Googlebot” is a claim — not proof.
HTTP User-Agent strings are useful identification signals, but they can be imitated. Someone can send a request containing the name of a well-known crawler without actually being that organisation.
Our AI visibility verification model therefore preserves the distinction between a claimed identity and a more strongly corroborated observation. Where additional network or infrastructure evidence is available, confidence can be raised. Where it is not, we do not quietly promote an assumption into a fact.
Our own test traffic must never become our own proof.
During commissioning we deliberately generated synthetic machine requests to verify that the observatory could detect, classify and record retrieval activity while leaving the website operating normally. Those tests are explicitly distinguishable from real-world observations so they can be excluded from later reporting. Otherwise we would be measuring ourselves and calling it external evidence — which would rather defeat the purpose.
What this proves — and what it emphatically does not prove.
Good AI visibility verification depends as much on knowing the limits of the evidence as it does on collecting the evidence itself. Our retrieval observatory measures machine access and retrieval activity. It does not magically reveal every subsequent decision made by a search engine, retrieval system or large language model.
A successful machine retrieval proves that a qualifying resource was requested and successfully returned. It does not, by itself, prove that the information was understood, indexed, cited, incorporated into an answer or used to make a recommendation.
Direct retrieval observations
- A machine client presented itself as a recognised search or AI retrieval system.
- A particular website or machine-readable resource was actually requested.
- The retrieval received a successful response or encountered a measurable failure condition.
- The request concerned a meaningful information resource rather than merely a supporting asset.
- Particular resources were retrieved repeatedly over time, allowing recrawl patterns to be examined.
- Available network and infrastructure signals can strengthen or weaken our confidence in the claimed machine identity.
Downstream machine behaviour
- That the retrieved content was subsequently indexed or stored.
- That an AI system correctly understood the entities, relationships or claims within the resource.
- That the information entered a particular model's retrieval context for a particular user query.
- That a retrieved page was the source used to generate a later AI answer or citation.
- That retrieval resulted in a business being recommended to a prospective customer.
- That increased crawler activity automatically means improved commercial AI Visibility.
Googlebot is not the same thing as “Google AI Mode used this page”.
If we observe Googlebot retrieving an article, the defensible statement is that Google's crawler retrieved that resource.
It would be considerably less defensible to convert that observation into a claim that “Google AI Mode read this article” or that the page was subsequently responsible for an AI-generated answer. Those are separate downstream events that require different evidence.
The same discipline applies to other search and AI systems. We report the event we observed — not the event we would like to infer from it.
Retrieval is one link in a much larger evidence chain.
Our objective is not to reduce AI Visibility to a single score. It is to build a sequence of independently useful observations that can be combined to understand how a business moves from being technically available to being represented and ultimately surfaced by AI systems.
Discoverability
Can machines locate the business, its entities and its information resources?
Access
Can legitimate machine systems reach the relevant resources without technical obstruction?
Instrumented hereRetrieval
Which meaningful resources are actually requested and successfully returned?
Instrumented hereUnderstanding
How accurately do external systems understand and describe the business and its expertise?
Citation & Representation
Is the business represented correctly or used as a source within generated answers?
Recommendation & Outcome
Does the system ultimately surface the business in relevant decision-making contexts?
The purpose of AI visibility verification is not to manufacture certainty where none exists. It is to replace as many assumptions as possible with separate, observable pieces of evidence — and to remain explicit about the gaps between them.
Test narrowly. Prove the path. Then widen the measurement.
Building an observability layer on a production website introduces an obvious obligation: the measurement system must not become the problem it is trying to measure. So the commissioning process for our AI visibility verification instrument was deliberately progressive rather than site-wide from the first deployment.
Do not give an unproven measurement layer production-wide reach merely because the code appears to work in isolation.
Prove that telemetry can be written.
The first task was not crawler analysis at all. It was simply to prove that the edge process could execute successfully and submit a controlled datapoint to the analytics environment. Until that basic path worked reliably, there was no reason to involve the live website.
Attach the instrument to one known page.
Once the telemetry path was proven, observation was applied to a deliberately narrow live scope rather than the whole site. The page was then accessed normally to confirm that the measurement layer executed while the website continued to behave exactly as expected.
Generate a known machine request and verify detection.
A deliberately generated crawler-style request provided a known test event. This allowed us to verify that the system could recognise the expected machine identity, observe the requested resource and submit the resulting telemetry while the page itself continued to return normally.
Check the Worker, the page and the failure surface.
Invocation behaviour and execution errors were checked before widening the deployment. The important result was not merely that the observatory collected data, but that it did so without introducing errors into the production request path.
Expand observation across the primary website.
Only after the restricted deployment and synthetic test behaved correctly was the observation layer expanded across the main Sydney Business Web hostname. At that point the collection system moved from commissioning into production data gathering.
Worker invocation is not the same as AI retrieval.
Once the production route was widened, the observatory naturally began executing against ordinary website requests as well as qualifying machine traffic.
Therefore a rising Worker invocation count is not an AI crawler metric. It simply confirms that requests are passing through the observation layer.
The useful AI visibility verification evidence is produced later, when qualifying machine retrievals are classified, filtered and analysed separately from ordinary traffic.
Controlled test observations successfully reached the analytics environment.
The restricted production page continued to operate normally while observation was active.
A known crawler-style request provided an intentional calibration event for the classification path.
Broader collection began only after the narrow deployment had behaved as intended.
The principle is simple: instrument → test → constrain → verify → widen. Good measurement should reduce uncertainty about the system under observation — not introduce a new source of uncertainty of its own.
Data collection tells us what happened. Measurement tells us whether it matters.
Once the observatory is collecting production data, the next challenge is interpretation. A stream of machine requests is not automatically useful AI visibility verification. The raw telemetry has to be filtered, classified and compared before it becomes evidence from which a defensible conclusion can be drawn.
Raw telemetry is evidence material. It is not yet a conclusion.
Observe
Record qualifying machine retrieval activity at the edge without altering the transaction being observed.
Classify
Distinguish crawler family, resource significance, response outcome and the available strength of identity attribution.
Filter
Remove synthetic calibration events, supporting asset noise and observations that should not receive the same analytical weight as meaningful document retrieval.
Interpret
Analyse patterns over time without converting correlation, frequency or crawler activity into claims that the instrument itself cannot prove.
What will we actually want to know?
Once a sufficient body of genuine observations exists, the reporting layer can begin turning individual retrieval events into more useful operational measures.
Which machine families are retrieving us?
We can group meaningful activity by the search, AI or retrieval family presenting the request rather than treating all automated traffic as one undifferentiated population.
Which meaningful URLs are being retrieved?
The most interesting evidence concerns which articles, service pages and machine-readable resources are actually being requested — not merely how many requests hit the domain.
Were those retrievals successful?
Successful delivery can be separated from failures and other response conditions, helping identify where accessibility exists and where technical friction may still remain.
How often are important resources revisited?
Repeated observations allow recrawl behaviour and approximate intervals to be studied over time, particularly for pages that form part of our AI Visibility evidence architecture.
How strong is the attribution?
Claimed machine identity and corroborating infrastructure signals can be considered separately so stronger observations do not become mixed indiscriminately with weaker User-Agent-only evidence.
Is retrieval behaviour changing?
Over a longer observation period we can look for changes in retrieval frequency, coverage and machine-family behaviour — while remaining cautious about assigning cause without supporting evidence.
“AI bots made 4,000 requests this month.”
The number may be technically correct and still be nearly useless. It can mix documents, images, scripts, failed requests, uncertain identities and repeated asset traffic into one impressive-looking total.
“These meaningful resources were successfully retrieved by these machine families.”
That statement can then be extended with retrieval frequency, confidence level, failed attempts, recrawl behaviour and historical change. The metric becomes narrower — but substantially more useful.
Not every observation deserves equal certainty.
Our reporting model can retain different levels of confidence rather than collapsing every crawler claim into a binary “verified / not verified” label.
A known crawler name is presented, but little independent corroboration is available.
The request carries additional characteristics that are consistent with the claimed machine family.
Available infrastructure information supports the organisation implied by the crawler identity.
Where the edge platform supplies an applicable verified-bot signal, that evidence can be retained distinctly.
Calibration data does not belong in production results.
Synthetic requests were essential while commissioning the instrument because they gave us known events against which the collection path could be tested.
But once measurement begins, those same events become contamination unless they can be excluded. Our reporting process therefore keeps deliberately generated calibration traffic separate from genuine external observations.
This sounds obvious. It is also exactly the sort of seemingly small distinction that determines whether an AI visibility verification dataset remains evidence or gradually turns into self-generated noise.
The objective is not to produce the largest number. It is to produce the smallest number that still answers the question truthfully.
Retrieval verification is one layer — not the whole of AI Visibility.
The observatory was not built as a standalone crawler counter. It fills a specific measurement gap inside the broader Sydney Business Web approach to AI visibility verification: connecting what we deliberately engineer on a website with observable evidence of how external search and AI systems discover, retrieve, interpret and ultimately represent that information.
AI Visibility is not produced by one schema block, one crawler visit, one citation or one favourable AI answer. It emerges from a connected system of identity, evidence, technical accessibility, retrieval and external representation.
Engineering the information is only the beginning.
Each layer answers a different question. The retrieval observatory strengthens one part of that system by allowing us to measure events that were previously much easier to assume than to observe directly.
Make the business understandable.
The business, people, services, expertise, content and relationships between them need to form a coherent information structure. Our Intelligent Entity Skeleton is the conceptual framework we use for engineering that underlying entity structure.
StructureGive important claims evidence.
Identity alone is not enough. Claims about expertise, services, history and capability become more useful when supported by consistent authorship, business records, case evidence and independent corroboration. We describe that wider body of evidence as the AI Credibility Footprint.
EvidenceMeasure whether machines actually retrieve it.
Crawler accessibility, network behaviour and meaningful resource retrieval sit between publishing information and downstream machine use. The new edge observatory adds direct measurement to this layer rather than relying entirely on assumptions about access and retrieval.
New instrumentTest what AI systems actually say.
We then examine downstream outcomes separately: how external systems describe the business, whether important entities and capabilities are represented accurately, whether sources are cited and whether the business appears in relevant recommendation contexts.
Outcome evidenceEngineer → corroborate → verify retrieval → test representation.
The layers do not substitute for one another. They reinforce one another while answering different technical questions.
Establish who the business is, what it does, who is responsible for it and how the important information connects.
Support important claims with visible, consistent and externally useful evidence rather than relying solely on self-description.
Observe whether qualifying machine systems can actually reach and retrieve meaningful information resources.
Test whether AI and search systems subsequently understand, cite, represent or recommend the business in relevant contexts.
Engineering what machines need to understand.
Our Intelligent Entity Skeleton is concerned with the coherent digital representation of the business: organisation, people, services, expertise, content, relationships, structured data and the supporting information architecture.
Retrieval measurement now gives us another way to examine whether machines are actually reaching important parts of that engineered structure.
Engineering what machines can verify.
The AI Credibility Footprint is concerned with the evidential environment around the entity: authorship, provenance, external corroboration, business records, case evidence and consistency across independent sources.
The retrieval observatory does not replace that evidence. It helps verify that important information resources are technically available to the systems that may subsequently use them.
Measurement does not create visibility.
The Worker does not make Sydney Business Web more authoritative, more relevant or more deserving of citation simply because it measures crawler activity.
Nor does collecting telemetry somehow cause an AI system to understand the business better. The engineering work and the measurement work are separate.
The value of the observatory is that it gives our AI visibility verification methodology another observable layer. We can engineer the information, measure part of its machine retrieval path, and then compare those observations with independent evidence of downstream representation.
We are not trying to build a single magic “AI Visibility score”. We are building something more useful: a chain of evidence in which each measurement says exactly what it can prove — and no more.
Next: Part Two — Measurement & Presentation
The collection layer is now operating. Genuine production observations are beginning to accumulate.
That is where Part One deliberately ends.
We have designed the measurement architecture, defined what constitutes useful evidence, established the boundaries of what that evidence can prove, commissioned the instrument progressively and separated genuine external observations from our own calibration traffic.
Part Two will be a separate technical article dealing primarily with the presentation and analysis layer: how raw retrieval telemetry is transformed into useful AI visibility verification evidence without overstating what the data says.
Importantly, we are not going to manufacture a conclusion simply because the instrument is capable of producing data. A useful observation period must exist before patterns deserve interpretation.
Part Two is coming soon.
First, we let the machines provide the evidence.
Related Sydney Business Web work and primary technical sources
This project forms part of a wider body of work around entity engineering, machine accessibility, evidence and AI Visibility. The external technical references below point directly to the platform and crawler documentation relevant to this implementation.
Sydney Business Web References
AI Visibility Services & Pricing
How Sydney Business Web approaches AI Visibility as an engineering problem involving entity clarity, evidence, technical accessibility and ongoing validation.
View AI Visibility services → Internal · MeasurementWhat AI Visibility Success Looks Like
A practical examination of the signals and outcomes we use when assessing whether a business is becoming more visible, understandable and credible to AI systems.
Explore success measures → Internal · EvidenceMaking a Business Website Visible to AI
A long-running practical record of how Sydney Business Web has engineered and tested its own machine visibility, including external AI-system observations.
See the evidence → Internal · ReferenceAI Visibility Glossary
Definitions of the technical concepts used throughout our AI Visibility work, including entities, retrieval, structured data, GEO, RAG and Sydney Business Web's proprietary frameworks.
Open the glossary →External Technical References
Cloudflare Workers Routes
Cloudflare's documentation for executing Workers against URL routes in front of an existing application server — the architectural capability used for passive edge observation in this project.
Read Cloudflare documentation ↗ Cloudflare · Official DocumentationWorkers Analytics Engine
Cloudflare's high-cardinality analytics platform for writing custom datapoints from Workers and subsequently querying those observations for analysis.
Read Analytics Engine documentation ↗ Google · Official DocumentationGooglebot: Crawling and Verification
Google's technical guidance on Googlebot behaviour and crawler verification, including the important warning that User-Agent identification can be spoofed by other clients.
Read Googlebot documentation ↗ Google · Official DocumentationHow Google Search Works
Google's own distinction between crawling, indexing and serving results — useful context for why retrieval evidence should not automatically be treated as proof of later indexing or representation.
Read Google's technical guide ↗