Claude als SEO-Übersetzer: 4.500 Seiten, 10 Sprachen

Drei Agenturen haben uns Angebote für die Lokalisierung von skillproof.dev in 10 europäische Sprachen gemacht. Die Summen lagen zwischen 14.000 und 22.000 Dollar, bei sechs bis zehn Wochen Laufzeit – vor allem, weil die Seite nicht statisch ist: über 30 Blogartikel, 106 Katalogkarten mit Skill-Bewertungen, die sich bei jedem erneuten Test ändern, Kategorieseiten und jeder UI-String im Shell-Layout. Eine Agentur kalkuliert das als einmaliges Projekt. Wir brauchten etwas, das einen ganz normalen Dienstag übersteht, an dem wir drei neue Skill-Reviews veröffentlichen und zwei alte überarbeiten.

Also haben wir keine Agentur beauftragt. Stattdessen ließen wir parallele Claude-Agenten laufen, einen pro Sprache, alle mit demselben Regelwerk, und lokalisierten damit rund 4.500 Seiten an etwa einem Tag. Dieser Artikel ist genau dieses Regelwerk: die sechs Regeln, die den Unterschied ausmachen zwischen einem Text, der nach Übersetzung klingt, und einem Text, der klingt, als hätte ihn jemand aus dem jeweiligen Markt selbst geschrieben – dazu die ehrlichen Kosten und die zwei Dinge, die zuerst schiefgingen, bevor wir sie behoben haben.

Das Problem beim Übersetzen einer lebendigen Website

Maschinelle Übersetzung hat das mechanische Problem schon vor Jahren gelöst. Google Translate liefert für jeden englischen Satz grammatikalisch korrektes Deutsch. Grammatik war nie das Problem. Es sind drei Dinge, an die Übersetzungstools nicht herankommen:

SEO-Keywords lassen sich nicht Wort für Wort übersetzen. „How to install Claude skills“ wird nicht durch ein Wörterbuch zu einer deutschen Suchanfrage; deutsche Entwickler suchen „Claude Skills installieren“, Verb am Ende, Produktname unangetastet. Macht man das falsch, ist die deutsche Seite zwar flüssig geschrieben, aber unauffindbar.

Die Anrede ist eine Marktentscheidung, keine Sprachregel. Deutsch kennt „du“ und „Sie“, Französisch „tu“ und „vous“ – welche Form eine Dev-Tools-Marke wählt, ist eine Positionierungsfrage, keine Grammatikfrage. Ein Agenturübersetzer ohne Markenkontext greift standardmäßig zur formellen Anrede, was neben der deutschen Seite von Linear oder Stripe steif wirkt.

Und eine Website ist kein Dokument. Es sind 4.500 Seiten, die sich wöchentlich ändern. Eine einmalige Übersetzungslieferung ist nach einem Monat veraltet, und eine Agentur bei jedem Update neu zu briefen ist kein Workflow, sondern ein Abo, das niemand will.

Wir haben unsere Arbeitsmethode in einen Skill verwandelt, seo-translator, der in unserem Skills-Repo liegt – exakt die Anweisungen, die dieser Artikel beschreibt, kostenlos nutzbar für die eigene Website.

Wie wir es aufgesetzt haben

Der Mechanismus ist einfach: ein Claude-Agent pro Zielsprache, jeder mit dem vollständigen Ausgangstext und demselben Regelwerk, alle parallel statt nacheinander. Zehn Sprachen heißen zehn Agenten, die gleichzeitig arbeiten, statt eines Übersetzers, der sich zwei Monate lang durch eine Warteschlange kämpft.

Jeder Agent bekam ein in sich geschlossenes Briefing: das Ausgangs-Markdown, die Never-translate-Liste, die Standardanrede für den jeweiligen Markt und die Zeichenlimits für Title und Meta-Description der Seite. Kein Agent musste während des Laufs irgendetwas nachfragen – das erwies sich als wichtiger, als wir dachten. Dazu gleich mehr.

Die sechs Regeln

1. Keywords so, wie der Markt sie wirklich sucht

Jeder Artikel und jede Skill-Karte trägt ein Ziel-Keyword. Die Anweisung lautet nicht „übersetze das Keyword“, sondern „finde heraus, wie Entwickler in diesem Markt genau danach suchen“. Für unseren Guide „how to install Claude skills“ ist die wörtliche deutsche Übersetzung grammatikalisch einwandfrei und völlig nutzlos. Getippt wird „Claude Skills installieren“. Dasselbe im Französischen: keine Lehrbuchübersetzung, sondern „installer les skills Claude“, so wie es französische Entwickler-Blogs tatsächlich formulieren. Wir ließen die Agenten die Formulierung gegen echte Vorkommen in Entwicklerforen und Docs-Seiten der jeweiligen Sprache abgleichen, bevor sie sich festlegten – statt einfach das englische Keyword durchs Wörterbuch zu jagen.

