WordPress mueve más del 40 % de la web, y buena parte de su día a día sigue siendo trabajo manual en wp-admin: actualizar plugins uno a uno, revisar usuarios, exportar la base de datos antes de tocar nada. Mientras tanto, un asistente como Claude Code vive justo donde WordPress guarda su otra cara, mucho menos conocida: la terminal. El puente entre ambos existe desde hace más de una década, es oficial y se llama WP-CLI. En este artículo explicamos qué es, cómo conectar Claude Code a un WordPress —local o remoto— y qué tareas reales resuelve la pareja.
Qué es WP-CLI y por qué es el idioma perfecto para una IA
WP-CLI es la interfaz de línea de comandos oficial de WordPress: un programa que se instala una vez y permite administrar cualquier sitio WordPress escribiendo comandos en lugar de navegando por el panel. Existe desde 2011, se mantiene como proyecto oficial de la comunidad y lo usan a diario los hostings gestionados para administrar millones de instalaciones.
Casi todo lo que se hace en wp-admin tiene su comando: wp plugin update --all actualiza los plugins, wp user list lista los usuarios, wp post create publica una entrada. Pero lo interesante es lo que el panel no ofrece y WP-CLI sí:
wp search-replace, que cambia una cadena en toda la base de datos —el caso típico: migrar de dominio— respetando los datos serializados que un reemplazo SQL a pelo corrompería.wp core verify-checksums, que compara cada archivo del núcleo con el original de wordpress.org y delata modificaciones sospechosas: la primera prueba que hacemos ante un posible hackeo.wp db export, una copia de seguridad de la base de datos en un comando, sin plugins de backup de por medio.
¿Y por qué importa esto para la IA? Porque un asistente como Claude Code habla terminal de forma nativa. Un panel visual está pensado para ojos y ratón humanos: para operarlo, un agente tiene que interpretar la pantalla y adivinar dónde hacer clic, un proceso lento y frágil. Un comando, en cambio, es texto: preciso al escribirlo, verificable al leer su salida, componible con el siguiente. Claude Code ejecuta wp plugin list, lee la tabla que devuelve, detecta los plugins desactualizados y encadena la siguiente orden. Sin capturas de pantalla, sin adivinar, sin margen para el "creo que he pulsado donde era".
Y hay un detalle que parece diseñado a medida para agentes: casi cualquier comando acepta --format=json o --format=csv. La salida deja de ser texto para ojos humanos y se convierte en datos estructurados que el asistente procesa sin ambigüedad: no interpreta una tabla, lee un listado de datos exacto del estado del sitio.
Es la misma lógica que contamos con los servidores MCP: darle a la IA manos que ya hablan su idioma. La diferencia es que aquí el puente no hay que instalarlo en el asistente: WP-CLI lleva quince años esperando a este momento.
Instalar WP-CLI (dos minutos, de verdad)
El escenario más común es también el más sencillo: tu WordPress vive en un servidor Linux de tu hosting y entras por SSH. La mayoría de los proveedores gestionados ya traen WP-CLI preinstalado, así que lo primero es comprobarlo:
ssh usuario@tu-servidor.com
wp --info
Si responde con la versión de PHP y de WP-CLI, no hay nada que instalar. Si no la tiene, son tres comandos (el único requisito es PHP 7.2.24 o superior):
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
El tercer comando es el que hace que wp funcione desde cualquier carpeta: /usr/local/bin ya está en el PATH de cualquier Linux, así que no hay nada más que configurar. En un hosting compartido sin permisos de root, ese paso cambia: mueve el archivo a ~/bin/wp y añade esa carpeta a tu PATH a mano:
mkdir -p ~/bin && mv wp-cli.phar ~/bin/wp
echo 'export PATH=$HOME/bin:$PATH' >> ~/.bashrc && source ~/.bashrc
Desde la carpeta del sitio, wp core version debe devolver la versión de WordPress instalada. Si lo hace, la conexión con Claude Code ya está técnicamente lista: no hace falta nada más. (¿Y si trabajas en local? Los entornos de desarrollo modernos como Local o DDEV ya lo traen de serie.)
Conectar Claude Code: una carpeta de proyecto y un CLAUDE.md
La "conexión" es más sencilla de lo que suena, pero conviene tener clara la geografía: Claude Code trabaja en tu ordenador y el WordPress vive en el servidor; el puente entre ambos es SSH. En tu máquina creas una carpeta de proyecto para el sitio —no hace falta tener ahí ni un solo archivo de WordPress— con dos cosas dentro: el archivo que le dice a WP-CLI dónde vive el servidor (lo vemos enseguida) y el CLAUDE.md con las reglas. Abres Claude Code en esa carpeta y cada comando wp viaja por SSH hasta el servidor, se ejecuta allí y devuelve su salida a la conversación. El único requisito extra es tener WP-CLI también en tu ordenador, aunque ahí no haya ningún WordPress. ¿Para qué, entonces? Actúa de puro cliente: cuando Claude Code ejecuta un comando con alias (wp @prod plugin list), el WP-CLI local lee el alias, abre la conexión SSH y lanza el comando en el WP-CLI del servidor, que es quien de verdad trabaja. Podría prescindirse de él y escribir la conexión SSH a mano en cada comando, pero los alias la resuelven una vez y para siempre. Y al asistente no hay que explicarle la herramienta: WP-CLI está sobradamente documentado en su entrenamiento.
Lo que convierte esa conexión en un flujo de trabajo serio es el archivo CLAUDE.md: el documento en la raíz de esa carpeta que Claude Code lee al arrancar cada sesión y donde viven las reglas de la casa. Para un sitio WordPress, el nuestro se parece a esto:
# Sitio: cliente.com — WordPress
## Entorno
- El WordPress vive en el servidor del hosting: los comandos `wp` viajan por SSH
## Reglas
- Antes de cualquier cambio en la base de datos: `wp db export`
- `wp search-replace` siempre primero con `--dry-run`
- Nunca leer ni modificar las credenciales de `wp-config.php`
La segunda pieza es la política de permisos de Claude Code, que gobierna cada comando con tres estados: preguntar, permitir o denegar. La configuración sensata para WordPress es asimétrica: los comandos de lectura (wp plugin list, wp user list, wp post list) pueden ejecutarse sin fricción, mientras que todo lo que escribe, actualiza o borra pide confirmación. Diez segundos de revisión antes de un wp plugin update --all en producción es un seguro barato.
Qué puede hacer: peticiones reales y lo que ocurre por debajo
La teoría se entiende mejor con encargos concretos. Estos son los que más repetimos:
| Le pides | Lo que hace por debajo |
|---|---|
| "¿Qué plugins tienen actualización pendiente?" | wp plugin list --update=available y te resume la tabla con lo urgente |
| "Haz copia y actualiza todo" | wp db export primero; después núcleo, plugins, temas y traducciones, comprobando la web tras cada paso |
| "Cambia el dominio en toda la base de datos" | wp search-replace con --dry-run primero, te enseña cuántas filas cambiarían y ejecuta solo si lo apruebas |
| "¿Este WordPress está hackeado?" | wp core verify-checksums, wp plugin verify-checksums --all y revisión de usuarios administradores sospechosos |
| "Encuentra el plugin que rompe la web" | Desactiva plugins uno a uno (wp plugin deactivate), comprueba tras cada uno y aísla al culpable |
| "Publica estas 15 entradas desde los Markdown de esta carpeta" | Un bucle de wp post create leyendo cada archivo, con título, categoría y estado que le indiques |
| "¿Por qué va lenta?" | wp profile stage y wp doctor check --all (dos extensiones oficiales) para señalar hooks y consultas lentas |
| "Limpia y regenera" | wp transient delete --all, wp cache flush, wp media regenerate tras un cambio de tamaños de imagen |
Fíjate en el patrón, el mismo que vimos con MCP: el asistente deja de trabajar de memoria y pasa a trabajar con el estado real del sitio, en el momento. No te dice "deberías revisar los plugins": los lista, los coteja y te trae el diagnóstico hecho.
El oficio, en una skill: enséñale tus rutinas una sola vez
Quizá eches en falta aquí la típica chuleta de comandos. No la hay, y es deliberado: los comandos no te los tienes que aprender tú. WP-CLI lleva quince años documentado y Claude Code lo conoce de sobra; tu trabajo es pedir, no memorizar.
Lo que el asistente no puede saber es cómo trabajas tú: en qué orden actualizas, qué compruebas después de cada cambio, dónde está la frontera entre "hazlo" y "avísame antes". Ese oficio se empaqueta en una skill, el mismo mecanismo que vimos con Remotion: un paquete de conocimiento que el asistente carga automáticamente cuando detecta que trabaja con WordPress. La nuestra se parece a esto:
# Skill: mantenimiento WordPress
Rutina de actualización
wp db exportantes de tocar nada- Actualizar núcleo, plugins y temas
- Comprobar la portada, una entrada y el formulario de contacto
- Cerrar con
wp core verify-checksums
Diagnóstico de rendimiento
- Si faltan, instala las extensiones de diagnóstico:
wp package install wp-cli/profile-command wp-cli/doctor-command - Empieza por
wp profile stagey señala la fase más lenta antes de proponer nada
La diferencia con el `CLAUDE.md` es el alcance: el archivo del proyecto vale para *ese* sitio; la skill viaja contigo. Para una agencia con veinte WordPress a su cargo, la misma skill sirve en los veinte — el criterio se escribe una vez y se aplica siempre. Es el mismo reparto de papeles que contamos en [el artículo de MCP](/blog/inteligencia-artificial/mcp-conectar-claude-code-con-tus-herramientas/): la skill es el conocimiento; WP-CLI, las manos.
## Los alias SSH: así llegan los comandos al servidor
La pieza que hace posible todo ese trabajo a distancia son los **alias** de WP-CLI. En un archivo `wp-cli.yml`, en la raíz de tu carpeta de proyecto, se define dónde vive el sitio:
```yaml
@prod:
ssh: deploy@cliente.com/var/www/cliente.com
Y a partir de ahí, cualquier comando viaja por SSH anteponiendo el alias: wp @prod plugin list lista los plugins de producción desde tu terminal. El único requisito es que el servidor tenga WP-CLI instalado (los hostings gestionados suelen traerlo) y que tu clave SSH tenga acceso.
Un detalle de rendimiento: cada comando abre su propia conexión SSH. Si se nota la espera —servidor lejano, muchas órdenes seguidas—, activa ControlMaster y ControlPersist en tu ~/.ssh/config: la primera conexión se queda abierta en segundo plano y todas las siguientes la reutilizan al instante, sin cambiar nada en los comandos:
Host cliente.com
ControlMaster auto
ControlPath ~/.ssh/control-%r@%h:%p
ControlPersist 10m
¿Y si el servidor aloja varias instalaciones de WordPress? Ningún problema: WP-CLI opera sobre la instalación de la carpeta en la que se ejecuta, así que la ruta que acompaña a cada alias decide el sitio. En un VPS con varios clientes, cada instalación tiene su alias aunque todas compartan máquina:
@cliente-a:
ssh: deploy@servidor.com/var/www/cliente-a.com
@cliente-b:
ssh: deploy@servidor.com/var/www/cliente-b.com
@cliente-c:
ssh: deploy@servidor.com/var/www/cliente-c.com
Y aquí viene el regalo para agencias: el alias especial @all, que trae WP-CLI de serie, ejecuta el mismo comando en todos los alias definidos. Un wp @all plugin list --update=available revisa las actualizaciones pendientes de toda la cartera de sitios de una tacada — la pregunta "¿qué clientes tienen plugins por actualizar?" pasa de una mañana de logins a una sola línea.
Para Claude Code esto significa poder operar el servidor sin salir de la conversación. El flujo de una actualización mensual seria queda así: copia de seguridad de la base de datos, actualización de núcleo, plugins y temas, y comprobación de que la web sigue funcionando. Pasos que a mano son media hora de atención; dirigidos, son una petición y un par de confirmaciones.
El alias hace fácil llegar; las reglas del CLAUDE.md deciden qué se puede tocar al llegar: en producción, nada se escribe sin tu confirmación.
La otra puerta: REST API, Application Passwords y el MCP de WordPress
WP-CLI exige algo que no siempre se tiene: acceso a la máquina, sea local o por SSH. Cuando no lo hay —un hosting sin SSH, un sitio de un tercero que solo te da un usuario—, existe una segunda puerta: la REST API de WordPress con Application Passwords, las contraseñas de aplicación que WordPress incluye de serie desde la versión 5.6. Se generan en el perfil del usuario, se revocan con un clic y permiten a Claude Code leer y escribir contenido vía HTTP sin conocer tu contraseña real.
Y en esa misma dirección apunta el movimiento más interesante del último año: WordPress 6.9 estrenó la Abilities API, un registro donde el núcleo, los plugins y los temas declaran sus capacidades de forma tipada —qué hace cada función, qué parámetros necesita, qué devuelve y quién tiene permiso para invocarla—. Sobre ella, el equipo de IA de WordPress publica el MCP Adapter oficial, que traduce esas habilidades al protocolo MCP para que un cliente como Claude Code las descubra y las use, igual que los servidores que repasamos en el artículo sobre MCP. Tiene dos transportes: HTTP para operar sitios remotos y STDIO en local, apoyándose precisamente en WP-CLI — las dos vías de este artículo acaban confluyendo. El diseño es prudente por defecto: el servidor solo expone primitivas de descubrimiento, y cada habilidad sensible debe marcarse como pública explícitamente por código, señal de que hoy va dirigido a desarrolladores; a su alrededor florecen ya plugins comerciales que ofrecen lo mismo con un interruptor. Terreno joven aún, pero la dirección es clara: WordPress quiere ser operable por agentes también desde fuera del servidor, y de forma oficial.
¿Cuál elegir? La regla es sencilla:
| Vía | Qué necesita | Qué alcanza | Ideal para |
|---|---|---|---|
| WP-CLI | Terminal local o SSH | Todo: base de datos, archivos, núcleo, plugins | Mantenimiento, migraciones, auditorías, desarrollo |
| REST API + Application Passwords | Solo un usuario del sitio | Lo que expone la API: contenido, medios, usuarios, taxonomías | Gestión de contenido en remoto sin SSH |
| MCP Adapter (Abilities API) | WordPress 6.9+ y exponer habilidades por código | Las habilidades que el sitio declara públicas | El puente oficial hacia los agentes; aún joven |
Para el trabajo serio de mantenimiento, hoy la respuesta es WP-CLI sin discusión: es la única vía que llega a la base de datos y a los archivos, que es donde viven los problemas de verdad.
Seguridad: darle las llaves sin perder el control
Conectar una IA a un WordPress en producción impone respeto, y debe imponerlo. Las tres reglas que aplicamos, en orden de importancia:
- Copia antes de tocar.
wp db exportantes de cualquier operación de escritura en la base de datos. Deshacer un desastre pasa a ser unwp db import: treinta segundos en lugar de una crisis. - Simulacro antes de ejecutar. Las operaciones masivas tienen modo de prueba:
wp search-replace --dry-runenseña qué cambiaría sin cambiar nada. La regla en nuestroCLAUDE.mdes literal: nunca un search-replace real sin su dry-run aprobado antes. - Permisos asimétricos. Lectura fluida, escritura con confirmación. Y para equipos, los hooks de Claude Code añaden una red determinista: un script propio puede vetar automáticamente cualquier comando que toque
@prod, contengadb dropo se salte el dry-run, por mucho que el asistente lo proponga.
Con ese método, el balance es el mismo que defendimos con MCP: son exactamente las precauciones que aplicarías al dar acceso a un técnico nuevo. La diferencia es que este técnico documenta cada comando que ejecuta.
Cuándo conviene (y cuándo no)
| Situación | ¿Claude Code + WP-CLI? |
|---|---|
| Mantenimiento periódico (copias, actualizaciones, limpieza) | Sí, es el caso de manual |
| Migraciones de dominio o de servidor | Sí: search-replace es oro |
| Auditar un sitio heredado o posiblemente comprometido | Sí, con trazabilidad completa |
| Cargar o transformar contenido a escala | Sí, en bucle desde tus archivos o datos |
| Desarrollo de temas y plugins a medida | Sí: el asistente escribe el PHP y lo prueba con el propio WP-CLI |
| Maquetar visualmente una página concreta | No: el editor visual sigue siendo más cómodo para eso |
| Sin SSH ni entorno local | Parcial: queda la vía REST, suficiente para contenido |
La regla que usamos, calcada a la de MCP: si una tarea de wp-admin se repite cada semana, es candidata a este flujo. Si es un retoque visual puntual, abre el editor y listo.
Por qué nos importa en una agencia
En yuGraphik defendemos las arquitecturas estáticas para muchos proyectos —lo argumentamos en Next.js vs WordPress—, pero la realidad del mercado es tozuda: una parte enorme de los negocios vive en WordPress y lo seguirá haciendo. Para esos sitios, la pareja Claude Code + WP-CLI cambia la economía del mantenimiento: las horas de clics repetitivos se convierten en conversaciones de minutos, y lo que se ahorra en rutina se invierte en lo que sí mueve la aguja, como el rendimiento —si tu WordPress suspende métricas, empieza por nuestra guía de Core Web Vitals— o el contenido.
Y hay un detalle que nos gusta especialmente: WP-CLI es infraestructura oficial, abierta y con quince años de madurez. Nada de este flujo depende de un plugin de moda ni de un servicio que pueda desaparecer: es la misma apuesta por los estándares duraderos que guía todo lo que construimos.
Conclusión
Conectar Claude Code con WordPress no requiere plugins, pasarelas ni configuración exótica: el puente lleva años instalado en la terminal y se llama WP-CLI. Con el asistente en la carpeta correcta, un CLAUDE.md con las reglas de la casa y los permisos bien puestos, el mantenimiento de un WordPress pasa de ser una lista de clics pendientes a una conversación con confirmaciones. Empieza por lo inofensivo —un inventario de plugins, una auditoría de salud— y ve subiendo con la confianza que dan las copias de seguridad.
Si gestionas uno o varios WordPress y quieres que este flujo trabaje para ti —del mantenimiento a la migración completa—, hablemos.
