Conectar Claude a WordPress: ejecuta WP-CLI y comprueba cada cambio con Relvato

Dos mitades: cambiar el sitio y comprobarlo

WP-CLI es la línea de comandos de WordPress. Lista plugins, los actualiza, exporta la base de datos, compara los archivos del núcleo con WordPress.org y mucho más. Es la forma en que un asistente cambia un sitio. Lo que no puede mostrarte es el sitio tal como lo ve un visitante: si el checkout sigue cobrando, si el formulario de inicio de sesión sigue enviándose, si una página sigue siendo rápida.

Ese es el hueco detrás de casi todas las historias de «una actualización me rompió el sitio»: la actualización informa de que todo ha ido bien, y el fallo está en otra parte, en un formulario, un script o una plantilla. Relvato comprueba exactamente eso, en un navegador real, desde fuera. A través de su conector, un asistente puede pedir el estado de un sitio (site_overview), lanzar comprobaciones ahora (trigger_scan), leer una ejecución en detalle (get_run) y obtener el informe que explica un fallo (get_fix_prompt).

Juntos forman un ciclo: cambiar algo con WP-CLI, comprobarlo con Relvato y leer el resultado antes de seguir, en la misma conversación.

Qué puede hacer cada Claude

Claude Code, en la terminal o dentro de la app de escritorio de Claude, puede ejecutar comandos de shell. Puede ejecutar WP-CLI contra un sitio local o, por SSH, contra uno remoto. Es la forma más directa de conectar Claude a WordPress.

Claude en la web, en el móvil y en el chat de escritorio no puede ejecutar una shell. Para cambiar un sitio desde ahí, usa el MCP Adapter de WordPress por HTTPS o, para sitios alojados en WordPress.com, su propio conector. El conector de Relvato funciona en todas las superficies de Claude.

Paso 1: añade el conector de Relvato

En Claude, abre Settings → Connectors, busca Relvato (o abre su página en el directorio), haz clic en Connect e inicia sesión en Relvato. En la pantalla de consentimiento permites al asistente leer tus sitios y resultados y hacer cambios: añadir sitios y comprobaciones, cambiar horarios y lanzar escaneos. Si perteneces a una organización, eliges cuál de sus espacios de trabajo puede usar.

En Claude Code, añade el servidor con un comando e inicia sesión cuando te lo pida. Los clientes que no pueden iniciar sesión pueden usar una clave de API de Relvato. La página para desarrolladores tiene ambas opciones.

# Claude Code: añade Relvato, luego ejecuta /mcp dentro de Claude Code y elige Authenticate
claude mcp add --transport http relvato https://app.relvato.com/api/mcp

Paso 2: dale WP-CLI por SSH

WP-CLI puede ejecutar comandos en un servidor remoto por SSH. Pon alias de tus sitios en un wp-cli.yml en la carpeta desde la que arrancas Claude Code, y cada comando indica el sitio al que va. WP-CLI tiene que estar instalado en el servidor y accesible como wp para el usuario SSH, y tu clave SSH tiene que funcionar sin pedir contraseña.

Empieza con una copia de staging. Comprueba primero la conexión con un comando inofensivo: wp @staging core version debería mostrar tu versión de WordPress.

# wp-cli.yml
@staging:
  ssh: deploy@staging.example.com/var/www/html
@prod:
  ssh: deploy@example.com/var/www/html

# comprueba la conexión
wp @staging core version

Paso 3: decide qué puede ejecutar sin preguntar

Por defecto, Claude Code pregunta antes de cada comando nuevo. En .claude/settings.json puedes aprobar de antemano los de solo lectura, dejar los cambios detrás de una confirmación y prohibir del todo los destructivos. Las reglas deny siempre ganan a las allow.

Dos precauciones. Las reglas coinciden con el comando tal como está escrito, así que wp @staging plugin list y wp @prod plugin list son reglas distintas. Y la propia documentación de Claude Code califica de frágiles las reglas que intentan fijar los argumentos de un comando. Tómalas como un cinturón de seguridad, no como un candado: el límite real es lo que el usuario SSH puede hacer en el servidor.

{
  "permissions": {
    "allow": [
      "Bash(wp @staging core version)",
      "Bash(wp @staging plugin list *)",
      "Bash(wp @staging plugin update * --dry-run)"
    ],
    "ask": [
      "Bash(wp @staging plugin update *)",
      "Bash(wp @staging db export *)"
    ],
    "deny": [
      "Bash(wp * db drop *)",
      "Bash(wp * db reset *)",
      "Bash(wp * eval *)",
      "Bash(wp * search-replace *)"
    ]
  }
}

