Auditoría web con IA: cómo auditar un sitio con agentes de IA, de la evidencia a una corrección verificada

1. Qué es una auditoría web con IA

Una auditoría web revisa cómo está construido, entregado y conectado un sitio: si está protegido, si los buscadores y los sistemas de IA pueden leerlo, si las personas pueden usarlo, qué tan rápido es y qué servicios de terceros carga. Una auditoría web con IA suma un agente de IA a ese trabajo. El agente lanza las comprobaciones, lee los resultados, los explica en lenguaje claro, decide contigo qué corregir primero y redacta la solicitud de cambio para la persona o el agente de código que hará la corrección.

Con las mismas palabras se describen tres cosas bastante distintas:

Esta guía trata el tercer enfoque, porque es donde la IA ahorra tiempo real y cada hallazgo sigue ligado a evidencia que puedes comprobar. Las comprobaciones siguen siendo repetibles; el agente aporta criterio, contexto y el traspaso a las personas y herramientas que publican los cambios. Si MCP es nuevo para ti, la guía de MCP explica en términos sencillos qué son los hosts, clientes, servidores y herramientas.

2. Qué puede y qué no puede hacer un agente de IA por sí solo

Un modelo de lenguaje es muy bueno leyendo, resumiendo y escribiendo. No es una herramienta de red. Si la aplicación no le da una herramienta para ello, no puede ver lo que ven un navegador o un rastreador por debajo de la página visible. La tabla compara un agente que trabaja solo, con a lo sumo una herramienta de navegación, y el mismo agente trabajando con comprobaciones estructuradas.

Los agentes de código con terminal, como Claude Code, Codex o Cursor, también pueden ejecutar curl, dig u openssl por su cuenta. Eso ayuda a confirmar un hallazgo, pero el agente elige los comandos sobre la marcha: la cobertura depende de lo que se le ocurra comprobar, los resultados varían entre ejecuciones y nada limita sus pruebas a dominios que hayas verificado.

El riesgo de la columna central tiene nombre. La lista de riesgos de OWASP para aplicaciones LLM describe la desinformación como una salida falsa o engañosa que parece creíble, con la alucinación como una de las causas principales, y que empeora cuando se confía en ella sin verificar. En una auditoría se traduce en «tu política DMARC está en none» para un dominio cuyo registro el modelo nunca leyó, o en una cabecera ausente que el servidor sí envía.

Un segundo riesgo viene de las propias páginas. Un agente que lee un sitio web lee texto no confiable, y una página puede incluir instrucciones dirigidas al modelo, a veces ocultas para los visitantes humanos. OWASP lo llama inyección indirecta de prompts. Una configuración de auditoría prudente trata el contenido de la página como datos sobre los que informar, nunca como instrucciones, y mantiene a una persona aprobando cualquier acción del agente.

Lo que el agente hace bien es todo lo que rodea a la evidencia: explicar qué significa un hallazgo para este sitio en concreto, agrupar hallazgos relacionados, preguntar por contexto que las comprobaciones no pueden conocer (¿sigue en uso ese viejo subdominio de staging?) y redactar una solicitud de corrección lo bastante precisa para un agente de código. Ese reparto del trabajo es el núcleo de una buena auditoría web con IA.

3. Las seis áreas que cubrir, con una checklist para cada una

Una auditoría web completa mira seis capas. Cada una responde a una pregunta distinta y produce un tipo de evidencia distinto. La guía de auditoría web sigue un mismo recorrido de cliente por las seis; aquí tienes la checklist de trabajo.

Seguridad

• HTTPS y TLS: una cadena de certificados de confianza, sin caducidad en las próximas semanas, TLS 1.2 o 1.3 y HTTP redirigiendo a HTTPS.
• Cabeceras de seguridad: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, protección contra framing y un Referrer-Policy en las respuestas HTML.
• CORS: sin Access-Control-Allow-Origin: * en respuestas que llevan datos privados y sin orígenes reflejados combinados con credenciales.
• DNS y DNS de correo: registros SPF y DMARC válidos en todo dominio que envía correo y registros restrictivos (v=spf1 -all, p=reject) en los dominios que nunca lo envían.
• Archivos y secretos expuestos: nada accesible en rutas como /.env, /.git/ o copias de seguridad antiguas, y ninguna clave de API en el JavaScript del front-end.
• Subdominios: sin registros DNS que apunten a recursos en la nube eliminados que otra persona podría reclamar (subdomain takeover).
• Superficie de ataque: solo los puertos abiertos y los métodos HTTP que quieres, páginas de acceso y administración que conoces y un CMS y plugins actualizados si usas WordPress.
• Cadena de suministro: scripts de terceros cargados solo desde fuentes que tú elegiste.

