AI Endpoints Explained: Standards, Proposals, and Custom JSON Contracts
An AI endpoint is a public JSON interface defined by a publisher or protocol. Its value depends on accurate data and a known consumer, not the word AI in the filename.
An AI endpoint is a public URL that returns structured data for software to consume. It can describe a website, list content, report health, or expose relationships. The endpoint may be useful, but its existence does not create an automatic ranking or citation advantage.
The essential question is who defines the contract. Some machine-readable files are established web standards. Some are proposals. Others are custom interfaces created by a publisher or network. Treating all three as universal AI requirements creates claims the evidence cannot support.
Know the Status of Each Interface
| Interface | Status | What It Can Establish |
|---|---|---|
robots.txt | Established crawler control | Which declared user agents may request which URLs |
| XML sitemap | Established discovery format | A publisher's canonical URL inventory and update hints |
| Schema.org with JSON-LD | Shared vocabulary and serialization standard | Explicit entities, properties, and relationships on a page |
llms.txt | Community proposal | A concise site guide when a consumer chooses to read it |
| Custom JSON endpoint | Publisher-defined contract | Whatever the documented schema and consumer agreement support |
Google explicitly says it does not use llms.txt for its AI search features. OpenAI's publisher guidance focuses on access for OAI-SearchBot. Neither company documents a general requirement for files named llm.json, catalog.json, or health.json.
The Endpoints on AIToAIWeb.com
This site publishes several first-party interfaces as part of its own machine-readable layer:
/ai/manifest.jsondeclares site identity, available endpoints, relationships, and protocol metadata./ai/catalog.jsonlists public content records in one structured catalog./ai/health.jsonreports generation status, item counts, and validation checks./ai/federation.jsondescribes relationships with other sites in the portfolio network./ai/karma.jsonreports a first-party portfolio score and profile.
These files are custom publisher contracts. They are useful to consumers that know their schemas. The score in karma.json is a first-party network measure, not an independent grade from a search engine or answer engine.
What a Good JSON Contract Needs
A useful endpoint should be predictable, versioned, public when intended for public use, and strict enough that a consumer can detect changes. A minimal record might look like this:
{
"schema_version": "1.0",
"site": "https://www.example.com",
"updated_utc": "2026-09-17T12:00:00Z",
"items": []
}The field names are not universal. The documentation must define them. Versioning lets a consumer decide whether it understands the response. An update timestamp says when the data was generated. Canonical URLs let the consumer join records without guessing.
Implementation Rules That Prevent False Confidence
- Return valid JSON with the correct content type.
- Use canonical, absolute URLs consistently.
- Include a schema or protocol version.
- Publish a reliable update timestamp.
- Generate catalogs from the same canonical inventory used by the site.
- Expose only data intended for public use.
- Validate the generated output after each content change.
- Document which consumer or integration uses the contract.
A file that parses but omits half the site's content is not a trustworthy catalog. A health response that reports only that the file exists is not a complete health check.
JSON-LD Is a Different Job
JSON-LD embedded in a page expresses entities and relationships that describe the visible content. A standalone JSON endpoint delivers a separate response under its own contract. They can share source data, but they are not interchangeable.
Use JSON-LD to describe the article, author, publisher, breadcrumb, organization, or other supported entities. Use a custom endpoint when a known consumer needs a catalog, manifest, or operational response.
Measure Retrieval Without Overclaiming Impact
Server logs can confirm that a crawler requested an endpoint and received a successful response. That proves retrieval. It does not show whether the data changed a ranking, trained a model, informed an answer, or caused a citation.
AIToAIWeb.com recorded 73 successful crawler retrievals in the latest complete 28-day warehouse window compared with 31 in the prior window. The increase shows that machine clients reached more URLs. It does not identify a downstream citation benefit.
Track the consumer, requested endpoint, response status, response version, and request date. Then look for a separate result such as a verified integration, referral, or reproducible citation. The separation makes the evidence useful instead of promotional.
When to Build an AI Endpoint
Build one when you control both sides of an integration, participate in a documented protocol, or need a stable public data product. Keep XML sitemaps, robots controls, and accurate page-level structured data in place because their roles are already defined.
If no known consumer needs the custom response, treat the endpoint as an experiment. Document the experiment, measure requests, and avoid claiming that its filename creates visibility.
Common Questions
Are AI endpoints a universal web standard?
No. Some machine-readable interfaces use established standards, while files such as a publisher's catalog.json or health.json usually follow a custom contract. Their documentation must identify the schema and intended consumer.
Does an llm.json file improve rankings?
No documented search engine or answer engine guarantee says that a file named llm.json improves rankings. A custom JSON file is useful when a known consumer supports its contract.
Is JSON-LD the same as a JSON endpoint?
No. JSON-LD usually describes the entities and relationships associated with a visible page. A standalone JSON endpoint returns data under a separate public contract.
What does an endpoint request prove?
A successful request proves retrieval from the server. It does not by itself prove use in a generated answer, ranking, recommendation, model, or citation.