Come rietichettare vecchi post in più lingue su WordPress con l’IA di Codex

Di recente mi sono trovato davanti a una sfida nuova per me: come aggiungere un nuovo tag — nel mio caso, «fantascienza» — a tutti gli articoli, sia in spagnolo sia nelle altre lingue. 

In altre parole, quasi 3.000 articoli che bisognava:

• Analizzare per capire su quali il tag avesse davvero senso.
• Aggiungere il tag nella lingua corrispondente a ciascuno senza cancellare gli altri tag.
• Controllare che fosse andato tutto bene.

Creare il tag in ogni lingua non aveva nulla di complicato con lo sviluppo che ho già montato. Il problema era etichettare soltanto i vecchi articoli che avrebbero dovuto averlo.

Si potrebbe fare a mano, certo, ma dopo aver rivisto i contenuti mi sono ritrovato con un elenco di 12 articoli in spagnolo. Questo significa che, dato che sul sito ho traduzioni in dieci lingue, dovevo etichettare in totale 120 post.

E cercare ogni articolo nella sua lingua, aprirlo e aggiungere il tag 120 volte, una dopo l’altra, francamente non mi attirava affatto.

Così mi è venuto in mente che fosse un compito piuttosto adatto a Codex.

Inoltre volevo usare questo caso, abbastanza semplice, come base per qualcosa di molto più generale: applicare modifiche automaticamente a molti articoli, senza lasciare che l’agente faccia cambiamenti di propria iniziativa e alla cieca.

È esattamente ciò che ti spiego in questo tutorial.

Obiettivo

Semplice: aggiungere un determinato tag a un elenco chiuso di post WordPress.

Includendo la traduzione corrispondente di quel tag per ogni versione linguistica dell’articolo, con Polylang, che è il plugin multilingua che uso io.

E non lo faremo alla buona, ma con alcune precauzioni:

• Lavoreremo su un elenco chiuso di articoli.
• Per prima cosa controlleremo che cosa sta per modificare Codex.
• Non creeremo automaticamente nuovi tag.
• Conserveremo tutti i tag che ogni post possiede già.
• Faremo una simulazione prima di scrivere.
• Poi controlleremo di nuovo WordPress per verificare il risultato.

Il tuo caso non deve essere identico al mio. Basta che tu voglia modificare qualcosa su una serie precisa di post WordPress che a mano ti richiederebbe parecchio tempo.

Da parte mia uso Codex, ma puoi seguire lo stesso processo anche se preferisci Claude Code o Antigravity. Cambia lo strumento, non i passaggi.

Passo 1. Crea il tag prima di iniziare

La prima cosa è avere già creato in WordPress il tag che vuoi applicare.

Conviene farlo manualmente, perché non voglio che Codex decida come organizzare la tassonomia del sito. Vogliamo che si limiti a individuare qualcosa che esiste già e ad assegnarlo a determinati post.

In WordPress, come sai, puoi farlo da:

Articoli > Tag

Se il tuo sito ha una sola lingua, con questo hai praticamente finito il passaggio.

Se usi Polylang (versione Pro o con sviluppo personalizzato sopra, come nel mio caso), crea anche le traduzioni del tag e controlla che siano correttamente collegate.

Per esempio, nel mio caso avevo:

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

E così via.

WordPress le salva internamente come termini (tag) diversi e ciascuno avrà il proprio ID. Questo sarà importante più avanti.

Una nota: io ho un plugin sviluppato da me che le crea automaticamente in tutte le lingue, ma tu probabilmente dovrai crearle manualmente, una per una per ogni lingua.

Prompt per controllare i tag

Quando li hai già creati, puoi chiedere a Codex di individuarli:

Voglio aggiungere un tag già esistente a vari post di WordPress.

Il tag principale è:

[NOME DEL TAG]

Per ora non modificare alcun dato.

Individua il tag in WordPress e, se il sito usa Polylang, tutte le sue traduzioni.

Restituiscimi per ogni lingua:

– lingua;

– nome del tag;

– slug;

