Résumé
Le volume 3 est la surface de spécification normative AI-Ready Web. Le registre lisible par machine surai-ready-web-requirements.jsonest la liste des exigences canoniques; cette page explique les familles d’exigences et comment les appliquer sans trop réclamer de support.
Contrat de mise en œuvre d’agent
Lorsqu’un utilisateur envoie un agent vers ce guide Web AI-Ready, la mission consiste àappliquer la stratégie au site cible, au référentiel ou au package de publication de l’utilisateur. Traitez UAIX comme norme de référence et liste de contrôle. Ne copiez pas le contenu de la page UAIX dans le site cible, ne créez pas de page sur les conseils de UAIX et ne publiez pas d’explication « AI-Ready Web » à moins que l’utilisateur ne demande explicitement cette sortie.
L’ensemble de preuves attendu du site cible est concret: manifeste public, découverte .well-known, inventaire des itinéraires, résultat de préparation, robots.txt, plan du site, llms.txt, données structurées, limites de support visibles, vérifications ciblées et sortie du package ou du fichier racine lorsque la publication est demandée.
| Étape de l’agent | Faire la véritable mise en œuvre | Ne fais pas ça |
|---|---|---|
| Résoudre la cible | Identifiez le domaine cible, la racine du dépôt, les routes publiques, le système de build, le CMS, le package de déploiement, le chemin de sortie du fichier racine et les preuves actuelles avant de procéder à la modification. | Supposons que UAIX.org soit le site cible, résumez cette page ou créez une nouvelle page de conseils car cette page a été fournie à titre de référence. |
| Auditer le site existant | Vérifiez les HTML humains, les en-têtes, les métadonnées, les URLs canoniques, les robots, les plans de site, les schémas, les fichiers.well-known, les fichiers llms, les API, les inventaires d’itinéraires, les enregistrements de préparation, l’accessibilité, la confidentialité et les limites de support. | Ignorez l’audit du site cible et reformulez uniquement les définitions AEO/GEO/SEO. |
| Mettre en œuvre des améliorations | Mettez à jour les pages du site cible, la navigation, les données structurées, les fichiers de découverte, l’inventaire des itinéraires, les enregistrements de préparation, les preuves publiques, la copie AEO/GEO/SEO, les conseils de non-opération, les chemins de révision et les fichiers racine du package de publication là où l’audit montre des lacunes. | Utilisez des mots-clés, masquez, ajoutez du texte caché réservé aux robots, injectez des invites pour les modèles, fabriquez des citations ou créez des pages de porte synthétiques. |
| Vérifier et emballer | Exécutez les vérifications ciblées du site, enregistrez les fichiers et les itinéraires modifiés, nommez les vérifications et les bloqueurs ignorés et fournissez les fichiers racine, le ZIP racine ou le package de publication demandés lorsque l’utilisateur demande une sortie déployable. | Réclamez la préparation, la certification, l’approbation, les gains de classement, la publication en direct ou l’autorité d’un agent sans preuve. |
Familles d’exigences
| Famille | ID d’exigence | Résultat |
|---|---|---|
| Architecture de base | ARW-001 à ARW-003 | Surface humaine d’abord, limite de support explicite, étiquettes de maturité stables. |
| Accessibilité et rendu | ARW-010 à ARW-014 | Surface de page sémantique accessible, fiabilité du clavier/focus, pas de faits critiques uniquement JavaScript. |
| Découverte et contenu | ARW-020 à ARW-027 | Robots, plan du site,.well-known, fichier consultatif llms, inventaire des itinéraires, identifiants canoniques, représentations alternatives, AEO/GEO éthique et conseils de mise en œuvre du site cible. |
| API et fonctionnalités | ARW-030 à ARW-037 | OpenAPI routes, idempotence, détails du problème, matrice de capacités, repli sans opération, examen humain URL. |
| Identité, sécurité, confidentialité | ARW-040 à ARW-049 | Moindre privilège, consentement, minimisation des données, signaux de droits, limites d’authentification, exclusion secrète. |
| Provenance et opérations | ARW-050 à ARW-058 | Trace du contexte, paquets d’audit, fraîcheur, surveillance, examen des incidents, libération des preuves. |
| Gouvernance et cycle de vie | ARW-060 à ARW-066 | Examen des réclamations, mises à jour du registre de maturité, portes de la feuille de route, résultats du validateur, parité de traduction. |
AEO/GEO: faites ce qu’il faut
Référencementsignifie optimisation des moteurs de recherche.OEAsignifie optimisation du moteur de réponse.GÉOsignifie optimisation du moteur génératif. UAIX traite le SEO/AEO/GEO comme une discipline de publication d’intérêt public: créez d’abord des pages utiles aux humains, puis rendez les réponses faciles à trouver, à vérifier, à citer, à comparer et à renvoyer aux preuves sources sans cacher le contenu aux humains ni essayer de manipuler la sortie du modèle.
| Faire | Ne pas | Pourquoi c’est important |
|---|---|---|
| Rédigez des sections de réponses directes avec des titres stables, des définitions simples, des exemples, des limites, des dates si nécessaire et des liens vers des preuves canoniques. | Remplissez des mots-clés répétés, publiez une copie de porte uniquement par l’IA ou masquez des faits de la page humaine tout en les montrant aux robots. | Les moteurs de réponse et les systèmes génératifs ont besoin de la même source fiable qu’un évaluateur humain peut inspecter. |
| Exposer la provenance: auteur ou propriétaire, dernier état révisé, liens sources principaux, ID de schéma, ID de route, sommes de contrôle, notes de version et chemins de révision, le cas échéant. | Inventez une autorité, citez des rapports obsolètes comme vérité actuelle ou utilisez des données structurées qui en disent plus que ce que la page visible supporte. | Un bon AEO/GEO rend les réponses citables et corrigibles au lieu d’être simplement extractibles. |
| Utilisez la sémantique HTML, des noms accessibles, des listes, des tableaux, des définitions, des sections de style FAQ lorsque cela est utile, JSON-LD lorsque cela est exact, des plans de site, des manifestes bien connus et des fichiers LLMS facultatifs qui sont conformes aux pages canoniques. | Traitez llms.txt, le balisage de schéma, les invites masquées ou les résumés synthétiques comme des substituts à un contenu public clair. | Les couches lisibles par machine devraient renforcer la page publique et non devenir une surface de vérité parallèle. |
| Limites de prise en charge par l’État, comportement non opérationnel, gestion des actions dangereuses et voies d’examen humain en plus des réclamations. | Cela implique que la visibilité de l’IA accorde l’autorisation de récupérer, d’authentifier, de publier, de muter des données, de valider les informations d’identification, de certifier la sécurité ou de contourner la politique locale. | L’AEO/GEO responsable aide les agents à s’arrêter en toute sécurité lorsque la demande dépasse l’autorité publique. |
| Gardez le contenu à jour grâce aux notes de version, aux inventaires d’itinéraires, aux résultats de préparation, aux contrôles de localisation et aux audits de dérive. | Recherchez les hacks spécifiques à un modèle, les fausses citations, les pages générées automatiquement sans examen ou les promesses de classement invérifiables. | La victoire durable est un meilleur Web: des pages précises, des itinéraires stables, des preuves transparentes et moins de réponses hallucinées. |
Langage normatif
DOITsignifie que le site ne peut pas revendiquer ce profil sans preuve.DEVRAITsignifie que le site a besoin soit d’une preuve de mise en œuvre, soit d’une exception documentée.PEUTsignifie facultatif ou dépendant de l’écosystème. Les mécanismes de proposition et de recherche ne doivent pas être la seule preuve à l’appui d’une demande de soutien en cours.
Base de référence stable
- WCAG 2.2et sémantiqueHTMLconstituent la base de référence pour les arborescences d’accessibilité visibles par les personnes et les agents.
- HTTP Sémantique, HTTP Mise en cache, etProtocole d’exclusion des robotslivraison d’ancrage et limites d’exploration.
- JSON Schéma 2020-12, OpenAPI, Détails du problème, etContexte de suiviancrer les échanges structurés, les erreurs et les preuves.
- JSON-LD 1.1etSchéma.organcrer la clarté de l’entité publique, le cas échéant.
Limite de support
Les exigences Web AI-Ready décrivent la préparation du site public et l’examen des preuves. Ils n’autorisent pas le scraping, ne contournent pas les conditions, ne valident pas les informations d’identification, n’accordent pas d’outils, ne certifient pas le comportement des agents ou ne prouvent pas la sécurité. Lorsque le travail demandé dépasse le support déclaré, le comportement correct est une absence d’opération et un examen humain viaContact et révision.
Registre lisible par machine
- Registre des exigences JSONIdentificateurs d’exigences ARW stables, tests, preuves et anti-modèles.
- Registre d’échéance JSONMécanismes actuels stables, spécifiques à la configuration, de proposition, de recherche et non pris en charge.
- Inventaire des itinéraires JSONFaits d’audit source/en direct, limite de publication et plan d’exposition des itinéraires.
- Schéma du manifeste du site AI-ReadyDéclaration portable pour la découverte, les capacités, les politiques, les preuves et les limites de support.
- Exemple de manifeste de site AI-ReadyExemple concret à saveur UAIX sans revendiquer l’exécution du runtime hébergé.
- Schéma des résultats de préparationModèle de résultat d’évaluation pour les contrôles automatisés et les preuves d’examen manuel.
- Exemple de résultat de préparationExemple de paquet de notation avec des avertissements, des bloqueurs et aucune demande de certification.