Résumé
Le volume 5 rend le programme Web AI-Ready utilisable par machine. Un site peut publier un manifeste AI-Ready, un pointeur de découverte .well-known, un résultat d’évaluation de l’état de préparation, un inventaire d’itinéraire et des fichiers de découverte racine alignés sans revendiquer de certification. L’objectif est la portabilité des preuves: les futurs humains et agents peuvent voir ce qui a été vérifié, ce qui a été ignoré, ce qui est bloqué, ce qui reste planifié et quel package ou quel fichier racine doit être déployé.
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. |
Ensemble d’artefacts
- 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.
Liste de contrôle des artefacts du site cible
Un site cible appliquant ces conseils doit créer ou aligner le manifeste public, la découverte .well-known, l’inventaire des itinéraires, le résultat de préparation, robots.txt, le plan du site, llms.txt, les données structurées, le texte de limite de support, les vérifications ciblées et tout package de fichiers racine déployable. Si l’un de ces artefacts est intentionnellement absent, le résultat de préparation doit indiquer la vérification ignorée et le risque résiduel.
Forme manifeste
Le schéma manifeste déclare l’identité du site, les routes publiques, les fichiers de découverte, les profils de capacités, les contrats d’API, les limites des politiques, les liens de preuves, la fraîcheur et les affirmations non prises en charge. Il est conçu uniquement pour les données publiques.
{
"profileId": "uaix.ai-ready-web.manifest.v1",
"site": { "name": "Example", "url": "https://example.com/" },
"readinessProfiles": ["ARW-F0", "ARW-F1"],
"discovery": { "robots": "https://example.com/robots.txt" },
"supportBoundary": "Public discovery and evidence only; no runtime authority."
}[]L'ordre des champs suit l'exemple de clé JSON, l'ordre du schéma publié et le registre de champs public.
Forme du résultat de préparation
Le résultat de préparation enregistre les contrôles automatisés, les contrôles manuels, les avertissements, les bloqueurs, les plages de scores, les contrôles ignorés, les preuves URLs et la déclaration selon laquelle le résultat n’est pas une certification ou une approbation.
Relation avec le registre
Les artefacts Web AI-Ready complètent UAI-1. Utilisez UAI-1 lorsque des messages portables, des packages de mémoire, des transferts, des reçus de révision et des paquets de preuves doivent voyager. Utilisez le manifeste AI-Ready lorsqu’un site Web doit indiquer dans quelle mesure il est lisible, détectable, exploitable, gouverné et limité.
Règle de validation
Chaque artefact doit être analysable JSON, doit utiliser des ID de profil stables, doit contenir une limite de prise en charge, doit éviter les secrets, doit distinguer les normes stables des propositions et doit pointer vers des chemins d’examen humain pour les travaux dangereux ou non pris en charge.