Auditoría SEO con IA: por qué una sesión no cubre todo un sitio web

Un asistente de IA puede revisar bien una página: lee el título, los encabezados y el texto que recibe y explica qué conviene cambiar. Una sola sesión de IA no puede auditar un sitio web completo, por dos razones. La mayor parte de la evidencia que necesita una auditoría SEO no está en el texto de la página que lee el asistente: está en los encabezados de respuesta, en robots.txt, en el sitemap XML, en las redirecciones y en las relaciones entre páginas. Y, a partir de un tamaño modesto, un sitio tiene más URLs de las que una sesión puede leer y comparar a la vez. La primera razón es la de más peso, y un modelo más grande no la reduce.

En 45 sitios web externos que SEOReport auditó entre mayo y octubre de 2026, el 94% de los 506 problemas detectados estaba en algún lugar que quien lee la página nunca ve. Este artículo repasa la aritmética de la cobertura, dónde está esa evidencia y cómo auditar un sitio web con IA entregando al asistente un diagnóstico de todo el sitio antes de que empiece a corregir. Amplía por qué las comprobaciones puntuales con IA no sustituyen una auditoría SEO sistemática, que comparaba los dos métodos; aquí el tema son los números.

Qué toca una sesión de chat y qué registra una auditoría del sitio

Una auditoría de un sitio web con IA en un chat suele empezar con una URL. La herramienta de lectura web del asistente solicita esa página y devuelve lo que recibió, a menudo convertido en texto legible, y la conversación razona sobre ese texto. Una auditoría sistemática empieza un nivel más arriba, en el sitio. Lee los archivos que rigen todo el host, registra la respuesta HTTP de cada URL que solicita, compara el HTML original con la página renderizada y, después, compara las páginas entre sí y con el sitemap.

El recorrido de una sola URL es un trabajo útil. También es solo uno de los muchos recorridos posibles por un sitio, y en cada paso se puede perder algo. La conversión a texto conserva las palabras que lee un visitante y puede descartar las etiquetas del head y los encabezados de respuesta. Y la siguiente sesión empieza sin las páginas que leyó esta.

¿Qué tamaño tiene el sitio que le pide auditar a un asistente?

De 45 sitios web externos que SEOReport auditó entre mayo y octubre de 2026, 15 (33%) no tenían sitemap XML ni en la dirección indicada en robots.txt ni en /sitemap.xml. Entre los 29 de esos sitios cuyo sitemap incluía al menos una URL, el sitemap de la mediana incluía unas 90 URLs; una cuarta parte incluía 20 o menos, otra cuarta parte más de 440, y el 10% más grande más de 3,000.

Son sitios web enviados para una auditoría de SEOReport, no una muestra aleatoria de la web, y tienden a ser pequeños. Aun así, la dispersión es amplia: los sitios del 10% más grande incluyen más de 150 veces tantas URLs como los del cuartil más pequeño. También importa el tercio de sitios sin sitemap en la dirección esperada. Para ellos no hay una lista de páginas donde la buscaría un asistente o un rastreador, así que las páginas tienen que descubrirse siguiendo enlaces, una solicitud tras otra.

¿Cuántas sesiones requiere una auditoría SEO con IA de todo un sitio?

La tabla siguiente es un modelo, no una medición. Divide los tamaños de sitemap anteriores entre un número supuesto de páginas que una sesión puede leer completas y seguir comparando entre sí. Las hipótesis:

• Una sesión lee cada URL del sitemap una vez, completa, y la mantiene disponible para compararla con las demás.
• Se muestran dos capacidades: 25 y 100 páginas por sesión. Ambas son ilustrativas. La capacidad real depende del asistente, de su herramienta de lectura web y del peso de cada página, y no la medimos.
• Solo se cuentan las URLs del sitemap. robots.txt, los encabezados de respuesta, los saltos de redirección y las páginas renderizadas suman trabajo, así que cada cifra es un límite inferior.

En aproximadamente la mitad de los 29 sitios con sitemap, la hipótesis generosa permite que todo el sitemap quepa en una sola sesión. Ahí es donde una revisión por chat resulta más defendible. Por encima de la mediana, el número de sesiones crece con el sitio, y la suma de sesiones no equivale a una auditoría.

Salvo que el asistente tenga una función de memoria o que usted vaya pegando notas de una sesión a otra, cada sesión nueva empieza sin las páginas que leyó la anterior. Las notas transmiten conclusiones. Una comparación posterior necesita la evidencia misma: la URL canónica exacta de la página 12, el código de estado detrás de la redirección de la página 340. Y una sesión que elige su propio método cada vez puede comprobar cosas distintas en lotes distintos, de modo que el lote 7 y el lote 8 no se miden igual.

La mayor parte de la evidencia SEO no está en la página que usted pega

