Auditoría con IA de un sitio de 500 páginas: cuántas sesiones de chat exige

Según el modelo de este artículo, auditar un sitio web de 500 páginas mediante un chat con IA exige unas 21 sesiones y alrededor de 15 horas de su propio tiempo para una sola pasada. El coste mayor es que los 21 resultados no suman una auditoría: cada sesión empieza sin la evidencia que vieron las demás, examina cosas distintas en páginas distintas y formula sus veredictos a su manera, de modo que no hay un método único que fusionar ni que repetir el mes siguiente. Las sesiones de IA son excelentes para explicar y corregir problemas; dan lo mejor de sí cuando parten de un inventario completo de hallazgos.

Tanto si audita un sitio web con ChatGPT, con Claude o con otro asistente, las cuentas que siguen son las mismas, porque se derivan de cómo funcionan las sesiones de chat y no de un producto concreto. El primer artículo de esta serie, por qué una sola sesión de IA no puede auditar un sitio web completo, explicó hasta dónde llega una sola sesión y modeló las sesiones por sitio con 25 y 100 páginas por sesión. Este suma lo que ocurre cuando se siguen abriendo sesiones nuevas: sus horas y la divergencia entre sesiones.

Un sitio de 500 páginas está en el cuartil superior, y aun así es habitual

En este modelo, el tamaño del sitio lo decide todo, así que partimos de tamaños reales. Entre 29 sitios web externos que SEOReport auditó entre mayo y octubre de 2026 y cuyo sitemap XML incluía al menos una URL, el sitemap mediano incluía unas 90 URL; una cuarta parte incluía 20 o menos, otra cuarta parte más de 440, y el décimo más grande más de 3,000.

Son sitios enviados para una auditoría de SEOReport, no una muestra aleatoria de la web. Un sitio de 500 páginas queda justo dentro de su cuartil superior: suele ser un negocio consolidado con un blog, páginas de servicios o productos y quizá varios idiomas. Un sitemap enumera las páginas que un sitio pide a los buscadores que encuentren; las URL de etiquetas, filtros y archivos pueden quedar fuera, así que el recuento del sitemap es el mínimo de lo que una auditoría debe tener en cuenta.

El modelo: páginas por sesión y, después, sesiones por sitio

Esto es un modelo, no una medición. Cada cifra se deriva de 4 supuestos explícitos, y usted puede cambiar cualquiera de ellos.

1. 25 páginas por sesión. Es la menor de las dos capacidades que usó el primer artículo de esta serie. Una revisión cuidadosa de una página lee mucho más que el texto visible: el código de estado, las cabeceras de respuesta, las etiquetas del head, los datos estructurados y la relación de la página con el sitemap y con otras páginas. En 45 sitios web externos que SEOReport auditó entre mayo y octubre de 2026, el 94% de los 506 problemas señalados estaba en algún lugar que el lector de la página nunca ve, y el sitio mediano tenía problemas señalados en 5 ubicaciones de evidencia distintas. Retener tanta evidencia por página y seguir respondiendo con cuidado sitúa a una sesión en la capacidad menor, no en la mayor. Las páginas sencillas permiten más; las plantillas pesadas, menos.
2. 1 sesión adicional para los archivos de todo el sitio. robots.txt, el sitemap XML y las redirecciones entre HTTP y HTTPS y entre el nombre de host con www y sin www.
3. 20 minutos de su tiempo por sesión. Unos 10 minutos para volver a explicar el método y entregar la lista de páginas, y 10 para guardar el resultado y fusionarlo en una lista maestra.
4. 1 minuto de su tiempo por página. Obtener o pegar la página con sus cabeceras y confirmar que la sesión la ha leído de verdad. Las herramientas de descarga de los asistentes suelen devolver la página convertida a texto, sin sus cabeceras; por eso existe este paso. Lo que ve un agente de IA cuando revisa su página muestra la diferencia.

Las fórmulas: sesiones = páginas ÷ 25, redondeado hacia arriba, más 1. Sus minutos = 20 × sesiones + páginas.

Las horas dependen menos del supuesto por sesión que el número de sesiones, porque los minutos dedicados a cada página no se reducen cuando la sesión es más grande. Con 10 páginas por sesión, el sitio de 500 páginas necesita 51 sesiones y unas 25 horas. Con 100 páginas por sesión, la capacidad generosa del primer artículo, necesita 6 sesiones y sigue rondando las 10 horas.

Las horas tampoco incluyen 3 cosas: el tiempo que el asistente dedica a trabajar, las correcciones en sí y cualquier segunda pasada para comprobar la primera.

Por qué 21 sesiones no suman una auditoría