– term ID.

Non creare nuovi tag.

Se manca una traduzione, ci sono duplicati o esiste qualsiasi ambiguità, fermati e avvisami.

Il term ID è semplicemente il numero con cui WordPress identifica internamente quel tag. L’importante è che Codex sappia quale ID corrisponde a ogni lingua.

Passo 2. Prepara un elenco chiuso di articoli

Adesso dobbiamo decidere quali post vogliamo modificare.

Qui consiglio di non lasciare troppa libertà all’agente.

Potremmo chiedergli:

Trova tutti gli articoli legati alla fantascienza e aggiungi loro il tag.

Ma così mescoleremmo due attività molto diverse:

1. Decidere editorialmente quali contenuti dovrebbero avere il tag.
2. Eseguire 20, 100 o 500 volte la stessa modifica in WordPress.

Io preferisco separarle per mantenere il controllo su ogni passaggio.

Puoi creare l’elenco manualmente se il numero di articoli non è molto alto.

Puoi anche usare ChatGPT o Codex per aiutarti a individuare dei candidati.

Nel mio caso, dato che il volume era elevato, gli ho passato le tre sitemap degli articoli e ho chiesto a ChatGPT di suggerirmi i candidati in base all’URL.

Comunque tu lo faccia, dovresti arrivare a un elenco concreto di articoli prima di modificare qualsiasi cosa.

Per esempio:

• Blade Runner: recensione e analisi.
• I migliori fumetti di fantascienza.
• Akira: manga e film.
• El Eternauta: recensione della serie.
• …

Come ti dicevo, alla fine ho ottenuto 12 articoli per lingua, eliminando qualche candidato che ChatGPT riteneva adatto ma io no.

Prompt per preparare l’insieme di lavoro

Quando hai l’elenco, passa questo a Codex:

Ti fornirò un elenco chiuso di articoli WordPress.

Lavora esclusivamente su questi articoli.

Non aggiungere altri contenuti anche se ritieni che potrebbero essere adatti al tag.

Elenco:

[INCOLLA QUI I TITOLI O GLI URL]

Per ora non effettuare alcuna modifica.

Individua ogni post e restituisci:

– titolo;

– URL;

– post ID;

– stato;

– lingua.

Se qualcuno non può essere identificato in modo univoco, fermati e segnalalo.

Con questo abbiamo già definito i due estremi dell’operazione:

1. Quali post vogliamo etichettare
2. Quale tag vogliamo aggiungere.

Passo 3. Configura l’accesso di Codex a WordPress

Per leggere determinate proprietà di WordPress e, soprattutto, per modificare i post, Codex deve autenticarsi.

Esistono diversi modi, più o meno sicuri. Uno piuttosto comodo consiste nell’usare una Application Password di WordPress.

Non è la tua normale password di accesso al pannello. È una password aggiuntiva creata appositamente affinché un’applicazione possa collegarsi a WordPress tramite la API REST. 

Così come puoi crearla, puoi revocarla in qualsiasi momento senza dover cambiare la tua password abituale.

Si crea da:

Utenti > Profilo > Password per le applicazioni

Dalle un nome che ti permetta di riconoscerla in seguito, per esempio “Codex”.

WordPress genererà una password.

Come passare la password a Codex

Non inserire la password direttamente nel prompt

Potrebbe anche funzionare, ma mandare le tue password nel cloud non è una buona abitudine.

L’ideale è salvarla localmente come variabile d’ambiente o dentro un file .env che non venga caricato nel repository, se stai lavorando con Git.

Per esempio, potresti salvare un file .env con soltanto queste tre righe:

WP_URL=https://tudominio.com

WP_USERNAME=tu_usuario

WP_APP_PASSWORD=tu_application_password

Salvalo in C:UsersTU_USUARIO_WINDOWS.codex.env

E aggiungi .env a .gitignore in modo che non venga caricato.

L’idea è che Codex possa usare le credenziali senza doverle mostrare o copiare continuamente.

Dopo aver creato il file, devi chiudere Codex e riaprirlo perché lo legga.

