Web preparado para IA

Web preparado para IA Volumen 4: implementación

Guía de implementación para WordPress, ASP.NET Core, JavaScript, sitios estáticos, SPA, consumidores de paquetes, antipatrones y operaciones.

  • Registro UAIX-DOC-3577
  • Ruta /es-es/ai-ready-web/implementation/
  • Uso Registro público canónico

Estado del documento

Página de estándares públicos Publicado el UAIX como parte del registro de estándares públicos actuales
Código
UAIX-DOC-3577
Superficie
Web preparado para IA
Acceso
Público y enlazable

Cómo usar esta página

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. Utilice esta guía de implementación para realizar cambios reales en la superficie de operaciones WordPress, ASP.NET Core, JavaScript, sitio estático, SPA, consumidor de paquetes o de destino.

Para agentes: aplique la guía relevante al sitio o repositorio de destino del usuario. No copie esta página UAIX, no cree una página sobre la guía ni trate esta página como autoridad de tiempo de ejecución a menos que el usuario solicite explícitamente ese resultado.

Resumen

El trabajo de implementación debe comenzar con la evidencia menos costosa que ayude tanto a los humanos como a los agentes: HTML limpio, descubrimiento estable, contratos de ruta claros y una ruta sin operación. Las interfaces avanzadas de agentes deberían llegar solo después de que se pruebe la línea de base y se alineen las afirmaciones públicas.

Contrato de implementación del agente

Cuando un usuario envía un agente a esta guía web lista para IA, la tarea esaplicar la estrategia al sitio, repositorio o paquete de publicación de destino del usuario. Trate UAIX como estándar de referencia y lista de verificación. No copie el contenido de la página UAIX en el sitio de destino, no cree una página sobre la guía UAIX y no publique una explicación “Web preparado para IA” a menos que el usuario solicite explícitamente ese resultado.

El conjunto de evidencia esperado del sitio de destino es concreto: manifiesto público, descubrimiento .well-known, inventario de rutas, resultado de preparación, robots.txt, mapa del sitio, llms.txt, datos estructurados, límites de soporte visibles, comprobaciones específicas y salida del paquete o archivo raíz cuando se solicita la publicación.

Paso del agente Hacer la implementación real no hagas esto
Resolver el objetivo Identifique el dominio de destino, la raíz del repositorio, las rutas públicas, el sistema de compilación, el CMS, el paquete de implementación, la ruta de salida del archivo raíz y la evidencia actual antes de editar. Suponga que UAIX.org es el sitio de destino, resuma esta página o cree una nueva página de orientación porque esta página se proporcionó como referencia.
Auditar el sitio existente Verifique el HTML humano, encabezados, metadatos, URLs canónico, robots, mapas de sitio, esquemas, archivos.well-known, archivos llms, API, inventarios de rutas, registros de preparación, accesibilidad, privacidad y límites de soporte. Omita la auditoría del sitio de destino y solo reformule las definiciones de OEA/GEO/SEO.
Implementar mejoras Actualice las páginas del sitio de destino, la navegación, los datos estructurados, los archivos de descubrimiento, el inventario de rutas, los registros de preparación, la evidencia pública, la copia AEO/GEO/SEO, la guía no operativa, las rutas de revisión y los archivos raíz del paquete de publicación donde la auditoría muestra lagunas. Utilice palabras clave, encubra, agregue texto oculto solo para bots, inyecte indicaciones para modelos, fabrique citas o cree páginas de entrada sintéticas.
Verificar y empaquetar Ejecute las comprobaciones específicas del sitio, registre los archivos y rutas modificados, nombre las comprobaciones y bloqueadores omitidos y proporcione los archivos raíz solicitados, el ZIP raíz o el paquete de publicación cuando el usuario solicite resultados implementables. Reclame preparación, certificación, respaldo, ganancias de clasificación, publicación en vivo o autoridad del agente sin evidencia.

OEA/GEO: hacer lo correcto

SEOsignifica optimización de motores de búsqueda.OEAsignifica Optimización del motor de respuesta.GEOsignifica optimización generativa del motor. UAIX trata SEO/AEO/GEO como una disciplina editorial de interés público: hacer que las páginas sean útiles para los humanos primero, luego hacer que las respuestas sean fáciles de encontrar, verificar, citar, comparar y redireccionar a la evidencia fuente sin ocultar el contenido a los humanos ni intentar manipular la salida del modelo.