Algunas de estas comprobaciones solo leen información pública. Otras, como solicitar rutas sensibles o escanear puertos, envían solicitudes con las que el propietario debería estar de acuerdo, por lo que una herramienta de auditoría debería ejecutarlas solo en objetivos cuya titularidad hayas verificado. La guía de auditoría de seguridad web cubre la parte de aplicación: cuentas, permisos e inicio de sesión.

SEO técnico

• Rastreabilidad: robots.txt no bloquea páginas ni recursos que quieres indexar.
• Indexación: ningún noindex perdido en páginas importantes y un sitemap que lista las URL canonical.
• Títulos y meta descriptions: presentes, únicos y descriptivos de la página.
• Encabezados: un encabezado principal claro y un esquema lógico.
• Canonicals: cada página apunta a su URL preferida, nunca a una redirección ni a una página de error.
• Datos estructurados: JSON-LD válido que coincide con el contenido visible.
• Enlaces internos y redirecciones: páginas importantes accesibles desde la navegación o el contenido, y sin cadenas de varias redirecciones.
• Datos de Search Console: páginas con muchas impresiones pero bajo porcentaje de clics, y consultas en las que te posicionas justo por debajo de los primeros resultados. Suelen ser las mejoras más rápidas.

Aquí importa un límite. Google renderiza JavaScript antes de indexar una página, pero sus nociones básicas de SEO con JavaScript siguen recomendando renderizado en el servidor o prerenderizado, en parte porque algunos bots no ejecutan JavaScript. Una auditoría que lee HTML estático ve la página como la ven esos bots; en un sitio que construye su contenido en el navegador, compara sus hallazgos con la página renderizada. La guía de auditoría de SEO técnico profundiza más.

Preparación para la visibilidad en IA

• Política para rastreadores de IA: las reglas de robots.txt de cada rastreador de IA reflejan lo que decidiste, no un valor por defecto de un plugin que nadie eligió. Varios proveedores documentan tokens distintos para sus rastreadores de búsqueda y de entrenamiento; Google, por ejemplo, describe Google-Extended junto a sus rastreadores de búsqueda.
• llms.txt: opcional. Un índice breve en Markdown de tus páginas más útiles, que merece la pena sobre todo en sitios con mucha documentación; la guía de llms.txt explica qué hace y qué no hace.
• Claridad de la entidad: el mismo nombre de empresa, descripción, ubicación y datos de contacto en todas partes, respaldados por datos estructurados de Organization.
• Capacidad de respuesta: páginas que responden directamente a preguntas reales de los clientes, cerca del principio, en texto y no en imágenes.
• Cobertura de prompts: una lista de las preguntas que los compradores hacen a un asistente y, para cada una, la página de tu sitio que la responde.
• Señales de fuente: un autor u organización con nombre, fechas y citas que facilitan citar y atribuir una página.

Son comprobaciones de preparación de tu propio contenido. No muestran si algún asistente te cita hoy; para eso hace falta un registro aparte de preguntas y respuestas. Google afirma que sus funciones de IA no tienen requisitos adicionales aparte de la elegibilidad normal en Search, así que primero van el acceso de rastreo y el contenido claro. La guía de auditoría de visibilidad en IA muestra cómo construir el conjunto de preguntas.

Accesibilidad

• Alternativas de texto: toda imagen informativa tiene un alt significativo y las decorativas tienen uno vacío.
• Formularios: todo campo tiene una etiqueta programática, no solo texto de placeholder.
• Estructura: encabezados en orden, landmarks como main y nav, y un enlace para saltar al contenido.
• Nombres: todo botón y enlace tiene un nombre accesible y no hay enlaces vacíos.
• Idioma: la página declara su idioma con el atributo lang.
• Comprobaciones manuales: uso solo con teclado, foco visible, contraste de color, zoom y reflow, y una pasada con lector de pantalla.