El número de sesiones es el problema menor. El gráfico siguiente toma los 506 problemas detectados en 45 sitios web externos que SEOReport auditó entre mayo y octubre de 2026 y sitúa cada uno donde una persona tendría que mirar para ver su evidencia. El 94% estaba en algún lugar que quien lee la página nunca ve: encabezados de respuesta, etiquetas del head, datos estructurados, el sitemap XML, robots.txt, redirecciones o relaciones entre páginas.

En esos mismos 45 sitios (mayo–octubre de 2026), todos tenían al menos un problema detectado fuera del texto visible de la página, y en 24 de ellos (53%) todos los problemas detectados estaban fuera de él. En la mediana, cada sitio tenía problemas en 5 ubicaciones de evidencia distintas, y una cuarta parte tenía 6 o más. Aun dejando fuera por completo los encabezados de seguridad, el 91% de los problemas restantes seguía estando fuera del texto visible de la página.

Cada ubicación exige su propia forma de mirar:

• La respuesta HTTP. La documentación de Google sobre cómo bloquear la indexación (consultada en octubre de 2026) indica que noindex puede enviarse como encabezado de respuesta X-Robots-Tag, y su documentación sobre cómo especificar la URL canónica indica que rel="canonical" puede enviarse como encabezado HTTP Link. Ninguno de los dos aparece en el texto de la página.
• robots.txt. La documentación de Google sobre robots.txt (consultada en octubre de 2026) indica que el archivo debe estar en el directorio raíz y que sus reglas solo se aplican al host, protocolo y puerto que lo sirven. www.example.com y shop.example.com responden cada uno a su propio archivo, como explica nuestra guía de robots.txt y acceso de rastreo.
• HTML original frente a página renderizada. La documentación de Google sobre SEO para JavaScript (consultada en octubre de 2026) indica que Google usa el HTML renderizado para indexar una página, que el mejor lugar para la etiqueta canónica es el HTML, que JavaScript no debe cambiarla por otra URL y que, cuando Google encuentra un noindex, puede omitir el renderizado. En 34 sitios externos en los que SEOReport comparó el HTML original del servidor con la página renderizada (mayo–octubre de 2026), 7 (21%) dependían de JavaScript para algo que un buscador lee primero: el título, la meta descripción, la etiqueta canónica o el H1 solo aparecían después de ejecutarse JavaScript, o el HTML original apenas contenía texto de la página. Un asistente que lee texto convertido ve una de esas dos versiones, y la conversación rara vez dice cuál.

Algunos problemas solo existen entre páginas

De esos mismos 45 sitios externos (mayo–octubre de 2026), 32 (71%) tenían al menos un problema que no se ve en ninguna URL por separado: solo aparece al comparar el sitemap con las páginas que incluye, al comparar las páginas entre sí o al leer la biblioteca de artículos en conjunto. Sin contar la biblioteca de artículos, la cifra es de 28 de 45 (62%).

Así se ve esa evidencia en un sitio ilustrativo:

# https://www.example.com/robots.txt
User-agent: *
Disallow: /checkout/

# https://www.example.com/sitemap.xml lists
https://www.example.com/checkout/
https://www.example.com/old-services/      (answers 301)

# https://www.example.com/en/services/ declares
hreflang="es" -> https://www.example.com/es/servicios/

# https://www.example.com/es/servicios/ declares
no hreflang link back to /en/services/

Cada archivo parece correcto por sí solo. Los problemas solo aparecen al leerlos juntos:

• El sitemap contradice a las páginas. La documentación de Google sobre sitemaps (consultada en octubre de 2026) indica que un sitemap no garantiza que sus URLs se rastreen e indexen, y su documentación sobre URLs canónicas califica la inclusión en el sitemap como una señal de canonicalización débil. Incluir una URL que redirige, está bloqueada o lleva noindex envía una señal contradictoria. En 29 sitios externos cuyas páginas del sitemap SEOReport descargó (mayo–octubre de 2026), 8 (28%) tenían al menos una URL en el sitemap que redirige, está marcada como noindex o está bloqueada por robots.txt.
• robots.txt oculta un noindex. La documentación de Google indica que un rastreador bloqueado por robots.txt nunca ve el noindex de la página, y que la URL puede indexarse igualmente si otras páginas enlazan a ella. Detectarlo exige leer robots.txt y la página a la vez, como desarrolla nuestro análisis de conflictos de indexabilidad.
• Hreflang sin enlace de vuelta. La guía de Google sobre versiones localizadas (consultada en octubre de 2026) afirma: "Si dos páginas no apuntan la una a la otra, se ignorarán las etiquetas". Confirmarlo requiere ambas páginas, como muestra la guía de implementación de hreflang.
• Una etiqueta canónica que apunta a un destino defectuoso. Una etiqueta canónica que nombra una página que redirige o lleva noindex solo se detecta si también se descarga el destino.

