Cómo reetiquetar posts antiguos en varios idiomas en WordPress con la IA de Codex

Hace poco me enfrenté a un reto nuevo para mí: cómo añadir una etiqueta nueva  -en mi caso “ciencia ficción”- a todos los artículos, tanto en español como en el resto de idiomas. 

Es decir, casi 3.000 artículos que había que:

• Analizar para ver en cuáles casaba bien la tag.
• Añadir la etiqueta en su correspondiente idioma a cada uno sin borrar el resto de etiquetas.
• Comprobar que todo había ido bien.

Crear la etiqueta en cada idioma no tenía ningún misterio con el desarrollo que le tengo metido. El problema es etiquetar solo los artículos antiguos que deberían llevarla.

Se podría hacer a mano, claro, pero revisando el contenido terminé con una lista de 12 artículos en español. Eso significa que, como tengo traducción a diez idiomas en la web, tenía que etiquetar un total de 120 posts.

Y lo de buscar cada entrada en su idioma, abrirla y añadir la etiqueta 120 veces, una tras otra, no lo veía, la verdad.

Así que se me ocurrió que era una tarea bastante apropiada para Codex.

Porque además quería usar este caso, bastante sencillo, como base para algo mucho más general: aplicar cambios a muchos artículos de forma automática, pero sin dejar que el agente haga cambios por su cuenta y a lo loco.

Eso es precisamente lo que te explico en este tutorial.

Objetivo

Sencillo: añadir una determinada etiqueta a una lista de posts concreta de WordPress.

Incluyendo la traducción correspondiente de esa etiqueta a cada versión lingüística del artículo, con Polylang, que es el plugin multi idioma que uso yo.

Y vamos a hacerlo no a salto de mata sino con unas cuantas precauciones:

• Trabajaremos sobre una lista cerrada de artículos.
• Comprobaremos primero qué va a modificar Codex.
• No crearemos etiquetas nuevas automáticamente.
• Conservaremos todas las etiquetas que ya tenga cada post.
• Haremos una simulación antes de escribir.
• Volveremos a chequear WordPress después para comprobar el resultado.

No necesitas que tu caso sea exactamente como el mío. Basta con que quieras cambiar algo en una serie de post determinados en WordPress que manualmente te costaría un buen rato.

Por otro lado, yo uso Codex, pero el proceso se puede seguir igual si prefieres usar Claude Code o Antigravity. Cambia la herramienta, los pasos no.

Paso 1. Crea la etiqueta antes de empezar

Lo primero es tener creada en WordPress la etiqueta que quieres aplicar.

Esto conviene hacerlo manualmente porque no es mi intención que Codex decida cómo debe organizarse la taxonomía de la web. Queremos que se limite a localizar algo que ya existe y asignarlo a determinados posts.

En WordPress, ya sabes, puedes hacerlo desde:

Entradas > Etiquetas

Si tu web tiene un solo idioma, con esto prácticamente has terminado este paso.

Si utilizas Polylang (versión Pro o con desarrollo propio por encima, que es mi caso), crea también las traducciones de la etiqueta y comprueba que están correctamente vinculadas.

Por ejemplo, en mi ejemplo tenía:

• Ciencia Ficción.
• Science Fiction.
• Science-fiction.
• Science-Fiction.
• Fantascienza.
• …

Así sucesivamente.

WordPress las guarda internamente como términos (etiquetas) diferentes y cada una tendrá su propio ID. Eso será importante más adelante.

Un apunte aquí: yo tengo un plugin de desarrollo propio que me las crea automáticamente en todos los idiomas, pero tú probablemente tengas que crearlas manualmente, una a una por idioma.

Prompt para comprobar las etiquetas

Cuando ya las tengas creadas, puedes pedir a Codex que las localice:

Quiero añadir una etiqueta ya existente a varios posts de WordPress.

La etiqueta principal es:

[NOMBRE DE LA ETIQUETA]

Por ahora no modifiques ningún dato.

Localiza la etiqueta en WordPress y, si la web utiliza Polylang, todas sus traducciones.