El W3C es explícito: las herramientas no pueden comprobar automáticamente todos los aspectos de accesibilidad y hace falta juicio humano. Una comprobación automática encuentra la etiqueta que falta; solo una persona puede decir si la etiqueta tiene sentido. La guía de auditoría de accesibilidad describe la revisión manual según WCAG 2.2.

Rendimiento

• Core Web Vitals: Largest Contentful Paint en 2,5 segundos o menos, Interaction to Next Paint en 200 milisegundos o menos y Cumulative Layout Shift de 0,1 o menos, en el percentil 75 de las cargas de página (web.dev).
• Primero los datos de campo: los datos del Chrome UX Report muestran lo que vivieron los usuarios reales de Chrome en los 28 días anteriores, cuando la página o el sitio tiene tráfico suficiente para figurar; los resultados de laboratorio de Lighthouse ayudan a encontrar la causa.
• Primero el móvil: prueba la versión móvil de las páginas que importan, como la página de inicio, una página de producto o servicio y el formulario de compra o contacto.
• Causas habituales: una imagen principal demasiado pesada, scripts y fuentes que bloquean el renderizado, saltos de diseño por imágenes sin dimensiones o banners tardíos, y etiquetas de terceros pesadas.

La documentación de PageSpeed Insights señala que los datos de laboratorio y de campo pueden diferir, y una buena puntuación de laboratorio no significa que los visitantes reales tuvieran una buena experiencia. La guía de auditoría de rendimiento web muestra cómo conectar una métrica lenta con el elemento que la causa.

Integraciones

• Inventario: toda herramienta de analítica, gestor de etiquetas, píxel publicitario, herramienta de consentimiento y etiqueta de verificación del sitio presente en la página, y quién es responsable de cada una.
• Duplicados y restos: dos copias de la misma etiqueta de analítica, o un píxel de una campaña que terminó el año pasado.
• Consentimiento: una herramienta de consentimiento donde haga falta y etiquetas que esperen a que se dé.
• Datos personales: sin direcciones de correo, teléfonos ni nombres en la capa de datos, las URL o los títulos de página que leen las etiquetas. La ayuda de Google Analytics, por ejemplo, pide a los propietarios de sitios que no incluyan información de identificación personal en URL, títulos y eventos.

Las comprobaciones estáticas muestran lo que declara el marcado. Si una etiqueta realmente espera al consentimiento, o qué eventos se disparan tras un clic, requiere una sesión de navegador con las herramientas de desarrollo abiertas. La guía de auditoría de integraciones web recorre ese rastreo.

4. Cómo auditar un sitio web con IA, paso a paso

El Model Context Protocol (MCP) es una forma común de que una aplicación de IA llame a herramientas de otros servicios. Con un servicio de auditoría conectado, el agente de tu chat o de tu herramienta de código puede ejecutar comprobaciones y trabajar directamente con los resultados. El flujo tiene nueve pasos; los dos primeros se hacen una vez por sitio y el resto se repite en cada auditoría.