Due cose importanti: 

1. Il nome utente di WordPress non deve per forza coincidere con il nome pubblico mostrato come autore. Inserisci nel file il vero nome utente.
2. La chiave generata da WordPress contiene spazi. Eliminali quando la salvi nel .env. Altrimenti non funzionerà.

Prompt per questa parte

Dopo il passaggio precedente, passa questo prompt a Codex:

Usa le credenziali WordPress disponibili nelle variabili d’ambiente locali.

Non mostrare, stampare o copiare password, token o altri segreti nell’output.

Non modificare ancora alcun contenuto.

Controlla soltanto che le variabili necessarie siano disponibili.

In questo modo saprai se le ha caricate correttamente, un passaggio indispensabile per proseguire.

Passo 4. Controlla che Codex riesca a collegarsi

Il passo successivo è verificare che la connessione funzioni.

La API REST è in pratica l’interfaccia tramite la quale Codex può chiedere a WordPress cose come Quali tag ha questo post? oppure Aggiungi questo tag e salva l’articolo.

In questa prima fase vogliamo fare soltanto la prima cosa. Chiedigli quindi di eseguire una query di sola lettura:

Controlla l’autenticazione verso la API REST di WordPress.

Esegui esclusivamente richieste GET.

Conferma:

– che la connessione funziona;

– quale utente WordPress è autenticato;

– che quell’utente abbia i permessi per modificare i post su cui lavoreremo.

Se c’è qualsiasi errore di autenticazione o di permessi, fermati.

Non effettuare richieste di scrittura.

Se è tutto a posto, abbiamo accesso. Se ricevi un errore 401, normalmente devi controllare le credenziali.

Passo 5. Individua le traduzioni di ogni post

Questo passaggio è necessario solo se hai un sito multilingua.

Se usi Polylang, non vogliamo che Codex cerchi le traduzioni confrontando i titoli, perché un titolo può cambiare moltissimo tra una lingua e l’altra.

Vogliamo che usi le relazioni di traduzione già presenti in WordPress/Polylang.

Partiamo da ogni articolo originale e individuiamo le sue versioni linguistiche.

Il prompt

Partendo esclusivamente dai post dell’elenco approvato, individua le loro traduzioni usando le relazioni di Polylang.

Non cercare le traduzioni in base alla somiglianza del titolo.

Per ogni articolo restituisci:

– post originale;

– lingua;

– titolo della traduzione;

– post ID;

– URL.

Il sito usa queste lingue:

[ELENCO DELLE LINGUE]

Ogni articolo dovrebbe avere:

[NUMERO DI VERSIONI]

versioni in totale.

Se manca una traduzione o trovi una relazione incoerente, fermati e non modificare nulla.

Qui abbiamo un controllo molto semplice che vale la pena fare.

Se hai 25 articoli × 5 lingue = 125 post Codex dovrebbe trovarne esattamente 125.

Se ne trova 124, non dovrebbe continuare.

Passo 6. Esegui un dry run completo

Adesso abbiamo abbastanza informazioni per impostare l’operazione reale, ma non la eseguiremo ancora.

Prima faremo un dry run, che non è altro che una simulazione di ciò che accadrebbe se autorizzassimo le modifiche.

Vogliamo che Codex costruisca una tabella collegando post > lingua > tag corrispondente > stato attuale.

Prompt

Adesso esegui un dry run completo dell’operazione.

Non effettuare richieste POST, PUT, PATCH o DELETE.

Per ogni post incluso nell’elenco validato:

1. Consulta i suoi tag attuali.

2. Identifica la lingua del post.

3. Individua la traduzione del nuovo tag che corrisponde esattamente a quella stessa lingua.

4. Ottieni il term ID di quel tag.

5. Controlla se quel term ID è già assegnato al post.

6. Calcola come risulterebbe l’array finale dei tag dopo averlo aggiunto, conservando tutti i term ID esistenti.

La relazione deve essere sempre:

post in lingua X → tag in lingua X → term ID di quel tag.