Las horas se ven y se pueden presupuestar. La divergencia cuesta más verla, y es lo que hace poco fiable el resultado combinado.

Cada sesión empieza sin los hallazgos de las demás. La sesión 14 no sabe que la sesión 3 encontró la misma etiqueta canonical ausente en la plantilla del blog. La vuelve a señalar como si fuera nueva, o trata un problema de plantilla que afecta a 180 páginas como una nota sobre una sola página. Los archivos de proyecto y las funciones de memoria arrastran notas anteriores, lo que ayuda, pero las notas son conclusiones. No hacen que la sesión 14 aplique los criterios de la sesión 3.

Cada sesión decide qué mirar. Cuando se le pide revisar un lote de páginas, un asistente elige qué señales comprobar en cada una. Una sesión lee los datos estructurados; otra los omite porque la página parecía correcta. Al final usted sabe qué páginas se abrieron, pero no qué comprobaciones se ejecutaron en cada una.

Cada sesión formula sus veredictos de forma distinta. "Falta el canonical", "no hay enlace rel=canonical" y "etiqueta canonical ausente" son un mismo hallazgo escrito de 3 maneras. La gravedad también varía: el mismo problema es "crítico" en una sesión y "menor" en la siguiente. La cifra que decide la prioridad, cuántas páginas comparten un problema, solo existe después de normalizar cada línea a mano.

Los problemas entre páginas caen entre sesiones. De esos mismos 45 sitios web externos que SEOReport auditó entre mayo y 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 su conjunto. Dividir un sitio en lotes de 25 divide justamente esas comparaciones. Dos artículos casi duplicados revisados en las sesiones 4 y 19 nunca se cruzan, y esa es una de las formas en que las páginas duplicadas que hay detrás de Duplicada: el usuario no ha indicado ninguna versión canónica sobreviven a una revisión página por página.

El mes siguiente no se puede repetir. La misma pregunta formulada dos veces puede recibir una respuesta redactada de otro modo y, de vez en cuando, un juicio distinto. Si repite las 21 sesiones en diciembre y encuentra menos problemas, no puede saber si el sitio ha mejorado o si las sesiones han cambiado de criterio. Sin un método fijo no hay una referencia con la que comparar.

flowchart TD
    subgraph many["Muchas sesiones de chat"]
        A["Elija las 25 páginas siguientes"] --> B["Sesión nueva: vuelva a explicar el método"]
        B --> C["La sesión comprueba lo que elige, con sus propias palabras"]
        C --> D["Copie sus hallazgos en sus notas"]
        D --> E{"¿Quedan páginas?"}
        E -->|"sí"| A
        E -->|"no"| F["Fusione a mano 21 conjuntos de notas"]
        F --> G["Ningún registro que repetir el mes siguiente"]
    end
    subgraph one["Una auditoría y luego IA por hallazgo"]
        H["Una auditoría: el mismo método en cada ejecución"] --> I["Inventario de hallazgos con evidencia"]
        I --> J["Una sesión de IA por hallazgo"]
        J --> K["Auditoría posterior, mismo método"]
        K -->|"hallazgo aún abierto"| J
    end

Lo que cambia una auditoría y lo que no cambia

Una auditoría también trabaja con muestras. Un diagnóstico completo de SEOReport examina la página de inicio, las páginas que incluye su sitemap y las páginas a las que apuntan sus enlaces internos. No lee todas las páginas, y cada hallazgo extraído de una muestra indica cuántas páginas examinó, de modo que el alcance de cada resultado queda registrado.

Lo que cambia es el método. Cada diagnóstico ejecuta el mismo conjunto definido de comprobaciones de la misma manera y registra la evidencia de cada una, así que dos informes del mismo sitio se pueden comparar hallazgo por hallazgo. Las comparaciones que caen entre sesiones de chat se hacen dentro de una sola ejecución: entradas del sitemap que contradicen las páginas que enumeran, enlaces internos a páginas inexistentes, artículos casi duplicados, fechas de artículos contradictorias y páginas a las que nada enlaza. El resultado es un único inventario: hallazgos con su evidencia y las URL afectadas, un plan de corrección priorizado con pasos de verificación y exportaciones en PDF, Markdown y JSON. Qué contiene un informe SEO con puntuación recorre esa estructura.

También cambia el tamaño del trabajo de la IA. En 249 sitios web externos que SEOReport auditó entre el 23 de agosto y el 4 de octubre de 2026, el informe mediano señalaba 14 problemas distintos (hallazgos con error o con advertencia), y una cuarta parte de los sitios tenía 17 o más. Un problema puede afectar a muchas páginas, pero sigue siendo una tarea bien definida. Una lista de unas 14 tareas con la evidencia adjunta es un encargo muy distinto de 21 sesiones abiertas de descubrimiento.