1. Conecta. Añade el servicio de auditoría como conexión MCP en tu cliente de IA e inicia sesión desde el navegador. Los servidores MCP remotos que requieren cuenta suelen usar OAuth, como describe la especificación de autorización de MCP, de modo que apruebas el acceso en una ventana de inicio de sesión y nunca pegas una contraseña ni una clave de API en el chat. Sitelemetry se conecta así en ChatGPT, Claude, Claude Code, Codex y Cursor; la guía de conexión MCP tiene los pasos de cada cliente.
2. Define el alcance y la autorización. Decide qué sitios y páginas entran y audita solo sitios que sean tuyos o para los que tengas permiso escrito. Las comprobaciones pasivas leen lo que ve cualquier visitante; las comprobaciones activas de seguridad envían solicitudes de sondeo, así que solo deben ejecutarse tras verificar que controlas el dominio. Dile al agente el alcance con palabras claras: solo producción, estas tres URL, sin enviar formularios.
3. Ejecuta la auditoría. Pide una auditoría completa o de un área: «Ejecuta una auditoría completa de https://www.example.com y lista los hallazgos por gravedad». Las auditorías largas pueden correr como tarea en segundo plano; deja que el agente espere el resultado en lugar de lanzar un segundo escaneo.
4. Lee la evidencia. Cada hallazgo debería venir con una gravedad, la evidencia observada, el impacto y una corrección. Pide al agente que cite la evidencia de todo lo clasificado como alto y reproduce uno o dos hallazgos tú mismo con curl -sI o dig. Un hallazgo que puedes reproducir es uno que puedes corregir con confianza.
5. Prioriza. Ordena por gravedad, luego por exposición (¿la página es pública?, ¿gestiona inicio de sesión o pagos?) y después por esfuerzo. Agrupa los hallazgos que comparten una misma corrección, como varias cabeceras definidas en la misma configuración del servidor, y pregunta al agente cuáles importan en este sitio y cuáles tienen poco riesgo aquí.
6. Entrega al agente de código un prompt de corrección listo para agentes. Convierte los hallazgos elegidos en una única solicitud de cambio precisa, con la evidencia, las restricciones, los criterios de aceptación y los pasos de reprueba (más abajo hay un ejemplo). Dásela al agente de código que trabaja en tu repositorio, o deja que el mismo cliente haga ambas cosas si tiene acceso al repositorio.
7. Publica por tu proceso habitual. Revisa el diff, prueba en staging y despliega como con cualquier cambio. La auditoría no sustituye a la revisión de código, y un agente de código no debería desplegar sin que una persona lo apruebe.
8. Vuelve a auditar para verificar. Ejecuta la misma comprobación sobre el mismo objetivo tras el despliegue. Un hallazgo se cierra cuando un resultado nuevo ya no lo muestra, no cuando el agente dice que editó un archivo.
9. Monitoriza. Programa la auditoría para que se repita, de modo que una actualización de plugin, una etiqueta nueva o un certificado a punto de caducar aparezcan antes de que los visitantes lo noten. Una vez por semana basta para la mayoría de los sitios pequeños; los que despliegan a diario se benefician de ejecuciones diarias.

La especificación de MCP recomienda que haya una persona en el circuito que pueda denegar llamadas a herramientas, y OWASP incluye la agencia excesiva, el riesgo de acciones dañinas cuando un agente tiene más funciones, permisos o autonomía de los que necesita su tarea, como un riesgo propio. En la práctica: deja que las herramientas de auditoría lean y que una persona apruebe los cambios de código y los despliegues.

Un prompt de corrección con el que un agente de código puede actuar sin adivinar tiene esta forma (ejemplo ilustrativo):

Fix: Strict-Transport-Security header missing
Target: https://www.example.com (all HTTPS responses)
Evidence: GET / over HTTPS returned 200 without a
Strict-Transport-Security header.
Constraints:
- Change only the header configuration of the web server or CDN.
- Use max-age=300 for now (first rollout stage); no preload.
- Do not change redirects, cookies or other headers.
Acceptance criteria:
- curl -sI https://www.example.com/ shows a
  Strict-Transport-Security header with max-age=300.
- The header is present on HTML, CSS and JavaScript responses.
Retest:
- Re-run the security audit for www.example.com and confirm
  the finding no longer appears.

Cada parte tiene una función. La evidencia dice al agente de código qué se observó, para que no tenga que redescubrir el problema. Las restricciones mantienen el cambio pequeño; empezar HSTS con un max-age corto y subirlo por etapas es el camino prudente que describe la guía de HSTS. Los criterios de aceptación son comandos que cualquiera puede ejecutar, y el paso de reprueba cierra el ciclo con la misma comprobación que encontró el problema.

5. Cómo evaluar una herramienta de auditoría web con IA

Si buscas la mejor herramienta de IA para auditar un sitio web, encontrarás listas larguísimas. La elección adecuada depende de tu sitio, pero las preguntas que distinguen una herramienta de auditoría con IA útil de un chatbot con un escáner pegado son las mismas para cualquier producto.

Después, prueba cualquier candidata en tu propio sitio antes de fiarte de ella:

• Ejecútala dos veces sobre la misma página sin cambios. Los hallazgos y las gravedades deberían coincidir.
• Comprueba tres hallazgos a mano, uno de seguridad, uno de SEO y uno de accesibilidad, con curl, dig o el código fuente de la página.
• Planta un problema conocido en staging, como una imagen sin alt o un título duplicado, y mira si lo detecta.
• Corrige un hallazgo y vuelve a auditar. Debería desaparecer y nada ajeno debería cambiar.
• Lee los límites. Una herramienta que dice lo que no comprueba inspira más confianza que una que afirma comprobarlo todo.

La sección 8 enumera qué cubre Sitelemetry, cómo entrega las correcciones y dónde están sus límites.

6. Errores comunes y cómo evitarlos