2. Anrede pro Markt, vorab festgelegt

Wir haben keinen Agenten den Ton raten lassen. Wir haben eine Tabelle festgelegt, an die sich jeder Agent gehalten hat:

Markt	Anrede	Referenz
Deutsch (de)	du	Linear, Vercel
Französisch (fr)	vous	Stripe, Notion
Spanisch (es)	tú	Die meisten Dev-Tool-Seiten
Italienisch (it)	tu	Informelle Dev-Konvention
Portugiesisch (pt)	você	Brasilianische Dev-Tool-Norm
Niederländisch (nl)	je	Standard bei SaaS
Polnisch (pl)	formell (Pan/Pani vermieden, neutrale Formulierung)	B2B-SaaS-Konvention
Japanisch (ja)	です/ます, kein Keigo	Business-höflicher Standard
Koreanisch (ko)	해요체	SaaS-Standard, nicht das formelle 합쇼체
Schwedisch (sv)	du	Im Schwedischen universell, auch im B2B

Die Kombination Deutsch/Französisch bringt maschinelle Standardübersetzung am stärksten aus dem Tritt, weil beide Sprachen standardmäßig auf die formelle Anrede zurückfallen – dabei zeigen unsere beiden Referenzmarken, dass es sich um eine echte Marktentscheidung handelt und nicht um eine stilistische Nebensache.

3. Eine harte Never-translate-Liste

Jeder Agent bekam dieselbe Ausschlussliste, geprüft bevor eine Ausgabe akzeptiert wurde: Codeblöcke und Inline-Code, CLI-Befehle, Produkt- und Markennamen (Claude, Claude Code, SkillProof, Anthropic), Dateipfade und jeder {placeholder}-Token in UI-Strings. Klingt selbstverständlich, bis man einen ersten Übersetzungsdurchgang sieht, der npm install als übersetzte Verbphrase ausgibt oder SKILL.md still und heimlich umbenennt. Wir haben das als Prüfschranke behandelt, nicht als Empfehlung: Jede Ausgabe mit einem übersetzten Codeblock oder einem veränderten Platzhalter fiel automatisch durch und wurde neu generiert.

4. Der Anti-KI-Durchgang

Der erste Entwurf jeder LLM-Übersetzung verrät sich durch bestimmte Muster: Calques (englische Satzstruktur in Zielsprachen-Vokabular), stehende KI-Floskeln, die eins zu eins mitübersetzt wurden („in der heutigen schnelllebigen Welt“ hat in jeder Sprache eine Entsprechung, und die ist genauso abgenutzt), und eine Flachheit, die ein Muttersprachler nach einem Absatz erkennt. Wir haben pro Sprache einen eigenen zweiten Durchgang gefahren, dessen einzige Aufgabe es war, genau das aufzuspüren – Sätze umzubauen, die offensichtlich englische Wortstellung in deutschem Vokabular trugen, übersetzte Füllwörter durch das zu ersetzen, womit ein Tech-Autor aus dem jeweiligen Markt den Absatz tatsächlich eröffnen würde. Dieser Durchgang ist der Grund, warum der Text wie von einem Muttersprachler geschrieben wirkt und nicht wie ein gut übersetztes Dokument.

5. Token-Disziplin

Das ist der Punkt, der das Ganze bezahlbar macht statt bloß machbar. Ein Durchgang pro Sprache, kein Entwurf-dann-Überarbeitung-dann-Politur. Kein Nacherzählen des Ausgangstexts vor der Übersetzung – eine Angewohnheit, die den Token-Verbrauch klammheimlich verdoppelt, ohne die Qualität zu verbessern. Und Batch-Verarbeitung: Katalogkarten werden in Stapeln übersetzt statt mit einem API-Aufruf pro Karte, denn der Overhead pro Aufruf summiert sich bei 106 kurzen Karten schnell.

6. Zeichenlimits pro Sprache durchgesetzt, nicht angenommen

Title-Tags mit 60 Zeichen und Meta-Descriptions mit 155 sind eine englischsprachige Faustregel, die im Deutschen nicht mehr trägt, wo zusammengesetzte Substantive lang ausfallen, oder im Japanischen, wo Zeichenanzahl etwas völlig anderes bedeutet als in lateinischer Schrift. Wir haben jedem Agenten das Limit als harte Vorgabe mitgegeben, geprüft am tatsächlich gerenderten String und nicht an der Länge des englischen Ausgangstexts, damit deutsche Titel nicht allein deshalb über 60 Zeichen hinausschießen, weil das deutsche Wort für „Übersetzer“ unpraktisch lang ist.

