Le Di a Claude Code una Contraseña de WordPress y Una Oración. Gestionó Todo el Sitio.
Un cliente me envía un email. Nada dramático: cambiar la bandera de España por la de México en el selector de idiomas de su sitio de WordPress. El típico encargo que no haces todos los días y que puede quemarte toda la mañana.
Hace siglos que no toco este sitio. Lo construyó un freelancer hace años. Ni siquiera recuerdo cómo configuró la internacionalización. Y sinceramente, no me apetece nada.
Entonces se me ocurrió una idea. ¿Y si Claude Code pudiera... simplemente encargarse de esto?
Así que hice lo obvio: generé una contraseña de aplicación de WordPress, se la pasé a Claude Code junto con la URL del sitio y la petición del cliente, y me fui a hacer otra cosa.
TL;DR: Claude Code encontró Polylang por su cuenta, cambió la bandera, purgó la caché de Elementor, verificó el front-end. Nunca mencioné qué plugin gestionaba los idiomas. Después auditó el resto del sitio. Luego abrí mis otros 54 sitios de clientes. Lo que era una lata se convirtió en un flujo de trabajo.
El Ticket de Cliente Que Casi Ignoré
La petición era bastante simple. El cliente tiene un sitio bilingüe (español/inglés), y el selector de idiomas muestra una bandera de España para la versión en español. Quieren la bandera mexicana en su lugar. Tiene todo el sentido para su audiencia.
Normalmente, te logueas, encuentras la configuración del plugin de traducción, localizas la configuración de banderas, la cambias, purgas la caché que esté funcionando, revisas el front-end, respondes al cliente. Veinte minutos si conoces el sitio. Cuarenta y cinco si no.
Yo no conocía este sitio. Se lo subcontracté a un freelancer hace dos o tres años. No recuerdo qué usó para las traducciones, qué page builder hay ahí dentro, qué plugin de caché está funcionando. Todo el mise en place de una instalación de WordPress de otra persona, y se supone que tengo que meterme a ciegas.
Así que en lugar de logearme en wp-admin como un adulto responsable, fui a Configuración > Usuarios > Contraseñas de Aplicación. Treinta segundos. Pegué la URL, la contraseña de aplicación, y el email del cliente en Claude Code. Una frase de contexto de mi parte: "encárgate de esto."
Y me largué.
Le di las llaves. No le dije qué tipo de coche era.
Encontró Polylang. Nunca Dije Polylang.
Bandera cambiada. Caché purgada. Front-end verificado. Cinco minutos en total. Ese es el resultado.
La transcripción cuenta una historia diferente a la que esperaba (la leí después del hecho, porque en ese momento estaba en otro lado completamente).
Claude Code obtuvo el código fuente HTML del sitio. Detectó una clase CSS: cpel-switcher__flag--es. Solo con esa clase, dedujo que Polylang estaba manejando las traducciones. Consultó /pll/v1/languages vía la REST API, encontró la entrada de idioma para español, cambió flag_code de es a mx vía PUT, y después fue por la caché.
La parte de la caché fue un lío (como siempre es con Elementor). Claude Code probó varios endpoints antes de encontrar el que realmente activaba una purga. Después obtuvo el HTML del front-end otra vez y ejecutó un grep en las clases para confirmar que la nueva bandera estaba activa.
Nota honesta: Claude Code no lo clavó al primer intento. Inicialmente trató de abrir Chrome y loguearse a través del formulario de wp-admin. Tenía la contraseña de aplicación pero la interpretó como credenciales normales. Envié una corrección: "usa la REST API, no el navegador." Una frase. Después de eso, completamente autónomo.
Infirió todo el stack desde HTML crudo. Yo habría gastado diez minutos solo haciendo clic por los paneles de configuración.
Después Pregunté Si Algo Estaba Mal. Eso Fue Un Error.
La bandera estaba lista. Pero aún tenía Claude Code conectado al sitio, y soy el tipo de persona que no puede dejar una herramienta funcionando sin curiosear. Así que escribí: "ya que estás ahí, ¿algo se ve mal? Solo lectura. No cambies nada."
Esperaba tal vez un alt tag faltante. Un plugin desactualizado. Algo educado.
Tres minutos después: ocho problemas. Y no del tipo cosmético.
Sitemap XML incompleto: las páginas mexicanas estaban completamente ausentes. En un sitio comercial bilingüe, eso es tu SEO para la mitad de tu contenido simplemente... no indexado. Ningún plugin de SEO instalado en absoluto. Página titulada "About US" donde las mayúsculas hacían que se leyera como "Estados Unidos" (probablemente un remanente de tres rediseños que nadie detectó). Traducciones de Polylang no enlazadas correctamente, lo que significa que el selector de idiomas enviaba a los usuarios a la homepage del otro idioma en lugar de la página traducida en la que realmente estaban. Headers de seguridad ausentes en todo el sitio: no HSTS, no X-Frame-Options, no CSP. El nombre de usuario admin era literalmente admin. Un archivo ZIP aleatorio en la biblioteca de medios que nadie podía explicar. Y una página mexicana sin equivalente en inglés, rompiendo la estructura bilingüe.
Esto es lo que hizo esto incómodo: yo soy quien se supone que mantiene este sitio. Estos problemas estuvieron ahí todo el tiempo. Un cliente pagando por mantenimiento, y el contratista (y después yo, por extensión) se había perdido todo esto. Claude Code lo encontró en tres minutos consultando metódicamente cada endpoint REST y comparando lo que debería existir contra lo que realmente existe.
Un consultor de WordPress cobra mínimo 2 horas por este tipo de auditoría. Algunas agencias lo empaquetan como un entregable independiente.
Esto costó una frase que escribí por capricho.
Por Qué Esto Funciona en Cualquier Sitio de WordPress Que Nunca Hayas Tocado
La WordPress REST API no es una característica. Es todo el sitio, expuesto como endpoints, nativamente, desde la versión 5.6. Y eso cambia lo que realmente significa "darle acceso a una IA".
No hay plugin que instalar. No hay servidor MCP que levantar. No hay archivo de configuración, no hay contenedor Docker, no hay nada. La API ya está funcionando en cada sitio de WordPress que no la haya deshabilitado explícitamente (casi ninguno lo hace). Posts, páginas, medios, usuarios, plugins, configuración del sitio. Y el ecosistema siguió: Polylang incluye /pll/v1/. WooCommerce incluye /wc/v3/. Yoast, RankMath, mismo patrón. Todo documentado, todo consultable.
Una contraseña de aplicación le da al portador exactamente los mismos permisos que el usuario de WordPress que la generó. Esa es toda la configuración. Treinta segundos en wp-admin. No hay baile OAuth. No hay dashboard de API key. No hay registro de webhook.
Ahora combina eso con lo que Claude Code ya hace bien: leer documentación, explorar superficies de API, inferir contexto desde respuestas. Lee el HTML del sitio, detecta Polylang desde una clase CSS, consulta el endpoint correcto, valida el resultado. Este es el mismo patrón que el servidor MCP de n8n que le da a Claude Code acceso estructurado a la API completa de n8n, con autonomía completa y cero UI. Excepto que con WordPress no instalas nada. Ha estado ahí por años, a plena vista.
El puente entre Claude Code y WordPress ha existido desde 2021. Apenas nos dimos cuenta.
Tenía 54 Sitios Más. Esto Es Lo Que Pasó.
Gestiono 54+ sitios de clientes. La sesión de la bandera tomó menos de diez minutos. Así que seguí, y durante los siguientes días ejecuté tres pruebas reales en diferentes sitios.
Actualizaciones de contenido y creación de artículos. Claude Code lee páginas existentes vía la API, capta el tono y estructura de lo que ya está publicado, genera contenido que coincide, y lo empuja vía POST/PUT en /wp/v2/posts y /wp/v2/pages. No wp-admin, no copy-paste en Gutenberg, no reformateo. Entra un brief de una línea, sale una página publicada.
Actualizaciones masivas de alt-tags. Claude Code obtuvo todos los medios vía /wp/v2/media, identificó cada imagen con texto alt faltante o vacío, y las actualizó lote por lote. Un sitio tenía 200+ imágenes. Eso es una tarde haciendo clic por la biblioteca de medios, escribiendo texto alt uno por uno, guardando, scrolleando, siguiente. Una sesión lo manejó.
Endurecimiento de seguridad. Renombrar el nombre de usuario admin predecible, revisar headers de respuesta, auditar permisos y roles de usuario. Las cosas que viven en tu lista de "lo haré el próximo mes" para cada sitio de cliente que gestionas.
Esto es lo que solo te pega cuando ves el panorama completo: ninguna de estas tareas es difícil individualmente. Cualquier dev puede actualizar alt tags. Cualquier dev puede renombrar un usuario admin. El problema nunca fue la dificultad. Era que hacerlo en un sitio está bien, hacerlo en 54 sitios es una razón de ser para la procrastinación. La API convierte cada tarea en una sesión repetible. Claude Code convierte la sesión en un lote. La multiplicación es lo que importa, no la unidad.
Divulgación honesta: probé los flujos de trabajo de contenido y alt-tags en 3-4 sitios, no en los 54. Pero el patrón se mantuvo idénticamente cada vez, y escalar al portafolio completo es aritmética a este punto, no especulación.
54 sitios. Antes: una lata por sitio. Ahora: una sesión por lote.
La Parte Que Nadie Te Dice Sobre Darle Acceso de Admin a una IA
Bueno. Hablemos de lo que ya estás pensando.
Una contraseña de aplicación con privilegios de admin da acceso completo de escritura a través de la REST API. Completo. Eso significa crear, modificar y eliminar contenido. En una petición ambigua como "limpia medios no utilizados," Claude Code podría interpretar "limpia" más generosamente de lo que pretendías.
En una prueba, le pedí a Claude Code que "revisara y organizara la biblioteca de medios." Marcó archivos para posible eliminación y preguntó antes de proceder. Fue cauteloso. Pero cauteloso es un comportamiento, no un contrato. El modelo decide cómo interpretar tu petición, y no siempre controlas esa interpretación por adelantado.
Regla innegociable: backup completo antes de cualquier sesión. O trabaja en staging. Elige uno.
Segunda cosa: deriva de alcance. La sesión de la bandera lo mostró claramente. Claude Code trató el login del navegador antes de que lo corrigiera. Sin un perímetro explícito en el prompt, explorará lo que pueda acceder, y esa superficie podría ser más amplia de lo que esperabas.
Esto es exactamente donde definir el alcance de ejecución antes de lanzar Claude Code en un sitio de cliente marca la diferencia entre una sesión fluida y un incidente. "Modifica solo la configuración de Polylang. No toques el contenido de páginas." Ese tipo de límite explícito.
Una cosa más que la REST API no cubre: archivos PHP, código de tema, WordPress core. Para eso necesitas acceso SSH. Claude Code sabe esto y lo dice cuando se topa con esa pared.
La contraseña de aplicación te da las llaves del camión. Mejor que hayas dicho a dónde vas antes de encender el motor.
El próximo año alguien lanzará un plugin de WordPress a $29/mes que hace exactamente esto. UI limpia. Onboarding de siete pasos. La gente pagará.
Mientras tanto, la REST API ha estado ahí desde 2021. La contraseña de aplicación toma treinta segundos. Claude Code se encarga del resto. Sin plugin. Sin configuración. Sin suscripción.
(¿Y para la rotación de contraseñas de aplicación en todos tus sitios? Solo le pides a Chrome en Claude que las genere en lotes. Shh.) 🤫
Fuentes
WordPress REST API Handbook: developer.wordpress.org/rest-api
Si tu flujo de trabajo involucra más Claude Code que Stack Overflow estos días, escribo sobre los patrones que realmente funcionan. Sígueme si ese es tu tipo de lectura.
(*) La portada es generada por IA. Las banderas son precisas, lo cual me sorprendió más que el artículo mismo.
Cuando un cambio simple de WordPress se convierte en una lección de automatización inteligente con AI. Descubre cómo transformar tareas repetitivas en flujos autónomos.