Wie man alte Beiträge in WordPress mit Codex-KI in mehreren Sprachen neu verschlagwortet

Vor Kurzem stand ich vor einer für mich neuen Herausforderung: wie man ein neues Schlagwort hinzufügt — in meinem Fall „ Science-Fiction “ — und zwar zu allen Artikeln, sowohl auf Spanisch als auch in den übrigen Sprachen. 

Also fast 3.000 Artikel, die man:

• Analysieren musste, um zu sehen, zu welchen das Tag wirklich passt.
• Jeweils mit dem Tag in der entsprechenden Sprache versehen musste, ohne die übrigen Tags zu löschen.
• Anschließend überprüfen musste, ob alles geklappt hat.

Das Tag in jeder Sprache anzulegen, war mit meiner eigenen Entwicklung kein Problem. Die eigentliche Schwierigkeit bestand darin, nur die alten Artikel zu taggen, die es wirklich bekommen sollten.

Natürlich könnte man das von Hand machen, aber nach der Durchsicht der Inhalte hatte ich am Ende eine Liste mit 12 Artikeln auf Spanisch. Das bedeutet: Da die Website in zehn Sprachen übersetzt ist, musste ich insgesamt 120 Posts.

taggen. Jeden einzelnen Beitrag in seiner Sprache zu suchen, zu öffnen und das Tag 120 Mal hintereinander hinzuzufügen, darauf hatte ich ehrlich gesagt keine Lust.

Also dachte ich, das sei eine ziemlich passende Aufgabe für Codex.

Außerdem wollte ich diesen recht einfachen Fall als Grundlage für etwas viel Allgemeineres nutzen: Änderungen automatisch auf viele Artikel anwenden, ohne dem Agenten zu erlauben, eigenmächtig und wild Änderungen vorzunehmen.

Genau das erkläre ich dir in diesem Tutorial.

Ziel

Ganz einfach: Einer geschlossenen Liste bestimmter WordPress-Posts ein bestimmtes Tag hinzufügen.

Einschließlich der passenden Übersetzung dieses Tags für jede Sprachversion des Artikels, mit Polylang, dem mehrsprachigen Plugin, das ich verwende.

Und wir machen das nicht irgendwie, sondern mit ein paar Vorsichtsmaßnahmen:

• Wir arbeiten mit einer geschlossenen Artikelliste.
• Zuerst prüfen wir, was Codex ändern will.
• Wir erstellen nicht automatisch neue Tags.
• Wir behalten alle Tags bei, die jeder Post bereits hat.
• Vor dem Schreiben führen wir eine Simulation durch.
• Danach prüfen wir WordPress erneut, um das Ergebnis zu kontrollieren.

Dein Fall muss nicht genau meinem entsprechen. Es reicht, wenn du bei einer bestimmten Reihe von WordPress-Posts etwas ändern möchtest, was dich manuell eine ganze Weile kosten würde.

Ich selbst verwende Codex, aber der Ablauf funktioniert genauso, wenn du lieber Claude Code oder Antigravity nutzt. Das Werkzeug ändert sich, die Schritte nicht.

Schritt 1. Erstelle das Tag, bevor du beginnst

Als Erstes muss das Tag, das du anwenden möchtest, bereits in WordPress angelegt sein.

Das sollte man am besten manuell tun, denn ich möchte nicht, dass Codex entscheidet, wie die Taxonomie der Website organisiert werden soll. Es soll sich darauf beschränken, etwas zu finden, das bereits existiert und es bestimmten Posts zuzuweisen.

In WordPress kannst du das, wie du weißt, hier erledigen:

Beiträge > Schlagwörter

Wenn deine Website nur eine Sprache hat, bist du mit diesem Schritt praktisch schon fertig.

Wenn du Polylang verwendest (Pro-Version oder mit eigener Entwicklung darüber, wie bei mir), erstelle auch die Übersetzungen des Tags und prüfe, ob sie korrekt miteinander verknüpft sind.

Zum Beispiel hatte ich in meinem Fall:

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

Und so weiter.

