Vigilancia automática de la accesibilidad de los sitios cliente

El sitio web de uno de sus clientes deja de funcionar. No se da cuenta enseguida. Los modelos de IA, en cambio, lo detectan en pocas horas: sus rastreadores ya no pueden recuperar las páginas, sus respuestas dejan de citar la marca, y la visibilidad IA cae en silencio. Cuando lanza su próxima auditoría trimestral, las puntuaciones han bajado veinte puntos y nadie sabe desde cuándo.

Hemos visto esta situación demasiadas veces. AI Labs Audit integra ahora una vigilancia automática de la accesibilidad de los sitios cliente en dos niveles: verificación al introducir la URL, y control diario en segundo plano. Así funciona, y por qué es una red de seguridad indispensable para una agencia GEO/AEO.

Nivel 1 — Verificación inmediata al introducir

Cuando añade o modifica la URL de un cliente (formulario de creación rápida o edición de ficha), la plataforma realiza un test HTTP en tiempo real antes del guardado. El botón "Guardar" se desactiva si el sitio devuelve un código de error, un timeout o una URL mal formada.

• Detección de erratas: ejempol.es en lugar de ejemplo.es se intercepta antes de contaminar la base de datos.
• Detección de sitios inexistentes: un cliente que rehace su web con un dominio nuevo y olvida avisarle, se detecta al introducir.
• Auto-prefijo: si escribe ejemplo.com sin https://, se añade automáticamente antes de testear.
• Endpoint REST dedicado: GET /api/client/check-url?url=... devuelve ok / http_error / timeout / unreachable / invalid_url en menos de 6 segundos.

Resultado: ninguna ficha cliente puede ya guardarse con una URL rota. Las auditorías programadas sobre ese cliente siempre parten de una URL accesible el día en que la añadió.

Nivel 2 — Control diario en segundo plano

Un sitio puede estar bien el día de la creación y caer tres meses más tarde. Por eso añadimos un cron diario que vuelve a testear todos los sitios cliente activos cada noche a las 04:10 (hora del servidor).

La tarea Celery daily_check_client_websites:

1. Selecciona todos los clientes activos con un site_web no vacío que no han sido testeados desde hace más de 20 horas.
2. Lanza peticiones HEAD en paralelo (10 workers, timeout 6s, fallback GET en 405) para no saturar el servidor.
3. Actualiza tres columnas en la ficha cliente: site_web_status, site_web_last_check, site_web_unreachable_since.
4. Resetea unreachable_since a NULL en cuanto un sitio vuelve a responder (recuperación).

Si más del 50 % de los sitios testeados en un lote cae en KO, la plataforma genera una alerta CRITICAL automática en system_alerts. Suele ser un problema de red o DNS del lado del servidor, no del cliente — la agencia es notificada antes de perseguir un problema fantasma.

Nivel 3 — Insignia visual en la ficha cliente

En la página ficha del cliente, si un sitio ha sido inaccesible durante más de 7 días, una insignia roja "Sitio KO" aparece junto al nombre del dominio, con un tooltip que detalla el estado exacto (timeout, http_error, unreachable...) y la fecha desde la que el sitio cayó.

¿Por qué 7 días y no inmediatamente? Para evitar falsas alertas en sitios con mantenimiento programado de unas horas, o un problema de red temporal. Más allá de una semana, estamos seguros de un problema real que merece intervención de la agencia.

Caso real: por qué cambia las reglas del juego

Una agencia partner tenía 80 clientes activos auditados mensualmente. Aproximadamente una vez por trimestre, un cliente rehacía su sitio sin avisar: nuevo CMS, nuevo dominio, redirección olvidada. Antes de esta funcionalidad, la agencia lo descubría en el momento del informe — hasta 30 días más tarde. Durante todo ese tiempo, los créditos se consumían auditando un sitio que devolvía 404.

Con la vigilancia integrada, el caso se detecta en 24 horas. El account manager llama al cliente al día siguiente, ajusta la ficha, y la siguiente auditoría parte de la URL correcta. Cero créditos desperdiciados, cero informes vacíos, cero malas sorpresas.

Disponibilidad y activación

La funcionalidad está activa por defecto en todos los planes que gestionan clientes (Consultant, Consultant+, Agent, Agencia+). Sin acción requerida: la verificación al introducir es automática, el cron corre en segundo plano, la insignia aparece en cuanto un cliente está afectado. Los checks consumen cero créditos — es infraestructura, no un servicio IA de pago.

El histórico del estado se consulta en las columnas añadidas a la tabla clients y se expone en la API REST (GET /api/clients/{id} devuelve los tres campos site_web_status, site_web_last_check, site_web_unreachable_since).

Conclusión

Vigilar la accesibilidad de un sitio cliente no es un tema atractivo, pero es la base de una medición GEO/AEO honesta. Auditar un sitio que devuelve 500 no aporta ninguna información útil sobre la visibilidad IA de la marca — solo llena el informe de ruido. AI Labs Audit prefiere avisarle antes de lanzar la auditoría que facturarle un informe vacío.

Puede probar la verificación inmediata desde hoy mismo: cree un cliente con una URL rota a propósito en su lista de clientes, y observe cómo el botón "Guardar" se mantiene desactivado hasta que lo corrija.

Artículo revisado y actualizado: mayo de 2026 — verificado frente a los comportamientos actuales de ChatGPT, Claude, Gemini y Perplexity.