Como reetiquetar posts antigos em vários idiomas no WordPress com a IA do Codex

Há pouco tempo me deparei com um desafio novo para mim: como adicionar uma nova etiqueta — no meu caso, “ficção científica” — a todos os artigos, tanto em espanhol como nos outros idiomas. 

Ou seja, quase 3.000 artigos que era preciso:

• Analisar para ver em quais a tag fazia realmente sentido.
• Adicionar a etiqueta no idioma correspondente a cada um sem apagar as restantes etiquetas.
• Verificar se tudo tinha corrido bem.

Criar a etiqueta em cada idioma não tinha mistério nenhum com o desenvolvimento que tenho montado. O problema era etiquetar apenas os artigos antigos que realmente deviam tê-la.

Poderia ser feito manualmente, claro, mas, depois de revisar o conteúdo, acabei com uma lista de 12 artigos em espanhol. Isso significa que, como tenho traduções para dez idiomas no site, eu precisava etiquetar um total de 120 posts.

E procurar cada post no respectivo idioma, abri-lo e adicionar a etiqueta 120 vezes, uma após a outra, sinceramente não me dava vontade nenhuma.

Por isso ocorreu-me que era uma tarefa bastante adequada para Codex.

Além disso, queria usar este caso, bastante simples, como base para algo muito mais geral: aplicar alterações automaticamente a muitos artigos, mas sem deixar que o agente faça mudanças por conta própria e à maluca.

É precisamente isso que explico neste tutorial.

Objetivo

Simples: adicionar uma determinada etiqueta a uma lista fechada de posts do WordPress.

Incluindo a tradução correspondente dessa etiqueta para cada versão linguística do artigo, com Polylang, que é o plugin multilíngue que eu uso.

E vamos fazê-lo não de qualquer maneira, mas com algumas precauções:

• Vamos trabalhar sobre uma lista fechada de artigos.
• Primeiro vamos verificar o que o Codex vai modificar.
• Não vamos criar novas etiquetas automaticamente.
• Vamos conservar todas as etiquetas que cada post já tenha.
• Vamos fazer uma simulação antes de escrever.
• Depois voltaremos a verificar o WordPress para confirmar o resultado.

Seu caso não precisa ser exatamente igual ao meu. Basta querer alterar alguma coisa em uma série específica de posts do WordPress que daria bastante trabalho fazer manualmente.

Por outro lado, eu uso Codex, mas o processo pode ser seguido da mesma forma se preferir usar Claude Code ou Antigravity. Muda a ferramenta, os passos não.

Passo 1. Crie a etiqueta antes de começar

A primeira coisa é ter já criada no WordPress a etiqueta que quer aplicar.

Convém fazer isto manualmente porque não quero que o Codex decida como deve organizar-se a taxonomia do site. Queremos que se limite a localizar algo que já existe e a atribuí-lo a determinados posts.

No WordPress, já sabe, pode fazê-lo em:

Artigos > Etiquetas

Se seu site tem apenas um idioma, este passo está praticamente concluído.

Se usa Polylang (versão Pro ou com desenvolvimento próprio adicional, como no meu caso), crie também as traduções da etiqueta e verifique se estão corretamente vinculadas.

Por exemplo, no meu caso tinha:

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

E assim sucessivamente.

O WordPress salve-as internamente como termos (etiquetas) diferentes e cada uma terá o seu próprio ID. Isso será importante mais à frente.

Uma observação: tenho um plugin desenvolvido por mim que cria as etiquetas automaticamente em todos os idiomas, mas provavelmente você precisará criá-las manualmente, uma por uma em cada idioma.

Prompt para verificar as etiquetas

Quando já as tiver criado, pode pedir ao Codex que as localize:

Quero adicionar uma etiqueta já existente a vários posts do WordPress.

A etiqueta principal é:

[NOME DA ETIQUETA]

Por agora não modifique nenhum dado.