Devuélveme para cada idioma:

– idioma;

– nombre de la etiqueta;

– slug;

– term ID.

No crees etiquetas nuevas.

Si falta alguna traducción, hay duplicados o existe cualquier ambigüedad, detente y avísame.

El term ID es simplemente el número con el que WordPress identifica internamente esa etiqueta. Lo importante es que Codex sepa qué ID corresponde a cada idioma.

Paso 2. Prepara una lista cerrada de artículos

Ahora tenemos que decidir qué posts queremos modificar.

Aquí recomiendo no dejar demasiada libertad al agente.

Podríamos pedirle:

Busca todos los artículos relacionados con ciencia ficción y etiquétalos.

Pero entonces estaríamos mezclando dos tareas muy distintas:

1. Decidir editorialmente qué contenidos deberían llevar la etiqueta.
2. Realizar 20, 100 o 500 veces la misma modificación en WordPress.

Yo prefiero separar ambas para ir controlando cada paso.

Puedes hacer el listado manualmente si el volumen de articulos no es muy alto.

También puedes utilizar ChatGPT o Codex para ayudarte a localizar candidatos.

En mi caso, como el volumen era grande, le pasé los tres sitemaps de artículos que tengo y le pedí a ChatGPT que, en base a la URL, me diera sus candidatos.

Lo hagas como lo hagas, deberías terminar con una lista concreta de artículos antes de modificar nada.

Por ejemplo:

• Blade Runner: crítica y análisis.
• Los mejores cómics de ciencia ficción.
• Akira: manga y película.
• El Eternauta: reseña de la serie.
• …

Yo como te he dicho acabé con 12 artículos por idioma, eliminando algún candidato que a ChatGPT le parecía adecuado pero a mí no.

Prompt para preparar el conjunto de trabajo

Una vez tengas la lista, chútale esto a Codex:

Voy a proporcionarte una lista cerrada de artículos de WordPress.

Trabaja exclusivamente sobre estos artículos.

No añadas otros contenidos aunque consideres que también podrían encajar con la etiqueta.

Lista:

[PEGA AQUÍ LOS TÍTULOS O URL]

Por ahora no hagas ninguna modificación.

Localiza cada post y devuelve:

– título;

– URL;

– post ID;

– estado;

– idioma.

Si alguno no puede identificarse de forma inequívoca, detente y señálalo.

Con esto ya tenemos definidos los dos extremos de la operación:

1. Qué posts queremos etiquetar
2. Qué etiqueta queremos añadir.

Paso 3. Configura el acceso de Codex a WordPress

Para leer determinadas propiedades de WordPress y, sobre todo, para modificar posts, Codex necesita autenticarse.

Hsy distintas formas, más o menos seguras. Una bastante cómoda de hacerlo es mediante una Application Password de WordPress.

No es tu contraseña normal de acceso al panel. Es una contraseña adicional creada específicamente para que una aplicación pueda conectarse a WordPress mediante la API REST. 

Así como puedes crearla, puedes revocarla en cualquier momento sin necesidad cambiar tu contraseña habitual.

Se crea desde:

Usuarios > Perfil > Contraseñas de aplicación

Ponle un nombre que te permita reconocerla después, por ejemplo “Codex”.

WordPress generará una contraseña.

Cómo pasarle la contraseña a Codex

No metas la contraseña directamente en el prompt

Por poder, podría funcionar, pero mandar a la nube tus passwords no es una buena costumbre.

Lo ideal es guardarla localmente como variable de entorno o dentro de un archivo .env que no se suba al repositorio, si es que estás trabajando con Git.

Por ejemplo, podrías guardar un archivo .env solo con estas tres líneas:

WP_URL=https://tudominio.com

WP_USERNAME=tu_usuario

WP_APP_PASSWORD=tu_application_password

Lo guardas en C:\Users\TU_USUARIO_WINDOWS\.codex\.env

Y añadir .env a .gitignore para que no lo suba.