Non assegnare mai il term ID del tag spagnolo a un post in un’altra lingua e non usare mai un tag la cui lingua non corrisponda esattamente alla lingua del post.

Restituisci una tabella con:

– post ID;

– lingua del post;

– titolo;

– tag attuali;

– nome del tag corrispondente a quella lingua;

– lingua del tag;

– term ID da aggiungere;

– se è già presente;

– tag finali previsti.

Controlla espressamente che la lingua del post e quella del tag coincidano in tutti i casi.

Se trovi un post per il quale non riesci a identificare in modo univoco il tag nella stessa lingua, se manca una traduzione del tag o se la lingua del post e quella del tag non coincidono, fermati e non modificare nulla.

Alla fine indica:

– numero totale di post;

– post che richiedono modifiche;

– post che contengono già il tag;

– errori o incoerenze.

Non scrivere ancora nulla.

Questo passaggio ha due vantaggi.

Il primo è evidente: possiamo vedere esattamente che cosa pensa di fare Codex.

Il secondo è che scopriremo i post che hanno già il tag.

Non serve modificare di nuovo quegli articoli.

Nel mio caso c’erano 120 post, ma 2 erano già etichettati correttamente (lo avevo fatto io a mano).

Passo 7. Controlla che non vengano cancellati tag

Questo è il punto a cui presterei più attenzione.

Immagina che un articolo abbia già questi tag:

• Bitcoin.
• Investimento.
• Tutorial.

E vogliamo aggiungere “Fiscalità”.

Il risultato che cerchiamo, ovviamente, è che l’articolo li contenga tutti e quattro, non soltanto Fiscalità.

Sembra ovvio, ma quando lavori tramite la API REST devi tenere presente che il campo tags rappresenta l’insieme dei tag che il post deve avere.

Per questo Codex deve prima leggere gli ID esistenti, aggiungere quello nuovo e poi inviare l’insieme completo.

Non vogliamo sostituire, vogliamo aggiungere.

Puoi rafforzarlo con un prompt specifico:

Prima di eseguire le modifiche, controlla questa regola:

NON sostituire MAI i tag attuali del post soltanto con il nuovo tag.

Per ogni post:

1. Leggi l’array attuale dei term ID.

2. Conserva tutti gli ID esistenti.

3. Controlla se il nuovo term ID esiste già.

4. Se non esiste, aggiungilo all’array.

5. Non eliminare né modificare nessun altro term ID.

Mostrami qualsiasi caso in cui non puoi garantire questa operazione.

Non scrivere ancora.

Se automatizzi un’operazione di questo tipo, io non salterei questo controllo.

Passo 8. Rivalida tutto subito prima di modificare WordPress

Abbiamo già approvato il dry run. Potremmo eseguire direttamente, ma costa davvero poco rileggere WordPress subito prima di scrivere.

Il motivo è semplice: lo stato di un post potrebbe essere cambiato tra una query e l’altra. Forse l’hai modificato tu in giorni diversi o l’ha fatto un’altra persona. E vogliamo assicurarci che Codex lavori sulla versione attuale.

Prompt

Esegui una rivalidazione subito prima di eseguire le modifiche.

Consulta di nuovo WordPress e conferma:

– che tutti i post previsti esistano ancora;

– che le relazioni di traduzione non siano cambiate;

– che i term ID del tag siano ancora corretti;

– che i tag attuali coincidano con lo stato che stai per modificare.

Se esiste qualsiasi differenza rispetto al dry run, fermati.

Se tutto coincide, indicami:

– numero totale di post;

– modifiche necessarie;

– post che sono già corretti.

Non eseguire ancora modifiche finché non ti do l’autorizzazione.

Così riduciamo parecchio il rischio.

Passo 9. Esegui la modifica

Se tutto ciò che precede è OK, adesso possiamo autorizzare la scrittura.

A questo punto conviene essere molto precisi su ciò che può e non può essere modificato.

Prompt

Autorizzo l’esecuzione delle modifiche.

Modifica esclusivamente i post inclusi nell’elenco validato.