Localize a etiqueta no WordPress e, se o site usar Polylang, todas as suas traduções.

Retorne para cada idioma:

– idioma;

– nome da etiqueta;

– slug;

– term ID.

Não crie novas etiquetas.

Se faltar alguma tradução, houver duplicados ou existir qualquer ambiguidade, para e avisa-me.

O term ID é simplesmente o número com que o WordPress identifica internamente essa etiqueta. O importante é que o Codex saiba que ID corresponde a cada idioma.

Passo 2. Prepara uma lista fechada de artigos

Agora precisamos decidir que posts queremos modificar.

Aqui recomendo não dar demasiada liberdade ao agente.

Poderíamos pedir-lhe:

Procure todos os artigos relacionados com ficção científica e adicione a etiqueta.

Mas então estaríamos a misturar duas tarefas muito diferentes:

1. Decidir editorialmente que conteúdos devem ter a etiqueta.
2. Fazer 20, 100 ou 500 vezes a mesma alteração no WordPress.

Eu prefiro separar ambas para ir controlando cada passo.

Pode fazer a lista manualmente se o volume de artigos não for muito alto.

Também pode usar ChatGPT ou Codex para ajudar você a localizar candidatos.

No meu caso, como o volume era grande, passei-lhe os três sitemaps de artigos que tenho e pedi ao ChatGPT que, com base no URL, me desse candidatos.

Faça como fizer, deve acabar com uma lista concreta de artigos antes de modificar seja o que for.

Por exemplo:

• Blade Runner: crítica e análise.
• Os melhores comics de ficção científica.
• Akira: manga e filme.
• El Eternauta: análise da série.
• …

Como eu disse, acabei com 12 artigos por idioma, eliminando alguns candidatos que o ChatGPT considerava adequados, mas eu não.

Prompt para preparar o conjunto de trabalho

Quando tiver a lista, manda isto ao Codex:

Vou fornecer uma lista fechada de artigos do WordPress.

Trabalha exclusivamente sobre estes artigos.

Não acrescente outros conteúdos mesmo que considere que também poderiam encaixar na etiqueta.

Lista:

[COLA AQUI OS TÍTULOS OU URL]

Por agora não faça nenhuma alteração.

Localize cada post e devolve:

– título;

– URL;

– post ID;

– estado;

– idioma.

Se algum não puder ser identificado de forma inequívoca, para e assinala-o.

Com isto já temos definidos os dois extremos da operação:

1. Que posts queremos etiquetar
2. Que etiqueta queremos adicionar.

Passo 3. Configura o acesso do Codex ao WordPress

Para ler determinadas propriedades do WordPress e, sobretudo, para modificar posts, o Codex precisa de autenticar-se.

Há várias formas, mais ou menos seguras. Uma bastante cómoda é usar uma Application Password do WordPress.

Não é sua senha normal de acesso ao painel. É uma senha adicional criada especificamente para que um aplicativo possa se conectar ao WordPress por meio da API REST. 

Assim como pode criá-la, você pode revogá-la a qualquer momento sem precisar alterar sua senha habitual.

Crie-se em:

Usuários > Perfil > Senhas de aplicativo

Dê um nome que permita reconhecê-la depois, por exemplo, “Codex”.

O WordPress vai gerar uma senha.

Como passar a senha ao Codex

Não coloque a senha diretamente no prompt

Até poderia funcionar, mas enviar suas senhas para a nuvem não é um bom hábito.

O ideal é guardá-la localmente como variável de ambiente ou dentro de um arquivo .env que não seja enviado para o repositório, caso esteja a trabalhar com Git.

Por exemplo, pode salvar um arquivo .env apenas com estas três linhas:

WP_URL=https://tudominio.com

WP_USERNAME=tu_usuario

WP_APP_PASSWORD=tu_application_password

Salve-o em C:UsersTU_USUARIO_WINDOWS.codex.env

E adiciona .env ao .gitignore para que não seja enviado.