WordPress speichert sie intern als unterschiedliche Begriffe (Tags), und jeder hat seine eigene ID. Das wird später wichtig.

Eine Anmerkung: Ich habe ein selbst entwickeltes Plugin, das sie automatisch in allen Sprachen erstellt. Du wirst sie wahrscheinlich manuell anlegen müssen, Sprache für Sprache.

Prompt zum Prüfen der Tags

Wenn du sie erstellt hast, kannst du Codex bitten, sie zu finden:

Ich möchte mehreren WordPress-Posts ein bereits vorhandenes Tag hinzufügen.

Das Haupt-Tag ist:

[NAME DES TAGS]

Ändere vorerst keinerlei Daten.

Finde das Tag in WordPress und, falls die Website Polylang verwendet, alle seine Übersetzungen.

Gib mir für jede Sprache zurück:

– Sprache;

– Name des Tags;

– Slug;

– term ID.

Erstelle keine neuen Tags.

Wenn eine Übersetzung fehlt, Duplikate vorhanden sind oder irgendeine Mehrdeutigkeit besteht, stoppe und informiere mich.

Die term ID ist einfach die Nummer, mit der WordPress dieses Tag intern identifiziert. Wichtig ist, dass Codex weiß, welche ID zu welcher Sprache gehört.

Schritt 2. Bereite eine geschlossene Artikelliste vor

Jetzt müssen wir entscheiden, welche Posts wir ändern möchten.

Hier empfehle ich, dem Agenten nicht zu viel Freiheit zu lassen.

Wir könnten ihn bitten:

Finde alle Artikel zum Thema Science-Fiction und tagge sie.

Dann würden wir allerdings zwei sehr unterschiedliche Aufgaben vermischen:

1. Redaktionell entscheiden, welche Inhalte das Tag erhalten sollen.
2. Dieselbe Änderung 20, 100 oder 500 Mal in WordPress ausführen.

Ich trenne beides lieber, damit ich jeden Schritt kontrollieren kann.

Du kannst die Liste manuell erstellen, wenn die Zahl der Artikel nicht sehr groß ist.

Du kannst auch ChatGPT oder Codex nutzen, um Kandidaten zu finden.

In meinem Fall war das Volumen groß, deshalb habe ich die drei Artikel-Sitemaps übergeben und ChatGPT gebeten, anhand der URL Kandidaten vorzuschlagen.

Egal, wie du es machst, am Ende solltest du eine konkrete Artikelliste haben, bevor du irgendetwas änderst.

Zum Beispiel:

• Blade Runner: Kritik und Analyse.
• Die besten Science-Fiction-Comics.
• Akira: Manga und Film.
• El Eternauta: Serienkritik.
• …

Wie gesagt, am Ende hatte ich 12 Artikel pro Sprache, nachdem ich einige Kandidaten gestrichen hatte, die ChatGPT passend fand, ich aber nicht.

Prompt zum Vorbereiten des Arbeitsumfangs

Wenn du die Liste hast, gib Codex Folgendes:

Ich werde dir eine geschlossene Liste von WordPress-Artikeln geben.

Arbeite ausschließlich mit diesen Artikeln.

Füge keine weiteren Inhalte hinzu, auch wenn du meinst, dass sie ebenfalls zum Tag passen könnten.

Liste:

[HIER TITEL ODER URLS EINFÜGEN]

Nimm vorerst keine Änderungen vor.

Finde jeden Post und gib zurück:

– Titel;

– URL;

– post ID;

– Status;

– Sprache.

Wenn einer nicht eindeutig identifiziert werden kann, stoppe und kennzeichne ihn.

Damit haben wir beide Seiten der Operation definiert:

1. Welche Posts wir taggen möchten
2. Welches Tag wir hinzufügen möchten.

Schritt 3. Richte den Codex-Zugriff auf WordPress ein

Um bestimmte WordPress-Eigenschaften lesen und vor allem Posts ändern zu können, muss sich Codex authentifizieren.

Dafür gibt es verschiedene, mehr oder weniger sichere Möglichkeiten. Eine recht bequeme Methode ist ein WordPress Application Password.

