Cómo conectar una IA (Claude) a tu WordPress y gestionarlo desde el chat

Una parte de mi web la gestiono así: le escribo a Claude "cambia el título del hero por X" o "publica este post con esta imagen destacada" y se hace. Sin abrir el panel de administración, sin buscar en qué página estaba ese texto, sin pelearme con el editor. En la home de farp.dev lo muestro como "IdeA" porque es exactamente eso: una idea que pasó de ocurrencia a flujo de trabajo diario.

Manos escribiendo en un portátil junto a un café: gestionar WordPress desde un chat con IA en lugar de wp-admin

Y lo interesante es que la base técnica no es ningún invento exótico: es la REST API de WordPress — que tu web ya tiene — más un sistema de credenciales llamado Application Passwords que WordPress trae de fábrica desde la versión 5.6 (2020). Lo que ha cambiado es que ahora las IAs pueden usar esa API como herramienta.

En esta guía te muestro los dos caminos para montarlo: uno sin escribir código (Claude Desktop + un servidor MCP) y uno para desarrolladores (scripts sobre la REST API). Y una sección de seguridad que no es adorno: le vas a dar a una IA la capacidad de modificar tu web, así que hay que hacerlo bien.

En pocas palabras: al terminar podrás pedirle a Claude cosas como "actualiza el título del post 123", "publica este borrador" o "lista los posts de la categoría X" desde el chat, con un usuario dedicado de permisos mínimos y credenciales revocables. Tiempo estimado: 30–45 minutos el camino sin código; 1–2 horas el camino dev. Nivel: básico-intermedio (el camino 1 no requiere programar).

Antes de empezar

Requisitos:

WordPress 5.6 o superior con HTTPS activo. Sin HTTPS no sigas: las credenciales viajarían en texto plano.
Acceso de administrador al WordPress (solo para crear el usuario dedicado; después no lo tocaremos más).
Para el camino 1: Claude Desktop instalado y Node.js 18+ en tu máquina.
Para el camino 2: saber JavaScript básico.

Cuándo NO hacerlo (honestamente):

Si tu web la gestiona alguien que no eres tú (una agencia, un freelance), coordina antes. Que aparezcan cambios "de la nada" en una web con más de un responsable es receta para desconfianza y para pisarse el trabajo.
Si tu WordPress está desactualizado o ya tienes dudas de su seguridad, arregla eso primero. Añadir una vía más de escritura a una instalación frágil es empeorar el problema; el suelo mínimo que doy por supuesto aquí está en seguridad web para pymes.
Si lo que buscas es que la IA publique contenido masivo sin supervisión, frena. Este flujo brilla para gestionar — cambios puntuales, publicar lo que tú ya revisaste, consultas — no para delegar el criterio editorial. La IA ejecuta; el criterio sigue siendo tuyo.
Si tu hosting bloquea la autenticación Basic (algunos compartidos lo hacen), tendrás un paso extra — te lo cuento en problemas comunes. No es bloqueante, pero conviene saberlo.

Paso 1: La base — un usuario dedicado con Application Password

Esto es común a ambos caminos y es donde se juega la seguridad de todo el montaje. No uses tu usuario administrador. Vamos a crear una identidad específica para la IA, con los permisos justos.

1.1 Crea el usuario con rol mínimo

En Usuarios → Añadir nuevo:

Nombre de usuario: algo identificable, por ejemplo claude-editor.
Email: uno tuyo (puede ser un alias tipo tu+claude@tudominio.com).
Rol: Editor si la IA va a gestionar contenido de cualquier autor; Autor si solo va a publicar posts propios y te basta con eso. Nunca Administrador.

La regla es simple: el rol define el techo de daño posible. Un Editor puede tocar contenido, pero no puede instalar plugins, cambiar temas, crear usuarios ni tocar ajustes del sitio. Si algo sale mal — un prompt confuso, una credencial filtrada — el radio de impacto queda acotado a contenido, que además es recuperable (WordPress guarda revisiones).

1.2 Genera la Application Password

Entra con ese usuario nuevo (o edita su perfil como admin) y baja hasta la sección Contraseñas de aplicación en su perfil. Escribe un nombre descriptivo — claude-desktop-mcp, por ejemplo — y pulsa "Añadir nueva contraseña de aplicación".

WordPress te mostrará una contraseña con este aspecto (una sola vez, cópiala ya):

AbCd EfGh IjKl MnOp QrSt UvWx

Puntos clave de por qué esto es mejor que usar tu contraseña normal:

No sirve para entrar a wp-admin. Solo funciona para la API. Aunque se filtre, nadie inicia sesión con ella en el panel.
Es revocable individualmente. Un clic en el perfil del usuario y esa credencial muere, sin afectar nada más.
Puedes crear una por herramienta (una para el MCP, otra para un script) y saber cuál revocar si algo huele mal.

Guárdala como un secreto: en tu gestor de contraseñas o en variables de entorno. Nunca en un archivo commiteado a git, nunca en un chat, nunca en el frontend.

