WP-CLI: cómo conectar Claude Code con WordPress

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.

Cómo instalar WP-CLI en el servidor (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.)

Cómo conectar Claude Code con WordPress: una carpeta y tres archivos

Para conectar Claude Code con WordPress hacen falta exactamente tres piezas: Claude Code en tu ordenador, WP-CLI en ambos extremos y un alias SSH que apunte al servidor. Sin plugins, sin pasarelas, sin servicios intermedios: la conexión es la propia terminal.

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 para el sitio —no hace falta tener ahí ni un solo archivo de WordPress— y dentro van tres archivos pequeños que responden a tres preguntas: dónde está el sitio, cómo hay que tratarlo y qué puede tocar el asistente sin preguntar. Los vemos uno a uno.

Antes, el único requisito previo: instala WP-CLI también en tu ordenador, aunque ahí no haya ningún WordPress. Actúa de mensajero: cuando Claude Code ejecuta un comando, el WP-CLI de tu máquina abre la conexión SSH y se lo entrega al WP-CLI del servidor, que es quien de verdad trabaja. Y al asistente no hay que explicarle nada de la herramienta: la conoce de sobra.

1. wp-cli.yml: dónde está tu WordPress

El primer archivo responde a la pregunta más básica. Define un alias: un apodo corto —aquí @prod, de producción— que guarda la dirección completa del servidor para que no haya que volver a escribirla:

@prod:
  ssh: deploy@cliente.com/var/www/cliente.com

Desde ese momento, cualquier comando llega al servidor anteponiendo el apodo: wp @prod plugin list lista los plugins del sitio real desde tu terminal. Solo hacen falta dos cosas: que el servidor tenga WP-CLI instalado (los hostings gestionados suelen traerlo) y que tu clave SSH tenga acceso.

2. CLAUDE.md: cómo hay que tratar el sitio

El segundo archivo es el que Claude Code lee al arrancar cada sesión: las reglas de la casa, escritas en lenguaje normal, sin sintaxis que aprender. 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`

3. settings.json: qué puede tocar sin preguntar

El tercer archivo, .claude/settings.json, es la política de permisos: gobierna cada comando con tres estados —preguntar, permitir o denegar—. La configuración sensata para WordPress es asimétrica: consultar es libre; tocar, pide permiso.

{
  "permissions": {
    "allow": [
      "Bash(wp plugin list:*)",
      "Bash(wp theme list:*)",
      "Bash(wp user list:*)",
      "Bash(wp post list:*)"
    ],
    "deny": [
      "Bash(wp db drop:*)",
      "Bash(wp db reset:*)"
    ]
  }
}

Todo lo que no aparece en la lista —cualquier comando que escriba, actualice o borre— cae en el estado por defecto: preguntar. Diez segundos de revisión antes de un wp plugin update --all en producción es un seguro barato.

Y ya está: una carpeta y tres archivos. Abres Claude Code ahí, pides en lenguaje natural, y cada comando wp viaja por SSH hasta el servidor, se ejecuta y devuelve su resultado a la conversación.

Los alias SSH de WP-CLI: de un sitio a toda la cartera

El alias @prod que acabamos de definir es la versión mínima de un mecanismo pensado para crecer. ¿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.

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

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.

Qué puede hacer Claude Code con WP-CLI: peticiones reales y lo que ocurre por debajo

La teoría se entiende mejor con encargos concretos. Estos son los que más repetimos:

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:

---
name: mantenimiento-wordpress
description: Rutinas de mantenimiento de WordPress con WP-CLI. Usar al
  actualizar, hacer copias, migrar o diagnosticar un sitio WordPress.
---

# Skill: mantenimiento WordPress

## Rutina de actualización
1. `wp db export` antes de tocar nada
2. Actualizar núcleo, plugins y temas
3. Comprobar la portada, una entrada y el formulario de contacto
4. 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 stage` y señala la fase más lenta antes de proponer nada

Dos detalles hacen que funcione: el archivo se guarda como SKILL.md dentro de ~/.claude/skills/mantenimiento-wordpress/, en tu ordenador y fuera de cualquier proyecto; y la description del encabezado es lo que Claude Code lee para decidir cuándo cargarla: descríbela bien y la skill aparecerá sola cada vez que la conversación toque WordPress.

¿Y en qué se diferencia esto del CLAUDE.md, si ambos son Markdown que Claude Code lee? En tres cosas. El cuándo: el CLAUDE.md se carga entero en cada sesión, sea relevante o no; la skill, solo cuando la tarea lo pide. El dónde: el archivo vive en la carpeta de un proyecto; la skill, fuera de todos, así que aplica en cualquiera. Y el qué: al CLAUDE.md le van los hechos y las líneas rojas de ese sitio; a la skill, el oficio reutilizable. En corto: el CLAUDE.md es el contrato con un sitio; la skill es tu forma de trabajar, y 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: la skill es el conocimiento; WP-CLI, las manos.

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:

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.

Cuándo usar Claude Code con WP-CLI (y cuándo no)

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.