Das ist nicht dein normales Passwort für das Dashboard. Es ist ein zusätzliches Passwort, das speziell erstellt wird, damit sich eine Anwendung über die REST API. 

Du kannst es jederzeit widerrufen, ohne dein normales Passwort ändern zu müssen.

Du erstellst es unter:

Benutzer > Profil > Anwendungspasswörter

Gib ihm einen Namen, an dem du es später erkennst, zum Beispiel „Codex“.

WordPress erzeugt ein Passwort.

Wie man Codex das Passwort zur Verfügung stellt

Schreibe das Passwort nicht direkt in den Prompt

Es könnte zwar funktionieren, aber Passwörter in die Cloud zu schicken, ist keine gute Gewohnheit.

Am besten speicherst du es lokal als Umgebungsvariable oder in einer .env Datei, die nicht ins Repository hochgeladen wird, falls du mit Git arbeitest.

Zum Beispiel kannst du eine .env-Datei mit nur diesen drei Zeilen speichern:

WP_URL=https://tudominio.com

WP_USERNAME=tu_usuario

WP_APP_PASSWORD=tu_application_password

Speichere sie unter C:UsersTU_USUARIO_WINDOWS.codex.env

Und füge .env zu .gitignore hinzu, damit die Datei nicht hochgeladen wird.

Die Idee ist, dass Codex die Zugangsdaten verwenden kann, ohne sie ständig anzeigen oder kopieren zu müssen.

Nachdem du die entsprechende Datei erstellt hast, musst du Codex schließen und erneut öffnen, damit es sie einliest.

Zwei wichtige Dinge: 

1. Der WordPress-Benutzername muss nicht mit dem öffentlichen Namen übereinstimmen, der als Autor angezeigt wird. Trage in der Datei den tatsächlichen Benutzernamen ein.
2. Der von WordPress erzeugte Schlüssel enthält Leerzeichen. Entferne sie beim Speichern in der .env-Datei. Sonst funktioniert es nicht.

Prompt für diesen Teil

Gib Codex nach dem vorherigen Schritt diesen Prompt:

Verwende die WordPress-Zugangsdaten aus den lokalen Umgebungsvariablen.

Zeige, drucke oder kopiere keine Passwörter, Tokens oder anderen Geheimnisse in der Ausgabe.

Ändere noch keine Inhalte.

Prüfe lediglich, ob die benötigten Variablen verfügbar sind.

So weißt du, ob Codex sie korrekt übernommen hat; das ist ein unverzichtbarer Schritt, bevor du weitermachst.

Schritt 4. Prüfe, ob Codex eine Verbindung herstellen kann

Als Nächstes prüfen wir, ob die Verbindung funktioniert.

Die REST API ist im Grunde die Schnittstelle, über die Codex WordPress Dinge fragen kann wie Welche Tags hat dieser Post? oder Füge dieses Tag hinzu und speichere den Artikel.

Im Moment möchten wir nur das Erste tun. Bitte Codex daher um eine reine Leseabfrage:

Prüfe die Authentifizierung gegenüber der WordPress REST API.

Führe ausschließlich GET-Anfragen aus.

Bestätige:

– dass die Verbindung funktioniert;

– welcher WordPress-Benutzer authentifiziert ist;

– dass dieser Benutzer die Berechtigung hat, die Posts zu bearbeiten, mit denen wir arbeiten werden.

Wenn ein Authentifizierungs- oder Berechtigungsfehler auftritt, stoppe.

Führe keine Schreibanfragen aus.

Wenn alles stimmt, haben wir Zugriff. Bei einem Fehler 401 solltest du normalerweise die Zugangsdaten prüfen.

Schritt 5. Finde die Übersetzungen jedes Posts

Dieser Schritt ist nur nötig, wenn deine Website mehrsprachig.

Wenn du Polylang verwendest, soll Codex Übersetzungen nicht durch den Vergleich von Titeln suchen, denn Titel können sich zwischen Sprachen stark unterscheiden.

Wir möchten, dass es die bereits vorhandenen Übersetzungsbeziehungen von WordPress/Polylang verwendet.

