Gestión de múltiples sitios WordPress con agentes de IA: qué decidir antes de conectarlos a 23+ sitios

La gestión de sitios WordPress cambia de naturaleza cuando pasas de un sitio a una flota. Ya no se trata de saber administrar WordPress. Se trata de hacer lo mismo 23 veces sin que cada sitio termine distinto.

Administro una flota de 23+ sitios en producción, sobre servidores AlmaLinux con WHM. Ahora que aparecen servicios que prometen una sola conexión de IA para todos los sitios que administras, la pregunta obvia es si conviene conectar un agente a esa flota.

Este artículo no cuenta que ya lo hice. Cuenta qué decidiría antes de hacerlo: qué permisos le daría, qué tareas dejaría en herramientas deterministas y dónde la IA sí ahorra trabajo. El código es ilustrativo.

El punto de partida: qué es operar 23+ sitios

El trabajo diario con una flota así no es diseño ni contenido. Es operación: ajustar Apache y PHP-FPM, recuperar espacio en disco, actualizar versiones de PHP y resolver DNS repartido entre varios proveedores.

En esa operación recuperé más de 40 GB de disco. No salieron de una herramienta mágica. Salieron de revisar cuenta por cuenta qué ocupaba espacio y por qué seguía ahí.

Esa experiencia deja tres ideas claras, y las tres aplican a cualquier agente que quieras conectar:

• El riesgo se multiplica. Un error en un sitio es un incidente. El mismo error repetido en 23 sitios es una crisis.
• Cada sitio tiene historia. Plugins viejos, versiones de PHP distintas, configuraciones que alguien hizo a mano. Lo que funciona en uno puede romper otro.
• Lo valioso es el inventario. Saber qué hay en cada sitio vale más que cualquier automatización que se ejecute a ciegas.

Conectar agentes IA a múltiples sitios

Conectar un agente a una flota es darle una credencial. Esa credencial define todo lo demás: lo que el agente puede ver, lo que puede cambiar y lo que puede romper si se equivoca o si alguien lo manipula.

Un agente de IA se equivoca de formas distintas a una persona. Puede interpretar mal una instrucción, seguir un texto malicioso que leyó en un log o en un comentario, o ejecutar con total seguridad algo que no debía.

Por eso el diseño empieza por los permisos, no por las capacidades. Estas son las decisiones que tomaría antes de conectar nada:

• Un usuario dedicado por sitio. Nunca la cuenta de un administrador humano. Si el agente hace algo raro, el registro de actividad dice exactamente quién fue.
• Contraseñas de aplicación por sitio. WordPress permite crear contraseñas de aplicación para la API REST. Una por sitio, con nombre claro, revocable en segundos sin tocar los demás.
• Solo lectura en la primera fase. El agente empieza leyendo: versiones, plugins, logs, estado. Escribir llega después, y solo si la lectura demostró que vale la pena.
• Nada de root en el servidor. Si el agente ejecuta WP-CLI, lo hace como el usuario de cada cuenta. Un error queda contenido en un sitio.

Hay un detalle que se olvida: el rol de WordPress limita lo que hace la API, pero un rol de administrador puede instalar plugins, y un plugin puede ejecutar cualquier código. Darle «administrador» a un agente es darle el servidor de ese sitio.

Si el agente necesita ejecutar comandos, no le des un shell. Dale una lista cerrada de comandos permitidos y valídala en tu código, no en las instrucciones del modelo:

import subprocess
# El agente no recibe un shell: recibe una lista cerrada, de solo lectura al inicio.
PERMITIDOS = {("core", "version"), ("plugin", "list"),
              ("core", "verify-checksums"), ("theme", "list")}

def ejecutar(sitio: str, args: list[str]) -> str:
    if tuple(args[:2]) not in PERMITIDOS:
        raise PermissionError(f"comando fuera de la lista: {args[:2]}")
    # Sin shell=True: el agente no puede encadenar ni inyectar comandos.
    r = subprocess.run(["sudo", "-u", USUARIOS[sitio], "wp", f"--path={RUTAS[sitio]}", *args],
                       capture_output=True, text=True, timeout=60)
    return r.stdout

Fíjate en lo que no está en la lista: option get. Parece inofensivo, pero muchos plugins guardan llaves de API en la tabla de opciones. Un comando de «solo lectura» también puede filtrar secretos.

