Cómo leen los sistemas de IA la Web en 2026: Descubrimiento, Recuperación, Citaciones y Agentes
Cómo los sistemas de IA leen la web en 2026
Del descubrimiento y la recuperación a las citas, recomendaciones y acciones de agentes
Un marco práctico y basado en evidencia para que los sitios web sean más fáciles de descubrir, comprender, verificar y utilizar por parte de sistemas de respuesta de IA, motores de recuperación y agentes de navegador.
Resumen: No existe un "factor de posicionamiento en IA" universal, ni un único rastreador de IA, ni un truco de marcado que garantice una cita. Los diferentes sistemas mecánicos realizan diferentes trabajos. Los rastreadores de búsqueda descubren y actualizan documentos. Los sistemas de respuesta de IA recuperan fuentes para consultas. Los sistemas de generación aumentada por recuperación (RAG) seleccionan pasajes de un corpus. Los agentes de navegador pueden inspeccionar páginas e intentar acciones. La estrategia duradera no es, por lo tanto, "optimizar para ChatGPT." Consiste en hacer que la información importante sea alcanzable, explícita, inequívoca, respaldada por evidencia, recuperable, citable y utilizable.
Nota de investigación importante: Este artículo no afirma que AuditMe haya completado ya un benchmark entre múltiples modelos. El Benchmark de Inteligencia Web de IA de AuditMe v1 descrito a continuación es una metodología abierta propuesta y una especificación de conjunto de datos. No se presentan aquí resultados de benchmarks, porcentajes o afirmaciones causales como resultados observados por AuditMe, a menos que se etiqueten explícitamente como tales.
Última revisión: 13 de septiembre de 2026.
TL;DR de un vistazo
| Pregunta | Mejor respuesta actual | Confianza / evidencia |
|---|---|---|
| ¿Google requiere un marcado GEO especial para AI Overviews o AI Mode? | No. Google afirma que los requisitos técnicos y de calidad normales de Search siguen aplicando y no existen requisitos técnicos adicionales para estas funciones de IA. | Documentación oficial de Google |
¿\llms.txt\ es un estándar universal de IA en la búsqueda? | No. Es una propuesta de la comunidad. Puede ser útil como ayuda de documentación, pero no es un mecanismo garantizado de citación o posicionamiento. | Propuesta + documentación de proveedores |
| ¿Existe un único "rastreador de IA"? | No. Los proveedores exponen múltiples rastreadores, agentes de búsqueda y mecanismos de agentes con diferentes propósitos. | Documentación oficial de proveedores |
| ¿Ser rastreado significa ser citado? | No. El descubrimiento, la recuperación y la citación son resultados separados. | Distinción arquitectónica |
| ¿Los datos estructurados garantizan la visibilidad en IA? | No. Los datos estructurados ayudan a las máquinas y a las funciones de Search compatibles a interpretar contenido; no son una garantía universal de citación. | Google + Schema.org |
¿Bloquear con \robots.txt\ siempre elimina una página de todos los productos de IA? | No. Los efectos dependen del proveedor y del mecanismo específico. | Documentación específica del proveedor |
| ¿Un modelo sin acceso en vivo a la web puede descubrir una nueva página desde la página misma? | No. Necesita una actualización posterior del modelo o una ruta de recuperación externa. | Arquitectura básica del sistema |
| ¿El HTML semántico importa para los agentes? | Sí como base de ingeniería. Los controles nativos, nombres y estados hacen las interfaces más explícitas. OpenAI recomienda específicamente las mejores prácticas de accesibilidad y ARIA para su experiencia de agente. | Estándares web + documentación de proveedores |
| ¿La canonicidad importa para la IA? | Sí para la claridad mecánica en un sentido amplio de ingeniería, pero no afirme que una etiqueta canónica controle directamente cada modelo de IA. La canonicalización es un mecanismo web/búsqueda establecido para consolidar URLs duplicadas. | Documentación de Google; la implicación para IA es una inferencia |
| ¿Qué deben medir los equipos? | Visibilidad, calidad de recuperación/citación y finalización de tareas por separado. | Marco de medición propuesto |
La frase modelo
Una página es útil para una máquina cuando puede ser encontrada, recuperada, analizada, recuperada, comprendida, verificada, citada y, cuando el flujo de trabajo lo requiere, utilizada para realizar una acción.
Prueba AuditMe en vivo — Escaneo instantáneo gratuito
Pega cualquier URL a continuación y obtén una puntuación SEO real en unos 60 segundos. Sin registro: es el mismo motor descrito en este artículo.
1. El web ya no tiene un único lector de máquina
Un mapa práctico del consumo mecánico
| Clase de sistema | Propósito principal | Preocupación típica del sitio web | Cómo se ve el éxito |
|---|---|---|---|
| Rastreador de búsqueda | Descubrir, actualizar e indexar documentos | Rastreabilidad, enlaces internos, HTTP, canonicalización, sitemaps | La página puede ser recuperada y considerada para Search |
| Respuesta de IA / motor de respuesta | Recuperar fuentes y sintetizar una respuesta | Relevancia, calidad de la fuente, claridad, frescura, recuperabilidad | La página es seleccionada como evidencia útil y puede ser citada |
| Modelo sin recuperación en vivo | Generar a partir del estado existente del modelo | Disponibilidad pública antes de entrenamiento/actualización, recuperación externa donde se admita | El modelo tiene conocimiento preciso — pero el sitio web no puede forzar esto directamente |
| Pipeline RAG | Recuperar pasajes de un corpus y generar | Divisibilidad en fragmentos, metadatos, URLs/documentos estables, claridad semántica | Los pasajes relevantes son recuperables y se utilizan fielmente |
| Agente de navegador | Navegar y realizar tareas | Controles semánticos, nombres/estados accesibles, flujos predecibles, errores/recuperación | El agente puede completar la tarea prevista de forma segura |
| Integración tipo Tool / WebMCP | Exponer capacidades explícitas del sitio a un agente | Definiciones de herramientas, entradas/salidas deterministas, seguridad y permisos | El agente utiliza una herramienta proporcionada por el sitio en lugar de adivinar la interfaz |
La última fila es especialmente importante porque la web agentizada está evolucionando más allá de la interacción pura por pantalla. OpenAI documenta actualmente herramientas de sitio basadas en WebMCP en su aplicación de escritorio como un estándar web propuesto para permitir que los sitios expongan capacidades directamente a agentes de IA. Chrome también describe WebMCP como parte de su dirección de compatibilidad con agentes. Consulta OpenAI: Using site tools in the ChatGPT desktop app y Chrome for Developers: A developer toolkit to make your website agent-ready.
La documentación de los proveedores hace la distinción explícita
Esta no es una taxonomía teórica inventada por consultores de SEO.
OpenAI: diferentes propósitos de rastreo y acceso
OpenAI documenta actualmente OAI-SearchBot para el descubrimiento de búsqueda en ChatGPT y documenta por separado GPTBot como un control relacionado con el posible uso de entrenamiento del modelo. OpenAI también documenta el acceso al navegador dirigido por el usuario y las consideraciones de accesibilidad para la compatibilidad con agentes. Para los editores, la lección práctica es simple: no asuma que "el bot de OpenAI" es una sola cosa con un solo propósito.
Consulta la FAQ actual de OpenAI para editores y desarrolladores.
Anthropic: múltiples agentes de usuario, diferentes roles
Anthropic documenta ClaudeBot, Claude-SearchBot y Claude-User. Sus propósitos declarados difieren: la recopilación para desarrollo de modelos, el rastreo orientado a búsqueda y la recuperación dirigida por el usuario no son trabajos intercambiables.
Consulta Anthropic: Does Anthropic crawl data from the web?.
Perplexity: rastreo de búsqueda vs. recuperación dirigida por el usuario
Perplexity documenta PerplexityBot para mostrar y enlazar sitios web en resultados de búsqueda y documenta por separado los mecanismos de acceso activados por el usuario.
Consulta Perplexity Crawlers.
Google: Search, controles relacionados con Gemini y agentes activados por el usuario
Google documenta Googlebot para Search, Google-Extended como un control separado para ciertos usos relacionados con Gemini, y agentes de recuperación activados por el usuario para búsquedas iniciadas por acciones de usuarios en productos de Google. Google afirma explícitamente que Google-Extended no es una señal de posicionamiento de Search.
Consulta la infraestructura de rastreo de Google y los agentes de recuperación activados por el usuario de Google.
Una mejor jerarquía de evidencia para afirmaciones de GEO
Al escribir sobre búsqueda de IA, utilice una jerarquía más estricta que el contenido de marketing genérico.
| Nivel de evidencia | Ejemplo | Cómo expresarlo |
|---|---|---|
| Comportamiento documentado oficialmente | Google afirma que no hay requisitos técnicos adicionales para AI Overviews / AI Mode | Declárelo directamente y enlace la fuente |
| Estándar web / especificación normativa | RFC 9309 define el Protocolo de Exclusión de Robots | Declare el mecanismo y el alcance con precisión |
| Observación controlada | Una prueba reproducible produce un patrón de citación repetido | Publique ejemplos, fechas, consultas y método |
| Inferencia de ingeniería | Los estados de UI explícitos son más fáciles de interpretar para la automatización | Etiquételo como una recomendación de ingeniería |
| Hipótesis | Cierta estructura de párrafo podría mejorar la recuperación de pasajes | Diga que es una hipótesis hasta que se demuestre |
| Folklore | "Todo LLM prefiere exactamente artículos de 1,500 palabras" | No lo publique como un hecho |
Esta jerarquía no es pedantería. Es la base de un contenido de búsqueda de IA creíble.
2. La cadena de evidencia web de IA
El marco central de este artículo es la Cadena de evidencia web de IA:
\\\`mermaid
flowchart LR
A[DISCOVER] --> B[ACCESS]
B --> C[PARSE]
C --> D[RETRIEVE]
D --> E[UNDERSTAND]
E --> F[VERIFY]
F --> G[SYNTHESIZE]
G --> H[CITE]
H --> I[RECOMMEND]
I --> J[ACT]
B -. failure .-> X1[Blocked / denied]
C -. failure .-> X2[JS-only / malformed]
F -. failure .-> X3[Weak or conflicting evidence]
J -. failure .-> X4[Unclear or inaccessible UI]
\\\`
Diferentes productos pueden fusionar, reordenar u omitir etapas. El marco no es una afirmación sobre los internos propietarios ocultos. Es una forma de identificar dónde un sitio web se vuelve menos útil para una máquina.
Los diez estados
| Etapa | Pregunta | Fallo típico | Respuesta de ingeniería útil |
|---|---|---|---|
| 1. Descubrir | ¿Puede el sistema encontrar la URL? | Página huérfana, enlaces internos débiles, ruta de rastreo bloqueada | Enlaces internos, sitemap, arquitectura de URL limpia |
| 2. Acceder | ¿Puede recuperar el recurso? | 403, 429, bloqueo CDN/WAF, muro de autenticación | Revisar la política de acceso, códigos de estado y manejo de bots |
| 3. Analizar | ¿Puede extraerse contenido útil? | Contenido solo en JavaScript, HTML mal formado, UI ruidosa | Renderizar contenido importante en servidor, HTML semántico |
| 4. Recuperar | ¿Puede seleccionarse la página/pasaje relevante? | Redacción ambigua, contenido fragmentado, poca claridad informativa | Encabezados claros, secciones con respuesta primero, enlaces descriptivos |
| 5. Comprender | ¿Puede el sistema identificar el significado y las entidades? | Nombres contradictorios, páginas duplicadas, relaciones poco claras | Entidades consistentes, URLs canónicas, datos estructurados |
| 6. Verificar | ¿Hay suficiente evidencia para confiar en la afirmación? | Números sin respaldo, fuentes débiles, datos desactualizados | Evidencia de primera parte, fuentes independientes cuando corresponda |
| 7. Sintetizar | ¿Puede utilizarse la evidencia sin perder contexto? | Afirmaciones demasiado generales, calificadores faltantes | Definiciones precisas, alcance, fechas y limitaciones |
| 8. Citar | ¿Es la página útil como fuente? | Texto de marketing genérico, sin evidencia concreta | Haga las afirmaciones específicas, atribuibles e inspeccionables |
| 9. Recomendar | ¿Es la entidad adecuada para la decisión del usuario? | Ajuste débil a pesar de la visibilidad | Explique casos de uso, compensaciones, limitaciones |
| 10. Actuar | ¿Puede un agente completar la tarea requerida? | Controles sin etiquetar, estado oculto, flujos frágiles | Controles nativos, nombres/estados accesibles, flujos de trabajo deterministas |
Encontrado no es Recuperado. Recuperado no es Citado. Citado no es Accionable.
Esta distinción es la idea práctica más importante de todo el marco.
Imagine una página de producto:
\\\`text
FOUND ✓
FETCHED ✓
PARSED ✓
RETRIEVED ✓
UNDERSTOOD ✓
VERIFIED ?
CITED ✗
RECOMMENDED ✗
ACTIONABLE ✗
\\\`
No sucedió nada contradictorio.
El sistema puede haber encontrado y leído la página, pero otra fuente puede haber sido mejor evidencia para la pregunta específica del usuario. La página también puede haber sido perfectamente informativa mientras tenía una interfaz deficiente para la automatización.
Por eso la pregunta:
"¿Es mi sitio visible en IA?"
está incompleta.
La pregunta de diagnóstico más fuerte es:
"¿En qué etapa de la cadena de evidencia mi sitio deja de ser útil?"
Esa pregunta conduce directamente al trabajo de ingeniería.
3. Descubrimiento y acceso: ¿puede la máquina llegar a la página?
La parte glamurosa de la GEO generalmente comienza con el contenido. El fallo no glamuroso a menudo es anterior: el sistema nunca obtiene acceso útil a la página.
La orientación actual de Google para AI Overviews y AI Mode es intencionalmente conservadora: los fundamentos de SEO existentes siguen aplicando, y Google afirma que no hay requisitos técnicos adicionales específicamente para la elegibilidad en esas funciones de IA. Una página necesita estar indexada y ser elegible para aparecer en la Búsqueda ordinaria con un fragmento. Consulta Google Search Central: AI features and your website.
Eso no significa que el SEO técnico sea aburrido. Significa que los fundamentos están haciendo más trabajo de lo que la industria de la GEO a menudo admite.
La pila de acceso
Para una página importante, verifique estas capas en orden:
\\\`text
URL
↓
DNS / TLS
↓
HTTP response
↓
Robots policy
↓
Authentication / WAF / CDN policy
↓
HTML / renderability
↓
Indexability
↓
Retrievability
\\\`
Un fallo cerca de la cima puede hacer que todo lo que está debajo sea irrelevante.
El estado HTTP es información
Un rastreador o agente necesita semántica predecible.
- \200\ debe significar que el recurso solicitado está disponible.
- \301\ / \308\ pueden expresar la consolidación permanente de URLs.
- \302\ / \307\ son redireccionamientos temporales.
- \401\ y \403\ comunican restricciones de acceso.
- \404\ y \410\ comunican recursos faltantes.
- \429\ comunica limitación de tasa.
- \5xx\ comunica un fallo del lado del servidor.
Consulta RFC 9110: HTTP Semantics y MDN: HTTP status codes.
robots.txt es un control de rastreo, no un interruptor universal de visibilidad
El Protocolo de Exclusión de Robots está documentado en RFC 9309. Google explica que robots.txt controla el rastreo, pero una URL bloqueada aún puede ser conocida por el motor de búsqueda a través de otras señales. Si necesita que una página sea excluida del índice de Google, \noindex\ es un mecanismo diferente — y el rastreador debe poder recuperar la página para ver esa directiva.
Consulta:
- Google: Introduction to robots.txt
- Google: Block indexing with noindex
- RFC 9309
Regla práctica
No escriba:
"Agregue robots.txt y la IA comprenderá su sitio."
Escriba:
"Use robots.txt para expresar preferencias de rastreo para rastreadores compatibles, luego verifique el comportamiento de cada proveedor que realmente le interese."
Esa afirmación es mucho más difícil de desmentir.
La trampa del CDN / WAF
Uno de los peores modos de fallo es permitir el rastreo en teoría pero bloquearlo en la práctica.
Las causas comunes incluyen:
- una regla de WAF activada por cadenas de agente de usuario;
- protección contra bots que devuelve desafíos en lugar de HTML;
- limitación de tasa en el borde de la red;
- restricciones de país/dirección IP;
- middleware de autenticación aplicado a páginas públicas;
- comportamiento inconsistente entre rutas HTML y API;
- reglas de seguridad excesivamente agresivas que tratan todo tráfico no del navegador como hostil.
El enfoque de ingeniería seguro no es "incluir en lista blanca cada bot." Consiste en comprender la guía de verificación publicada por el proveedor, usar excepciones de mínimo privilegio cuando corresponda y monitorear registros.
Google documenta métodos de verificación de rastreadores y publica rangos de IP. OpenAI, Anthropic y Perplexity también documentan sus rastreadores web y controles de acceso. Comience desde su documentación principal en lugar de desde una lista de terceros de supuestos nombres de bots de IA.
El acceso de búsqueda y el acceso de agente no son el mismo problema
La documentación actual de Google sobre búsqueda generativa de IA afirma que los requisitos técnicos normales de Search siguen siendo la base para AI Overviews y AI Mode. Mientras tanto, el toolkit de compatibilidad con agentes de Chrome de 2026 se enfoca en el problema separado de agentes utilizando la web después de que la hayan encontrado.
Eso nos da dos trabajos muy diferentes:
\\\`text
SEARCH DISCOVERY
Can the system find and retrieve the page?
AGENT INTERACTION
Can the system understand and operate the page?
\\\`
Un buen sitio web necesita ambos solo cuando su flujo de trabajo de negocio lo requiere.
4. Recuperación y claridad de entidad: ¿puede la máquina seleccionar la información correcta?
Una vez que un sistema puede acceder a una página, el siguiente problema no es "¿Es bueno el texto?"
Es:
¿Puede el sistema seleccionar de forma confiable la pieza de información correcta para la consulta?
Aquí es donde la GEO se superpone con la recuperación de información, la arquitectura de información y la claridad de entidad.
La recuperación premia la explicitud, no el misterio
Una máquina puede trabajar con prosa. También puede trabajar con prosa altamente creativa. Pero si un hecho importante está oculto dentro de la narrativa de una página, la página le da al sistema de recuperación más trabajo que hacer.
Compare:
Débil:
Nuestra plataforma ofrece a los equipos ambiciosos una experiencia poderosa para descubrir nuevas formas de mejorar sitios web.
Fuerte:
AuditMe es una plataforma de auditoría SEO de sitios web. Revisa el SEO técnico, el contenido, el rendimiento y las señales relacionadas del sitio web y produce resultados de auditoría estructurados.
La segunda oración no es más bonita. Es más útil como evidencia.
Responda la pregunta exacta cerca de la parte superior
Para páginas informativas importantes, un patrón robusto es:
\\\`text
H1: Exact topic
1–3 sentence definition
Key facts / answer
Scope / caveats
Detailed explanation
Evidence / sources
Examples
FAQ
\\\`
Esto funciona para humanos porque reduce el costo de búsqueda. También crea unidades semánticas limpias para sistemas de recuperación y herramientas de accesibilidad.
No hay evidencia de que cada producto de IA requiera esta estructura exacta. El punto es la practicidad de ingeniería: la información clara es más fácil de inspeccionar, citar, resumir y verificar que la información vaga.
La claridad de entidad es más amplia que las palabras clave
El SEO tradicional a menudo pregunta:
¿Para qué palabra clave debe posicionarse esta página?
Un modelo de contenido orientado a IA también debería preguntar:
¿Qué entidad trata esta página, qué hace la entidad y en qué se diferencia de las entidades cercanas?
Eso incluye:
- el nombre canónico;
- alias y nombres de producto;
- categoría;
- distinciones entre producto, empresa, artículo y herramienta;
- relaciones con organizaciones padre;
- URL oficial;
- autor o organización cuando sea relevante;
- fechas e información de versión;
- capacidades y limitaciones explícitas.
Esto no es una "puntuación mágica de entidad para LLM." Es una forma de eliminar la ambigüedad semántica de la representación web de una entidad.
Canonicalización: un mecanismo real de SEO con una implicación importante para la IA
Google describe la canonicalización como el proceso de seleccionar una URL representativa entre páginas duplicadas o casi duplicadas. Google también enfatiza que la URL canónica es una sugerencia, no una regla absoluta.
Consulta Google: How to specify a canonical URL.
¿Por qué eso importa para la estrategia de contenido orientada a IA?
Porque las máquinas funcionan mejor cuando el mismo concepto se representa de manera consistente.
Considere un sitio hipotético con tres páginas:
\\\`text
/site/seo-checker
/site/seo-audit-tool
/site/ai-seo-audit
\\\`
Supongamos que las tres páginas apuntan principalmente al mismo propósito de producto subyacente.
Una arquitectura de información más limpia podría ser:
\\\`text
/site/website-seo-checker ← canonical destination
301 from:
/site/seo-checker
/site/seo-audit-tool
/site/ai-seo-audit
\\\`
Importante: este ejemplo es ilustrativo, no un experimento reportado por AuditMe. No se afirma aquí ningún resultado anterior/después de posicionamiento, tráfico o citación.
La lección de ingeniería sigue siendo sólida: cuando múltiples URLs representan esencialmente el mismo recurso o propósito, una consolidación deliberada puede reducir la duplicación y hacer la representación del propio sitio más coherente.
La conclusión específica para la IA debe expresarse con cuidado:
La canonicalización es un mecanismo web/búsqueda documentado. Cualquier afirmación de que causa directamente que un modelo de IA cite una URL es una hipótesis adicional que requiere medición.
Esa afirmación es mucho más defendible que declarar la canonicalización un "factor de posicionamiento para LLM."
Use enlaces descriptivos como información, no como decoración
Compare:
\\\`html
<a href="/docs">Read more</a>
\\\`
con:
\\\`html
<a href="/docs/robots-txt-guide">Read the complete robots.txt guide</a>
\\\`
El segundo enlace comunica el destino y el contexto directamente.
Los buenos enlaces internos mejoran la navegación para las personas y crean relaciones más claras entre documentos para los sistemas automatizados que analizan enlaces.
Consulta Google: Links and crawling.
5. Evidencia y citas: ¿puede la página respaldar la respuesta?
El objetivo de la GEO no es simplemente ser mencionado.
El objetivo más fuerte es convertirse en evidencia útil.
Eso suena como una distinción sutil hasta que mira la calidad de la web.
Una respuesta mecánica puede encontrarse con:
- la página de inicio de una empresa con afirmaciones vagas;
- una página de aterrizaje de proveedor;
- una página de documentación técnica;
- una fuente gubernamental;
- un artículo académico;
- un benchmark de primera parte;
- una prueba independiente;
- una discusión de la comunidad;
- un artículo desactualizado;
- una página que simplemente repite otra fuente.
Estos no son tipos de evidencia intercambiables.
Una jerarquía de evidencia simple
Para una afirmación de hechos, pregunte qué tipo de fuente posee naturalmente la verdad.
| Tipo de afirmación | Evidencia de partida a menudo más fuerte |
|---|---|
| Característica del producto | Documentación oficial del producto |
| Comportamiento de API | Documentación oficial de la API |
| Regulación | Fuente gubernamental / regulatoria |
| Estándar | Organismo de estándares / RFC / especificación |
| Fundación de empresa / liderazgo | Fuente oficial de la empresa + corroboración independiente cuando sea necesaria |
| Rendimiento medido | Metodología de benchmark reproducible y resultados brutos |
| Experiencia de usuario | Pruebas independientes / reseñas / investigación de usuarios |
| Dato histórico | Fuentes primarias o fuentes secundarias de alta calidad |
| Afirmación médica / científica | Investigación revisada por pares o institución de salud autorizada |
El punto no es "siempre use fuentes primarias." La evidencia independiente puede ser esencial. El punto es hacer coincidir la afirmación con la evidencia adecuada.
La presencia de citación es más débil que la relevancia de citación
Supongamos que una respuesta de IA cita su página de inicio porque el nombre de su empresa aparece allí.
Eso no es lo mismo que su guía técnica sea seleccionada para respaldar una explicación detallada de un comportamiento de API.
Para que una fuente sea genuinamente útil, la página citada debe responder a la afirmación que se le atribuye.
Eso sugiere una métrica interna más útil:
Tasa de Soporte de Citación
\\\`text
citations that actually support the associated claim
------------------------------------------------------ × 100
all citations attributed to your content
\\\`
Esta es una métrica propuesta, no un estándar de la industria.
Haga que la evidencia sea inspeccionable
Para hechos importantes, prefiera:
- fechas exactas;
- números precisos con metodología;
- versiones con nombre;
- citas directas solo cuando sean necesarias y breves;
- tablas cuando la comparación importe;
- enlaces a documentación principal;
- limitaciones explícitas;
- distinción clara entre medición e interpretación.
Evite:
"Los expertos dicen..."
cuando puede decir:
"La documentación de Google establece..."
o:
"En nuestro protocolo de prueba, medido el [fecha], el resultado fue..."
El segundo patrón le da a una máquina y a un humano un mejor punto de anclaje evidencial.
No fabrique investigación original
Esta es la regla que debería guiar toda la estrategia de contenido de AuditMe.
Si no lo ha medido, no escriba:
"Nuestros datos demuestran..."
Escriba:
"Nuestra metodología propuesta mediría..."
o:
"La documentación actual del proveedor indica..."
o:
"Una hipótesis de ingeniería útil es..."
Esto es especialmente importante en GEO porque la industria está llena de muestras diminutas presentadas como leyes universales.
6. Escribe para humanos y máquinas sin escribir como un robot
Existe una falsa elección en las discusiones sobre contenido de IA:
Escribe para humanos o escribe para máquinas.
El buen contenido técnico puede hacer ambos.
El truco no es hacer la prosa robótica. El truco es hacer que el significado sea explícito.
La fórmula anti-contenido de IA
Para cada sección importante, responda cinco preguntas:
- ¿Qué es?
- ¿Por qué importa?
- ¿Qué está documentado realmente?
- ¿Qué debería hacer?
- ¿Qué no debería asumir?
Ejemplo:
¿Qué es \llms.txt\?
Una convención propuesta basada en Markdown para dar a los agentes un mapa conciso de información y recursos importantes del sitio.
¿Por qué podría importar?
Podría reducir el esfuerzo necesario para que un agente encuentre documentación útil en un sitio.
¿Qué está documentado?
La propuesta define un formato y describe usos previstos.
¿Qué debería hacer?
Publique un \llms.txt\ pequeño y preciso si ayuda a su ecosistema de documentación y manténgalo consistente con el sitio real.
¿Qué no debería asumir?
No afirme que \llms.txt\ sea una señal de posicionamiento universal o un mecanismo de citación garantizado.
Eso es escritura clara. También es escritura amigable para máquinas.
Use tablas cuando la comparación sea el punto
Las tablas son especialmente útiles cuando una pregunta tiene dimensiones mutuamente comparables.
Search vs. AI Search vs. RAG vs. Agente de navegador
| Dimensión | Motor de búsqueda | Respuesta de IA | RAG | Agente de navegador |
|---|---|---|---|---|
| Trabajo central | Descubrir / posicionar documentos | Recuperar evidencia y responder | Recuperar pasajes de un corpus | Realizar tareas |
| ¿Necesita indexación? | Generalmente sí | A menudo depende de la arquitectura de la fuente | Depende del corpus | No necesariamente |
| ¿Necesita acceso en vivo? | El rastreo es asincrónico | A menudo en el momento de la consulta | Depende del pipeline | Generalmente sí |
| Fallo principal | No encontrado / no indexado | Fuente incorrecta / evidencia débil | Fragmento incorrecto / fallo de recuperación | Fallo de interacción |
| Propiedad importante del sitio | Rastreabilidad | Relevancia + evidencia | Documentos divisibles en fragmentos | UI semántica y determinista |
| Salida típica | Enlaces | Respuesta + fuentes | Respuesta generada | Acción / resultado de tarea |
Tabla de identidad de bots
| Proveedor | Mecanismo / rastreador | Propósito amplio | Preocupación práctica del editor |
|---|---|---|---|
| OpenAI | \OAI-SearchBot\ | Descubrimiento de búsqueda en ChatGPT | Permitir cuando desee visibilidad en la búsqueda de ChatGPT |
| OpenAI | \GPTBot\ | Posible recopilación para entrenamiento de modelos | Política separada de la visibilidad en búsqueda |
| Anthropic | \ClaudeBot\ | Recopilación para desarrollo de modelos | Separado del rastreo orientado a búsqueda |
| Anthropic | \Claude-SearchBot\ | Relevancia en búsqueda | Ruta de descubrimiento de búsqueda |
| Anthropic | \Claude-User\ | Acceso web dirigido por el usuario | Una ruta de recuperación solicitada por el usuario |
| Perplexity | \PerplexityBot\ | Descubrimiento / enlace en búsqueda | Ruta de visibilidad en búsqueda |
\Googlebot\ | Rastreo de búsqueda | Acceso principal de Google Search | |
\Google-Extended\ | Control relacionado con Gemini | No es una señal de posicionamiento de Google Search | |
| Agentes de recuperación activados por el usuario | Búsqueda o navegación solicitada por el usuario | Semántica de acceso diferente |
Siempre verifique la documentación actual del proveedor antes de cambiar las reglas de acceso de producción. Los nombres de bots, productos y políticas pueden cambiar.
El estilo de escritura que mejor viaja a través de los sistemas
Las páginas técnicas fuertes tienden a compartir estas propiedades:
- un tema obvio por página;
- definiciones directas;
- terminología consistente;
- secciones cortas con encabezados significativos;
- datos en tablas cuando sea apropiado;
- fechas y versiones explícitas;
- ejemplos concretos;
- explicaciones originales en lugar de paráfrasis interminables;
- enlaces a fuentes cerca de las afirmaciones importantes;
- una sección de referencias para investigación más profunda.
Esto no es una receta para "engañar a la IA." Es simplemente buena arquitectura de información.
7. La pila técnica: HTML, datos estructurados, robots.txt, sitemaps y \llms.txt\
La implementación técnica debería responder a una pregunta:
¿Puede una máquina recuperar de forma confiable el significado y el estado de la página sin adivinar?
El HTML semántico supera al HTML decorativo
Prefiera la semántica nativa cuando ya expresen la interacción que necesita.
Mejor:
\\\`html
<button type="submit">Run audit</button>
\\\`
Más riesgoso:
\\\`html
<div role="button" tabindex="0">Run audit</div>
\\\`
MDN recomienda explícitamente usar elementos \<button>\ nativos cuando sea posible porque proporcionan comportamiento integrado del navegador y de accesibilidad. Consulta MDN: button role.
Para un formulario:
\\\`html
<form aria-label="Run website audit">
<label for="url-input">Website URL</label>
<input
id="url-input"
name="url"
type="url"
autocomplete="url"
required
aria-describedby="url-hint"
/>
<p id="url-hint">Enter the full URL, including https://</p>
<button type="submit">Run audit</button>
</form>
\\\`
Esto es buena accesibilidad y buena ingeniería de interfaces, independientemente de la IA.
ARIA debe describir el estado real, no un estado inventado
\aria-expanded\, \aria-controls\, \aria-pressed\ y \aria-busy\ pueden comunicar estado a las tecnologías asistivas cuando se usan correctamente.
Para UI expandible:
\\\`html
<button
type="button"
aria-expanded="false"
aria-controls="advanced-options"
>
Advanced options
</button>
<section id="advanced-options" hidden>
...
</section>
\\\`
Para estado de carga:
\\\`html
<div aria-live="polite" aria-busy="true">
Analyzing your website…
</div>
\\\`
MDN explica que \aria-busy\ indica que un elemento está siendo modificado y puede ayudar a las tecnologías asistivas a evitar anunciar actualizaciones incompletas. Eso no demuestra que cada agente de navegador literalmente "espere \aria-busy=false\". La afirmación segura es más reducida: el estado explícito hace la interfaz más observable y determinista. Consulta MDN: aria-busy.
JSON-LD: contexto útil, no un interruptor mágico de IA
Google usa datos estructurados para entender el contenido de las páginas y admitir funciones de Search compatibles. Schema.org define el vocabulario.
Ejemplo:
\\\`html
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "SoftwareApplication",
"name": "Example Audit Tool",
"applicationCategory": "BusinessApplication",
"description": "A website auditing tool for technical and content analysis.",
"url": "https://example.com/tool"
}
</script>
\\\`
La regla crucial es la consistencia: los datos estructurados deben describir lo mismo que los usuarios pueden ver realmente en la página.
Consulta:
Next.js App Router: metadatos dinámicos y JSON-LD
Next.js proporciona API de metadatos integradas y un patrón documentado de JSON-LD. La documentación actual recomienda renderizar JSON-LD en \layout.js\ o \page.js\, y recomienda sanear los payloads antes de inyectarlos en el documento.
Metadatos dinámicos
\\\`tsx
import type { Metadata } from 'next'
export async function generateMetadata(): Promise<Metadata> {
const title = 'Website SEO Audit'
return {
title,
description:
'Audit technical SEO, content and website quality with a structured report.',
}
}
export default function Page() {
return <main>...</main>
}
\\\`
Consulta Next.js: generateMetadata.
JSON-LD dinámico
\\\`tsx
export default async function Page() {
const product = await getProduct()
const jsonLd = {
'@context': 'https://schema.org',
'@type': 'SoftwareApplication',
name: product.name,
description: product.description,
url: product.url,
}
const jsonLdString = JSON.stringify(jsonLd).replace(/</g, '\\u003c')
return (
<main>
<script
type="application/ld+json"
dangerouslySetInnerHTML={{ __html: jsonLdString }}
/>
{/ page content /}
</main>
)
}
\\\`
Consulta Next.js: JSON-LD.
Los sitemaps siguen importando
Los sitemaps son una forma sencilla de exponer URLs canónicas que desea que se rastreen. No garantizan la indexación, pero son infraestructura de descubrimiento útil.
Consulta Google: Build and submit a sitemap y sitemaps.org.
\llms.txt\: propuesta útil, no un protocolo universal
La propuesta \llms.txt\ usa Markdown para proporcionar un índice conciso, legible por humanos y máquinas, de recursos importantes. La propuesta ha evolucionado y ahora se mantiene como una convención de la comunidad en lugar de un estándar web universal.
Consulta llms.txt v2 y el formato principal.
Una implementación razonable podría verse así:
\\\`md
Example Documentation
Official documentation for Example API and SDKs.
Documentation
- Getting started: First steps
- Authentication: API authentication
- API reference: Complete endpoint reference
Optional
- Changelog: Product and API changes
\\\`
No use \llms.txt\ para duplicar todo el sitio. Su valor está en la curación y la claridad.
Construya una jerarquía de fuente de verdad
Para un producto u organización importante, cree una fuente canónica para cada clase de afirmación principal:
\\\`text
Product identity ───────→ canonical product page
API behavior ───────────→ official documentation
Pricing ────────────────→ current pricing page
Company facts ──────────→ organization/about page
Research findings ──────→ benchmark/report page
Change history ─────────→ changelog
\\\`
Esto evita que el mismo hecho se escriba de seis maneras diferentes en seis páginas.
8. La web agentizada: ¿puede una IA realmente usar tu sitio web?
La visibilidad en búsqueda es solo la mitad del problema emergente máquina-web.
La otra mitad es la interacción.
El toolkit de compatibilidad con agentes de Chrome de 2026 describe una transición importante: los agentes primero tuvieron que buscar en la web; cada vez más también necesitan usar la web. Las herramientas ahora incluyen auditorías de navegación agentizada y flujos de trabajo de Chrome DevTools para probar cómo los agentes interactúan con las páginas.
Consulta Chrome: A developer toolkit to make your website agent-ready.
La guía actual de editores de OpenAI hace un punto de ingeniería similar para su experiencia de agente: la accesibilidad ayuda al agente a comprender la estructura de la página y los elementos interactivos, incluyendo roles, etiquetas y estados. Consulta OpenAI: Publishers and Developers FAQ.
Una página puede ser legible pero no operable
Considere este flujo:
\\\`text
Agent finds pricing page ✓
Agent reads pricing ✓
Agent compares plans ✓
Agent clicks "Start trial" ✓
Agent sees form ✓
Agent understands fields ✗
Agent cannot recover validation ✗
Task completed ✗
\\\`
El SEO tradicional rara vez capturaría este fallo.
Una prueba agentizada debería.
Diseñe para estado explícito
Una buena interfaz operable por máquinas expone:
- un nombre accesible para el control;
- el rol del control;
- su estado actual;
- la relación con el contenido que controla;
- una acción predecible;
- retroalimentación de validación;
- un estado de éxito visible o expuesto programáticamente;
- una ruta de recuperación cuando la acción falla.
Ejemplo: un formulario de auditoría en React
\\\`tsx
'use client'
import { useState } from 'react'
export default function AuditForm() {
const [status, setStatus] = useState<'idle' | 'running' | 'completed' | 'error'>('idle')
const [message, setMessage] = useState('')
async function runAudit(event: React.FormEvent<HTMLFormElement>) {
event.preventDefault()
setStatus('running')
setMessage('')
try {
// Perform the actual request here.
await runWebsiteAudit()
setStatus('completed')
setMessage('Audit completed successfully.')
} catch {
setStatus('error')
setMessage('The audit failed. Check the URL and try again.')
}
}
const busy = status === 'running'
return (
<form aria-label="Run website audit" onSubmit={runAudit}>
<label htmlFor="url-input">Website URL</label>
<input
id="url-input"
name="url"
type="url"
required
autoComplete="url"
aria-describedby="url-hint"
/>
<p id="url-hint">Use a complete HTTPS URL.</p>
<button type="submit" disabled={busy} aria-busy={busy}>
{busy ? 'Analyzing…' : 'Start audit'}
</button>
<p aria-live="polite" aria-busy={busy}>
{message}
</p>
</form>
)
}
\\\`
El punto importante no es React, Next.js o una biblioteca de estado en particular. Podría implementarse con estado de React, Zustand, Redux, acciones del servidor u otro enfoque.
La propiedad面向 agente es el comportamiento explícito: el botón es un botón, el campo tiene una etiqueta, el estado de ejecución es observable, y los estados de éxito/error se comunican.
No hay base para afirmar que este código exacto garantiza el éxito en cada agente de IA. Simplemente sigue los principios establecidos de accesibilidad web e interacción que hacen que la automatización dependa menos de la adivinanza visual.
WebMCP y herramientas explícitas de agentes
La web también se está moviendo hacia interfaces mecánicas explícitas. La documentación actual de herramientas de sitio de OpenAI describe WebMCP como un estándar web propuesto que permite a los sitios exponer herramientas directamente a los agentes.
Eso sugiere una progresión útil:
\\\`text
Screen scraping
↓
Semantic HTML
↓
Predictable interaction
↓
Machine-readable state
↓
Explicit site tools
\\\`
El punto final de esa evolución puede no ser "hacer que el agente sea mejor para hacer clic." Puede ser hacer que el sitio web dependa menos de hacer clic en general.
Lista de verificación de UX para agentes
Antes de declarar una página lista para agentes, pruebe:
| Prueba | Condición de aprobación |
|---|---|
| Navegación | Las acciones principales son descubribles sin pistas solo visuales |
| Etiquetas | Los controles de formulario tienen nombres accesibles claros |
| Botones | Se usan controles nativos cuando sea posible |
| Estado | El estado de carga/éxito/error es explícito |
| Validación | Los errores explican exactamente qué necesita corregirse |
| Recuperación | Las acciones fallidas pueden reintentarse de forma segura |
| Confirmación | Las acciones de alto impacto requieren confirmación apropiada |
| Determinismo | La misma entrada produce resultados predecibles |
| Enfoque | El comportamiento de teclado y enfoque es coherente |
| Éxito | La finalización está representada claramente en el estado del DOM/UI |
9. Medición: de la visibilidad en IA a la Tasa de Finalización de Tareas del Agente
La industria ya tiene muchas formas de contar tráfico y posiciones. La web máquina emergente necesita medidas adicionales.
El peligro es inventar una puntuación gigante y pretender que es un estándar de la industria.
Un mejor enfoque es definir métricas estrechas con fórmulas explícitas.
1. Tasa de Mención en IA
\\\`text
queries where the target entity is mentioned
--------------------------------------------- × 100
eligible test queries
\\\`
Útil para medir la presencia de marca.
No equivalente a la calidad de la recomendación.
2. Tasa de Citación
\\\`text
queries where a target URL is cited
----------------------------------- × 100
eligible test queries
\\\`
Útil, pero simplista.
3. Tasa de Soporte de Citación
\\\`text
cited answers where the page actually supports the claim
---------------------------------------------------------- × 100
all cited answers
\\\`
Esto es más significativo porque distingue una citación real de una citación decorativa.
4. Tasa de Éxito de Recuperación
Para un sistema de recuperación controlado:
\\\`text
queries where the correct passage/page is retrieved
----------------------------------------------------- × 100
eligible queries
\\\`
Esto debería medirse contra un criterio de relevancia conocido.
5. Tasa de Consistencia de Entidad
Una métrica propuesta para auditar si los hechos importantes se representan de manera consistente a través de fuentes canónicas.
\\\`text
consistent entity facts across audited pages
--------------------------------------------- × 100
entity facts checked
\\\`
Ejemplos de hechos:
- nombre oficial;
- categoría de producto;
- URL actual;
- organización padre;
- versión;
- fecha de precios;
- capacidad/limitación.
6. Tasa de Finalización de Tareas del Agente
Esta es la métrica que vale la pena probar seriamente.
\\\`text
successfully completed eligible tasks
-------------------------------------- × 100
eligible agent task attempts
\\\`
Una tarea debe tener un inicio claro y un estado final exitoso claramente definido.
Ejemplos:
- encontrar el plan de precios que incluye la característica X;
- ejecutar una auditoría de sitio web;
- crear un informe;
- localizar documentación de API;
- enviar una solicitud de soporte;
- agregar un artículo al carrito;
- comparar dos planes.
7. Tasa de Éxito de Pasos del Agente
\\\`text
successful task transitions
---------------------------- × 100
attempted transitions
\\\`
Esto le permite diagnosticar dónde se rompe una tarea.
Ejemplo:
| Paso | Humano | Agente |
|---|---|---|
| Encontrar precios | 100% | 100% |
| Abrir comparación de planes | 99% | 91% |
| Iniciar registro | 98% | 83% |
| Completar campos obligatorios | 97% | 72% |
| Recuperarse de validación | 94% | 41% |
| Llegar a confirmación | 96% | 66% |
Estos números son solo ilustrativos. No son mediciones de AuditMe.
8. Tiempo de Finalización del Agente
Mida:
\\\`text
first task event → successful completion
\\\`
No optimice solo por velocidad bruta. Una acción rápida y incorrecta es peor que una más lenta y correcta.
9. Tasa de Recuperación del Agente
\\\`text
tasks successfully recovered after recoverable failure
-------------------------------------------------------- × 100
tasks that encountered a recoverable failure
\\\`
Esto es especialmente útil para formularios, interfaces de búsqueda y flujos de trabajo de múltiples pasos.
10. Participación de Referenciales de Máquina
Donde los datos de referenciales se pueden identificar de forma confiable:
\\\`text
visits attributed to a tracked AI/referral source
-------------------------------------------------- × 100
all tracked visits
\\\`
OpenAI documenta actualmente \utm_source=chatgpt.com\ en las referencias de búsqueda de ChatGPT, lo que hace práctica una ruta de medición a nivel de proveedor. Las analíticas específicas del proveedor deben documentarse en lugar de inferirse.
Un Esquema de Telemetría de Agentes
Un patrón de implementación útil es registrar la semántica de la tarea, no solo los clics.
Estructura de eventos sugerida
\\\`ts
type AgentEvent = {
event:
| 'task_started'
| 'step_viewed'
| 'action_started'
| 'validation_failed'
| 'action_succeeded'
| 'task_completed'
| 'task_abandoned'
taskId: string
stepId?: string
route: string
timestamp: string
outcome?: 'success' | 'failure' | 'cancelled'
errorCode?: string
durationMs?: number
}
\\\`
Envíe estos eventos desde el límite del flujo de trabajo, no desde movimientos arbitrarios de UI.
Ejemplo
\\\`ts
function track(event: AgentEvent) {
navigator.sendBeacon(
'/api/telemetry',
JSON.stringify(event)
)
}
track({
event: 'task_started',
taskId: 'audit-2026-09',
route: '/website-seo-checker',
timestamp: new Date().toISOString(),
})
\\\`
La distinción clave es:
La telemetría debería decirle si la tarea de negocio tuvo éxito, no simplemente si alguien hizo clic en un píxel.
¿Cómo sabe que un agente realizó la tarea?
Esto requiere precaución.
Un sitio web no debería asumir que una solicitud es humana o automatizada basándose solo en una cadena de agente de usuario. Los agentes de navegador pueden renderizar páginas usando pilas de navegador ordinarias, y los controles de privacidad/seguridad pueden cambiar la firma de red observable.
Mejores opciones incluyen:
- llamadas explícitas de herramientas de agente cuando la integración las soporte;
- IDs de tarea del lado del servidor;
- eventos de aplicación autenticados;
- callbacks firmados cuando corresponda;
- IDs de traza/contexto propagados a través de un flujo de trabajo;
- cabeceras o metadatos específicos del proveedor cuando estén documentados oficialmente.
El mecanismo exacto depende de la arquitectura del producto.
La métrica en sí sigue siendo útil incluso cuando la clasificación de actores es imperfecta: realice el seguimiento de la tarea; luego clasifique por separado el canal de ejecución con evidencia.
10. El playbook de AuditMe: benchmark, corrige el cuello de botella, publica la evidencia
Las secciones anteriores explican el sistema. Esta sección final lo convierte en un modelo operativo práctico.
Paso 1: Audita la cadena de evidencia, no solo la página de inicio
Cree una matriz para sus URLs más importantes:
| URL | Descubrir | Acceder | Analizar | Recuperar | Comprender | Verificar | Citar | Actuar |
|---|---|---|---|---|---|---|---|---|
| Página de producto | ✓ | ✓ | ✓ | ? | ? | ? | ? | ✓ |
| Documentación de API | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | N/A |
| Precios | ✓ | ✓ | ✓ | ✓ | ✓ | ? | ? | ? |
| Registro | ✓ | ✓ | ✓ | N/A | ✓ | N/A | N/A | ? |
Use \✓\, \?\, \✗\ y una nota.
Esto es más accionable que una sola "puntuación de preparación para IA."
Paso 2: Corrige el fallo significativo más temprano
Si la página está bloqueada en Acceso, no dedique tres días a reescribir el contenido.
Si la página es legible pero ambigua, no comience agregando más schema.
Si la página es frecuentemente citada pero falla en tareas de agente, más contenido probablemente no es el cuello de botella inmediato.
Un buen orden es:
\\\`text
ACCESS
↓
PARSE
↓
RETRIEVE
↓
UNDERSTAND
↓
VERIFY
↓
CITE
↓
ACT
\\\`
Corrija primero la interrupción significativa más temprana.
Paso 3: Crea fuentes canónicas para hechos críticos
Para cada afirmación crítica del negocio, decida dónde vive la verdad.
\\\`text
One product → one canonical product description
One API behavior → one official endpoint/reference page
One pricing model → one current pricing source
One research result → one dated benchmark/report
\\\`
Otras páginas pueden resumirlo, pero deberían enlazar de vuelta a la fuente de verdad.
Paso 4: Haz que la página sea fácil de extraer
Una buena página de referencia generalmente incluye:
- un título preciso;
- definición de una oración;
- TL;DR;
- tabla de comparación cuando corresponda;
- ejemplos concretos;
- enlaces a fuentes;
- fechas y versiones;
- limitaciones;
- FAQ para preguntas genuinamente recurrentes;
- encabezados y anclajes estables.
Haga esto primero para las personas. Las máquinas se benefician porque la arquitectura de información es explícita.
Paso 5: Haz que la interfaz sea semánticamente honesta
Use:
- \<button>\ para botones;
- \<a>\ para navegación;
- \<label>\ para etiquetas de formulario;
- \<form>\ para formularios;
- encabezados en una jerarquía lógica;
- estados \aria-*\ solo cuando describen el estado real;
- mensajes de error visibles y programáticos;
- estados de éxito/falla predecibles.
Esto es ingeniería de accesibilidad, no un truco de IA.
Paso 6: Trata \llms.txt\ como infraestructura de documentación opcional
Créelo cuando ayude a los agentes y consumidores de documentación a encontrar sus recursos más importantes.
No dependa de él.
No lo prometa.
No lo convierta en un segundo sitemap lleno de cada URL del sitio.
Paso 7: Define tu benchmark antes de recolectar datos
Aquí es donde entra el Benchmark de Inteligencia Web de IA de AuditMe v1.
Estado: metodología propuesta — aún no ejecutada
AuditMe no afirma actualmente haber completado el conjunto de datos entre múltiples modelos descrito en este artículo.
El propósito de publicar primero la metodología es hacer que las mediciones futuras sean reproducibles en lugar de inventar conclusiones primero y buscar una metodología después.
Campos propuestos del conjunto de datos
\\\`text
benchmark_version
run_id
run_timestamp
query_id
query_text
query_intent
engine
model
retrieval_mode
source_url
source_domain
source_type
source_position
citation_present
citation_relevance
claim_supported
entity_match
content_date
freshness_bucket
structured_data_present
first_party_source
external_corroboration
access_status
parse_status
retrieval_status
agent_task_id
agent_step
agent_step_success
task_success
duration_ms
notes
\\\`
Dimensiones de evaluación propuestas
| Dimensión | Pregunta central |
|---|---|
| Descubrimiento | ¿La fuente era localizable? |
| Acceso | ¿Puede el sistema recuperarla? |
| Recuperación | ¿Se seleccionó la página/pasaje relevante? |
| Comprensión | ¿Se interpretó correctamente la entidad/afirmación? |
| Verificación | ¿La fuente respaldó la afirmación? |
| Citación | ¿Se expuso la fuente y era relevante? |
| Recomendación | ¿La recomendación era una buena opción? |
| Acción | ¿Puede un agente completar la tarea? |
Clases de consultas propuestas
Un benchmark futuro no debería usar solo términos genéricos.
Incluya:
\\\`text
definition queries
comparison queries
best-of queries
problem-solving queries
commercial-intent queries
technical queries
entity disambiguation queries
freshness-sensitive queries
source-verification queries
agent-task queries
\\\`
¿Por qué publicar la metodología antes que los resultados?
Porque previene un error de investigación común:
decidir qué debería demostrar el estudio antes de decidir cómo debería ejecutarse el estudio.
Una metodología pública permite que otros equipos critiquen el diseño antes de que los resultados adquieran autoridad.
Paso 8: Publica el conjunto de datos abiertamente cuando exista
El paquete ideal es:
\\\`text
/auditme-ai-web-benchmark-v1
├── README.md
├── LICENSE
├── methodology.md
├── schema.json
├── prompts/
├── raw/
├── normalized/
├── evaluations/
├── analysis/
└── examples/
\\\`
Los objetivos de distribución potenciales incluyen GitHub y Hugging Face Datasets, con versionado estable.
No publique credenciales, datos de usuarios privados o material restringido por proveedores. Publique solo lo que permitan el método de recolección y las licencias de las fuentes.
Paso 9: Convierte la investigación original en una referencia viva
Cuando el benchmark eventualmente exista, publique:
\\\`text
Benchmark v1.0
↓
Dataset
↓
Methodology
↓
Results
↓
Limitations
↓
Replication guide
↓
Benchmark v1.1 / v2
\\\`
Una "guía definitiva" estática es útil.
Un activo de investigación vivo es más defendible.
Paso 10: Mide el cuello de botella y repite
El bucle práctico es:
\\\`text
OBSERVE
↓
DIAGNOSE
↓
PRIORITIZE
↓
FIX
↓
VERIFY
↓
PUBLISH THE EVIDENCE
↓
REPEAT
\\\`
Ese es el sistema operativo para sitios web listos para IA.
La lista de verificación web de IA de 100 puntos
Use esto como una lista de verificación de implementación, no como una puntuación de posicionamiento universal.
A. Descubrimiento — 10 puntos
- Las URLs importantes están enlazadas internamente
- Ninguna página crítica está huérfana
- El sitemap XML existe y está actualizado
- Las URLs canónicas son deliberadas
- Las páginas importantes retornan URLs estables
- Las cadenas de redireccionamiento están minimizadas
- No hay \noindex\ accidental en páginas críticas
- El contenido público no está oculto tras autenticación accidental
- Las URLs dirigidas a búsqueda son comprensibles
- Los cambios de URL tienen un plan de migración
B. Acceso — 10 puntos
- Las páginas críticas retornan códigos HTTP correctos
- El CDN/WAF no bloquea accidentalmente rastreadores legítimos
- La limitación de tasa está monitoreada
- HTTPS funciona de manera consistente
- La política de bots está documentada internamente
- Los requisitos de rastreadores específicos del proveedor están revisados
- Los registros del servidor pueden diagnosticar solicitudes fallidas
- Las páginas de error no se hacen pasar por HTML exitoso
- La autenticación se requiere solo donde sea apropiado
- El contenido público puede recuperarse sin interacción innecesaria
C. Análisis — 10 puntos
- El contenido principal existe en HTML utilizable
- El texto importante no está solo dentro de activos canvas/imagen
- Los encabezados son semánticos
- Las listas usan semántica de lista
- Las tablas son tablas reales cuando se presentan datos tabulares
- Los formularios usan controles de formulario reales
- Los enlaces usan anclas
- Las imágenes tienen alternativas significativas donde se necesiten
- El contenido dinámico tiene un estado renderizado coherente
- El código fuente de la página y el contenido renderizado no se contradicen
D. Recuperación — 10 puntos
- El H1 declara el tema exacto
- Las respuestas importantes aparecen temprano
- Los encabezados describen la pregunta que se responde
- Los párrafos son lo suficientemente autónomos como para citar
- Los enlaces describen sus destinos
- Los conceptos clave usan terminología consistente
- Las tablas se usan para comparaciones reales
- Las preguntas de FAQ son preguntas reales de usuarios
- Las definiciones importantes son explícitas
- Ningún hecho importante depende de un contexto vago circundante
E. Claridad de entidad — 10 puntos
- El nombre canónico es consistente
- El tipo de producto/empresa/entidad es explícito
- La URL oficial es clara
- Las relaciones con la organización padre son claras
- Los alias son intencionales
- Las fechas y versiones son explícitas
- Las páginas duplicadas están revisadas
- Los datos estructurados coinciden con el contenido visible
- Las diferentes páginas no contradicen hechos centrales
- Existe una fuente de verdad obvia para las afirmaciones importantes
F. Evidencia — 10 puntos
- Las afirmaciones de hechos principales tienen una fuente apropiada
- Las afirmaciones de primera parte se identifican como tales
- Se usa evidencia independiente cuando es útil
- Los números incluyen contexto o metodología
- Las afirmaciones sensibles al tiempo incluyen fechas
- Las afirmaciones técnicas sensibles a la versión incluyen versiones
- Las limitaciones están declaradas
- Las afirmaciones experimentales se etiquetan como experimentales
- Las hipótesis no están escritas como hechos
- Las fuentes permanecen accesibles y relevantes
G. Capacidad de citación — 10 puntos
- Las páginas contienen hechos concretos, no solo esloganes
- Las definiciones son concisas
- Las tablas resumen relaciones importantes
- Las afirmaciones importantes son atribuibles
- Las fuentes son fáciles de inspeccionar
- El alcance de la página es claro
- Existe contexto de autor/organización cuando sea relevante
- La fecha de actualización es visible donde sea útil
- La página proporciona algo que vale la pena citar
- La página no sobreexagera lo que la evidencia demuestra
H. Interacción de agente — 10 puntos
- Se usan botones nativos cuando sea posible
- Los campos de formulario tienen etiquetas
- Los controles tienen nombres accesibles
- El estado de expandir/contraer es explícito
- El estado de carga es observable
- Los errores de validación son explícitos
- El estado de éxito es explícito
- Existen rutas de reintento/recuperación
- Las acciones de alto impacto tienen confirmación apropiada
- Las tareas principales pueden completarse de forma predecible
I. Medición — 10 puntos
- Las tareas importantes tienen eventos de inicio medibles
- Las tareas importantes tienen eventos de éxito medibles
- Los errores usan códigos estables donde sea útil
- Se capturan las duraciones
- El canal del agente se clasifica cuidadosamente
- Las referencias de IA se pueden analizar donde la datos del proveedor lo permiten
- Las auditorías de citación usan un criterio consistente
- Las pruebas de recuperación usan consultas y versiones fijas
- Los benchmarks registran fechas
- Los resultados distinguen observación de interpretación
J. Gobernanza — 10 puntos
- La documentación tiene un responsable
- Los hechos críticos tienen fuentes canónicas
- Los cambios de contenido están versionados cuando sea necesario
- Los cambios de política del proveedor están monitoreados
- Las reglas de seguridad se revisan antes de excepciones de bots
- Los datos personales/privados se excluyen de benchmarks públicos
- Los datos de investigación tienen una política de licencia/uso
- La metodología del benchmark es pública
- Las limitaciones conocidas están documentadas
- La puntuación se trata como un diagnóstico, no como un hecho del motor de búsqueda
Qué no hacer en 2026
No construyas un "stack de trucos de GEO"
No existe evidencia defendible de que una combinación mágica de \llms.txt\, marcado FAQ, conteo exacto de palabras o fórmula de párrafos fuerce a todos los sistemas de IA a citar un sitio.
No confundas la búsqueda de IA de Google con todos los demás sistemas de IA
Los AI Overviews y AI Mode de Google operan dentro del ecosistema de búsqueda de Google. Otros proveedores tienen diferentes rastreadores, métodos de recuperación, productos y políticas.
No llames a cada rastreador de IA un "bot de entrenamiento"
Los propios proveedores distinguen el rastreo orientado a búsqueda de la recopilación para desarrollo de modelos y del acceso activado por el usuario.
No afirme que una fuente fue utilizada solo porque fue citada
La citación es evidencia de presentación de fuente, no una ventana transparente a cada paso interno del razonamiento de un modelo.
No publique números de benchmark que no haya medido
Esto debería ser innegociable para una marca de investigación seria.
No construyas una interfaz inaccesible y luego culpes al agente
Un formulario confuso es un formulario confuso. Corrija la interfaz.
Cómo se ve un sitio web genuinamente listo para IA
Un sitio web fuerte y listo para IA es sorprendentemente normal.
Tiene:
\\\`text
Fast, stable pages
+
Clear information architecture
+
Accessible semantic HTML
+
Canonical sources of truth
+
Useful structured data
+
Strong internal linking
+
Evidence-backed content
+
Transparent dates / versions
+
Predictable interactions
+
Measured workflows
\\\`
Note lo que falta:
No existe una etiqueta mágica de IA.
Ese es el punto.
El cambio más profundo: los sitios web se están convirtiendo en interfaces de conocimiento
El cambio más importante no es que ChatGPT o Gemini puedan resumir páginas.
El cambio más profundo es que el software puede cada vez más:
- encontrar información;
- recuperar evidencia;
- comparar alternativas;
- navegar interfaces;
- invocar herramientas;
- completar flujos de trabajo.
Eso significa que un sitio web ahora tiene al menos tres audiencias:
Personas que lo leen.
Máquinas que lo recuperan.
Agentes que pueden operarlo.
Una página que sirve bien a los tres no necesita una "versión de IA" separada de la web.
Necesita información clara e interfaces explícitas.
Una prueba final práctica
Tome una página crítica y haga estas diez preguntas:
- ¿Puede un rastreador descubrirla?
- ¿Pueden los sistemas previstos recuperarla?
- ¿Puede extraerse contenido útil sin adivinar?
- ¿Puede recuperarse la respuesta exacta?
- ¿Es la entidad inequívoca?
- ¿Pueden verificarse las afirmaciones importantes?
- ¿Otro ingeniero citaría esta página como evidencia?
- ¿Puede un usuario entenderla sin leer todo?
- ¿Puede un agente operar la interfaz relevante?
- ¿Puede medir si el trabajo realmente tuvo éxito?
Si la respuesta al número 1 es no, comience ahí.
Si los números 1–8 son sí pero el número 9 es no, tiene un problema de UX para agentes.
Si 1–9 son sí pero 10 es no, tiene un problema de medición.
Eso es mucho más útil que preguntar si su sitio web está "optimizado para IA."
Conclusión final
La web no está siendo reemplazada por un gigantesco motor de búsqueda de IA.
Se está convirtiendo en un entorno de lectura mecánica por capas donde diferentes sistemas descubren, recuperan, interpretan, verifican, citan, recomiendan y a veces actúan sobre los mismos documentos subyacentes.
Eso cambia la pregunta de optimización.
La pregunta anterior era:
¿Cómo posicione esta página?
La pregunta más reciente es:
¿Cómo hago que esta página sea útil para un sistema de recuperación?
Y la pregunta emergente es:
¿Cómo hago que este sitio web sea útil para una máquina que debe completar una tarea?
La respuesta más fuerte no es un conjunto de trucos de GEO.
Es una disciplina de ingeniería:
Haga que la información correcta sea fácil de descubrir, fácil de acceder, fácil de analizar, fácil de recuperar, difícil de malinterpretar, fácil de verificar, valiosa para citar y segura de usar para actuar.
Esa es la base de la web legible por máquinas.
Y es un objetivo mucho más duradero que optimizar para un solo modelo, rastreador o producto.
Sobre las herramientas prácticas
Para una línea base técnica a nivel de sitio web, el AuditMe Website SEO Checker puede usarse como un punto de partida práctico para revisar las señales principales de SEO y del sitio web.
Para una vista general rápida orientada a puntuación, el AuditMe SEO Score Checker proporciona otro punto de partida antes de una investigación más profunda.
El blog de AuditMe más amplio contiene la investigación de SEO, GEO y búsqueda de IA que rodea este marco.
11. Referencias, documentación y lecturas adicionales
Los enlaces a continuación están intencionalmente orientados hacia la documentación principal, estándares y recursos de ingeniería de primera parte. Revíselos directamente antes de hacer cambios de producción porque los ecosistemas de agentes web evolucionan rápidamente.
Google Search, rastreo y búsqueda de IA
- Google Search Central — AI features and your website
- Google Search — AI in Search
- Google Search — AI Overviews
- Google Search Central — Crawling infrastructure
- Google — Common crawlers
- Google — User-triggered fetchers
- Google Search Central — Crawling and indexing overview
- Google Search Central — robots.txt introduction
- Google Search Central — Block indexing with noindex
- Google Search Central — Canonicalization
- Google Search Central — Consolidate duplicate URLs
- Google Search Central — Links and crawlable links
- Google Search Central — Build and submit a sitemap
- Google Search Central — Structured data
- Google Search Central — Search Gallery
- Google Rich Results Test
- Google Search Console
- Google URL Inspection
- Google Search Central — Search updates
- Google Search Central — Generative AI content guidance
- Google Search Central — Preferred sources
OpenAI
- OpenAI — Publishers and Developers FAQ
- OpenAI — SearchBot
- OpenAI — GPTBot
- OpenAI — Using site tools in the ChatGPT desktop app
- OpenAI — Web search in ChatGPT
Anthropic
Perplexity
Web agentizada y automatización de navegador
- Chrome for Developers — A developer toolkit to make your website agent-ready
- Chrome DevTools
- Lighthouse
- Chrome — Web Bot Auth
- WebMCP
HTML y accesibilidad
- MDN — Semantic HTML
- MDN — HTML accessibility
- MDN — ARIA
- MDN — Button role
- MDN — aria-expanded
- MDN — aria-busy
- MDN — button element
- MDN — label element
- MDN — form element
- W3C — WAI-ARIA
- W3C — WAI-ARIA Authoring Practices Guide
- W3C — ARIA in HTML
- WHATWG — HTML Standard
Next.js y datos estructurados
- Next.js — JSON-LD
- Next.js — generateMetadata
- Next.js — Metadata and OG images
- Schema.org
- Schema.org — Organization
- Schema.org — Article
- Schema.org — SoftwareApplication
- Schema.org — WebSite
HTTP, robots y estándares de sitemaps
- RFC 9309 — Robots Exclusion Protocol
- RFC 9110 — HTTP Semantics
- MDN — HTTP status codes
- MDN — HTTP overview
- Sitemaps.org
\llms.txt\
Rendimiento y experiencia de usuario
- web.dev — Core Web Vitals
- web.dev — Largest Contentful Paint
- web.dev — Interaction to Next Paint
- web.dev — Cumulative Layout Shift
- Chrome UX Report
- PageSpeed Insights
Common Crawl e investigación de web abierta
Calidad de búsqueda y alfabetización en investigación
- Google Search Quality Evaluator Guidelines
- Google Search documentation
- Google Search Central — What's new
Estado de investigación y estándar editorial
Este artículo separa intencionalmente:
- comportamiento documentado por el proveedor;
- estándares web;
- recomendaciones de ingeniería;
- métricas propuestas;
- metodología de benchmark futura;
- ejemplos ilustrativos.
No presenta un benchmark no ejecutado como investigación completada.
El Benchmark de Inteligencia Web de IA de AuditMe v1 de este artículo es una metodología propuesta. No se afirman aquí resultados de benchmarks entre múltiples modelos.
Cuando eventualmente existan los resultados, deberían publicarse con las consultas, fechas de prueba, versiones de modelo/proveedor donde sean observables, reglas de muestreo, criterio de evaluación, datos brutos o con licencia adecuada, limitaciones e instrucciones de replicación.
Ese es el estándar requerido si este trabajo va a ser útil como una referencia seria en lugar de otra ronda de folklore de GEO.
Última revisión: 13 de septiembre de 2026.
Eduard Tymchenko
SEO Expert & Founder of AuditMe
Seasoned SEO & SMM expert with 10+ years of experience. Built AuditMe to help businesses improve their search rankings through data-driven, results-oriented SEO strategies. Specializes in technical SEO, Core Web Vitals, and WordPress optimization.
Ejecuta tu auditoría SEO gratuita
Obtén un análisis SEO completo de cualquier URL en 60 segundos. Sin registro.
O abre el analizador completo con más detalles
Analiza tu sitio gratisHerramientas SEO gratuitas
Artículos relacionados
Continúa aprendiendo con estas guías y tutoriales de SEO:
The PAOVR Loop: The Real Agent Loop That Actually Finishes Jobs
Stop building agents that narrate completion. A production-grade field guide to loop engineering, JSON contracts, and reliable AI systems.
20 min read
Master Prompts in 2026: Stop Prompting Like It's 2023
Production guide to master prompts, LLM orchestration, agent loops, and prompt engineering for production — with JSON contracts, verification, RAG-aware context, and eval that survives model swaps.
25 min read
How to Measure AI Search Visibility in 2026: The Evidence-First GEO Framework
Measure AI search visibility in 2026: evidence-first GEO framework with prompt panels, first-party Google, Bing and ChatGPT data, and a 30-day improvement loop.
33 min read
The Double Life of the RAG Crawler: Building Knowledge Engines and Defending Them in 2026
Build RAG crawlers that don't rot — and defend knowledge bases from graph-guided extraction attacks like RAGCrawler. Architecture, tooling, failures, and a security playbook for 2026.
25 min read