Una sesión de chat puede detectar cualquiera de estos casos si casualmente tiene ambas mitades. Repartidas en muchas sesiones, las mitades acaban fácilmente en conversaciones distintas, y ninguna conversación ve el problema.

Cómo comprobar qué cubrió realmente una auditoría con IA de su sitio

Antes de actuar según la auditoría de un asistente, pídale cuatro cosas: la lista de URLs que descargó, las líneas de robots.txt que leyó, el código de estado y los encabezados de su página de inicio, y si comparó el HTML original con la página renderizada. Si no puede mostrarlos, considere que la auditoría no los cubrió. Después, compare su lista de URLs con su sitemap.

Usted mismo puede reunir esa evidencia con tres comandos:

curl -s https://www.example.com/robots.txt
curl -s -D - -o /dev/null https://www.example.com/ | grep -iE '^(HTTP/|location|x-robots-tag|link)'
curl -s https://www.example.com/sitemap.xml | grep -o '<loc>' | wc -l

El segundo comando hace una solicitud GET normal y solo muestra los encabezados de respuesta. Use la dirección del sitemap que indique su robots.txt si es distinta de /sitemap.xml. Si el sitemap es un índice, el último recuento es el número de sitemaps secundarios, no de páginas. Compruebe también que el asistente recibió realmente su página. De 377 sitios web externos enviados a SEOReport entre mayo y octubre de 2026, al menos 51 (13.5%) no permitieron que un rastreador automatizado evaluara la página de inicio, y al menos 34 (9%) respondieron con un desafío antibots o un CAPTCHA. La herramienta de lectura web de un asistente también es un cliente automatizado; si se topó con una página de desafío, lo que revisó fue el desafío. Nuestro artículo sobre la protección antibots que bloquea a los rastreadores trata ese caso.

Entregue al asistente una auditoría del sitio y deje que corrija después

Los asistentes destacan en el trabajo que viene después de un diagnóstico: explicar un hallazgo, escribir el cambio en la plantilla, preparar un mapa de redirecciones, reformular un título. Lo que le falta a una sesión es un punto de partida repetible y a escala de sitio. Un diagnóstico completo de SEOReport lo proporciona. Lee robots.txt y el sitemap, examina su página de inicio y una muestra de las páginas que incluye su sitemap y a las que apuntan sus enlaces internos, registra el estado HTTP de cada página que solicita y compara el HTML original de su página de inicio con la página renderizada. Informa de los hallazgos que solo existen entre páginas, como entradas del sitemap que contradicen a las páginas que incluyen, enlaces internos a páginas inexistentes y artículos casi duplicados. Cada hallazgo incluye su evidencia y nombra las URLs afectadas, y cada hallazgo basado en una muestra indica cuántas páginas examinó. Cada diagnóstico aplica las mismas comprobaciones definidas de la misma manera, así que dos informes del mismo sitio se pueden comparar hallazgo por hallazgo.

Un agente puede crear el informe, consultar su estado y leer cada hallazgo a través del servidor MCP y la API REST. Así, sus sesiones parten del diagnóstico y dedican su capacidad a las correcciones, un hallazgo cada vez. La página para agentes describe esa configuración.

Preguntas frecuentes

¿Puede ChatGPT hacer una auditoría SEO?

Cualquier asistente competente puede revisar las páginas que se le entregan o que puede descargar, y explica los problemas con claridad. Una auditoría SEO de todo un sitio también necesita robots.txt, el sitemap, los encabezados de respuesta, el HTML original y el renderizado, y comparaciones entre páginas. Trate una auditoría por chat como una revisión de las páginas que leyó, y pida esa lista.

¿Cerrarán la brecha los modelos de IA más grandes?

Más capacidad aumenta el número de páginas por sesión en el modelo anterior. No traslada la evidencia al texto de la página: los encabezados, robots.txt y los conflictos entre páginas siguen teniendo que descargarse y compararse de forma deliberada. Un método fijo importa tanto como la capacidad, porque es lo que hace que dos ejecuciones coincidan.

¿Basta una sesión de IA para un sitio pequeño?

En un sitio de unas 20 URLs, una sesión puede leer todas las páginas. Aun así necesita tener delante robots.txt, el sitemap, los encabezados de respuesta y el HTML original, así que pídalos expresamente. El tamaño es la mitad fácil del problema.

¿Debo pegar todo mi sitemap en el chat?

Un sitemap pegado le da a la sesión una lista de URLs. No le da las páginas, sus encabezados ni sus códigos de estado. El asistente sigue teniendo que solicitar cada URL, y eso nos devuelve a la aritmética de sesiones anterior.