La regla de fondo es simple: la seguridad vive en el código que rodea al agente. Las instrucciones del tipo «no hagas cambios sin preguntar» son una preferencia, no un control.

Herramientas para administrar sitios en masa

Antes de preguntarte qué puede hacer la IA, pregúntate qué ya resuelve una herramienta determinista. En la gestión de una flota, la respuesta es: casi todo lo repetitivo.

Las herramientas de administración en masa, sean paneles comerciales o scripts propios, resuelven lo mismo: ver el estado de todos los sitios en un lugar y aplicar la misma acción a varios. Para eso no hace falta un modelo de lenguaje.

En mi caso, la base es WP-CLI ejecutado en lote. Un inventario de solo lectura, que corre como el dueño de cada sitio, responde en minutos qué versión de WordPress tiene cada uno y qué plugins tienen actualización pendiente:

# Inventario de solo lectura: versión de WordPress y plugins con actualización pendiente.
for dir in /home/*/public_html; do
  [ -f "$dir/wp-config.php" ] || continue
  usuario=$(stat -c %U "$dir")
  # Corre como el dueño del sitio, nunca como root: WP-CLI ejecuta código del sitio.
  echo "$usuario,$(sudo -u "$usuario" wp --path="$dir" core version 2>/dev/null)" \
    >> /root/inventario/core.csv
  sudo -u "$usuario" wp --path="$dir" plugin list --update=available \
    --fields=name,version,update_version --format=csv 2>/dev/null \
    | sed "1d; s|^|$usuario,|" >> /root/inventario/plugins.csv
done

Ese inventario es más útil que cualquier agente por una razón: siempre da el mismo resultado para el mismo estado. Se puede comparar entre días, versionar y auditar.

Lo que sigue siendo trabajo del panel del servidor, en mi caso WHM, tampoco necesita IA:

• Versiones de PHP por cuenta. Se cambian por sitio, con prueba previa, porque un plugin viejo puede no soportar la versión nueva.
• Espacio en disco. Respaldos olvidados, logs sin rotar y cachés que crecen sin límite. Se encuentran con reportes por cuenta, no con conversaciones.
• Ajuste de Apache y PHP-FPM. Los límites de procesos se calculan con la memoria del servidor y el tráfico de cada sitio. Son números, no opiniones.
• DNS repartido entre proveedores. Un inventario de dónde vive cada zona evita que un cambio se haga en el proveedor equivocado.

Si quieres llevar esta disciplina a infraestructura como código, escribí sobre cómo modelar una flota así en Terraform en AWS para 23+ sitios.

Optimizando la gestión con IA

Con los permisos acotados y lo repetitivo resuelto, queda la pregunta interesante: ¿dónde sí suma un agente? En las tareas que consisten en leer mucho, entender contexto y resumir.

Triage de logs

Revisar el log de errores de PHP de 23 sitios es lento y aburrido. La mayoría de las líneas son avisos repetidos; unas pocas anuncian un problema real.

Un agente puede agrupar errores repetidos, separar los avisos de los fallos fatales y decirte qué sitio empezó a fallar desde la última actualización. Tú revisas un resumen de diez líneas, no diez mil.

Una precaución: los logs contienen texto que escribió alguien de fuera, como URLs, agentes de usuario y parámetros. Un agente que lee logs puede encontrarse instrucciones maliciosas escondidas ahí. Por eso el agente que lee logs no debe poder escribir nada.

Resúmenes de actualizaciones

Con el inventario en la mano, el agente puede leer las notas de versión de cada plugin pendiente y responder lo que importa: ¿es una corrección de seguridad?, ¿cambia algo que use este sitio?, ¿hay reportes de incompatibilidad?

Eso convierte una lista de 60 actualizaciones en tres grupos: aplicar hoy, aplicar con prueba y esperar.

Borradores de cambios con aprobación humana

El agente puede redactar el plan: qué actualizar, en qué sitios, en qué orden y cómo revertir. Una persona lo revisa y lo aprueba. La ejecución corre en un script determinista, no en el modelo.

Esa separación es la parte importante. El agente propone; el script ejecuta lo aprobado, respalda antes y revierte si la prueba falla:

# ⚠️ Producción: el cambio lo aprobó una persona; aun así, primero el respaldo.
usuario=sitio01; ruta=/home/$usuario/public_html; marca=$(date +%F-%H%M)
wpu() { sudo -u "$usuario" wp --path="$ruta" "$@"; }
wpu db export "/home/$usuario/respaldos/$marca.sql"
previa=$(wpu plugin get "$plugin" --field=version)
# Un plugin a la vez: si algo falla, se sabe exactamente qué fue.
wpu plugin update "$plugin"
# La prueba de humo decide; el agente no puede declarar el éxito.
if ! curl -fsS -o /dev/null --max-time 20 "https://$dominio/"; then
  wpu plugin install "$plugin" --version="$previa" --force
  echo "revertido $plugin a $previa en $usuario" | logger -t flota
fi

La prueba de humo de este ejemplo es mínima: que la portada responda. En un sitio real se agregan las páginas que más importan, como el carrito o el formulario de contacto.

Auditoría y rollback: lo que no se negocia

Con una flota, la pregunta «¿qué cambió y quién lo cambió?» tiene que responderse en minutos. Si el agente participa, la respuesta debe incluirlo con nombre propio.

• Registro de cada acción. Qué propuso el agente, quién lo aprobó, qué comando se ejecutó, en qué sitio y con qué resultado. Fuera del servidor del sitio, para que un sitio comprometido no pueda borrarlo.
• Respaldo antes de cada escritura. Base de datos y archivos afectados, con fecha en el nombre. Sin respaldo, no hay ejecución.
• Rollback probado, no supuesto. Restaurar un respaldo se ensaya en un sitio de prueba. Un respaldo que nunca se restauró es una esperanza.
• Despliegue por grupos. Primero un sitio de bajo riesgo, después unos pocos, después el resto. Un error se detecta cuando afecta a uno, no a 23.
• Un interruptor de apagado. Revocar las contraseñas de aplicación del agente debe tardar segundos y no afectar a nadie más.

Nada de esto es exclusivo de la IA. Es la disciplina normal de operar producción. La diferencia es que un agente actúa más rápido que una persona, y por eso los controles tienen que estar listos antes.

Lo que NO debes hacer

• Una sola cuenta de administrador para toda la flota. Si esa credencial se filtra o el agente se equivoca, el daño alcanza a todos los sitios a la vez. Credenciales separadas por sitio, siempre.
• Dejar que el agente ejecute directo en producción. Actualizar plugins o editar archivos sin aprobación ni respaldo convierte un error de interpretación en una caída. El agente propone; un script aprobado ejecuta.
• Usar IA para lo que un comando ya resuelve. Pedirle a un modelo que «revise qué versión de WordPress tiene cada sitio» es más lento, más caro y menos confiable que un inventario con WP-CLI.

El siguiente paso

La gestión de sitios WordPress con agentes de IA puede ahorrar horas, pero solo si el agente llega a una flota ordenada: inventario al día, permisos mínimos, ejecución determinista y rollback probado. Sin eso, la IA solo acelera los errores.

Si tu equipo administra muchos sitios y quiere ordenar su operación, evaluar si un agente de IA tiene sentido o auditar sus servidores antes de automatizar, en Conqr Digital Agency diseñamos arquitecturas que escalan. Revisemos tu caso.

Si quieres conocer cómo trabajo la parte de servidores, revisa el servicio de servidores Linux y correo.

Preguntas frecuentes

¿Es seguro conectar un agente de IA a todos mis sitios WordPress?

Depende de los permisos que le des. Con credenciales separadas por sitio, una lista cerrada de comandos de solo lectura y aprobación humana para cualquier escritura, el riesgo es manejable. Con una sola cuenta de administrador para toda la flota, no lo es.

¿Qué herramientas uso para administrar muchos sitios WordPress a la vez?

La base es determinista: WP-CLI ejecutado en lote como el usuario de cada sitio, un inventario de versiones y plugins, y el panel del servidor (WHM en mi caso) para cuentas, PHP y espacio en disco. Un agente de IA puede apoyarse en esas herramientas, no reemplazarlas.

¿Qué tareas de administración conviene delegar a la IA?

Las que consisten en leer mucho y resumir: revisar logs de error de varios sitios, explicar qué cambia en una actualización y redactar un plan de cambios. Ejecutar esos cambios en producción sigue siendo decisión de una persona.