A ideia é que o Codex possa usar as credenciais sem precisar mostrá-las nem copiá-las continuamente.

Depois de criar o arquivo correspondente, você precisa fechar o Codex e abri-lo novamente para que ele leia o arquivo.

Duas coisas importantes: 

1. O nome de usuário do WordPress não precisa coincidir com o nome público que aparece como autor. Escreva o usuário real no arquivo.
2. A chave gerada pelo WordPress contém espaços. Remova-os ao salvar a senha no arquivo .env. Caso contrário, não funcionará.

Prompt para esta parte

Depois do passo anterior, passa este prompt ao Codex:

Usa as credenciais do WordPress disponíveis nas variáveis de ambiente locais.

Não mostre, imprima nem copie senhas, tokens ou outros segredos na saída.

Ainda não modifique nenhum conteúdo.

Verifique apenas se as variáveis necessárias estão disponíveis.

Assim saberás se as apanhou corretamente, um passo imprescindível para avançar.

Passo 4. Verifique se o Codex consegue se conectar

O passo seguinte é verificar se a conexão funciona.

A API REST é basicamente a interface através da qual o Codex pode perguntar ao WordPress coisas como Que etiquetas tem este post? ou Adicione esta etiqueta e salve o artigo.

Neste primeiro momento só queremos fazer a primeira coisa. Para isso, pede-lhe que faça uma consulta apenas de leitura:

Verifique a autenticação contra a API REST do WordPress.

Faz apenas requisições GET.

Confirme:

– que a conexão funciona;

– que usuário do WordPress está autenticado;

– que esse usuário tem permissões para editar os posts com que vamos trabalhar.

Se existir qualquer erro de autenticação ou permissões, para.

Não faça pedidos de escrita.

Se estiver tudo bem, já temos acesso. Se receber um erro 401, normalmente é preciso rever as credenciais.

Passo 5. Localize as traduções de cada post

Este passo só é necessário se tiver um site multilíngue.

Se usa Polylang, não queremos que o Codex procure traduções comparando títulos, porque um título pode mudar imenso entre idiomas.

Queremos que use as relações de tradução que o WordPress/Polylang já tem.

Partimos de cada artigo original e localizamos as suas versões linguísticas.

O prompt

Partindo exclusivamente dos posts da lista aprovada, localiza as respectivas traduções usando as relações do Polylang.

Não procure traduções pela semelhança do título.

Para cada artigo devolve:

– post original;

– idioma;

– título da tradução;

– post ID;

– URL.

O site usa estes idiomas:

[LISTA DE IDIOMAS]

Cada artigo deve ter:

[NÚMERO DE VERSÕES]

versões no total.

Se faltar alguma tradução ou encontrar uma relação inconsistente, para e não modifique nada.

Aqui temos uma verificação muito simples que vale a pena fazer.

Se tem 25 artigos × 5 idiomas = 125 posts O Codex deve encontrar exatamente 125.

Se encontrar 124, não deve continuar.

Passo 6. Faz um dry run completo

Agora temos informação suficiente para montar a operação real, mas ainda não vamos executá-la.

Primeiro faremos um dry run, que não passa de uma simulação do que aconteceria se permitíssemos as alterações.

Queremos que o Codex construa uma tabela relacionando post > idioma > etiqueta correspondente > estado atual.

Prompt

Faz agora um dry run completo da operação.

Não faça pedidos POST, PUT, PATCH ou DELETE.

Para cada post incluído na lista validada:

1. Consulta as etiquetas atuais.

2. Identifica o idioma do post.

3. Localize a tradução da nova etiqueta que corresponde exatamente a esse mesmo idioma.

4. Obtenha o term ID dessa etiqueta.

5. Verifique se esse term ID já está atribuído ao post.

6. Calcula como ficaria o array final de tags depois de o adicionar, conservando todos os term IDs existentes.

A relação deve ser sempre:

post no idioma X → etiqueta no idioma X → term ID dessa etiqueta.