Un caso real: actualizar plugins sin romper el checkout

Así funciona el ciclo en la práctica, primero en staging. Pregunta a Claude qué plugins están desactualizados. Ejecuta wp @staging plugin list --update=available. Después pide a Relvato el estado del sitio antes de tocar nada (site_overview), para tener una referencia con la que comparar.

Haz una copia de seguridad (wp @staging db export) y previsualiza la actualización (--dry-run). Actualiza un plugin, pide a Relvato que lance ahora las comprobaciones del sitio (trigger_scan) y lee los resultados (get_run). Si falla el checkout, el inicio de sesión o un formulario, get_fix_prompt devuelve el mismo informe con el que trabaja la IA de Relvato: el stack del sitio, qué cambió justo antes y el error exacto. Claude puede razonar sobre la causa y, si hace falta, devolver el plugin a la versión anterior con WP-CLI.

Solo cuando staging está limpio lo repites en producción. Si el plugin de Relvato está conectado, Relvato también vuelve a lanzar comprobaciones por sí solo tras las actualizaciones de plugins. Preguntar en la conversación te da la respuesta mientras sigues ahí.

Termina con comprobaciones de integridad que WP-CLI puede hacer por sí mismo: wp core verify-checksums compara los archivos del núcleo con WordPress.org, y wp plugin verify-checksums --all hace lo mismo con los plugins de WordPress.org. Los plugins premium no se pueden verificar así.

wp @staging plugin list --update=available
wp @staging db export
wp @staging plugin update woocommerce --dry-run
wp @staging plugin update woocommerce
#  → Relvato: trigger_scan, luego get_run
#  → si algo falló: get_fix_prompt, y vuelve atrás:
wp @staging plugin install woocommerce --version=<versión anterior> --force
wp @staging core verify-checksums
wp @staging plugin verify-checksums --all

Sin terminal: el WordPress MCP Adapter

WordPress 6.9 añadió la Abilities API, una forma estándar de que los plugins describan lo que pueden hacer. El MCP Adapter, un plugin oficial separado del núcleo y todavía anterior a su versión 1.0, expone esas capacidades a los asistentes de IA como un servidor MCP. El plugin anterior de Automattic, wordpress-mcp, está archivado en su favor.

El adaptador habla con clientes locales a través de WP-CLI (wp mcp-adapter serve) y con remotos por HTTPS en /wp-json/mcp/mcp-adapter-default-server, autenticándose con una contraseña de aplicación de WordPress. Solo se exponen las capacidades que un plugin marca como públicas, así que lo que puede hacer el asistente depende de lo que publiquen tus plugins. WooCommerce tiene una vista previa para desarrolladores basada en él, para productos y pedidos.

Dale un usuario de WordPress propio con el menor acceso necesario, no tu cuenta de administrador, y revoca la contraseña de aplicación cuando termines. Los sitios en WordPress.com pueden usar en su lugar el conector MCP de WordPress.com, en los planes de pago.

wp plugin install https://github.com/WordPress/mcp-adapter/releases/latest/download/mcp-adapter.zip --activate

# Claude Code, conectado a un sitio local a través de WP-CLI
claude mcp add wordpress -- wp --path=/var/www/html mcp-adapter serve --server=mcp-adapter-default-server --user=ai-editor

Salvaguardas que importan más que el prompt

Un asistente es exactamente tan seguro como la cuenta con la que actúa. Usa primero una copia de staging, una copia de seguridad antes de cada cambio y un usuario SSH y de WordPress con solo el acceso que la tarea necesita. Deja los cambios detrás de una confirmación, y no uses Claude Code con las confirmaciones desactivadas en un sitio en producción: su documentación lo reserva para contenedores y máquinas virtuales aislados.

Comprueba después de cada cambio, no solo antes. WP-CLI puede decirte que una actualización ha terminado. Solo una comprobación desde fuera te dice que el sitio sigue funcionando para quienes lo usan. Por eso el conector de Relvato está hecho para este ciclo, y por eso deliberadamente no puede borrar datos, aceptar cambios visuales, aplicar correcciones ni tocar claves de API: eso se queda en el panel de Relvato, donde lo revisas tú.