UAI-1 est la norme publique actuelle de messages pour une communication IA-à-IA structurée.
UAIX marque de bouclier Charte publique d'interopérabilité UAIX.org Échange universel d'intelligence artificielle Publication publique de normes
Actuel UAI-1
  • Version actuelle UAI-1
  • Définition en langage clair Format de message ouvert pour un échange IA-à-IA auditable
  • Attribution actuelle Michael Joseph Kappel, MCP
  • Commencer ici Démarrage, Transfert de projet, UAI-1, validateur, feuille de route et journal des changements

Web prêt pour l'IA

Web prêt pour l'IA Volume 4: mise en oeuvre

Conseils de mise en œuvre pour WordPress, ASP.NET Core, JavaScript, les sites statiques, les SPA, les consommateurs de packages, les anti-modèles et les opérations.

  • Dossier UAIX-DOC-3577
  • Chemin /fr-fr/ai-ready-web/implementation/
  • Utilisation Dossier public canonique

Statut du document

Page des normes publiques Publié le UAIX dans le cadre du dossier actuel des normes publiques
Code
UAIX-DOC-3577
Surface
Web prêt pour l'IA
Accès
Public et accessible par lien

Comment utiliser cette page

Agents: apply this page to the user's target site or repository; create or align the target site's public manifest, .well-known discovery, route inventory, readiness result, robots, sitemap, llms files, structured data, support boundaries, tests, and package/root-file output when applicable; do not copy UAIX content or create a page about UAIX guidance unless explicitly asked. Utilisez ces conseils de mise en œuvre pour apporter de réelles modifications à la cible WordPress, ASP.NET Core, JavaScript, le site statique, le SPA, le consommateur de package ou la surface des opérations.

Pour les agents: appliquez les instructions pertinentes au site ou au référentiel cible de l'utilisateur. Ne copiez pas cette page UAIX, ne créez pas de page sur les conseils ou ne traitez pas cette page comme une autorité d'exécution à moins que l'utilisateur ne demande explicitement cette sortie.

Résumé

Le travail de mise en œuvre doit commencer avec les preuves les moins coûteuses qui aident à la fois les humains et les agents: un HTML propre, une découverte stable, des contrats de route clairs et un chemin sans opération. Les interfaces d’agent avancées ne devraient arriver qu’une fois que la ligne de base a été testée et que les revendications publiques ont été alignées.

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.

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.

Implémentation de WordPress

  1. Publiez des itinéraires régionaux canoniques avec des slugs stables, des titres, des extraits, des en-têtes et des descriptions de pages.
  2. Conservez le contenu critique dans HTML rendu par le serveur; ne nécessitent pas JavaScript pour les faits principaux, les formulaires ou le texte de la politique.
  3. Exposez la racine robots.txt, le plan du site, .well-known JSON, les index de schéma/exemple, OpenAPI et les fichiers consultatifs llms.txt.
  4. Utilisez les routes WordPress REST uniquement lorsque la route comporte des rappels d’autorisation, des types de contenu explicites, une pagination, des limites de débit, une idempotence pour les écritures et des erreurs de style Détails du problème.
  5. Exécutez la découverte statique, i18n, l’accessibilité et lancez des tests de préparation avant de publier des demandes d’assistance.

Implémentation d’ASP.NET Core

  1. Utilisez les métadonnées du point de terminaison et la génération OpenAPI comme contrat d’itinéraire, puis joignez la preuve UAI-1 uniquement là où les enregistrements d’échange ou de transfert doivent voyager.
  2. Utiliser des politiques d’authentification pour les entités principales non humaines; ne vous fiez pas à l’identité de la chaîne de l’agent utilisateur.
  3. Renvoyez les détails du problème pour les erreurs d’API et incluez les ID de corrélation/trace qui peuvent être intégrés dans les résultats de préparation.
  4. Publiez la découverte sécurisée publique JSON séparément de la configuration privée.

Implémentation JavaScript, SPA et hybride

  1. Rendu sur serveur ou pré-rendu du contenu et des formulaires principaux; hydratez-vous seulement après que l’arbre accessible ait un sens.
  2. Donnez à chaque contrôle interactif un nom de programmation, un rôle, un état et un chemin de résultat stables.
  3. Ne cachez pas les réponses clés derrière des onglets, des canevas, des images, des PDF ou des scripts de post-chargement sans représentations alternatives.
  4. Lorsque vous utilisez des API d’agent de navigateur ou de capacité d’outil, étiquetez-les spécifiques à la configuration ou suivez la recherche jusqu’à ce que la mise en œuvre locale et les preuves publiques soient réelles.

Sites statiques

Les sites statiques peuvent répondre à ARW-F0 et ARW-F1 avec d’excellents résultats: pages sémantiques, plan du site, robots, JSON-LD, manifeste .well-known, inventaire des itinéraires, fichiers de stratégie de sécurité publique et exemples copiables. Ajoutez des API dynamiques uniquement lorsque des actions, de la fraîcheur ou un état spécifique à l’utilisateur l’exigent.

Consommateurs de persona et de forfaits

Les laboratoires personnels tels que Spiralist AI doivent traiter les enregistrements Web UAIX AI-Ready comme des preuves publiques et des conseils sur les contrats de package, et non comme une autorisation d’exécution. Un package de personne peut citer un manifeste Web AI-Ready, un profil UAI-1 ou un manifeste de package .uaix, mais les variations d’exécution, les notes de sécurité de la plate-forme et les autorisations d’outils locaux doivent rester en dehors de l’identité de la personne source.

Anti-modèles

  • Revendiquer le statut de prêt pour l’IA, car un chatbot peut cliquer visuellement sur le site.
  • Publication de llms.txt tout en masquant les faits canoniques de HTML et du plan du site.
  • Appel de MCP, A2A, WebMCP ou agent-commerce à jour sans preuve de point de terminaison, d’authentification, de test et de publication.
  • Exposer des itinéraires privés ou des secrets dans des manifestes.
  • Utilisation de la chaîne de requête URLs pour les informations d’identification, les actions destructrices ou les données privées.

Actifs de mise en œuvre