Wir beginnen mit jedem Originalartikel und suchen seine Sprachversionen.

Der Prompt

Finde ausgehend ausschließlich von den Posts der genehmigten Liste ihre Übersetzungen anhand der Polylang-Beziehungen.

Suche Übersetzungen nicht anhand ähnlicher Titel.

Gib für jeden Artikel zurück:

– Original-Post;

– Sprache;

– Titel der Übersetzung;

– post ID;

– URL.

Die Website verwendet diese Sprachen:

[SPRACHENLISTE]

Jeder Artikel sollte haben:

[ANZAHL DER VERSIONEN]

Versionen insgesamt.

Wenn eine Übersetzung fehlt oder du eine inkonsistente Beziehung findest, stoppe und ändere nichts.

Hier haben wir eine sehr einfache Prüfung, die sich lohnt.

Wenn du 25 Artikel × 5 Sprachen = 125 Posts Codex sollte exakt Folgendes finden: 125.

Wenn es 124 findet, sollte es nicht fortfahren.

Schritt 6. Führe einen vollständigen dry run durch

Jetzt haben wir genügend Informationen, um die eigentliche Operation aufzubauen, aber wir führen sie noch nicht aus.

Zuerst machen wir einen dry run, also nichts anderes als eine Simulation dessen, was passieren würde, wenn wir die Änderungen erlaubten.

Codex soll eine Tabelle erstellen, die Folgendes verknüpft: Post > Sprache > entsprechendes Tag > aktueller Status.

Prompt

Führe jetzt einen vollständigen dry run der Operation durch.

Führe keine POST-, PUT-, PATCH- oder DELETE-Anfragen aus.

Für jeden Post in der validierten Liste:

1. Frage seine aktuellen Tags ab.

2. Bestimme die Sprache des Posts.

3. Finde die Übersetzung des neuen Tags, die genau derselben Sprache entspricht.

4. Ermittle die term ID dieses Tags.

5. Prüfe, ob diese term ID dem Post bereits zugewiesen ist.

6. Berechne, wie das endgültige Tags-Array nach dem Hinzufügen aussehen würde, wobei alle vorhandenen term IDs erhalten bleiben.

Die Beziehung muss immer lauten:

Post in Sprache X → Tag in Sprache X → term ID dieses Tags.

Weise einem Post in einer anderen Sprache niemals die term ID des spanischen Tags zu und verwende niemals ein Tag, dessen Sprache nicht exakt mit der Sprache des Posts übereinstimmt.

Gib eine Tabelle zurück mit:

– post ID;

– Sprache des Posts;

– Titel;

– aktuellen Tags;

– Name des Tags, das zu dieser Sprache gehört;

– Sprache des Tags;

– term ID, die hinzugefügt werden müsste;

– ob sie bereits vorhanden ist;

– erwarteten endgültigen Tags.

Prüfe ausdrücklich, dass die Sprache des Posts und die Sprache des Tags in allen Fällen übereinstimmen.

Wenn du einen Post findest, für den du das Tag in derselben Sprache nicht eindeutig bestimmen kannst, wenn eine Tag-Übersetzung fehlt oder wenn die Sprache des Posts und die des Tags nicht übereinstimmen, stoppe und ändere nichts.

Gib am Ende an:

– Gesamtzahl der Posts;

– Posts, die geändert werden müssen;

– Posts, die das Tag bereits enthalten;

– Fehler oder Inkonsistenzen.

Schreibe noch nichts.

Dieser Schritt hat zwei Vorteile.

Der erste ist offensichtlich: Wir können genau sehen, was Codex vorhat.

Der zweite ist, dass wir Posts entdecken werden, die das Tag bereits haben.

Diese Artikel müssen nicht erneut geändert werden.

In meinem Fall waren es 120 Posts, aber 2 waren bereits korrekt getaggt (das hatte ich manuell gemacht).

Schritt 7. Prüfe, dass keine Tags gelöscht werden

Auf diesen Punkt würde ich am meisten achten.

Stell dir vor, ein Artikel hat bereits diese Tags:

• Bitcoin.
• Investition.
• Tutorial.

Und wir möchten „Besteuerung“ hinzufügen.

Das gewünschte Ergebnis ist natürlich, dass der Artikel alle vier enthält, nicht nur Besteuerung.

Das klingt selbstverständlich, aber wenn du über die REST API arbeitest, musst du bedenken, dass das Feld tags die vollständige Menge der Tags darstellt, die der Post haben soll.

Deshalb muss Codex zuerst die vorhandenen IDs lesen, die neue hinzufügen und anschließend die vollständige Menge senden.

Wir wollen nicht ersetzen, sondern hinzufügen.

Du kannst das mit einem eigenen Prompt noch einmal verstärken:

Prüfe vor dem Ausführen der Änderungen diese Regel:

Ersetze NIEMALS die aktuellen Tags des Posts nur durch das neue Tag.

Für jeden Post:

1. Lies das aktuelle Array der term IDs.

2. Behalte alle vorhandenen IDs bei.

3. Prüfe, ob die neue term ID bereits vorhanden ist.

4. Falls nicht, füge sie dem Array hinzu.

5. Lösche oder ändere keine andere term ID.

Zeige mir jeden Fall, in dem du diese Operation nicht garantieren kannst.

Schreibe noch nicht.

Wenn du eine solche Operation automatisierst, würde ich diese Prüfung nicht überspringen.

Schritt 8. Validiere alles unmittelbar vor der Änderung von WordPress erneut

Der dry run ist bereits genehmigt. Wir könnten direkt ausführen, aber es kostet praktisch nichts, WordPress unmittelbar vor dem Schreiben noch einmal auszulesen.

Der Grund ist einfach: Der Zustand eines Posts könnte sich zwischen zwei Abfragen geändert haben. Vielleicht hast du ihn an verschiedenen Tagen bearbeitet oder jemand anderes hat es getan. Wir möchten sicherstellen, dass Codex mit der aktuellen Version arbeitet.

Prompt

Führe unmittelbar vor dem Ausführen der Änderungen eine erneute Validierung durch.

Frage WordPress erneut ab und bestätige:

– dass alle vorgesehenen Posts weiterhin existieren;

– dass sich die Übersetzungsbeziehungen nicht geändert haben;

– dass die term IDs des Tags weiterhin korrekt sind;

– dass die aktuellen Tags dem Zustand entsprechen, den du ändern willst.

Wenn es irgendeine Abweichung vom dry run gibt, stoppe.

Wenn alles übereinstimmt, nenne mir:

– Gesamtzahl der Posts;

– notwendige Änderungen;

– Posts, die bereits korrekt sind.

Führe noch keine Änderungen aus, bis ich dir die Erlaubnis gebe.

So reduzieren wir das Risiko deutlich.

Schritt 9. Führe die Änderung aus

Wenn alles oben OK ist, können wir das Schreiben jetzt autorisieren.

An diesem Punkt sollte sehr genau festgelegt werden, was geändert werden darf und was nicht.

Prompt

Ich autorisiere die Ausführung der Änderungen.

Ändere ausschließlich die Posts in der validierten Liste.

Für jeden Post:

1. Lies seine aktuellen Tags.

2. Bestimme die Sprache des Posts.

3. Verwende ausschließlich die Übersetzung des neuen Tags, deren Sprache exakt der Sprache dieses Posts entspricht.

4. Ermittle die term ID dieses Tags.

5. Prüfe, ob diese term ID bereits vorhanden ist.

6. Falls sie nicht vorhanden ist, füge sie dem aktuellen Tags-Array hinzu.

7. Behalte alle anderen vorhandenen term IDs bei.

8. Speichere das vollständige resultierende Array.

Die Beziehung muss immer lauten:

Post in Sprache X → Tag in Sprache X → term ID dieses Tags.

Weise einem Post in einer anderen Sprache niemals die term ID des spanischen Tags zu und verwende niemals ein Tag, dessen Sprache nicht exakt mit der Sprache des Posts übereinstimmt.