Was es wirklich gekostet hat

Wir haben den Token-Verbrauch über den gesamten Lauf protokolliert. Das sind echte Zahlen aus unserer eigenen Sonnet-Nutzung, keine Schätzungen:

Inhaltstyp	Tokens pro Sprache	Anmerkungen
Blogartikel mit ca. 2.500 Wörtern	120.000–160.000	Ausgangstext + Übersetzung + Anti-KI-Durchgang
106 Katalog-Skill-Karten (im Batch)	150.000–170.000	Kurze Karten, aber 106 Stück summieren sich
Kategorie- und UI-Strings	Unter 20.000	Klein, größtenteils statisch

Über 10 Sprachen hinweg kam die komplette Lokalisierung der Website auf ein paar Dollar API-Kosten – nicht auf die über 14.000 Dollar, die man uns für ein langsameres, schneller veraltendes Ergebnis angeboten hatte. Der gesamte Lauf – über 30 Artikel, 106 Karten, Kategorieseiten und UI-Strings, über 10 Sprachen hinweg – dauerte etwa einen Tag mit parallel laufenden Agenten, größtenteils unbeaufsichtigt, sobald die Briefings standen. Das ist die Zahl, die die Rechnung wirklich verändert: Es geht nicht darum, dass KI-Übersetzung günstiger ist als eine Agentur, sondern dass sie günstig genug ist, um bei jeder Änderung des Ausgangstexts neu zu laufen – etwas, das eine einmalige Agenturlieferung nie leisten kann.

Was schiefging

Zwei Fehlerarten waren es wert, vor dem Livegang abgefangen zu werden, und keine davon wäre ohne Validierung aufgefallen.

Der erste Fehler waren Agenten, die „wartend“ meldeten, statt eine Ausgabe zu liefern – meist weil ein Briefing auf etwas außerhalb des eigenen Kontexts des Agenten verwies, etwa „nutze dieselbe Formulierung wie die deutsche Version“ bei einem Agenten, der gar keinen Zugriff auf die deutsche Ausgabe hatte. Die Lösung: jedes Briefing vollständig in sich geschlossen zu machen – keine Verweise auf andere Agenten, kein „prüf das mit dem anderen Lauf ab“, alles, was der Agent zum Abschluss der Aufgabe brauchte, direkt mitgeliefert.

Der zweite Fehler war ein Diakritika-Verlust bei einem Stapel polnischer Katalogkarten: Irgendwo in der Pipeline hat ein Formatierungsschritt still und heimlich die Sonderzeichen entfernt, in einem Terminal sah die Ausgabe noch unauffällig aus, auf der Seite war sie falsch. Wir haben es entdeckt, weil wir durch Zählen validieren, nicht durch Lesen von Agentenberichten: Jede übersetzte Datei wird gegen den Ausgangstext geprüft – Zeichenanzahl-Plausibilität, Anzahl der Überschriften und ein Abgleich der unübersetzten Tokens (Codeblöcke, Platzhalter, Produktnamen), die unverändert bleiben sollten. Wenn ein Agent „Übersetzung fertig“ meldet, ist das kein Beweis. Eine Datei mit derselben Anzahl an Überschriften wie das Original, denselben unangetasteten Codeblöcken und einem Titel unter dem Zeichenlimit des Markts – das ist ein Beweis.

hreflang-Tags sind der Teil, der aus 10 Sprachversionen eine einzige indexierbare Website macht statt zehn konkurrierender. Jede Sprachversion braucht gegenseitige hreflang-Links, die auf jede andere Version und auf sich selbst verweisen – sonst rankt eine Suchmaschine für eine Anfrage munter die falschsprachige Seite. Ist die URL-Struktur einmal festgelegt, ist das reine Mechanik, aber es ist auch der Schritt, den die meisten DIY-Übersetzungsprojekte auslassen, und es lohnt sich, ihn richtig zu machen, bevor die erste lokalisierte Seite online geht. Unser Installationsguide behandelt die Skill-Installation, falls du das als wiederholbaren Skill statt als Einmalskript aufsetzt.

Was wir einem Team raten würden, das am Montag startet

Übersetze nicht am ersten Tag gleich die ganze Website. Wähle die zwei, drei Seiten mit dem meisten Traffic, lass sie durch alle 10 Sprachen laufen und prüfe die Ausgabe gegen einen Muttersprachler, bevor du auf den Rest skalierst. Die Regeln oben haben wir gelernt, indem wir sie zuerst falsch gemacht haben; überspringst du diesen Schritt, lernst du sie auf 4.500 Seiten statt auf dreien neu.