Nunca atribua o term ID da etiqueta espanhola a um post noutro idioma nem use uma etiqueta cujo idioma não coincida exatamente com o idioma do post.

Retorne uma tabela com:

– post ID;

– idioma do post;

– título;

– tags atuais;

– nome da etiqueta que corresponde a esse idioma;

– idioma da etiqueta;

– term ID que seria preciso adicionar;

– se já está presente;

– tags finais previstas.

Verifique expressamente que o idioma do post e o idioma da etiqueta coincidem em todos os casos.

Se encontrar qualquer post para o qual não consiga identificar de forma inequívoca a etiqueta do mesmo idioma, se faltar uma tradução da etiqueta ou se o idioma do post e o da etiqueta não coincidirem, para e não modifique nada.

No final indica:

– número total de posts;

– posts que precisam de alteração;

– posts que já contêm a etiqueta;

– erros ou inconsistências.

Não escreva nada ainda.

Este passo tem duas vantagens.

A primeira é evidente: podemos ver exatamente o que o Codex pensa fazer.

A segunda é que vamos descobrir posts que já têm a etiqueta.

Não é preciso voltar a modificar esses artigos.

No meu caso havia 120 posts, mas 2 já estavam corretamente etiquetados (tinha-o feito manualmente).

Passo 7. Verifique que não vão ser apagadas etiquetas

Este é o ponto a que eu daria mais atenção.

Imagina que um artigo já tem estas etiquetas:

• Bitcoin.
• Investimento.
• Tutorial.

E queremos adicionar “Fiscalidade”.

O resultado que procuramos é, evidentemente, que o artigo fique com as quatro, não apenas Fiscalidade.

Parece óbvio, mas quando trabalha através da API REST é preciso ter em conta que o campo tags representa o conjunto de etiquetas que o post deve ter.

Por isso, o Codex precisa primeiro ler os IDs existentes, adicionar o novo e depois enviar o conjunto completo.

Não queremos substituir, queremos adicionar.

Pode reforçá-lo com um prompt específico:

Antes de executar as alterações, verifique esta regra:

NUNCA substitua as etiquetas atuais do post apenas pela nova etiqueta.

Para cada post:

1. Lê o array atual de term IDs.

2. Conserva todos os IDs existentes.

3. Verifique se o novo term ID já existe.

4. Se não existir, adiciona-o ao array.

5. Não elimine nem modifique nenhum outro term ID.

Mostra-me qualquer caso em que não possa garantir esta operação.

Não escreva ainda.

Se vai automatizar uma operação deste tipo, eu não saltaria esta verificação.

Passo 8. Revalida tudo imediatamente antes de modificar o WordPress

Já temos o dry run aprovado. Poderíamos executar diretamente, mas, mesmo assim, custa muito pouco voltar a ler o WordPress logo antes de escrever.

A razão é simples: o estado de um post pode ter mudado entre uma consulta e outra. Talvez o tenha editado em dias diferentes ou outra pessoa o tenha feito. E queremos garantir que o Codex trabalha sobre a versão atual.

Prompt

Faz uma revalidação imediatamente antes de executar as alterações.

Volta a consultar o WordPress e confirma:

– que todos os posts previstos continuam a existir;

– que as relações de tradução não mudaram;

– que os term IDs da etiqueta continuam corretos;

– que as etiquetas atuais coincidem com o estado que vai modificar.

Se existir qualquer diferença em relação ao dry run, para.

Se tudo coincidir, indica-me:

– número total de posts;

– alterações necessárias;

– posts que já estão corretos.

Ainda não execute alterações até eu dar autorização.

Assim reduzimos bastante o risco.

Passo 9. Executa a alteração

Se tudo o que está acima estiver OK, agora sim podemos autorizar a escrita.

Neste ponto convém ser bastante preciso sobre o que pode e não pode mudar.

Prompt

Autorizo a execução das alterações.

Modifica exclusivamente os posts incluídos na lista validada.