La idea es que Codex pueda utilizar las credenciales sin necesidad de mostrarlas ni copiarlas continuamente.

Una vez que hayas creado el archivo correspondiente, tienes que cerrar Codex y volverlo a abatir para que lo lea.

Dos cosas importantes: 

1. El nombre de usuario de WordPress no tiene por qué coincidir con el nombre público que aparece como autor. Escribe el usuario real en el archivo.
2. La clave que te genera WordPress contiene espacios. Bórralos cuando la guardes en el .env. Si no, no funcionará.

Prompt para esta parte

Tras el paso anterior, pásale este prompt a Codex:

Utiliza las credenciales de WordPress disponibles en las variables de entorno locales.

No muestres, imprimas ni copies contraseñas, tokens u otros secretos en la salida.

Todavía no modifiques ningún contenido.

Comprueba únicamente que las variables necesarias están disponibles.

De esta forma sabrás si las ha cogido correctamente, paso imprescindible para avanzar.

Paso 4. Comprueba que Codex puede conectarse

Lo siguiente es comprobar que la conexión funciona.

La API REST es básicamente la interfaz mediante la que Codex puede preguntarle a WordPress cosas como ¿Qué etiquetas tiene este post? o Añade esta etiqueta y guarda el artículo.

En este primer momento solo queremos hacer lo primero. Para ello, pídele que haga una consulta de lectura:

Comprueba la autenticación contra la API REST de WordPress.

Realiza únicamente peticiones GET.

Confirma:

– que la conexión funciona;

– qué usuario de WordPress está autenticado;

– que ese usuario tiene permisos para editar los posts con los que vamos a trabajar.

Si existe cualquier error de autenticación o permisos, detente.

No realices peticiones de escritura.

Si todo está bien, ya tenemos acceso. Si recibes un error 401, normalmente hay que revisar las credenciales.

Paso 5. Localiza las traducciones de cada post

Este paso solo es necesario si tienes una web multidioma.

Si utilizas Polylang, no queremos que Codex busque traducciones comparando títulos, ya que un título puede cambiar muchísimo entre idiomas.

Queremos que utilice las relaciones de traducción que ya tiene WordPress/Polylang.

Partimos de cada artículo original y localizamos sus versiones lingüísticas.

El prompt

Partiendo exclusivamente de los posts de la lista aprobada, localiza sus traducciones utilizando las relaciones de Polylang.

No busques traducciones por parecido del título.

Para cada artículo devuelve:

– post original;

– idioma;

– título de la traducción;

– post ID;

– URL.

La web utiliza estos idiomas:

[LISTA DE IDIOMAS]

Cada artículo debería tener:

[NÚMERO DE VERSIONES]

versiones en total.

Si falta cualquier traducción o encuentras una relación inconsistente, detente y no modifiques nada.

Aquí tenemos una comprobación muy sencilla que merece la pena realizar.

Si tienes 25 artículos × 5 idiomas = 125 posts Codex debería encontrar exactamente 125.

Si encuentra 124, no debería continuar.

Paso 6. Haz un dry run completo

Ahora tenemos suficiente información para montar la operación real, pero todavía no vamos a ejecutarla.

Primero haremos un dry run, que no es más que una simulación de lo que ocurriría si permitiésemos los cambios.

Queremos que Codex construya una tabla relacionando post > idioma > etiqueta correspondiente > estado actual.

Prompt

Haz ahora un dry run completo de la operación.

No realices peticiones POST, PUT, PATCH o DELETE.

Para cada post incluido en la lista validada:

1. Consulta sus etiquetas actuales.

2. Identifica el idioma del post.

3. Localiza la traducción de la nueva etiqueta que corresponda exactamente a ese mismo idioma.

4. Obtén el term ID de esa etiqueta.

5. Comprueba si ese term ID ya está asignado al post.

6. Calcula cómo quedaría el array final de tags después de añadirlo, conservando todos los term IDs existentes.

La relación debe ser siempre:

post en idioma X → etiqueta en idioma X → term ID de esa etiqueta.