Schreib die Anrede-Tabelle, bevor du auch nur ein übersetztes Wort schreibst. Das ist eine geschäftliche Entscheidung, keine sprachliche, und darüber am Anfang zu streiten ist deutlich billiger, als es nachträglich zu korrigieren, wenn 106 Karten schon das falsche Pronomen benutzen.

Validiere durch Zählen, nicht durch Nachfragen. Wenn deine Pipeline dir nicht mechanisch sagen kann, dass eine übersetzte Datei die richtige Anzahl an Überschriften und unangetastete Codeblöcke hat, hast du keine Übersetzungspipeline, sondern nur eine Hoffnung.

Und wenn du das für eine inhaltsschwere Website machst statt für eine Handvoll statischer Seiten: Dieselbe Disziplin, die eine Content-Strategie über Dutzende Artikel hinweg zusammenhält, hält auch einen Übersetzungslauf über Dutzende Sprachen hinweg zusammen – ein Regelwerk, konsequent angewendet, jedes Mal gegen den Ausgangstext geprüft. Wie wir uns selbst an diesem Maßstab messen, haben wir unter wie wir Claude-Skills testen beschrieben.

Willst du den Keyword-Lokalisierungsschritt erst an einer einzelnen Seite ausprobieren, bevor du dich auf einen vollen Lauf festlegst, formatiert unser SEO-Konverter die Ausgabe; unsere Seite mit den besten Schreib-Skills rankt die getesteten Skills, die sich dazu kombinieren lassen, darunter SEO Audit für alles, was ein reiner Übersetzungsdurchgang nicht abfängt, etwa defekte interne Links zwischen den Sprachversionen.

FAQ

Kann Claude wirklich eine ganze Website übersetzen, nicht nur einzelne Seiten?

Ja, aber nicht als ein riesiger Prompt. Was bei uns funktioniert hat: die Website in parallel laufende Agenten pro Sprache aufzuteilen, jeder mit einem in sich geschlossenen Briefing, das das komplette Regelwerk abdeckt – Keyword-Lokalisierung, Anrede, Never-translate-Liste und Zeichenlimits. Ein einzelner Agent, der versucht, 10 Sprachen in einem Kontext zu halten, verliert schnell an Konsistenz; 10 Agenten, die je eine Sprache halten, blieben konsistent, weil das Briefing die Regeln trug – nicht das Gedächtnis des Agenten.

Reicht KI-Übersetzung für SEO, oder braucht es einen menschlichen Durchgang?

Bei technischen Inhalten und Marketingtexten kommt ein gut gebrieftes Claude-Ergebnis nah genug heran, dass eine stichprobenartige Prüfung durch einen Muttersprachler das richtige Maß an menschlichem Eingriff ist – keine komplette Neuübersetzung. Das SEO-spezifische Risiko liegt nicht in der Grammatik, sondern in der Keyword-Formulierung: Ein Agent, der wörtlich statt marktgerecht übersetzt, produziert flüssige, aber unauffindbare Seiten. Deshalb dreht sich Regel eins in diesem Artikel um die Suchformulierung, nicht um Grammatik.

Was kostet es, eine Website mit Claude in mehrere Sprachen zu übersetzen?

Basierend auf unserem eigenen Lauf: Ein Artikel mit 2.500 Wörtern kostet auf Sonnet rund 120.000–160.000 Tokens pro Sprache, und 106 kurze Katalogkarten kosten im Batch rund 150.000–170.000 Tokens pro Sprache. Über 10 Sprachen kam unsere komplette Website-Lokalisierung insgesamt auf ein paar Dollar API-Kosten. Der größere Kostenfaktor ist nicht die Token-Menge, sondern die Zeit für den Aufbau des Regelwerks und der Validierungsschritte – die zahlt man einmal und nutzt sie bei jedem künftigen Update wieder.

Was ist der größte Fehler, den Teams bei der Lokalisierung mit KI machen?

Die Validierung auszulassen und der eigenen „fertig“-Meldung des Agenten zu vertrauen. Wir haben einen Diakritika-Bug und ein Problem mit hängenden Agenten nur entdeckt, weil wir die übersetzte Ausgabe mechanisch gegen den Ausgangstext prüfen – Überschriftenanzahl, unangetastete Codeblöcke, Zeichenlimits – statt zu lesen, was der Agent behauptet, getan zu haben. Behandle jeden Übersetzungslauf so, als bräuchte er dieselbe Abnahmeschranke wie eine Codeänderung: Prüfe das Artefakt, nicht den Bericht.