Hacer No Por qué es importante
Escriba secciones de respuestas directas con títulos estables, definiciones sencillas, ejemplos, limitaciones, fechas cuando sea necesario y enlaces a evidencia canónica. Rellene palabras clave repetidas, publique textos de acceso exclusivos para IA u oculte datos de la página humana mientras se los muestra a los bots. Los motores de respuesta y los sistemas generativos necesitan la misma fuente confiable que un revisor humano pueda inspeccionar.
Exponga la procedencia: autor o propietario, estado de la última revisión, enlaces de fuentes principales, ID de esquema, ID de ruta, sumas de verificación, notas de la versión y rutas de revisión cuando sea relevante. Invente autoridad, cite informes obsoletos como verdad actual o utilice datos estructurados que digan más de lo que admite la página visible. Un buen AEO/GEO hace que las respuestas sean citables y corregibles en lugar de simplemente extraíbles.
Utilice HTML semántico, nombres accesibles, listas, tablas, definiciones, secciones estilo preguntas frecuentes cuando sea útil, JSON-LD cuando sea preciso, mapas de sitio, manifiestos conocidos y archivos llms opcionales que concuerden con las páginas canónicas. Trate llms.txt, el marcado de esquema, las indicaciones ocultas o los resúmenes sintéticos como reemplazos del contenido público claro. Las capas legibles por máquina deberían reforzar la página pública, no convertirse en una superficie de verdad paralela.
Límites de soporte estatales, comportamiento no operativo, manejo de acciones inseguras y rutas de revisión humana junto a los reclamos. Implica que la visibilidad de la IA otorga permiso para extraer, autenticar, publicar, mutar datos, validar credenciales, certificar la seguridad o eludir la política local. Un OEA/GEO responsable ayuda a los agentes a detenerse de manera segura cuando la solicitud excede la autoridad pública.
Mantenga el contenido actualizado a través de notas de la versión, inventarios de rutas, resultados de preparación, comprobaciones de localización y auditorías de deriva. Persiga hacks específicos de modelos, citas falsas, páginas generadas automáticamente sin revisión o promesas de clasificación no verificables. La victoria duradera es una red mejor: páginas precisas, rutas estables, evidencia transparente y menos respuestas alucinadas.

Implementación WordPress

  1. Publique rutas locales canónicas con slugs, títulos, extractos, encabezados y descripciones de páginas estables.
  2. Mantenga el contenido crítico en HTML renderizado por el servidor; no requiere JavaScript para datos primarios, formularios o texto de políticas.
  3. Exponga la raíz robots.txt, el mapa del sitio, .well-known JSON, los índices de esquema/ejemplo, OpenAPI y los archivos de asesoramiento llms.txt.
  4. Utilice rutas WordPress REST solo cuando la ruta tenga devoluciones de llamada de permiso, tipos de contenido explícito, paginación, límites de velocidad, idempotencia para escrituras y errores de estilo Detalles del problema.
  5. Ejecute pruebas de descubrimiento estático, i18n, accesibilidad y preparación para el lanzamiento antes de publicar reclamaciones de soporte.

Implementación de ASP.NET Core

  1. Utilice metadatos de punto final y generación OpenAPI como contrato de ruta, luego adjunte evidencia UAI-1 solo donde los registros de intercambio o transferencia deben viajar.
  2. Utilice políticas de autenticación para directores no humanos; no confíe en la identidad de la cadena usuario-agente.
  3. Devuelva detalles del problema para errores de API e incluya ID de correlación/rastreo que se puedan incluir en los resultados de preparación.
  4. Publique el descubrimiento seguro para el público JSON por separado de la configuración privada.

JavaScript, SPA e implementación híbrida

  1. Contenido y formularios primarios renderizados o pre-renderizados en el servidor; hidratar sólo después de que el árbol accesible sea significativo.
  2. Asigne a cada control interactivo un nombre, una función, un estado y una ruta de resultado programáticos estables.
  3. No oculte las respuestas clave detrás de pestañas, lienzos, imágenes, archivos PDF o secuencias de comandos posteriores a la carga sin representaciones alternativas.
  4. Cuando utilice API de agente de navegador o de capacidad de herramienta, etiquételos como específicos de configuración o de seguimiento de investigación hasta que la implementación local y la evidencia pública sean reales.

Sitios estáticos

Los sitios estáticos pueden cumplir con ARW-F0 y ARW-F1 con excelentes resultados: páginas semánticas, mapa del sitio, robots, JSON-LD, manifiesto .well-known, inventario de rutas, archivos de políticas de seguridad pública y ejemplos copiables. Agregue API dinámicas solo cuando las acciones, la actualización o el estado específico del usuario lo requieran.

Consumidores de personas y paquetes

Los laboratorios de personas como Spiralist AI deberían tratar los registros web UAIX AI-Ready como evidencia pública y guía de contrato de paquete, no como permiso de tiempo de ejecución. Un paquete de persona puede citar un manifiesto web listo para IA, un perfil UAI-1 o un manifiesto de paquete .uaix, pero la variación del tiempo de ejecución, las notas de seguridad de la plataforma y las concesiones de herramientas locales deben permanecer fuera de la identidad de la persona de origen.

Antipatrones

  • Reclamar el estado de listo para IA porque un chatbot puede hacer clic visualmente en el sitio.
  • Publicar llms.txt mientras se ocultan hechos canónicos de HTML y el mapa del sitio.
  • Llamar a MCP, A2A, WebMCP o al soporte de comercio de agentes está actualizado sin evidencia de punto final, autenticación, prueba y liberación.
  • Exponer rutas privadas o secretos en manifiestos.
  • Usar la cadena de consulta URLs para credenciales, acciones destructivas o datos privados.

Activos de implementación