Per ogni post:

1. Leggi i suoi tag attuali.

2. Identifica la lingua del post.

3. Usa esclusivamente la traduzione del nuovo tag la cui lingua corrisponde esattamente alla lingua di quel post.

4. Ottieni il term ID di quel tag.

5. Controlla se quel term ID è già presente.

6. Se non è presente, aggiungilo all’array attuale dei tag.

7. Conserva tutti gli altri term ID esistenti.

8. Salva l’array completo risultante.

La relazione deve essere sempre:

post in lingua X → tag in lingua X → term ID di quel tag.

Non assegnare mai il term ID del tag spagnolo a un post in un’altra lingua e non usare mai un tag la cui lingua non corrisponda esattamente alla lingua del post.

Se per qualsiasi post non riesci a identificare in modo univoco il tag nella stessa lingua, se manca una traduzione del tag o se la lingua del post e quella del tag non coincidono, non modificare quel post e registra l’errore.

NON modificare:

– titolo;

– contenuto;

– excerpt;

– slug;

– categorie;

– autore;

– data;

– stato;

– immagine in evidenza;

– campi ACF;

– SEO;

– nessun altro dato del post.

Non modificare post al di fuori dell’elenco approvato.

Registra per ogni operazione:

– post ID;

– lingua del post;

– nome del tag assegnato;

– lingua del tag;

– term ID aggiunto;

– tag prima;

– tag dopo;

– codice di risposta di WordPress;

– risultato.

Se un’operazione fallisce, registra l’errore e non cercare di correggerlo modificando altri campi.

Adesso Codex effettuerà le richieste necessarie verso WordPress.

Ma ci resta ancora un controllo.

Passo 10. Rileggi tutti i post

Una risposta corretta della API significa che WordPress ha accettato la richiesta.

Ma se stiamo lavorando con decine o centinaia di articoli, vale la pena controllare lo stato finale, invece di dare semplicemente per scontato che sia andato tutto bene.

Quindi eseguiamo un nuovo giro di query in lettura.

Prompt

Terminate le modifiche, esegui una verifica indipendente tramite nuove richieste GET.

Per ogni post dell’elenco controlla:

1. Che contenga il term ID del nuovo tag corrispondente alla sua lingua.

2. Che conservi tutti i term ID che aveva prima.

3. Che non sia stato aggiunto nessun tag inatteso.

4. Che non sia stato modificato nessun post al di fuori dell’elenco.

Restituisci un riepilogo finale con:

– post controllati;

– modifiche effettuate;

– post che erano già correttamente etichettati;

– errori REST;

– tag precedenti persi;

– post modificati inaspettatamente;

– discrepanze finali.

Considera il compito completato soltanto se ci sono 0 discrepanze.

Con questo chiudiamo il processo.

Non abbiamo soltanto effettuato le modifiche, abbiamo anche verificato che cosa è stato realmente salvato correttamente in WordPress.

Conclusioni

La prima è che per pochi post probabilmente continua a essere più veloce farlo a mano. Ma la scala cambia rapidamente, soprattutto con il multilingua:

• 10 articoli × 10 lingue = 100 post
• 30 articoli × 10 lingue = 300 post
• 50 articoli × 10 lingue = 500 post

A quel punto non si tratta più soltanto di risparmiare clic, ma soprattutto di ridurre gli errori.

L’idea che voglio lasciarti, perché trovo questo sistema davvero utile, è che Codex non decide e non modifica liberamente il tuo WordPress:

• Prima costruisce il sistema.
• Poi simula.
• Poi rivalida.
• Solo allora scrive.
• E alla fine ricontrolla tutto.

Per la manutenzione editoriale su larga scala, mi sembra un modo molto più sensato di usare agenti come Codex.

Infatti ho già chiarissima un’altra modifica che riguarda più di 500 post e che pensavo di fare manualmente via SQL. 

Dopo aver provato questa strada, mi è chiaro che è molto migliore e che la probabilità di errore si riduce notevolmente.

È stato un viaggio di sola andata.