Para cada post:

1. Lê as tags atuais.

2. Identifica o idioma do post.

3. Usa exclusivamente a tradução da nova etiqueta cujo idioma coincida exatamente com o idioma desse post.

4. Obtenha o term ID dessa etiqueta.

5. Verifique se esse term ID já está presente.

6. Se não estiver presente, adiciona-o ao array atual de tags.

7. Conserva todos os restantes term IDs existentes.

8. Salve o array completo resultante.

A relação deve ser sempre:

post no idioma X → etiqueta no idioma X → term ID dessa etiqueta.

Nunca atribua o term ID da etiqueta espanhola a um post noutro idioma nem use uma etiqueta cujo idioma não coincida exatamente com o idioma do post.

Se, para qualquer post, não conseguir identificar de forma inequívoca a etiqueta no mesmo idioma, se faltar uma tradução da etiqueta ou se os idiomas não coincidirem, não modifique o post e registre o erro.

NÃO modifique:

– título;

– conteúdo;

– excerpt;

– slug;

– categorias;

– autor;

– data;

– estado;

– imagem destacada;

– campos ACF;

– SEO;

– nenhum outro dado do post.

Não modifique posts fora da lista aprovada.

Registre para cada operação:

– post ID;

– idioma do post;

– nome da etiqueta atribuída;

– idioma da etiqueta;

– term ID adicionado;

– tags antes;

– tags depois;

– código de resposta do WordPress;

– resultado.

Se uma operação falhar, registre o erro e não tente corrigi-lo modificando outros campos.

Agora sim, o Codex fará os pedidos necessários ao WordPress.

Mas ainda nos falta uma verificação.

Passo 10. Volta a ler todos os posts

Uma resposta correta da API significa que o WordPress aceitou o pedido.

Mas se estamos a trabalhar com dezenas ou centenas de artigos, vale a pena verificar o estado final, e não simplesmente assumir que tudo correu bem.

Por isso fazemos uma nova ronda de consultas de leitura.

Prompt

Terminadas as alterações, faz uma verificação independente por meio de novos requisições GET.

Para cada post da lista verifique:

1. Que contém o term ID da nova etiqueta correspondente ao seu idioma.

2. Que conserva todos os term IDs que tinha antes.

3. Que não foi adicionada nenhuma etiqueta inesperada.

4. Que não foi modificado nenhum post fora da lista.

Retorne um resumo final com:

– posts revistos;

– alterações realizadas;

– posts que já estavam corretamente etiquetados;

– erros REST;

– etiquetas anteriores perdidas;

– posts modificados inesperadamente;

– discrepâncias finais.

Considera a tarefa concluída apenas se houver 0 discrepâncias.

Com isto fechamos o processo.

Não só fizemos as alterações, como também verificámos o que ficou realmente salvo corretamente no WordPress.

Conclusões

A primeira é que, para poucos posts, provavelmente ainda é mais rápido fazer tudo manualmente. Mas a escala muda rapidamente, sobretudo em sites multilíngues:

• 10 artigos × 10 idiomas = 100 posts
• 30 artigos × 10 idiomas = 300 posts
• 50 artigos × 10 idiomas = 500 posts

Aqui já não se trata apenas de poupar clique, mas sobretudo de reduzir erros.

A ideia que quero que mantenha, porque me parece realmente útil neste sistema, é que o Codex não decide nem modifica livremente seu WordPress:

• Primeiro constrói o sistema.
• Depois simula.
• Depois revalida.
• Só então escreve.
• E no fim volta a verificar tudo.

Para manutenção editorial em massa, parece-me uma forma bastante mais sensata de usar agentes como o Codex.

Aliás, já tenho muito clara outra alteração que afeta mais de 500 posts e que pensava fazer manualmente com SQL. 

Depois de experimentar esta via, tenho a certeza de que é muito melhor e de que as probabilidades de erro diminuem consideravelmente.

Foi uma viagem só de ida.