El hilo común es el mismo. Trata al agente como un colega rápido y elocuente que no ha visto el servidor: dale evidencia, mantén sus permisos acotados y comprueba el resultado en el sitio en vivo.

7. Un ejemplo práctico: el sitio de una clínica pequeña

Una clínica dental tiene un sitio WordPress en www.example-clinic.com con un formulario de reservas en línea. La responsable de la oficina conecta un servicio de auditoría a su asistente de IA, verifica el dominio y pide una auditoría completa de la página de inicio y la de reservas. Entre los resultados (ilustrativos, no son datos reales):

El agente explica por qué los dos primeros van antes: la copia expone datos a cualquiera que adivine la ruta, y la dirección del código de seguimiento se pasa a todas las etiquetas de terceros que leen la capa de datos. Pregunta si el bloqueo de rastreadores de IA fue intencionado. Nadie lo había decidido, así que pasa a ser una decisión de la propietaria y no una corrección.

Para la copia de seguridad, la solución no es código: borrar el archivo, buscar otras copias en el servidor y averiguar qué proceso lo creó. Después, revisar los registros de acceso por si hubo descargas anteriores, cambiar las contraseñas o claves que contuviera la copia y, si pudieron exponerse datos de pacientes, seguir el procedimiento de la clínica ante brechas de datos. Para las etiquetas del formulario, el agente redacta un prompt de corrección que nombra los cinco campos y la página de reservas en la que están, con la restricción de que el diseño visual no cambie y el criterio de aceptación de que un lector de pantalla anuncie una etiqueta para cada campo. El agente de código del desarrollador hace el cambio, el desarrollador lo revisa y lo despliega, y una nueva auditoría muestra el hallazgo resuelto. El registro DMARC va a quien gestione el DNS, empezando con p=none y con informes, como explica la guía de despliegue de DMARC. Cada elemento termina igual: cambiado, desplegado y comprobado de nuevo con la auditoría que lo encontró.

8. Cómo ejecutar este flujo con Sitelemetry

Sitelemetry es una herramienta de auditoría web con IA creada para el flujo de esta guía:

• Seis áreas. Seguridad, con hasta 27 módulos en el plan Enterprise: DNS, SPF y DMARC, TLS, postura HTTPS, cabeceras de seguridad, CORS, archivos expuestos, exposición de API y secretos, subdomain takeover, cadena de suministro, superficie de autenticación, puertos abiertos, métodos HTTP, WordPress y más. SEO técnico, con clics, CTR, posición y mejoras rápidas de Google Search Console. Preparación para la visibilidad en IA, accesibilidad, rendimiento mediante PageSpeed Insights, Lighthouse y datos de campo de CrUX, e integraciones.
• Evidencia y correcciones. Los hallazgos incluyen gravedad, evidencia, impacto y corrección, y cada auditoría puede generar un prompt de corrección listo para agentes con restricciones, criterios de aceptación y pasos de reprueba.
• Dentro de tus herramientas de IA. Funciona por MCP con inicio de sesión OAuth en ChatGPT, Claude, Claude Code, Codex y Cursor; la guía de conexión MCP explica cómo conectarlo. El inicio de sesión OAuth significa que apruebas el acceso en una ventana del navegador y nunca pegas una contraseña ni una clave de API en el chat.
• Verifica y monitoriza. Vuelve a auditar tras una corrección para confirmarla en el sitio en vivo. Según el plan, la monitorización se ejecuta cada semana, cada día o cada hora. Los informes se exportan en JSON o PDF, con informes de marca blanca en Enterprise.
• Planes. Starter a 49 USD, Professional a 149 USD y Enterprise a 249 USD al mes; la página de precios detalla lo que incluye cada uno.

Sus límites son los que esta guía te pide buscar. Las auditorías alojadas observan el objetivo sin modificarlo y las comprobaciones activas de seguridad se ejecutan solo en objetivos verificados. Las comprobaciones de SEO, visibilidad en IA, accesibilidad e integraciones leen HTML estático sin ejecutar JavaScript. La visibilidad en IA comprueba la preparación del contenido y no consulta a asistentes de IA. Las comprobaciones de accesibilidad son estáticas y se orientan a WCAG 2.2, no son una evaluación manual completa, y la auditoría de seguridad no es un pentest. Conserva las comprobaciones manuales de la sección 3 para lo que el análisis estático no puede ver.