Eine der einfachsten Möglichkeiten, mehr organischen Traffic zu bekommen, ist die Übersetzung einer Website.
Das ist logisch: mehr URLs, mehr Suchintentionen; wenn der Inhalt gut ist, bringt er dir mehr Traffic.
Klar, es mit KI zu machen klingt einfach. Und bei kleinen Websites ist es das auch.
Bei mittleren und großen Websites wird die Sache komplizierter, zumindest wenn man es richtig machen will.
Denn es geht nicht nur darum, einen Artikel auf Spanisch zu nehmen, ihn in ChatGPT einzufügen und fünf Versionen anzufordern.
Das reicht für einen Test, aber eine echte Website hat Kategorien, Tags, SEO, Bilder, benutzerdefinierte Felder, interne Links, Menüs, Archivseiten, Startseiten, Slugs, Daten, hreflang und redaktionelle Struktur.
Ganz zu schweigen davon, dass es in jedem Artikel Fettdruck, Listen und Kursivschrift gibt, die man in der Übersetzung idealerweise beibehält.
Und alles muss übersetzt werden.
Was ich diese Woche auf meiner Website gemacht habe, war der Aufbau eines Systems, um aus einer spanischen Website eine mehrsprachige Website in zehn Sprachen zu machen: Englisch, Französisch, Portugiesisch, Italienisch, Deutsch, Niederländisch, Schwedisch, Polnisch und Norwegisch, mit dem Plugin Polylang, einem selbst entwickelten Plugin und ein paar angepassten GPTs.
Das Ergebnis ist, dass ich die Website jetzt in zehn Sprachen habe, mit der gesamten Kategorien- und Tag-Struktur und mehreren bereits veröffentlichten übersetzten Artikeln.
Und mit einem System, das jedem spanischen Artikel zwischen 5 und 10 Minuten zusätzliche Arbeit hinzufügt, um ihn in diese zehn Sprachen zu übersetzen, was mir mehr als vernünftig erscheint.
Ich erzähle dir den ganzen Prozess, falls du ihn nachbauen willst.
Índice de Contenidos del Artículo
- 1. Das Ausgangsproblem: Artikel zu übersetzen reichte nicht
- 2. Die Basis: WordPress, Polylang und lokale Kopie
- 3. Das System: eigenes Plugin plus GPTs
- 4. Bereits erstellte Inhalte: Schritt für Schritt
- Das Ergebnis
- Erkenntnisse aus dem Prozess und Fazit
- Häufige Fragen
- Ja, aber man sollte es nicht als einfache Textübersetzung angehen. Eine Website hat Artikel, Seiten, Kategorien, Tags, Slugs, SEO-Metadaten, Bilder, interne Links, Menüs, Call-to-Actions und Beziehungen zwischen Sprachen.
- Du brauchst eine gut aufgebaute mehrsprachige Installation, ein System, um jeden Inhalt mit seiner Übersetzung zu verknüpfen, und eine kontrollierte Art, Informationen zu exportieren, zu übersetzen und zu importieren.
- Weil das für einen einzelnen Text funktionieren kann, aber nicht für eine komplette Website.
- Polylang dient dazu, den mehrsprachigen Teil innerhalb von WordPress zu verwalten und jeden Inhalt mit seinen Versionen in anderen Sprachen zu verknüpfen.
- Das eigene Plugin bringt Kontrolle. Es erlaubt, den Inhalt in einem strukturierten Format zu exportieren, ihn außerhalb von WordPress zu übersetzen und ihn wieder zu importieren, während die interne Logik der Website erhalten bleibt.
- Wenn das System einmal aufgebaut ist, kann die Übersetzung eines neuen Artikels nur ein paar zusätzliche Minuten zum Veröffentlichungsablauf hinzufügen.
- Angepasste GPTs können ausreichen, wenn du eine gewisse manuelle Kontrolle behalten und Kosten reduzieren willst. Die API ist sinnvoller, wenn du alles automatisieren, direkt ins Plugin integrieren und die Nutzungskosten tragen willst.
- Ja, aber man muss ihr konkrete Anweisungen geben.
- Zu denken, dass das Übersetzen einer Website nur bedeutet, die Sprache des sichtbaren Textes zu ändern.
1. Das Ausgangsproblem: Artikel zu übersetzen reichte nicht
Als ich die Entwicklung analysierte, stellte ich fest, dass ich in meinem Fall, über die Artikel selbst hinaus, all das hier übersetzen musste:
- Kategorien.
- Tags.
- Slugs.
- Meta-Beschreibungen.
- SEO-Titel.
- Beitragsbilder.
- Alt-Texte.
- ACF-Felder.
- Interne Blöcke.
- Links zwischen Artikeln.
- Archivseiten.
- Feste Texte des Themes.
- Startseiten-Module.
- CTAs.
- Formulare.
- Inhaltsverzeichnisse.
- Verwandte Artikel.
- Daten und Notizen beibehalten.
- …
Viele Texte dort und zu viele Sprachen, um das alles einzeln zu erledigen.
Aber es musste übersetzt werden, denn wenn eines dieser Teile auf Spanisch bleibt, ist die Übersetzung nur halb fertig.
Deshalb ging es nicht darum, „Inhalte zu übersetzen“, sondern eine vollständige und skalierbare mehrsprachige Architektur zu schaffen, falls ich morgen weitere Sprachen hinzufügen möchte.
Und genau das passierte: Ich begann nur mit fünf Sprachen (Englisch, Portugiesisch, Französisch, Deutsch und Italienisch) und fügte die anderen vier unterwegs hinzu. Nebenbei bestätigte ich, dass das System so skalieren konnte, wie ich es brauchte.
2. Die Basis: WordPress, Polylang und lokale Kopie
Das Projekt basiert auf einer WordPress-Website mit Genesis-Theme, eigenem magazinartigem Design und mehreren angepassten Vorlagen.
Da es ein Projekt von gewissem Umfang war und viele Tests erfordern würde, arbeitete ich mit einer lokalen Kopie mit LocalWP. Die Idee war, Dinge ohne Angst kaputtmachen zu können, Importe zu testen, Taxonomien zu prüfen und zu validieren, dass Polylang jede Übersetzung korrekt verknüpfte.
Übrigens, ich habe dieses Plugin als Basis verwendet, weil es bereits alles erzeugt, was man für eine Website in mehreren Sprachen braucht. Darauf aufbauend habe ich mein Plugin erstellt, es ergänzt und an das angepasst, was ich brauchte: die Webstruktur und Artikel in mehreren Sprachen schnell zu erstellen.
Außerdem habe ich in dieser ersten Phase LocalWP optimiert weil die Umgebung anfangs zu langsam war und ich einen Ort brauchte, an dem ich flüssig exportieren, importieren, löschen, wiederholen und validieren konnte..
3. Das System: eigenes Plugin plus GPTs
Ich hätte eine Standardlösung für automatische Übersetzung verwenden können, aber das Ziel war ein anderes.
Einfache Übersetzung jedes Artikels
Bei der Übersetzung der Artikel war ich SEHR ehrgeizig, denn ich wollte ein System, in dem eigens dafür erstellte GPTs den Inhalt jedes Artikels übersetzen und dabei Folgendes beibehalten:
- Meinen Stil persönlich.
- Die gleiche Struktur des Originalartikels.
- Offizielle Titel von Filmen, Serien oder Büchern in jeder Sprache (das heißt: Wenn das Werk spanisch ist, sollte die Übersetzung den Titel verwenden, unter dem es zum Beispiel in Italien veröffentlicht wurde.
- Saubere Slugs.
- Bild-Alt-Texte übersetzt.
- Yoast mit vollständig übersetzten Feldern, einschließlich description.
- Benutzerdefinierte ACF-Felder, sodass ich wählen konnte, ob sie exportiert werden oder nicht, ob sie übersetzt werden oder so bleiben wie sie waren (zum Beispiel die Note, die ich jedem Werk in meinen Rezensionen gebe).
- HTML-Fragmente, ohne sie zu beschädigen: Listen, Fettdruck, Codeblöcke… sie sollten erhalten bleiben, und notwendige Teile sollten unübersetzt bleiben (wie Code-Skripte).
- Interne Links der Artikel: damit sie auf die URL der jeweiligen Sprache zeigen und nicht immer auf das Original.
- Veröffentlichungsdatum: Das Originaldatum des spanischen Artikels muss beibehalten werden.
Wie du siehst, steckt dahinter nicht einfach „übersetzen und fertig“. Dahinter liegen viele Tests und sogar einige Ausschlüsse, wie das Schema das vorerst nur auf Spanisch bleibt.

Und außerdem wollte ich, dass es ein kostenloses Systemist, mit GPTs statt der API von OpenAI oder Claude. Mehr manuell, aber günstiger.
Die Lösung, die ich gewählt habe, umfasst diese Schritte:
- Ich veröffentliche wie gewohnt einen Artikel auf Spanisch.
- Ich nutze mein Plugin, um ein strukturiertes JSON zu exportieren, das den gesamten Artikelinhalt in Übersetzungseinheiten zerlegt enthält.
- Ein GPT übersetzt dieses JSON in die neun Sprachen und gibt mir neun JSON zurück (eins pro Sprache).
- Das Plugin importiert die neun übersetzten JSON.
- Polylang verknüpft jede Übersetzung mit ihrem Original.
- Die Artikel werden als Entwürfe erzeugt.
- Ich prüfe und/oder veröffentliche.
- Ich repariere interne Links (automatisch), falls nötig.
Außerdem gab es einen ersten Schritt: die Struktur in mehreren Sprachen erstellen. Das macht man nur beim ersten Mal, wenn neue Sprachen hinzukommen; bei mir war das zweimal: zuerst für die fünf Anfangssprachen und später für die anderen vier.
Wenn wir diese erste Aufgabe herausnehmen einmalige, fügt der von mir entworfene Prozess nur etwa fünf Minuten mehr zur Erstellung jedes Artikels hinzu während ich den nützlichen Inhalt meiner Website mit neun multipliziere.
Nicht schlecht.
Die mehrsprachige Struktur
Schauen wir:
- Extrem angepasste Website.
- Mit Interface-Texten.
- Eine Startseite, die fast alle Texte im Code gespeichert hatte.
- 23 Kategorien und Unterkategorien, mit ihren Modulüberschriften, vielen Texten in maßgeschneiderten Feldern und ihren SEO-Variablen.
- 24 Tags mit ähnlichen Eigenschaften.
- Mehrere maßgeschneiderte Module.
- Plugins, die Mehrsprachigkeit standardmäßig nicht erlauben.
Und ich weiß nicht, ob ich noch etwas vergesse.
All das musste einmal pro Sprache übersetzt werden. Und das hätte mich, keine Ahnung, mindestens vier Stunden pro Fall gekostet. Und das unter der Annahme, dass ich all diese Sprachen könnte, was nicht der Fall ist.
Auf keinen verdammten Fall.
Was habe ich gemacht?
Nun, diesen Prozess:
- Alle Texte in Variablen umwandeln, im Code und in den benutzerdefinierten Feldern von ACF..
- Eine Funktion im Plugin erstellen, die all diese Variablen jeder Kategorie oder jedes Tags als JSON exportiert.
- Ein GPT erstellen, das dieses JSON in die Sprache übersetzt, die ich brauche.
- Einen Importer im Plugin hinzufügen, der das übersetzte JSON nimmt und die vollständige Taxonomie-Struktur in der neuen Sprache erstellt.
- Den Prozess mit jeder Sprache wiederholen.
- Die Texte ändern, die noch offen waren.
Es gab mehrere Punkte, die genervt haben, wie die Slugs in den Taxonomien, da das einfache Polylang nicht erlaubt, zwei gleiche Slugs zu erstellen (nur mit Pro).
Das heißt, der Tag „comic“ auf Spanisch konnte auf Englisch nicht als „comic“ erstellt werden, sondern musste „comic-en“ oder ähnlich heißen.
Ich habe das Plugin so entwickelt, dass es das erlaubt, indem es dominio.com/comic auf Spanisch und dominio.com/en/comic auf Englisch beibehält.
Yaarp (das Plugin, das ich für verwandte Artikel nutzte) machte ebenfalls Probleme, also deaktivierte ich es, weil es Artikel aus anderen Sprachen empfahl. Wahrscheinlich baue ich ihm künftig eine Funktion, die die Sprache gegenüber den übrigen Variablen in den Empfehlungen priorisiert.
Das Listen-Abonnement in anderen Sprachen habe ich für den Start ebenfalls gestrichen. Vielleicht entscheide ich mich in Zukunft, meinen Newsletter übersetzt zu versenden, aber vorerst mache ich das nicht, also habe ich keine neuen Listen in Acumbamail.
4. Bereits erstellte Inhalte: Schritt für Schritt
Alles, was ich dir erzählt habe, funktioniert hervorragend für neue Artikel, aber was passiert mit den mehr als zweihundert, die ich bereits veröffentlicht habe?
Ich würde dir gern sagen, dass ich eine Funktion erstellt habe, die ihre Übersetzung automatisiert, aber so ist es nicht.
Das Maximum, das ich erreicht habe, ist eine Funktion, die mir exportierte JSON in Chargen mehrerer Artikelerzeugt, aber als ich versucht habe, mehrere Artikel gleichzeitig in neun Sprachen zu übersetzen, verarbeitet GPT sie schlechter. Also vorerst: einer nach dem anderen.

Wenn ich bedenke, dass ich etwa drei Minuten pro Artikel brauche, ist es ziemlich einfach, zehn pro Tag zu übersetzen; damit hätte ich in weniger als einem Monat die gesamte Website in zehn Sprachen.
Passt für mich.
Ich habe auch daran gedacht mir ein Hermes aufzusetzen und zu testen, ob es das manuell erledigt, aber da ich im Moment keine Eile habe und mir das kein Geld bringt, möchte ich nicht mehr Tokens ausgeben als nötig.
Das Ergebnis
Im Moment bin ich zufrieden. Ich habe bereits mehr als zehn Artikel in zehn Sprachen übersetzt. Das heißt, meine Website ist in einer Woche um 33 % gewachsen.
Im Moment erzwinge ich keine Indexierung. Ich möchte warten, bis ich mindestens 50 oder 60 Artikel habe. Aber wenn sie indexiert werden, beunruhigt mich das auch nicht. Das ist langfristig.
Was ich dir sagen kann, ist: Ich bin mit dem Ergebnis zufrieden.
Ich denke, das System, das ich aufgebaut habe, ist ziemlich robust — mit möglichen Verbesserungen, klar — aber selbst in meinen kühnsten Träumen vor einem Jahr hätte ich mir nicht vorstellen können, eine mehrsprachige Website mit diesem Content-Volumen zu verwalten.
Jetzt, wie ich immer sage: Mal sehen, wohin mich das alles führt.
Erkenntnisse aus dem Prozess und Fazit
Die wichtigste Schlussfolgerung — die ich schon erwartet hatte — ist, dass eine Website mit KI zu übersetzen nicht bedeutet, „Texte zu übersetzen“, sondern ein System zu entwerfen.
KI ist super nützlich, wenn sie saubere Eingaben erhält und kontrollierte Ausgaben zurückgibt. Aber wenn du ihr einen riesigen Block ohne Struktur und ohne Regeln gibst, gibt sie dir etwas Hübsches zurück, das sich aber nicht importieren lässt.
Glaub mir, das ist mir am Anfang oft passiert.
Der Schlüssel war, ein System zu bauen, in dem jeder Teil das tut, was er tun soll:
- WordPress ist das Herz von allem.
- Polylang verknüpft Inhalte.
- Das Plugin exportiert und importiert.
- GPT übersetzt.
- Ich treffe die redaktionellen Entscheidungen.
Klar zu wissen, wo jedes Teil hineinpasst und warum es genau das tut und nicht mehr, hat mir ermöglicht, ein echtes System zu schaffen, um eine Website mit KI-Übersetzung als Hebel zu skalieren.
Wenn dir mein System gefallen hat und du möchtest, dass ich einen Punkt genauer erkläre, schreib deine Fragen in die Kommentare und ich antworte.

Schreibe einen Kommentar