Nunca asignes el term ID de la etiqueta española a un post de otro idioma ni utilices una etiqueta cuyo idioma no coincida exactamente con el idioma del post.

Devuelve una tabla con:

– post ID;

– idioma del post;

– título;

– tags actuales;

– nombre de la etiqueta que corresponde a ese idioma;

– idioma de la etiqueta;

– term ID que habría que añadir;

– si ya está presente;

– tags finales previstos.

Comprueba expresamente que el idioma del post y el idioma de la etiqueta coinciden en todos los casos.

Si encuentras cualquier post para el que no puedas identificar de forma inequívoca la etiqueta de su mismo idioma, si falta una traducción de la etiqueta o si el idioma del post y el de la etiqueta no coinciden, detente y no modifiques nada.

Al final indica:

– número total de posts;

– posts que requieren modificación;

– posts que ya contienen la etiqueta;

– errores o inconsistencias.

No escribas nada todavía.

Este paso tiene dos ventajas.

La primera es evidente: podemos ver exactamente qué piensa hacer Codex.

La segunda es que descubriremos posts que ya tengan la etiqueta.

No hace falta volver a modificar esos artículos.

En mi caso había 120 posts, pero 2 ya estaban correctamente etiquetados (lo había hecho yo manualmente).

Paso 7. Comprueba que no se van a borrar etiquetas

Éste es el punto al que prestaría más atención.

Imagina que un artículo ya tiene estas etiquetas:

• Bitcoin.
• Inversión.
• Tutorial.

Y queremos añadir “Fiscalidad”.

El resultado que buscamos evidentemente es que el artículo contenga las cuatro, no solo Fiscalidad.

Parece una obviedad, pero cuando trabajas mediante la API REST hay que tener en cuenta que el campo tags representa el conjunto de etiquetas que debe tener el post.

Por eso Codex debe leer primero los IDs existentes, añadir el nuevo y enviar después el conjunto completo.

No queremos sustituir, queremos añadir.

Puedes reforzarlo con un prompt específico:

Antes de ejecutar los cambios, comprueba esta regla:

NUNCA sustituyas las etiquetas actuales del post por únicamente la nueva etiqueta.

Para cada post:

1. Lee el array actual de term IDs.

2. Conserva todos los IDs existentes.

3. Comprueba si el nuevo term ID ya existe.

4. Si no existe, añádelo al array.

5. No elimines ni modifiques ningún otro term ID.

Muéstrame cualquier caso en el que no puedas garantizar esta operación.

No escribas todavía.

Si vas a automatizar una operación de este tipo, yo no me saltaría esta comprobación.

Paso 8. Revalida todo justo antes de modificar WordPress

Ya tenemos el dry run aprobado. Podríamos ejecutar directamente, pero, aun así, cuesta muy poco volver a leer WordPress justo antes de escribir.

La razón es sencilla: el estado de un post podría haber cambiado entre una consulta y otra. Quizá lo has editado tú en días diferentes o lo ha hecho otra persona. Y queremos asegurarnos de que Codex trabaja sobre la versión actual.

Prompt

Haz una revalidación inmediatamente antes de ejecutar los cambios.

Vuelve a consultar WordPress y confirma:

– que siguen existiendo todos los posts previstos;

– que las relaciones de traducción no han cambiado;

– que los term IDs de la etiqueta siguen siendo correctos;

– que las etiquetas actuales coinciden con el estado que vas a modificar.

Si existe cualquier diferencia respecto al dry run, detente.

Si todo coincide, indícame:

– número total de posts;

– modificaciones necesarias;

– posts que ya están correctos.

Todavía no ejecutes cambios hasta que te dé autorización.

Así reducimos bastante el riesgo.

Paso 9. Ejecuta la modificación

Si todo lo anterior está ok, ahora sí podemos autorizar la escritura.

En este punto conviene ser bastante preciso respecto a qué puede y qué no puede cambiar.

Prompt

Autorizo la ejecución de los cambios.

Modifica exclusivamente los posts incluidos en la lista validada.