Wenn du für einen Post das Tag in derselben Sprache nicht eindeutig bestimmen kannst, eine Tag-Übersetzung fehlt oder die Sprache des Posts und des Tags nicht übereinstimmen, ändere diesen Post nicht und protokolliere den Fehler.

Ändere NICHT:

– Titel;

– Inhalt;

– Excerpt;

– Slug;

– Kategorien;

– Autor;

– Datum;

– Status;

– Beitragsbild;

– ACF-Felder;

– SEO;

– keine anderen Daten des Posts.

Ändere keine Posts außerhalb der genehmigten Liste.

Protokolliere für jede Operation:

– post ID;

– Sprache des Posts;

– Name des zugewiesenen Tags;

– Sprache des Tags;

– hinzugefügte term ID;

– Tags vorher;

– Tags nachher;

– WordPress-Antwortcode;

– Ergebnis.

Wenn eine Operation fehlschlägt, protokolliere den Fehler und versuche nicht, ihn durch Änderungen an anderen Feldern zu beheben.

Jetzt führt Codex die notwendigen Anfragen an WordPress aus.

Aber eine Prüfung fehlt noch.

Schritt 10. Lies alle Posts erneut

Eine erfolgreiche API-Antwort bedeutet, dass WordPress die Anfrage akzeptiert hat.

Wenn wir aber mit Dutzenden oder Hunderten von Artikeln arbeiten, lohnt es sich, den endgültigen Zustand, statt einfach anzunehmen, dass alles geklappt hat.

Deshalb führen wir eine neue Runde von Leseabfragen aus.

Prompt

Führe nach Abschluss der Änderungen eine unabhängige Prüfung mit neuen GET-Anfragen durch.

Prüfe für jeden Post der Liste:

1. Dass er die term ID des neuen Tags enthält, die zu seiner Sprache gehört.

2. Dass alle term IDs erhalten geblieben sind, die er vorher hatte.

3. Dass kein unerwartetes Tag hinzugefügt wurde.

4. Dass kein Post außerhalb der Liste geändert wurde.

Gib eine abschließende Zusammenfassung zurück mit:

– überprüften Posts;

– vorgenommenen Änderungen;

– Posts, die bereits korrekt getaggt waren;

– REST-Fehlern;

– verlorenen vorherigen Tags;

– unerwartet geänderten Posts;

– abschließenden Abweichungen.

Betrachte die Aufgabe nur dann als abgeschlossen, wenn es 0 Abweichungen gibt.

Damit schließen wir den Prozess ab.

Wir haben nicht nur die Änderungen vorgenommen, sondern auch geprüft, was tatsächlich korrekt in WordPress gespeichert wurde.

Fazit

Erstens: Bei wenigen Posts ist es wahrscheinlich weiterhin schneller, alles von Hand zu erledigen. Aber die Größenordnung ändert sich schnell, besonders bei mehreren Sprachen:

• 10 Artikel × 10 Sprachen = 100 Posts
• 30 Artikel × 10 Sprachen = 300 Posts
• 50 Artikel × 10 Sprachen = 500 Posts

Ab diesem Punkt geht es nicht mehr nur darum, Klicks zu sparen, sondern vor allem darum, Fehler zu reduzieren.

Die Idee, die du aus diesem System mitnehmen sollst, weil ich sie wirklich nützlich finde, ist: Codex entscheidet und verändert dein WordPress nicht frei:

• Zuerst baut es das System auf.
• Dann simuliert es.
• Dann validiert es erneut.
• Erst danach schreibt es.
• Und am Ende prüft es wieder alles.

Für redaktionelle Massenpflege scheint mir das eine deutlich vernünftigere Art zu sein, Agenten wie Codex zu verwenden.

Tatsächlich habe ich schon ganz klar eine weitere Änderung im Kopf, die mehr als 500 Posts betrifft und die ich ursprünglich manuell per SQL durchführen wollte. 

Nach diesem Test ist für mich klar, dass dieser Weg viel besser ist und die Fehlerwahrscheinlichkeit erheblich sinkt.

Das war eine Reise ohne Rückfahrkarte.