메인 내용으로 이동


An alternative approach to AIs.txt, proposed by Robert Reich


The proposed standard provides a mechanism for transforming website content into question-answer (QA) pairs. It details a data format, including general dataset information, specific website details, and the QA pairs, each accompanied by related metadata.

Key Advantages

  1. Data Optimization and Efficiency. A significant challenge for AI when processing web content is the sheer volume of data that needs to be read, parsed, and understood. Large websites can lead to performance issues due to token limitations and slow data processing. The proposed model, which transforms website content into structured QA pairs, provides a concise and meaningful summary of the web location. The AI doesn't need to read and process the entire document but can instead focus on the distilled and relevant data. This can significantly improve the speed and efficiency of AI operations.
  2. Enhanced Accessibility (a11y). The proposed QA pairs format can work in tandem with meta tag descriptions to enhance the accessibility of web content. By transforming content into a question-answer format, it becomes easier for assistive technologies (like screen readers) to parse and understand the content, making the information more accessible to users with disabilities.
  3. Greater Publisher Control. The Robots.txt file is primarily a directive for search engine crawlers, specifying which parts of a website should not be crawled. However, it gives limited control to the publisher over how the content is understood and used. In contrast, the proposed model allows publishers to dictate the QA pairs directly, which can be seen as giving more detailed instructions to the AI about the content. They can control which parts of their content are highlighted, how it is interpreted, and how it is presented to the end user. This shift gives more authority back to the publishers and can help ensure their content is utilized consistently with their intentions.
  4. Legal Grounding. Unlike Robots.txt, which has no legal bindings, the proposed model could have a structure that provides some legal grounding. This would provide website owners more protection about using their content.


This proposal aims to enhance the efficiency and effectiveness of AI in extracting meaningful information from websites, thus tackling token limits and information overload issues. In addition, it promotes giving some control back to the publisher, akin to an RSS feed or sitemap.xml. Finally, the structured data format can also support generating site-specific versions of AI models.

High-Level API

The data format utilizes JSON with the following main objects:

  • datasetInfo: Provides general information about the dataset, such as its source, collection method, privacy-preserving technique, data balance, legal considerations, and contact info.
  • website: Contains specific details about each website, such as URL, crawl frequency, suggested crawl pages, compression techniques, privacy and legal considerations, compensation, and content.
  • content: An array under website that contains QA pairs each with its question, answer, keywords, rank, votes, metadata (like date added, source, language), augmented data, and data balance.

Detailed Design

The QA pairs are expected to be AI-generated and periodically updated. The AI crawler should be designed to interpret the content and form suitable QA pairs. Alongside these pairs, there will also be a mechanism for ranking the quality of the teams, which is expected to help improve the quality of the dataset overall.

Backwards Compatibility and Interoperability

No known backward compatibility or interoperability issues at this stage.

While robots.txt files currently have no legal binding, this proposal suggests structuring the Terms of Service (TOS) to provide some legal grounding for these files. This would respect the website's privacy and legal considerations outlined in the website object.

Open Issues and Questions

  • How will the AI accurately generate QA pairs?
  • How will the system handle potential inaccuracies in the generated QA pairs?
  • How to formulate the TOS for the legal grounding of the files?
  • How to handle possible disagreements or disputes regarding the content or the ranking of the QA pairs?