Nota: si no ves la sección "Contraseñas de aplicación", tu sitio probablemente no está sirviendo por HTTPS, o un plugin de seguridad la desactivó. Ambas cosas tienen arreglo — mira problemas comunes.

Camino 1: Sin código — Claude Desktop + servidor MCP

MCP (Model Context Protocol) es, en dos líneas: un protocolo abierto para darle herramientas a una IA. Un "servidor MCP" expone acciones concretas — "listar posts", "actualizar post", "subir imagen" — y Claude las invoca cuando se lo pides en lenguaje natural.

Existen varios servidores MCP para WordPress publicados en npm (busca "wordpress mcp" en npmjs.com y revisa cuál está mantenido y qué permisos pide; algunos son de solo lectura, otros permiten escritura). Todos siguen el mismo patrón de configuración.

1. Localiza el archivo de configuración de Claude Desktop

Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

Si no existe, créalo.

2. Añade el servidor MCP de WordPress

La estructura es siempre command + args + env. Con un servidor hipotético llamado wordpress-mcp-server:

{
  "mcpServers": {
    "wordpress": {
      "command": "npx",
      "args": ["-y", "wordpress-mcp-server"],
      "env": {
        "WP_URL": "https://tusitio.com",
        "WP_USER": "claude-editor",
        "WP_APP_PASSWORD": "AbCd EfGh IjKl MnOp QrSt UvWx"
      }
    }
  }
}

Los nombres exactos de las variables (WP_URL, WP_USER, WP_APP_PASSWORD) dependen del servidor que elijas — revisa su README. El concepto no cambia: URL del sitio, usuario dedicado, Application Password.

3. Reinicia Claude Desktop y prueba

Cierra y abre Claude Desktop. Deberías ver el servidor conectado (icono de herramientas en el chat). Empieza con algo de solo lectura:

"Lista los últimos 5 posts de mi WordPress con su ID y estado."

Si responde con tus posts reales, está funcionando. Ahora una escritura controlada:

"En el post con ID 123, cambia el título a 'Nuevo título de prueba' pero déjalo como borrador."

Verifica en wp-admin que el cambio existe. A partir de aquí, el flujo es conversación normal: "publica el borrador X", "corrige la errata del segundo párrafo del post sobre precios", "crea un post borrador con este texto que te pego".

Un hábito que yo mantengo con clientes: las escrituras importantes pasan por borrador primero. Le pido a Claude que prepare el cambio como borrador, lo miro 30 segundos, y le digo "publícalo". Ese pequeño peaje evita casi todos los sustos.

Camino 2: Con código — la REST API directa

Si eres dev, entender la llamada desnuda te da control total: puedes montar tus propias herramientas, integrarlo en scripts o dárselo a Claude Code como comando. La autenticación es HTTP Basic con el usuario y la Application Password.

Actualizar un post

// update-post.mjs — Node 18+
const WP_URL = process.env.WP_URL;             // https://tusitio.com
const WP_USER = process.env.WP_USER;           // claude-editor
const WP_APP_PASSWORD = process.env.WP_APP_PASSWORD;

const auth = 'Basic ' + btoa(`${WP_USER}:${WP_APP_PASSWORD}`);

const res = await fetch(`${WP_URL}/wp-json/wp/v2/posts/123`, {
  method: 'POST',
  headers: {
    Authorization: auth,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    title: 'Título actualizado desde el chat',
  }),
});

if (!res.ok) {
  console.error(`Error ${res.status}:`, await res.text());
  process.exit(1);
}

const post = await res.json();
console.log(`OK — "${post.title.rendered}" (estado: ${post.status})`);

Detalles que importan:

La REST API de WordPress usa POST también para actualizar (acepta PUT y PATCH, pero POST es lo documentado y lo que siempre funciona).
En el body puedes enviar cualquier campo editable: title, content, excerpt, status (draft, publish), categories, tags...
Las Application Passwords se pueden enviar con o sin espacios; ambas formas validan.

Crear un post como borrador

const res = await fetch(`${WP_URL}/wp-json/wp/v2/posts`, {
  method: 'POST',
  headers: { Authorization: auth, 'Content-Type': 'application/json' },
  body: JSON.stringify({
    title: 'Post creado por la IA',
    content: '<p>Contenido del post…</p>',
    status: 'draft',          // borrador: siempre revisar antes de publicar
    categories: [4],          // IDs de categoría (GET /wp/v2/categories para verlos)
  }),
});

Con dos o tres scripts así (list-posts, update-post, create-draft) ya tienes un juego de herramientas que Claude Code puede ejecutar por ti: le describes qué hace cada script y él los invoca según lo que le pidas en el chat. Es, en esencia, construir tu propio mini-MCP. Este mismo patrón sirve para tocar páginas (/wp/v2/pages), medios (/wp/v2/media) o cualquier custom post type expuesto en la API — así es como funciona lo del "activa el banner": el banner es un campo de una página, y cambiar un campo es una llamada.

Este tipo de flujo, por cierto, es un ejemplo perfecto de que no todo necesita una app o un panel a medida: a veces la mejor interfaz es un chat sobre una API que ya existe. Escribí sobre esa lógica de decisión en cuándo necesitas una app y cuándo no. Y el mismo patrón —credenciales acotadas, permisos mínimos, una IA operando sobre una API real— se puede llevar más abajo, hasta el propio servidor: eso lo cuento en cómo conectar una IA a tu hosting cPanel.