Lo que la auditoría no hace es sustituir el criterio ni redactar las correcciones. Ahí es donde las sesiones de IA se ganan su sitio, que es lo que un artículo anterior sobre las comprobaciones puntuales con IA planteaba desde el otro lado.

Cómo aprovechar bien las sesiones de IA en un sitio grande

Entregue a la sesión los hallazgos, no el sitio. Empiece cada sesión con un hallazgo, su evidencia y las URL afectadas. Un agente también puede crear el informe y leer cada hallazgo por sí mismo mediante la API REST o el servidor MCP, como se describe en nuestra página para agentes de IA, de modo que su trabajo parte del diagnóstico en lugar de volver a descubrir el sitio.

Asigne una corrección por sesión. Una tarea acotada mantiene la atención de la sesión en una sola causa y facilita revisar su respuesta. Un prompt con esta forma funciona bien:

Finding: XML sitemap lists URLs that redirect.
Evidence: https://www.example.com/old-pricing -> 301 -> https://www.example.com/pricing
          https://www.example.com/team -> 301 -> https://www.example.com/about
Platform: [your CMS, sitemap generator and hosting]
Task: Explain the most likely reason the sitemap still lists these URLs on this
platform, and give the smallest change that makes it list only final URLs.
Address this finding only.

Si tiene que usar el chat para descubrir problemas, ponga antes el método por escrito. Pegue la misma lista de comprobación al inicio de cada sesión, asigne a cada sesión una lista fija de páginas y exija un único formato de salida: una tabla con URL, comprobación, valor observado y veredicto. Así la fusión se vuelve mecánica. Esto reduce la divergencia en la redacción y en la cobertura; no recupera los problemas que solo aparecen entre páginas.

Verifique con una auditoría posterior y con Google. Para todo lo que señale Search Console, corrija primero todas las URL afectadas y, después, ejecute "Probar URL publicada" en la herramienta de inspección de URLs sobre una de ellas para confirmar que Google puede obtener la página modificada. La prueba en directo no comprueba las decisiones sobre duplicados ni sobre la versión canónica, así que para esos problemas solo confirma el acceso. A continuación, haga clic en "Validar corrección" en el problema. La documentación de Google sobre el informe "Indexación de páginas" (consultada en octubre de 2026) indica que la validación suele tardar hasta unas dos semanas y, en algunos casos, mucho más. Un informe posterior, o el seguimiento semanal mediante la API que se describe en monitorización SEO continua, muestra si el hallazgo se ha resuelto con el mismo método que lo detectó.

En los sitios pequeños el panorama es más benévolo: en el modelo, un sitio de 20 páginas supone 2 sesiones y alrededor de una hora, y una pregunta sobre una sola página no necesita ninguna auditoría. El coste crece con el sitio, y también el valor de un método repetible.

Preguntas frecuentes

¿Puede un asistente con navegación web auditar todo el sitio por su cuenta?

La navegación elimina el pegado, así que el tiempo de 1 minuto por página del modelo se reduce. Pero el asistente sigue abriendo las páginas de una en una, elige cuáles abrir y a menudo recibe el texto convertido de la página en lugar de la respuesta completa con sus cabeceras. El comportamiento de las herramientas varía entre asistentes, y ninguno aporta un método fijo que funcione igual el mes siguiente.

¿Una ventana de contexto más grande elimina el problema?

Aumenta el número de páginas por sesión, lo que reduce el número de sesiones. En el modelo, 100 páginas por sesión siguen suponiendo 6 sesiones y unas 10 horas para un sitio de 500 páginas, porque procesar cada página lleva el mismo tiempo. Y la divergencia entre ejecuciones sigue intacta.

¿Son realistas 25 páginas por sesión?

Es un supuesto, elegido para una sesión que lee cabeceras, etiquetas del head y datos estructurados además del texto. Ajústelo a sus páginas y aplique la fórmula: sesiones = páginas ÷ páginas por sesión, redondeado hacia arriba, más 1. Las conclusiones sobre la divergencia no dependen de él.

¿Debo conservar las transcripciones del chat como registro de la auditoría?

Consérvelas como notas de trabajo. Una transcripción registra lo que concluyó una sesión, normalmente sin la evidencia en bruto que vio, como el código de estado y los valores de las cabeceras en ese momento. Un registro que guarda la evidencia junto a cada hallazgo permite que otra persona compruebe el veredicto más tarde y lo compare con la auditoría siguiente.