Para cada post:

1. Lee sus tags actuales.

2. Identifica el idioma del post.

3. Utiliza exclusivamente la traducción de la nueva etiqueta cuyo idioma coincida exactamente con el idioma de ese post.

4. Obtén el term ID de esa etiqueta.

5. Comprueba si ese term ID ya está presente.

6. Si no está presente, añádelo al array actual de tags.

7. Conserva todos los demás term IDs existentes.

8. Guarda el array completo resultante.

La relación debe ser siempre:

post en idioma X → etiqueta en idioma X → term ID de esa etiqueta.

Nunca asignes el term ID de la etiqueta española a un post de otro idioma ni utilices una etiqueta cuyo idioma no coincida exactamente con el idioma del post.

Si para cualquier post no puedes identificar de forma inequívoca la etiqueta de su mismo idioma, si falta una traducción de la etiqueta o si el idioma del post y el de la etiqueta no coinciden, no modifiques ese post y registra el error.

NO modifiques:

– título;

– contenido;

– excerpt;

– slug;

– categorías;

– autor;

– fecha;

– estado;

– imagen destacada;

– campos ACF;

– SEO;

– ningún otro dato del post.

No modifiques posts fuera de la lista aprobada.

Registra para cada operación:

– post ID;

– idioma del post;

– nombre de la etiqueta asignada;

– idioma de la etiqueta;

– term ID añadido;

– tags antes;

– tags después;

– código de respuesta de WordPress;

– resultado.

Si una operación falla, registra el error y no intentes corregirlo modificando otros campos.

Ahora sí Codex realizará las peticiones necesarias contra WordPress.

Pero todavía nos queda una comprobación.

Paso 10. Vuelve a leer todos los posts

Una respuesta correcta de la API significa que WordPress ha aceptado la petición.

Pero si estamos trabajando con decenas o cientos de artículos, merece la pena comprobar el estado final, no simplemente asumir que todo ha salido bien.

Así que hacemos una nueva ronda de consultas de lectura.

Prompt

Terminadas las modificaciones, realiza una verificación independiente mediante nuevas peticiones GET.

Para cada post de la lista comprueba:

1. Que contiene el term ID de la nueva etiqueta correspondiente a su idioma.

2. Que conserva todos los term IDs que tenía antes.

3. Que no se ha añadido ninguna etiqueta inesperada.

4. Que no se ha modificado ningún post fuera de la lista.

Devuelve un resumen final con:

– posts revisados;

– modificaciones realizadas;

– posts que ya estaban correctamente etiquetados;

– errores REST;

– etiquetas anteriores perdidas;

– posts inesperadamente modificados;

– discrepancias finales.

Considera la tarea completada únicamente si hay 0 discrepancias.

Con esto cerramos el proceso.

No solo hemos realizado los cambios, también hemos comprobado lo que realmente ha quedado guardado correctamente en WordPress.

Conclusiones

La primera es que para unos pocos posts probablemente sigue siendo más rápido hacerlo a mano. Pero la escala cambia enseguida, sobre todo con el multiidioma:

• 10 artículos × 10 idiomas = 100 posts
• 30 artículos × 10 idiomas = 300 posts
• 50 artículos × 10 idiomas = 500 posts

Ahí ya no se trata solo de ahorrar clics, sino sobre todo de trata de reducir errores.

La idea que quiero que te lleves porque me parece realmente útil de este sistema es que Codex no decide y modifica libremente tu WordPress:

• Primero construye el sistema.
• Después simula.
• Luego revalida.
• Solo entonces escribe.
• Y al terminar vuelve a comprobarlo todo.

Para mantenimiento editorial masivo, ésa me parece una forma bastante más sensata de utilizar agentes como Codex.

De hecho, ya tengo clarísima otra modificación que afecta a más de 500 post y que pensaba hacer por SQL a manubrio. 

Tras haber probado esta vía, tengo claro que es mucho mejor y que las probabilidades de error se reducen considerablemente.

Éste ha sido un viaje solo de ida.