Help agents find your policy

Discovery is part of the initial website setup. Publish your policy at your own origin, then add pointers where participating bots and agents can find it. These steps work without a commercial application or payment provider.

1. Publish the authoritative policy

Serve https://example.com/odexa.json with HTTP 200 and Content-Type: application/json, without authentication or a redirect. Replace example.com throughout these examples with your website’s actual origin.

The policy core defines the document and its validation rules. The policy must identify the same origin and list the resources, uses and obligations it covers. Keep the policy public even when covered assets require protected access.

Clients that implement Odexa use this fixed location. Additional pointers help them discover the protocol; they do not replace retrieval and validation of the authoritative document.

2. Add a robots.txt signpost

Add these comments to your existing root /robots.txt:

# Odexa policy: https://example.com/odexa.json
# Informational discovery link; this comment is not a crawl directive.

Keep your existing User-agent, Allow, Disallow and Sitemap records. Publishing Odexa does not require opening blocked paths, and a policy pointer does not override crawl restrictions. Check that your intended participating clients can fetch the policy.

The # prefix makes this an informational comment. Ordinary robots parsers ignore comments; clients need additional support to use the pointer. Do not treat Odexa: as an established robots directive. See RFC 9309, sections 2.2.3–2.2.4.

3. Add an llms.txt link

Create a root /llms.txt, or add a policy section to your existing file:

# Example organisation

> A short description of your website.

## Agent access and use

- [Odexa policy](https://example.com/odexa.json): Read and evaluate the published terms for the resources and uses this policy covers.
- [About Odexa](https://odexa.io/guides/discovery/): How participating clients discover and use the protocol.

Keep the terms in the JSON policy so the text file does not become a second, conflicting copy. The llms.txt proposal provides guidance and links for agents; it does not guarantee that every bot reads the file or implements Odexa.

4. Link from your pages

Add a descriptive policy link in the HTML head:

<link rel="describedby" href="/odexa.json" type="application/json">
<link rel="describedby" href="/llms.txt" type="text/plain">

The policy core also defines an optional HTTP policy link. All policy pointers should lead to the canonical policy on the origin that controls the content. A documentation link may lead to odexa.io; the website’s policy remains on its own origin.

Discovery, permission and agreements

These signposts do not grant permission, record acceptance, appoint a provider or prove agent compliance. Participating clients validate the policy and follow the selected exchange profile. Protected delivery still requires the appropriate access controls. Other published licences and applicable rights remain relevant.

Static policy publication needs no agreement service. Only advertise service metadata when you actually operate a compatible service. Do not add an /odexa-service.json link for an endpoint that does not exist. The quickstart explains the current standalone service example.

Check your setup

Open /robots.txt, /llms.txt and /odexa.json directly. Confirm that the policy pointer uses your origin, returns JSON without a login or redirect, matches the current policy, and is not accidentally blocked for your intended clients. Verify the exact scope with the policy validator. Keep the pointers when you change your implementation or provider.