What it means
The first question is whether this request reached the useful page. A server can return an HTML document that is actually a security challenge, sign-in screen, or temporary holding page. Reading the status number alone does not tell you what content the checker received.
A browser and a direct request can receive different results. Security settings, request headers, JavaScript, localization, or personalization may affect the response. A difference is a reason to inspect the evidence; it does not by itself establish deliberate cloaking or show which version a search engine used.
Crawler identity is a separate issue. A client can send a published user-agent name without belonging to the named company. Vendor verification guidance uses evidence such as network addresses and DNS checks. BLURSOR's diagnostic requests do not become genuine vendor visits just because they use those published names.
Hypothetical example: the browser reaches a page after a challenge
A fictional retailer's direct checker requests receive a verification screen, while the browser capture reaches the product page. The useful conclusion is that these request paths behaved differently. It would be inaccurate to turn that observation into a claim that every AI crawler is blocked or that all crawler access is working.
How BLURSOR measures it
In the report: What BLURSOR received · Verified crawler evidence · Different delivered responses
BLURSOR compares several request profiles, including a transparent checker identity and requests using published crawler user-agent strings. It records response facts and classifies the returned representation. A browser capture, when available, is an independent request path and may be reused from cache.
A count such as 11 / 11 means that all eleven recorded direct profiles received delivered content. It is not eleven verified vendor visits. The report also groups differing responses and identifies the selected direct representation used for page analysis. Challenges or missing evidence do not supply trustworthy raw page-quality measurements.
What to do next
- Give your hosting team the tested URL, check time, and specific request outcomes when a result is unexpected.
- Compare those observations with server or CDN logs before changing access controls.
- Use the relevant vendor's verification method when the decision depends on a real crawler visit.
What it cannot tell you
- One run does not establish treatment across every location, identity, browser state, or later visit.
- Receiving a page does not establish that an AI system indexed, cited, or recommended it.
Sources and further reading
The definitions below describe the underlying concepts. The measurement section describes BLURSOR’s own checks.