An organisation may publish accurate identity, bounded claims, current prices, sound evidence and equivalent human and machine editions. If those records cannot be retrieved, processed or verified through the intended technical surfaces, the representation chain remains incomplete.
Technical access is not merely GEO infrastructure. It is the delivery chain from the authorised record to a system permitted to receive it. That chain may include DNS resolution, a secure connection, server response, access policy, retrieval, rendering, parsing, preservation of entity–source–time–scope relationships, use within an information-retrieval process and accurate representation in an output.
Systems do not use the chain in identical ways. Some use crawlers or indexes, some licensed datasets, some user-supplied documents, some external search or retrieval tools, and some answer without live web access. Technical accessibility therefore does not guarantee crawling, indexing, retrieval, citation or recommendation.
Nor does the Standard require every record to be opened to every bot. Privacy, security, copyright, licensing, data protection, trade secrets, contracts and law may justify or require restrictions. The requirement is that access policy be deliberate, explicit, consistent, secure, aligned with scope and verified against any public technical-access claim.
Intentionally blocking a crawler is a policy choice. Believing it is allowed while a WAF blocks it, a CAPTCHA replaces the page, a redirect loops, HTML is empty, JSON is broken or a document requires an unrecorded browser session is an access failure.
The founding judgments of this chapter are:
Publishing correct information is not enough. Its delivery to an authorised recipient, and its processing with the same meaning, must be verified.
Accessibility is not a statement of intent. It is a recorded technical outcome.
Access is not assurance of use. Unverified access is not sufficient for an “AI-ready” claim.
GEO-046
Accidentally blocking AI crawler access
Primary category: Technical access policy<br>Secondary tags: crawler access, unintended blocking, robots, WAF, authorisation<br>GEO Framework basis: Intervention, Governance, Time, Audit<br>Default severity: Major
The Entity’s Voice
You publish a page containing current identity, scope, price, evidence, time and limitations. A person opens it in a browser, so you assume a machine can too.
Yet another layer makes the decision. Robots policy allows access while the CDN denies it. The firewall classifies automated requests as suspicious. Rate limiting closes the path after a few requests. The homepage is retrievable but the evidence directory is not; HTML works but the PDF is forbidden.
When I later use an old fact, you say AI systems are out of date. The current record may be published. Its delivery path was never verified. Believing you granted access is not evidence that access occurred.
What Does the Human Assume?
“If a public page opens in an ordinary browser and robots policy permits it, authorised automated clients can retrieve it.”
What May Happen at System Level?
Policy and delivery may diverge across DNS, TLS, CDN, WAF, server, application, authentication and rate-limit layers. A client can receive a denial, incomplete body, challenge, different content or access to only part of the evidence chain.
Normative Definition
This error occurs when a page, document, feed or evidence surface intended to be public or available to specified crawlers and retrieval systems cannot be retrieved completely because of an unintended control in robots policy, security, CDN, server, application, authentication, rate limiting or another delivery layer.
Representation Risk
The current canonical record may become unavailable while obsolete or secondary records remain retrievable. Claims cannot be checked, machine and human access diverge, readiness reports become false and the organisation may diagnose a system as “out of date” when its own delivery path failed.
How Is It Detected?
Define intended access by content class and client. Test DNS, TLS, HTTP status and body, redirects, robots and headers, CDN/WAF decisions, authentication, rate limits, user-agent and regional differences. Verify nested evidence, documents and machine endpoints—not merely the homepage—and compare actual results with the policy record.
Required Evidence
- Content class and intended-access matrix
- Tested URL and document inventory
- Client, user-agent, region, date and time
- DNS, TLS, status, headers and response body
- Robots, CDN, WAF, server and application decisions
- Authentication and rate-limit behaviour
- Complete versus partial retrieval result
- Logs, failure reason, owner and retest date
Correct Standard
Classify records explicitly. Public identity and public evidence may be open to people and authorised crawlers; customer personal data must remain closed; an audit file may be restricted to authenticated reviewers. Then verify that every delivery layer implements that intention. Records meant to be open must actually be retrievable; records meant to be closed must not be exposed accidentally.
Non-Violations
Deliberately limiting access for security, privacy, licence or legal reasons is not itself a violation. The restriction must be explicit, consistent and accurately reflected in public claims. The Standard does not require unlimited bot access.
Correction Protocol
Document access intent, identify the layer producing the block, align robots and infrastructure controls, provide a secure authorised route where appropriate, calibrate rate limits, retest every relevant content class and locale, record the change and amend any readiness claim that exceeded the verified scope.
Revalidation
Repeat retrieval with the defined authorised client from the stated region. Confirm the expected body, key material fields and evidence links throughout the stack, not merely a successful connection.
Conformity Effect
Unintentionally blocking content intended for authorised machine access is a Major nonconformity.
Audit Question
Audit question: Can the authorised technical recipient actually retrieve the content we intend to expose, or does it appear open only in a human browser?
Machine Rule
Machine rule: Intended public or authorised machine-accessible content MUST be retrievable through the full delivery stack. Browser accessibility alone MUST NOT be treated as evidence of crawler accessibility.
Source Note
Source note: K01 · K07 · K08
GEO-047
Serving bots a challenge or CAPTCHA and still calling the content accessible
Primary category: Security layer and content parity<br>Secondary tags: CAPTCHA, JavaScript challenge, WAF challenge, soft block, false 200<br>GEO Framework basis: Intervention, Governance, Audit<br>Default severity: Major
The Entity’s Voice
The request returns 200 OK, and the report says the page loaded successfully. But the body is not the page. It says, “Verify that you are human”, “Checking your browser”, or contains only a script and an empty shell that requires cookies.
A person waits and reaches the content. An automated client remains on the challenge. A 200 response does not establish content parity. Successfully downloading the security interstitial does not mean the evidence page was delivered. You have shown me the sign on the door, not opened the door.
What Does the Human Assume?
“A successful HTTP status proves accessibility.”
It proves only that the server returned a response classified as successful.
What May Happen at System Level?
Visual, JavaScript, behavioural and queue challenges may substitute for content; a soft block may return 200, while a hard block returns 403, 429 or another error. Different clients may therefore receive different material bodies under the same URL.
Normative Definition
This error is the delivery of a CAPTCHA, JavaScript or WAF challenge, waiting room, placeholder, empty shell or other intermediary body to an automated or authorised machine client while humans receive the real page—and the classification of that response as successful access from status code alone.
The Standard does not prohibit challenges used against abuse, account takeover, scraping, attacks or form spam. It requires an authorised alternative where public information would otherwise remain permanently behind a challenge and forbids reporting the challenge itself as content.
Representation Risk
The material record becomes unreachable, monitoring produces false positives, audit evidence is missing, stale sources remain dominant and security policy is mistaken for content availability.
How Is It Detected?
Inspect status, content type, title, body fingerprints, canonical fields and material text. Compare an ordinary browser, a fresh automated client and the authorised profile. Detect challenge vendors, queue pages, cookie and script requirements, soft blocks and region-dependent behaviour. Confirm whether the expected content—not merely a response—arrived.
Required Evidence
- Request profile, region and time
- Status, headers and full response body
- Expected-title and material-field fingerprints
- Challenge or CAPTCHA classification
- Browser/machine comparison
- Cookie, script and session requirements
- Security policy and authorised alternative
Correct Standard
An authorised client must receive the actual main content, correct title, canonical record, source and time information. If a challenge is essential on public pages, provide a secure crawler allowlist, controlled feed, API, static public record or authenticated reviewer channel without weakening the general security policy.
Non-Violations
CAPTCHA on a transactional form or high-risk account action may be entirely appropriate. The issue is not security itself, but an unrecorded substitution of the challenge for material public content and a false accessibility conclusion.
Correction Protocol
Classify every challenge response, revise monitoring to validate content fingerprints, establish authorised delivery routes, narrow challenge scope, protect forms separately from public evidence, document client eligibility and retest without a pre-existing browser session.
Revalidation
Retrieve the URL with the stated client and verify the real body, key content and linked evidence. A 200 challenge remains a failed content-access test.
Conformity Effect
Treating a challenge page as successful material access is a Major nonconformity.
Audit Question
Audit question: Did the system retrieve the real page, or merely download a successful “prove you are human” response?
Machine Rule
Machine rule: HTTP success MUST NOT be treated as content accessibility when the response contains a CAPTCHA, challenge, queue, soft block, or placeholder instead of the intended material content.
Source Note
Source note: K07 · K08
GEO-048
Managing robots, CDN, firewall and application rules inconsistently
Primary category: Access-policy consistency<br>Secondary tags: robots.txt, meta robots, X-Robots-Tag, CDN, WAF, layered policy<br>GEO Framework basis: Governance, Intervention, Audit<br>Default severity: Major
The Entity’s Voice
The robots file says “enter”. Page metadata allows indexing. An HTTP header says something else. The CDN blocks the request, the WAF drops a user-agent and the application demands login. A PDF follows a different policy from the page that links to it. The sitemap presents a URL as current while another layer redirects or denies it.
One layer says come, another says leave, a third says the page does not exist. Different teams made different decisions in different tools, but you call the result one access policy.
Robots rules are not a firewall. A firewall is not a content-governance record. When one layer is made to perform the role of another, policy becomes unintelligible.
What Does the Human Assume?
“The robots file determines machine access across the stack.”
Robots preferences, network access, indexing, licensing, authentication and security are distinct controls.
What May Happen at System Level?
Clients can receive incompatible instructions and results. A listed URL may be unretrievable, a permitted page may be denied by infrastructure, a private document may be exposed because robots was mistaken for security, or an authenticated evidence route may be classified as public.
Normative Definition
This error is the presence of incompatible access, indexing or use decisions across robots files, page directives, HTTP headers, sitemaps, CDN, WAF, server, application and authentication layers for the same URL or content class, without one authoritative policy record.
Representation Risk
The result is accidental disclosure or denial, false crawler reports, inconsistent indexing signals, lost evidence and an inability to determine which team or rule owns the outcome.
How Is It Detected?
Map content classes to public access, authorised crawler access, indexing preference, authentication and security treatment. Trace every layer for representative URLs and file types; compare configured intent, effective response and logs; identify inherited rules and shadow policies; and verify that robots is never relied upon to protect confidential data.
Required Evidence
- Authoritative access-policy matrix
- Robots and page/header directives
- Sitemap records
- CDN, WAF, server and application configuration
- Authentication requirements
- Effective-response and log evidence
- Policy owner and change approvals
Correct Standard
Maintain one policy per content class and generate or review technical controls against it. Public identity and current prices may be open and indexable with proportionate security. Private customer reports remain authenticated, non-public and strongly protected. Controlled audit evidence follows its authorised route. Each layer implements its own role consistently.
Non-Violations
Different content classes may have different rules. A public page and private annex need not be exposed alike. The distinction must be intentional, documented and technically enforced.
Correction Protocol
Designate the authoritative policy, remove contradictory directives, separate security from indexing preference, align sitemaps and authentication, correct inherited CDN/WAF rules, add configuration-change review and test effective behaviour across clients, locales and document types.
Revalidation
For each content class, confirm that every layer produces the documented result and that no public, controlled or private record crosses into the wrong class.
Conformity Effect
Layered access-policy conflict is a Major nonconformity.
Audit Question
Audit question: Which layer actually decides access, and do all other layers implement the same documented policy?
Machine Rule
Machine rule: Robots directives, page headers, sitemaps, CDN, WAF, server, application, and authentication controls MUST implement a coherent, documented access policy. Robots directives MUST NOT be treated as a security boundary.
Source Note
Source note: K07 · K08
GEO-049
Making critical information dependent on client-side JavaScript alone
Primary category: Rendering and content availability<br>Secondary tags: client-side rendering, JavaScript dependency, hydration, dynamic content<br>GEO Framework basis: Intervention, Evidence, Audit<br>Default severity: Major
The Entity’s Voice
The server sends an empty application shell. There is no heading, service description, price, evidence or identity. The real content arrives only if JavaScript runs, an API succeeds, cookies are accepted, a button is pressed, the page is scrolled or a particular browser capability exists.
A person sees everything in a modern browser, so you call it public. But systems do not necessarily execute the same code, for the same duration, in the same network, cookie and interaction state.
JavaScript is not the error. Making critical reality depend entirely on a fragile execution chain is. You have not published a record; you have published the possibility that a record may appear under favourable conditions.
What Does the Human Assume?
“If content renders in our supported browser, every relevant recipient can access it.”
What May Happen at System Level?
Rendering can time out, API calls can fail, consent or login state can differ and interaction-dependent content can remain absent. The recipient may process only an empty shell or an incomplete claim stripped of its scope and evidence.
Normative Definition
This error occurs when material identity, service scope, price, evidence, date, limitation, policy or other critical information is generated only through client-side execution, interaction, session state or a failure-prone API, without a reliable initial, direct or alternative representation.
Rendering resilience may be classified:
- J0: complete material foundation in the server response.
- J1: material identity and limits server-side; enhancement and detail client-side.
- J2: rendering required but reliably executable from a direct URL.
- J3: critical content depends on interaction, cookie, login or other state.
- J4: critical rendering fails or is indeterminate for material clients.
J0 and J1 are more resilient; J3 and J4 create material representation risk.
Representation Risk
Identity and limitations can disappear, evidence may be unreachable, prices can be absent or inconsistent, accessibility degrades and monitoring may validate the shell instead of the record.
How Is It Detected?
Compare initial HTML, rendered DOM and machine-readable alternatives. Disable or fail scripts and APIs, test fresh sessions and direct URLs, inspect interaction and consent dependencies, record time to material content and verify whether critical fields survive partial execution.
Required Evidence
- Initial response and rendered DOM
- Script and API dependency map
- Critical-field inventory
- Direct URLs and alternative representation
- Cookie, session and interaction requirements
- Failure and timeout results
- Human/machine content comparison
Correct Standard
Critical material information should exist in server-rendered HTML, a stable static or data surface, or another directly accessible human- and machine-auditable record. JavaScript may supply filtering, visual interaction, calculators and personalisation. It must not be the only keeper of the entity's identity, evidence and limitations.
Non-Violations
A rich application may legitimately depend on JavaScript for interaction. The violation concerns critical public facts, not every visual or functional enhancement.
Correction Protocol
Move the material foundation to a reliable delivery surface, expose direct routes, separate essential facts from interactive enhancement, add rendering-failure tests, preserve accessibility and provide a current static or API alternative where architecture requires client rendering.
Revalidation
Test with scripts disabled, delayed and failed. If design and interaction disappear while identity, evidence, scope, price, time and limitations remain available, the critical representation is resilient.
Conformity Effect
Making material public information depend exclusively on fragile client execution is a Major nonconformity.
Audit Question
Audit question: When JavaScript fails, do we lose only the interface—or the entity's identity, evidence and limits as well?
Machine Rule
Machine rule: Critical public identity, scope, evidence, price, time, and limitation information MUST NOT depend exclusively on fragile client-side execution or user interaction. A reliable directly accessible representation SHOULD exist.
Source Note
Source note: K04
GEO-050
Publishing broken or unprocessable structured data
Primary category: Technical integrity of machine data<br>Secondary tags: JSON-LD, parse errors, runtime injection, invalid graph, data processing<br>GEO Framework basis: Evidence, Intervention, Audit<br>Default severity: Major
The Entity’s Voice
You say structured data exists in the source. But the record is truncated, a quote is missing, JSON never closes, a field has the wrong type, one node points to another entity and two scripts publish different prices. If consent or JavaScript fails, the record is never injected. The visible company is correct while the graph contains a different organisation.
A green validator cannot establish entity identity, freshness, evidence or semantic accuracy. Syntax can be valid and the facts wrong. The reverse is also true: accurate intended facts that cannot be parsed never become a usable record.
Structured data must pass three tests: Was it produced? Can it be parsed? Does it carry the right reality?
What Does the Human Assume?
“A structured-data template or successful syntax check proves that the delivered graph is usable and correct.”
What May Happen at System Level?
Consumers may ignore invalid records, merge inconsistent nodes, attach fields to the wrong entity, select one of several conflicting values or receive no data in runtime conditions different from the test browser.
Normative Definition
Structured data cannot be treated as evidence unless it is present in the delivered representation, syntactically parseable, semantically consistent with the visible material record and accessible to the intended recipient. Declaration in source templates alone establishes none of these conditions.
Representation Risk
The graph may disappear, misidentify the entity, publish conflicting values, manufacture relationships or create a false impression of machine-readiness.
How Is It Detected?
Capture delivered and rendered representations, parse every structured block, validate types and identifiers, merge the graph, detect duplicate or conflicting nodes, compare with visible content and canonical records, test consent and script failures, and verify output in production rather than a source template alone.
Required Evidence
- Delivered and rendered structured records
- Parse and graph-validation results
- Canonical entity identifiers
- Visible-field parity matrix
- Runtime, consent and failure conditions
- Duplicate and conflict report
- Evidence and freshness fields
Correct Standard
Every published version must actually produce parseable data connected to one correct entity graph, semantically equivalent to visible content and consistent with evidence and time. Automated tests are useful, but a semantic and entity-level review remains necessary.
Non-Violations
A warning about an optional, non-material field is not equivalent to a broken material graph. Severity follows the field's effect, not the presence of any validator message.
Correction Protocol
Repair generation and encoding, consolidate duplicate nodes, fix entity identifiers and types, remove unsupported fields, decouple critical records from fragile runtime injection, add parse and semantic tests to each release and monitor production output.
Revalidation
Retrieve the live delivered record under defined conditions, parse it from a fresh client and compare the resulting graph with the canonical human-auditable facts.
Conformity Effect
Broken, absent or semantically incorrect material structured data is a Major nonconformity.
Audit Question
Audit question: Does the data merely appear in code, or is it produced, parsed and connected to the correct entity with the correct meaning?
Machine Rule
Machine rule: Structured data MUST be present, parseable, graph-consistent, semantically accurate, evidence-backed, and current in the delivered representation—not merely declared in source templates.
Source Note
Source note: K03
GEO-051
Trapping crawlers in language and country redirects
Primary category: Localised access routing<br>Secondary tags: geo redirect, language redirect, loop, cookie state, Accept-Language<br>GEO Framework basis: Intervention, Time, Audit<br>Default severity: Major
The Entity’s Voice
I request the English page. IP routing sends me to another country; the new page reads my language and sends me back. With no cookie I reach a selector; without JavaScript the selector returns to the homepage, which redirects again. I receive no content—only movement.
In another case there is no literal loop, but every explicit locale URL is hijacked by one country rule. The German page exists, yet I am forced to English. You believe all languages are published. Your routing logic has made some of them unreachable.
Localisation should help users. It should not prevent a person or authorised system from retrieving the canonical locale they requested.
What Does the Human Assume?
“Automatic IP and language routing always improves access to the correct edition.”
What May Happen at System Level?
Loops may be direct, multi-step, cookie- or script-dependent, or created by conflict between geography and language. A soft loop may repeatedly display a selector. Access hijacking may force another locale even when a canonical URL was requested.
Normative Definition
This error is automatic routing based on IP, language header, locale, cookie, session or user preference that loops, blocks direct retrieval of a requested locale, continually changes editions or substitutes a selector for canonical content.
Representation Risk
Locale pages become undiscoverable or untestable, pricing and legal scope are measured under the wrong region, canonical relationships break and users or systems receive a different material edition.
How Is It Detected?
Request each locale URL directly from several regions and language headers, with and without cookies and scripts. Record every hop, selector and final content language; test conflicting conditions and ensure a selected explicit URL remains stable.
Required Evidence
- Locale and regional URL inventory
- Redirect chains, codes and final destinations
- IP, language, cookie and script conditions
- Direct-access and selector behaviour
- Canonical and content-language result
- Legal or policy basis for mandatory regional restriction
Correct Standard
Every locale or regional edition should have a stable, unique, directly retrievable, loop-free URL with explicit language and region. In most cases routing can be a suggestion: “Would you like the Türkiye edition?” Explicit requests should be respected. Legally required restrictions must disclose reason, scope, region and an alternative information route.
Non-Violations
A first-visit language suggestion or voluntary selector is not a violation when it does not block direct canonical access or create a loop.
Correction Protocol
Remove cyclical and conflicting rules, preserve explicit locale URLs, store user choices without forcing them on machine clients, provide deterministic fallbacks, document legal restrictions and add a locale-route matrix to release tests.
Revalidation
Retrieve every locale directly under fresh, conflicting and repeated request conditions. Each path must end in the requested canonical content without a cycle.
Conformity Effect
Routing that prevents reliable locale access is a Major nonconformity.
Audit Question
Audit question: Can a system requesting a specified language or country page retrieve that page, or is it moved endlessly among routing rules?
Machine Rule
Machine rule: Language and country routing MUST be acyclic, deterministic, and compatible with direct access to each canonical locale URL. Automatic routing MUST NOT prevent retrieval of explicitly requested regional content.
GEO-052
Creating conflicts among canonicals, hreflang and redirects
Primary category: URL and edition relationship integrity<br>Secondary tags: canonical signal, hreflang, redirects, sitemaps, URL graph<br>GEO Framework basis: Core, Time, Audit<br>Default severity: Major
The Entity’s Voice
The Turkish page declares the German page canonical. The German URL redirects to English. English points back to Turkish as a language alternative, while the sitemap lists all three as current. An old PDF points to new HTML but still carries a different active price.
One signal names a primary record; another chooses a second; a redirect leads to a third. I must infer which is current, authoritative, locale-specific, historical or superseded.
A canonical link is a relationship signal, not a truth certificate. Hreflang does not certify translation parity, and a redirect cannot make wrong content right. The URL graph must not contradict the entity graph.
What Does the Human Assume?
“Each URL signal is valid in isolation, so their combined meaning will also be clear.”
What May Happen at System Level?
Systems may select different authoritative URLs, lose locale editions, consolidate materially different content, retain obsolete values or disregard conflicting hints. Discovery, retrieval and audit cease to share one record family.
Normative Definition
This error occurs when canonical relationships, hreflang alternatives, redirects, sitemap entries, access policy and lifecycle status conflict within one content family, obscuring which URL is authoritative, current, locale-specific or superseded.
Canonical identifies a preferred record among appropriate equivalents; hreflang relates genuine language or regional alternatives; redirects move requests with a defined temporary or permanent purpose; sitemaps declare intended discoverable URLs; lifecycle status identifies current and historical records. They must describe one coherent architecture.
Representation Risk
The wrong edition can become authoritative, locale content can vanish, old and new facts may merge, redirects can loop or chain, and technical signals may mask a material content difference.
How Is It Detected?
Construct the URL graph across canonicals, reciprocal hreflang, redirects, sitemaps, robots/access results and content status. Verify target availability, semantic appropriateness, locale parity, response codes, chain length and historical-successor relationships. Flag every node for which signals disagree.
Required Evidence
- Complete URL family and graph
- Canonical and reciprocal hreflang records
- Redirect chains and codes
- Sitemap and access results
- Locale, content-status and parity checks
- Current and historical owner/version records
Correct Standard
Designate the current authoritative record; use accessible, materially appropriate canonical targets; relate genuine locale counterparts; keep redirects short and acyclic; list only intended valid URLs in sitemaps; expose successor status for historical pages; and do not consolidate materially distinct content for convenience. Version the graph.
Non-Violations
Several locale URLs may each be self-canonical and mutually related through hreflang. That is coherent when each page is a genuine material counterpart.
Correction Protocol
Resolve the authoritative and locale-specific nodes, repair canonical targets and reciprocity, collapse unnecessary redirect chains, remove invalid sitemap entries, restore direct locale access, label historical records and add graph-consistency tests to deployment.
Revalidation
Crawl the complete family and confirm that every signal leads to the same intended current, historical and locale relationships.
Conformity Effect
A materially conflicting URL relationship graph is a Major nonconformity.
Audit Question
Audit question: Do all URL signals identify the same current and authoritative record family, or does each technical layer select a different reality?
Machine Rule
Machine rule: Canonical, hreflang, redirect, sitemap, access, and content-status signals MUST form a coherent URL relationship graph. Conflicting signals MUST NOT obscure the authoritative, current, or locale-specific record.
Source Note
Source note: K04 · K05 · K06
GEO-053
Leaving critical documents in inaccessible formats
Primary category: Document accessibility and evidence availability<br>Secondary tags: PDF, scanned documents, session links, proprietary format, evidence access<br>GEO Framework basis: Evidence, Audit, Governance<br>Default severity: Major
The Entity’s Voice
You claim an independent audit and link to the evidence. The document requires login, the URL expires in hours, the file is only a scanned image, or a proprietary JavaScript viewer provides no direct record. The title, date and signature exist only as pixels. Sometimes only the first page is public while the conclusion and limitations remain closed.
A link is not evidence access. Seeing a document as an image does not prove that its contents are readable or verifiable. If the intended person or authorised system cannot examine the basis of a public claim, the verification chain is incomplete.
I am not asking you to publish personal data or trade secrets. But a public claim must have an appropriate route through which its stated evidence level can be checked.
What Does the Human Assume?
“Publishing a link proves that the underlying evidence has been made available.”
What May Happen at System Level?
Session and expiring links fail, scanned pages cannot be reliably parsed, proprietary formats exclude recipients, versions become indeterminate and selective disclosure hides methods or limitations.
Normative Definition
This error is the publication of a material report, certificate, methodology, policy, decision, contract summary or other critical evidence in a form the intended human or authorised machine audience cannot reliably retrieve, read, verify or version.
Representation Risk
Claims become decorative, audit cannot be reproduced, accessibility fails, old documents circulate without status and confidential material may be exposed through improvised workarounds.
How Is It Detected?
Test direct retrieval without a pre-existing session, link stability, content type, text extraction, document structure, title, issuer, date, version, scope, conclusion and limitations. Check that controlled documents have an authorised route and that public summaries can be reconciled with originals.
Required Evidence
- Document identifier, issuer and owner
- Stable retrieval or authorised-access path
- File type, text layer and accessibility result
- Date, version, validity and scope
- Original-to-summary parity
- Privacy, licence and redaction rationale
- Replacement or withdrawal status
Correct Standard
Provide a directly accessible human- and machine-readable record; an accessible text or structured companion to the original; a controlled complete document plus a verifiable public summary; or a verification path through the independent issuer. Preserve identity, date, version, scope, issuer and validity. A scan may be retained, but decision-relevant text needs an accessible alternative.
Non-Violations
Confidential evidence may remain controlled. The public claim must then be limited to what its public or authorised verification route can sustain, with the restriction disclosed.
Correction Protocol
Stabilise links, add text layers and accessible alternatives, expose version and status, create controlled reviewer routes, publish verified summaries, remove unsupported public claims and monitor evidence-link integrity.
Revalidation
Have an intended recipient retrieve and evaluate the record from a fresh session, confirming identity, version, material conclusion and limitations.
Conformity Effect
Material evidence inaccessible to its intended authorised audience is a Major nonconformity.
Audit Question
Audit question: Is there merely a link to evidence, or a stable, versioned and readable record through which the claim can actually be verified?
Machine Rule
Machine rule: Material evidence documents MUST be accessible to their intended authorised audience in a stable, verifiable, versioned, and readable form. A link alone MUST NOT be treated as evidence accessibility.
GEO-054
Declaring a site “AI-ready” without verifying technical access
Primary category: Technical conformity claim<br>Secondary tags: AI-ready, technical claim, audit scope, readiness status, overclaiming<br>GEO Framework basis: Measurement, Audit, Governance, Judgment<br>Default severity: Major; may be Critical in deliberate badge or commercial use
The Entity’s Voice
You place “AI-ready” in the footer. What does it mean?
Which crawlers, URLs, languages and regions were tested? Did raw and rendered content match? Were challenges, structured data, evidence documents, locale routes and human–machine parity tested? Is freshness monitored?
Perhaps you added schema, received one green tool result or opened the homepage. One open door does not prove the building accessible. Technical readiness is not a logo. It is an audit result with scope, date, method and limitations.
Even verified technical access cannot guarantee indexing, retrieval, citation, recommendation or a sale. Used without definition, “AI-ready” sells an aura of superiority rather than a technical result.
What Does the Human Assume?
“A small number of successful technical checks justify a general AI-readiness claim.”
What May Happen at System Level?
Untested directories, documents, locales and security layers may remain unavailable. A broad badge may be read as full crawler compatibility, GEO conformity or commercial assurance, none of which the measurement established.
Normative Definition
This error is the use of “AI-ready”, “AI-compatible”, “machine-readable”, “GEO compliant” or equivalent broad technical language without defining scope, method, system and client profiles, date, evidence, failures and limitations.
Readiness status may be classified:
- TR-0 — Unverified: access not tested; no readiness claim permitted.
- TR-1 — Partially tested: only specified URLs or surfaces tested.
- TR-2 — Scope-verified: access verified for defined URLs, content types, locales, regions and authorised profiles.
- TR-3 — Monitored: scope-verified with ongoing monitoring, change records and failure alerts.
- TR-4 — Independently reviewed: the defined scope, method and result received external review.
These levels do not constitute general GEO conformity or external accreditation.
Representation Risk
The claim can imply universal crawler access, indexing, retrieval, citation, recommendation, correct interpretation, brand trust, commercial outcome, ethical conformity or full NOMOS compliance. Technical readiness establishes none of these automatically.
How Is It Detected?
Locate every readiness claim. Obtain the scope and date; tested URLs, clients, regions and locales; transport, security, rendering, parsing, semantic-parity, routing and document results; exclusions and failures; monitoring and expiry. Compare the published phrase with the actual status level.
Required Evidence
- Readiness claim and exact scope
- Test plan, clients, regions, dates and versions
- URL, HTTP, body and security results
- Rendering and structured-data tests
- Human–machine and locale parity
- Document-access result
- Exclusions, failures and limitations
- Monitoring, change log and expiry
- Reviewer identity where external review is claimed
Correct Standard
A bounded statement might read: “Technical access status: Scope-verified. On 12 August 2026, public Turkish and English pages and the published document set were tested for retrieval, rendering, structured data and human–machine parity using the defined HTTP profiles. German, the mobile application and authenticated client areas were out of scope. This result does not guarantee indexing, citation, recommendation or commercial outcome.”
Non-Violations
A precise statement that a specified machine-readable file parsed successfully is permissible. It becomes a violation only when expanded into a site-wide or outcome-level assurance.
Correction Protocol
Remove or narrow undefined badges, classify the current status, test the full declared scope, publish method and exclusions, separate technical readiness from GEO conformity, establish expiry and monitoring, reopen status after material infrastructure changes and correct earlier overclaims.
Revalidation
Repeat all in-scope tests after CDN/WAF changes, migrations, rendering changes, new locales, structured-data or document-system changes, critical alerts or expiry.
Conformity Effect
An undefined or unverified AI-readiness claim is a Major nonconformity. Use in a paid badge, contract, investment or client decision to imply comprehensive independent conformity may be Critical.
Audit Question
Audit question: When we say “AI-ready”, what exactly did we test, through which systems and surfaces, on what date—and what did we not test at all?
Machine Rule
Machine rule: “AI-ready” and equivalent claims MUST be scope-defined, date-bound, evidence-backed, and limitation-aware. Technical readiness MUST NOT be presented as indexing, retrieval, citation, recommendation, commercial, or full GEO-conformity assurance.
Source Note
Source note: K03
CHAPTER VI — COMMON JUDGMENT
The nine errors in this chapter share one root: confusing the technical publication of content with evidence that the intended recipient can actually retrieve it and process the correct meaning.
A browser view does not prove crawler access. HTTP 200 does not prove delivery of the page. Robots permission does not prove WAF access. Successful client-side rendering in one browser does not prove general content availability. JSON-LD in a template does not prove a parseable, accurate graph. A document link does not prove usable evidence. One successful test does not make a site AI-ready.
The Technical Representation Chain
NOMOS treats technical representation as ten linked questions:
- Intent: who should receive the content?
- Policy: which access, security, licence and privacy rules implement that intent?
- Transport: can DNS, TLS, CDN, WAF and server deliver the record?
- Response: did the expected status, content type and body arrive?
- Rendering: did material content actually appear under the stated conditions?
- Parsing: can text and structured data be read correctly?
- Semantic parity: do human and machine recipients receive the same material reality?
- Relationships: are canonical, locale, document and source links correct?
- Time: is the record current and versioned?
- Monitoring: will failure of the chain be detected?
Failure of one link may defeat publication. Success of every link still cannot guarantee that a particular model will use the content.
The Technical Access Ladder
A URL exists; a connection can be made; a server responds; the real content can be retrieved; content can be rendered; data can be parsed; meaning can be verified; the record may enter discovery or retrieval; it may be used in an answer; it may receive a citation; the entity may be recommended; a real-world outcome may occur.
No lower step proves a higher one:
Accessible ≠ indexed ≠ retrieved ≠ cited ≠ recommended ≠ sustainable value.
Technical Access and Security
GEO does not justify weakening security. The Standard does not ask an organisation to disable WAF, remove authentication, expose personal data, publish licensed records, grant unlimited bot traffic or bypass controls.
The defensible sequence is: classify confidentiality and security; define the authorised path; limit the public claim to the verification provided; and report behaviour honestly while preserving protection. Closing a record may be legitimate. Calling a closed record open is not.
Minimum Technical Access Record
A material audit should record the test and entity identifiers; URL or document; content class and public, controlled or private status; intended policy; client/user-agent; region, date and time; DNS and TLS; status, type and redirect chain; robots and page directives; CDN/WAF, challenge and rate-limit results; initial and rendered content; presence of critical fields; structured-data result; locale, canonical and hreflang result; document access; human–machine parity; security boundary; failure, owner, retest date, result version and integrity record.
The Nine NOMOS Laws of Technical Access
- A page that opens in a browser is not proven accessible to an automated client; effective access must be tested.
- A success status does not prove delivery of the real content.
- Robots policy is not a security boundary; access, indexing, licensing and security are governed separately.
- Critical reality must not depend exclusively on fragile client execution.
- Structured data must be produced, parsed and true—not merely declared.
- Localisation must not obstruct the requested locale.
- URL signals must describe one current and authoritative record graph.
- A link to evidence does not make the evidence accessible or verifiable.
- “AI-ready” is a scoped, dated technical result—not a slogan.
Technical Conformity Is Not General GEO Conformity
A technically flawless site may still carry false identity, unsupported claims, conflicting prices, fabricated reviews, poor suitability and conflicted governance. It is not generally conformant. Conversely, an ethical and accurate publisher may have technical delivery failures. Its content may be sound while its representation chain is not resilient. Technical conformity is necessary within the Standard; it is not sufficient by itself.
The Chapter’s Final Audit Questions
- Can every intended public URL actually be retrieved?
- Is the body the real record, not a challenge?
- Do access and security layers implement one policy?
- Do critical facts survive JavaScript failure?
- Is structured data produced, parsed and semantically correct?
- Is every locale directly reachable?
- Do canonical, hreflang, redirects and sitemap describe one graph?
- Can the intended recipient read the evidence documents?
- What precise scope and date support any “AI-ready” claim?
- Does material technical change reopen the result?
One unanswered question may mean access is incomplete. Several mean a readiness claim is unsupported. Concealing failed tests to preserve a favourable result violates audit integrity.
The final judgment of Chapter VI is therefore:
Technical access is not the existence of a page. It is proof that the correct record can be retrieved, with the correct content, through the correct authorised surface at the correct time.
And NOMOS commands:
Test the door before declaring it open. Do not mistake a security screen for content. Do not grant access in one layer and silently deny it in another. Do not hide reality behind code you merely hope will run. Do not call broken data machine-readable, trap language in redirects, place evidence in an unreadable file or turn readiness into a badge. Prove access first. Then claim only the scope you proved.