Seguridad: la sección que no puedes saltarte

Le estás dando a un sistema automatizado capacidad de escritura sobre tu web pública. Esto no es paranoia, es higiene básica:

Permisos mínimos, siempre. Usuario dedicado con rol Editor o Autor. Nunca le des a la IA credenciales de un administrador si solo va a editar contenido. La diferencia entre "un post quedó mal" y "instalaron un plugin malicioso" es exactamente esa decisión.
Application Password, nunca la contraseña principal. La contraseña de tu usuario abre wp-admin entero; la Application Password solo abre la API y se revoca en un clic. Si alguna vez pegaste la app password donde no debías, revócala y genera otra — cuesta 20 segundos.
HTTPS obligatorio. Basic Auth envía las credenciales codificadas en base64, que NO es cifrado — cualquiera que intercepte el tráfico las lee. HTTPS es lo que las protege. WordPress, de hecho, rechaza Application Passwords sobre HTTP plano por defecto, y hace bien.
Registra los cambios. Un plugin de auditoría tipo Simple History o WP Activity Log te muestra qué hizo el usuario claude-editor y cuándo. Si un día ves un cambio que no reconoces, tienes trazabilidad y un botón de revocar. Las revisiones de WordPress, además, te dejan revertir cualquier edición de contenido.
Revisa antes de publicar cambios masivos. "Actualiza el precio en los 40 posts que lo mencionan" es una orden tentadora y peligrosa: un malentendido se multiplica por 40. Mi regla: cambios masivos van a borrador o se ejecutan sobre 2–3 posts primero, se revisan, y luego se lanza el resto. La IA es rápida; tu revisión es lo que la hace segura.
Rota y limpia. Si dejas de usar una herramienta, revoca su Application Password. Credencial que no se usa es credencial que solo puede darte problemas.

Problemas comunes

Error 401 aunque las credenciales son correctas. El clásico. Muchos hostings compartidos (y algunas configuraciones de Apache con CGI/FastCGI) descartan la cabecera Authorization antes de que llegue a WordPress. Soluciones, de menos a más invasiva: añade esto al .htaccess:

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

Si no puedes tocar el .htaccess, algunos servidores MCP y scripts permiten pasar la credencial por una cabecera alternativa, o puedes usar un plugin de autenticación para la API. Y verifica lo obvio: que el usuario y la password no tengan errores de copia (los espacios de la app password son válidos, pero un carácter perdido no).

Error 401 con mensaje sobre "application passwords not available". HTTPS no está activo o un plugin de seguridad (Wordfence y similares) desactivó las Application Passwords. Actívalas en la configuración del plugin.

Hago un cambio y la web no lo muestra. Tu plugin de caché (o el caché del hosting/CDN) sigue sirviendo la versión anterior. El cambio SÍ está hecho — compruébalo en wp-admin. Purga la caché o configura el plugin para purgar al actualizar contenido. Con Cloudflare delante, revisa también su caché.

Error 403 "Sorry, you are not allowed to edit this post". El rol del usuario no alcanza. Un Autor no puede editar posts de otros usuarios ni páginas; para eso necesitas Editor. Sube el rol solo si de verdad lo necesitas — recuerda el principio de mínimos.

Claude Desktop no muestra el servidor MCP. JSON inválido en el config (una coma de más es lo típico — pásalo por un validador), Node.js no instalado o no en el PATH, o no reiniciaste la app del todo (ciérrala desde la bandeja del sistema, no solo la ventana).

Preguntas frecuentes

¿Esto funciona con ChatGPT u otras IAs? El lado WordPress es agnóstico: Application Passwords + REST API funcionan con cualquier cliente. El camino MCP es el ecosistema de Claude (Desktop y Claude Code); otras plataformas tienen sus mecanismos equivalentes (GPTs con Actions, por ejemplo) apuntando a la misma API. Los principios de seguridad no cambian ni un milímetro.

¿Puede la IA romperme la web? Con el montaje de esta guía, el peor caso realista es contenido mal editado — que se revierte con las revisiones de WordPress. No puede tocar plugins, temas ni configuración porque el usuario no tiene esos permisos. Ese es exactamente el motivo de no usar un usuario administrador: no le des la capacidad de romper lo que no necesita tocar.

¿Y si quiero que también gestione WooCommerce, formularios o campos personalizados? Se puede: WooCommerce tiene su propia REST API (con sus propias claves), y los custom fields se exponen vía register_meta o plugins como ACF con su extensión de REST. Pero cada superficie nueva que abres merece la misma pregunta: ¿qué permisos mínimos necesita y qué pasa si se usa mal? Empieza con posts y páginas, coge confianza con el flujo, y amplía después.

Este flujo me ahorra horas cada mes, y montarlo bien la primera vez es lo que lo hace tranquilo de usar. Si prefieres que esto lo hagamos juntos, una consultoría 1:1 de $60 y salimos con el plan.