2021 kam ein deutscher E-Commerce-Client zu Seahawk mit einem Brief, der im Grunde sagte: „Wir brauchen unseren WooCommerce-Shop auf Englisch, Französisch und Polnisch. Bis März." Es war November. Und das Budget für menschliche Übersetzung war, sagen wir, ambitioniert in die falsche Richtung. Wir hatten Googles Translate-API bei ein paar Projekten vorher verwendet und der Output war, ehrlich gesagt, peinlich für alles über Buttonbezeichnungen hinaus. Also machte ich mich auf die Suche.
Das war, als ich mich richtig mit DeepL hinsetzte. Ich hatte es in ein paar Developer-Threads erwähnt gesehen, aber hatte es nicht ernst genommen. Der größte Fehler, den ich in diesem halben Jahrzehnt machte. Sobald ich dieselben Produktbeschreibungen durch beide APIs laufen ließ und dem Client die Outputs nebeneinander zeigte, gab es keinen Wettbewerb. Wir haben den deutschen Shop in drei Sprachen vor Weihnachten ausgeliefert, der Client fügte sechs Monate später Niederländisch hinzu, ohne ins Schwitzen zu kommen, und dieses Projekt ist immer noch eines, auf das ich hinweise, wenn Leute fragen, wie gute API-Integration aussieht.DeepL. I'd seen it mentioned in a few developer threads but hadn't taken it seriously. Biggest mistake I made in that half-decade. Once I ran the same product descriptions through both APIs and showed the client side-by-side output, there was no contest. We shipped the German store in three languages before Christmas, the client added Dutch six months later without breaking a sweat, and that project is still one I point to when people ask what good API integration looks like.
Dieser Beitrag geht um die praktische Realität, DeepL in eine Website einzubinden. Nicht um die Marketing-Kopie. Die eigentlichen Implementierungsentscheidungen, das Kostenmodell, die Fallstricke und was ich meinem früheren Ich vor dem Start sagen würde.
Warum DeepL die Alternativen tatsächlich schlägt
Ich werde ehrlich: Für europäische Sprachen ist DeepL eine andere Klasse. Das Modell wurde stark auf dem Europarl-Korpus und anderen hochwertigen parallelen Texten trainiert, und man spürt es sofort im Output für Deutsch, Französisch, Spanisch, Italienisch, Niederländisch, Polnisch und Portugiesisch. Die Satzstruktur wirkt durchdacht statt nur Wort-für-Wort getauscht.
Googles API (v2 und v3) ist günstiger und deckt mehr Sprachen ab. 133 vs. DeepLs 29 unterstützte Sprachen (Stand Mitte 2024). Wenn du Suaheli oder Bengalisch brauchst, ist DeepL nicht die Antwort. Punkt. Aber wenn dein Kunde in der EU expandiert oder nach Japan geht (DeepL beherrscht Japanisch bemerkenswert gut), würdest du ihm einen Bärendienst erweisen, wenn du aus Gewohnheit standardmäßig Google nimmst.
Das andere, worüber niemand genug spricht: DeepLs Formalitätsparameter. Du kannst formality=more oder formality=less setzen und die API passt das Register der Ausgabe entsprechend an. Das ist enorm wichtig für Deutsch, wo du/Sie keine nebensächliche stilistische Wahl ist. Eine DTC-Modemarke braucht ein anderes Register als ein B2B-SaaS-Unternehmen. Meine Kunden haben diese Unterscheidung in ihren übersetzten Texten bemerkt, ohne dass ich sie erst darauf hinweisen musste.formality parameter. You can set formality=more or formality=less and the API will adjust the register of the output accordingly. That matters enormously for German, where du/Sie isn't a minor stylistic choice. A DTC fashion brand wants a different register than a B2B SaaS company. I've had clients notice this distinction in their translated copy without me even pointing it out.
Die Cost-Struktur verstehen, bevor du dich festlegst
DeepL berechnet pro übersetztes Zeichen. Der kostenlose API-Plan (DeepL API Free) gibt dir 500.000 Zeichen pro Monat. Das klingt nach viel, bis du einen WooCommerce-Katalog mit 800 Produkten und langen Beschreibungen übersetzt.
Der Pro-Plan kostet etwa 6,99 $/Monat für 500.000 Zeichen und skaliert von da an. Bei den meisten Agency-Projekten, die ich betreue, liegt der Preis irgendwo zwischen 15 und 60 Dollar pro Monat, je nach Kataloggröße und Update-Häufigkeit. Das vergleicht sich mit professionellen Menschentarif-Raten (typischerweise 0,10 bis 0,18 £ pro Wort auf dem britischen Markt) – die API hat sich innerhalb der ersten 200 Wörter amortisiert.
Das hat mich früh gebrand: HTML-Handling. DeepL kann rohes HTML empfangen und wird versuchen, Tags zu bewahren anstatt sie zu übersetzen. Du übergibst tag_handling=html in deiner Anfrage. Aber wenn dein HTML fehlerhaft ist oder deine Produktbeschreibungen Inline-Scripts enthalten (schau dir einige WooCommerce-Plugins an), kann die Ausgabe durcheinander kommen. Ich habe gelernt, Inhalte zu bereinigen, bevor sie die API erreichen, nicht danach.HTML handling. DeepL can receive raw HTML and will attempt to preserve tags rather than translate them. You pass tag_handling=html in your request. But if your HTML is malformed or your product descriptions contain inline scripts (looking at you, some WooCommerce plugins), the output can get mangled. I learned to sanitise content before it hits the API, not after.
Die zwei Integrationswege: WordPress und benutzerdefinierte Builds
WordPress-Websites
Für WordPress ist der direkteste Weg, den ich genutzt habe, die WPML-Integration. WPML hat einen nativen DeepL-Connector in sein Translation-Management-Modul eingebaut. Du autorisierst deinen DeepL-API-Schlüssel in den WPML-Einstellungen, wählst aus, welche Inhaltstypen automatisch übersetzt werden sollen, und WPML verwaltet die Warteschlange. Es ist keine Magie, ein Überprüfungsschritt durch einen Menschen ist immer noch sinnvoll, um ihn in den Workflow einzubauen, aber für eine Website mit 300 Seiten spart das Wochen.WPML integration. WPML has a native DeepL connector built into their Translation Management module. You authorise your DeepL API key inside WPML's settings, select which content types to auto-translate, and it handles the queue. It's not magic, a human review step is still worth building into the workflow, but for a 300-page site it saves weeks.
Die Alternative ist Polylang Pro mit dem DeepL-Add-on. Etwas günstigere Lizenzierung, etwas weniger poliert auf der Seite des Translation-Managements. Ich habe Polylang letztes Jahr auf einer Website einer französischen Restaurantgruppe verwendet. Für dieses Maßstab in Ordnung. Aber für alles mit benutzerdefinierten Post-Typen und ACF-Feldern beherrscht WPML die Spezialfälle in meiner Erfahrung besser.
Wenn du Headless WordPress baust (Gatsby oder Next.js Frontend, der via GraphQL auf WP zugreift), solltest du die DeepL API direkt aus deiner Build Pipeline oder einer Serverless Function aufrufen. Versuche nicht, das durch ein Plugin in dieser Architektur zu leiten. Es wird nicht sauber skalieren.
Custom / Non-WordPress Builds
Hier wird es interessant. DeepL veröffentlicht offizielle Client-Bibliotheken für Python, Node.js, PHP, Ruby, .NET und Java. Die Node.js Bibliothek ist solide. Ich habe sie in einem Next.js Projekt eingesetzt, wo wir Übersetzungen in Redis gecacht haben, um redundante API Calls bei wiederholten Strings zu vermeiden.official client libraries for Python, Node.js, PHP, Ruby.NET, and Java. The Node.js library is solid. I've used it on a Next.js project where we cached translations in Redis to avoid redundant API calls on repeated strings.
Ein Basic Node.js Call sieht so aus:
`` const deepl = require('deepl-node'); const translator = new deepl.Translator('YOUR_AUTH_KEY'); const result = await translator.translateText('Hello, world', null, 'fr'); console.log(result.text); // 'Bonjour le monde' `` const deepl = require('deepl-node'); const translator = new deepl.Translator('YOUR_AUTH_KEY'); const result = await translator.translateText('Hello, world', null, 'fr'); console.log(result.text); // 'Bonjour le monde' ``
Einfach. Die eigentliche Architektur-Frage ist Caching. Du willst die API nicht bei jedem Seitenaufruf treffen. Speichere Übersetzungen in deiner Datenbank oder einer Cache-Schicht (Redis funktioniert gut, sogar eine einfache JSON-Datei funktioniert für kleine Sites). Invalidiere den Cache, wenn sich der Quellinhalt ändert. Das ist alles. Die meiste Komplexität liegt in der Cache-Invalidierungs-Logik, nicht im API Call selbst.
Handling Placeholders und Dynamic Content
Das hat einen meiner Developer bei Seahawk auf einem SaaS Projekt verwirrt, wo die UI Strings Variablen wie {{user_name}} und {{count}} enthielten. Fütterst du diese raw zu DeepL, wird es manchmal die Variablennamen übersetzen. Nicht ideal, wenn {{nombre_de_usuario}} in deiner spanischen UI endet.{{user_name}} and {{count}}. Feed those raw to DeepL and it'll sometimes translate the variable names. Not ideal when {{nombre_de_usuario}} ends up in your Spanish UI.
Die Lösung: Nutze DeepL's XML Handling und wrapp deine Placeholders in ignore Tags, bevor du sie sendest.XML handling and wrap your placeholders in ignore tags before sending.
`` <deepl:ignore>{{user_name}}</deepl:ignore> has {{count}} new messages. `` <deepl:ignore>{{user_name}}</deepl:ignore> has {{count}} new messages. ``
Setzen Sie tag_handling=xml und ignore_tags=deepl:ignore in Ihren Request-Parametern. Die API behält alles innerhalb dieser Tags bei. Das ist in DeepLs API-Referenz dokumentiert, aber beim ersten Lesen leicht zu übersehen. Hat mich bei diesem SaaS-Projekt etwa drei Stunden Debugging gekostet. Hoffentlich kostet es Sie keine.tag_handling=xml and ignore_tags=deepl:ignore in your request parameters. The API preserves anything inside those tags. This is documented in DeepL's API reference but it's easy to miss on a first read. Cost me about three hours of debugging on that SaaS project. Hopefully it costs you none.
Einen sinnvollen Review-Workflow aufbauen
Maschinenübersetzung ist kein Publishing-Button. Ich würde nie empfehlen, DeepL-Output direkt auf eine Live-Site zu bringen, ohne mindestens einen Native Speaker durchlaufen zu lassen – besonders nicht für kundengerichtete Inhalte. Aber der Workflow muss nicht schmerzhaft sein.
So richte ich es für die meisten Client-Projekte ein:
- Erste Übersetzung durch DeepL API ausführen.
- Output in eine Staging-Übersetzungstabelle pushen (in WPML ist das automatisch; bei Custom-Builds schreibe ich in eine translations-DB-Tabelle mit einer status-Spalte, die standardmäßig auf pending gesetzt ist).
translationsDB table with astatuscolumn defaulting topending). - Einen Link an den In-Market-Reviewer des Clients senden (oft das lokale Team des Clients selbst oder ein Freelancer von ProZ).ProZ).
- Reviewer bearbeitet direkt im CMS oder einer einfachen Review-Oberfläche, die ich baue.
- Status wechselt zu approved, Inhalt geht live.
approved, content goes live. - Den String sperren, damit er beim nächsten API-Sync nicht überschrieben wird.
Dieser letzte Schritt ist entscheidend. Ich habe Setups gesehen, bei denen ein Content-Update in der Ausgangssprache eine vollständige Neuübersetzung auslöst und alle manuellen Korrektionen löscht. Baue den Lock-Mechanismus, bevor du irgendetwas anderes baust.
SEO-Überlegungen für mehrsprachige Websites
Allein übersetzte Inhalte werden nicht ranken. Du brauchst hreflang-Tags in deinem HTML <head> für jede Sprachvariante, und sie müssen korrekt sein. Ein fehlerhaft aufgesetztes hreflang-Setup kann deine internationalen Seiten in den Suchergebnissen tatsächlich unterdrücken. Ich habe das bei einem Kunden erlebt, dessen wunderschön übersetzte französische Website vier Monate lang in der Dunkelheit lag, weil jemand die Sprachcodes falsch gemacht hat ( fr-FR vs fr).hreflang tags in your HTML <head> for every language variant, and they need to be correct. A mismatched hreflang setup can actually suppress your international pages in search results. I've seen this happen to a client who had a beautiful translated French site sitting in obscurity for four months because someone got the language codes wrong ( fr-FR vs fr).
Über hreflang hinaus: übersetzte URLs. Im Idealfall sollten auch die Slugs übersetzt sein, nicht /fr/how-to-cook-pasta sondern /fr/comment-cuire-les-pates. DeepL kann Slugs übersetzen, aber danach solltest du sie durch einen Slug-Formatierer laufen lassen (Kleinbuchstaben, Bindestriche, Sonderzeichen entfernen). WPML macht das automatisch. Bei Custom Builds musst du es manuell handhaben./fr/how-to-cook-pasta but /fr/comment-cuire-les-pates. DeepL can translate slugs but you'll want to run them through a slug formatter afterwards (lowercase, hyphens, remove special characters). WPML does this automatically. In custom builds, handle it manually.
Und Metadaten. Seitentitel, Meta-Beschreibungen, Alt-Text auf Bildern. All das braucht eine Übersetzungsbehandlung. Ich laufe Metadaten separat durch DeepL in der Pipeline, nicht als Teil des Body-Content-Batches. So lassen sich Zeichenlimits leichter kontrollieren.
Wo DeepL an seine Grenzen stößt
Ehrliche Antwort: markenbezogene Terminologie. DeepL kennt nicht, wie dein Kunde seine Produktfeatures nennt. Wenn ein Fintech-Kunde „Smart Vault" als Produktname verwendet, wird DeepL das übersetzen. Jedes Mal.
Die Lösung ist DeepL's Glossar-Funktion. Du definierst Begriffspaare über die API (Quellbegriff, Zielbegriff, Sprachenpaar) und hängst die Glossar-ID an deine Übersetzungsanfragen an. So wird „Smart Vault" in jeder Sprache „Smart Vault", weil du es ihr gesagt hast. Du kannst Glossare über die API oder über DeepL's Dashboard verwalten. Ich richte Glossare jetzt bei jedem Project Kickoff ein. Das dauert 20 Minuten und verhindert eine Fehlerkategorie, die sonst Stunden bei der Überprüfung kosten würde.glossary feature. You define term pairs via the API (source term, target term, language pair) and attach the glossary ID to your translation requests. That Smart Vault becomes "Smart Vault" in every language because you've told it to. You can manage glossaries programmatically or via DeepL's dashboard. I set up glossaries as part of every project kickoff now. It takes 20 minutes and prevents a category of errors that would otherwise cost hours to catch in review.
Die andere ehrliche Einschränkung: DeepL's Sprachabdeckung. 29 Sprachen ist wirklich restriktiv, wenn dein Kunde Ambitionen über Europa und Ostasien hinaus hat. Wenn du Arabisch brauchst, schaust du dir einen Hybrid-Ansatz an: DeepL für die europäischen Sprachen, Google Cloud Translation oder Microsoft Azure Translator für alles andere, vereinigt hinter einer einzigen internen API-Schicht, die nach Sprachenpaar routet. Einmal zu bauen ist nervig. Sehr komfortabel zu warten.
FAQ
Ist die DeepL API kostenlos nutzbar?
Es gibt einen kostenlosen Tarif mit 500.000 Zeichen pro Monat, was großzügig für Tests und kleine Projekte ist. Der kostenlose Plan erfordert eine Kreditkarte, belastet diese aber nicht, solange du das Limit nicht überschreitest oder upgratest. Für Produktionsseiten mit echtem Traffic oder Inhaltsmengen wirst du fast sicher einen kostenpflichtigen Plan wollen. Die Pro-Tarife beginnen bei etwa 6,99 USD/Monat und skalieren nach Zeichennutzung.
Kann ich DeepL mit WordPress ohne Plugin nutzen?
Technisch ja. Du kannst die REST API direkt aus einem WordPress-Custom-Plugin oder functions.php aufrufen und dazu wp_remote_post() verwenden. Aber wenn du keine Räder neu erfinden magst, kümmern sich die WPML- oder Polylang-Integrationen um die Übersetzungswarteschlange, String-Synchronisierung und Content-Sperrung für dich. Ich würde nur direkt auf Custom-API in WordPress gehen, wenn du einen sehr spezifischen architektonischen Grund hast.wp_remote_post(). But unless you enjoy reinventing wheels, the WPML or Polylang integrations handle the translation queue, string syncing, and content locking for you. I'd only go custom-API-direct in WordPress if you have a very specific architecture reason.
Wie genau ist DeepL im Vergleich zur menschlichen Übersetzung?
Bei europäischen Sprachen schneidet DeepL in BLEU-Score-Benchmarks regelmäßig nur wenige Prozentpunkte unter menschlicher Übersetzung ab. Praktisch gesprochen: ausreichend für Produktbeschreibungen und UI-Strings, nicht ausreichend für Rechtsdokumente, kreative Texte oder alles, wo Ton und kulturelle Nuance der Kern sind. Baue immer einen Schritt der menschlichen Überprüfung in Kundenprojekte ein.
Beeinflusst DeepL-Übersetzung die SEO?
Automatisch übersetzte Inhalte, die nicht überprüft wurden, können von Suchmaschinen als qualitativ minderwertig gekennzeichnet werden, besonders wenn sie unnatürlich wirken. Google hat erklärt, dass sie automatisch übersetzte Inhalte nicht von Grund auf benachteiligen, aber dünne oder fehlerhafte Inhalte werden unterperformen. Meine Regel: Überprüfe vor dem Indexieren, nicht danach.
Welcher ist der beste Weg, Übersetzungsaktualisierungen zu handhaben, wenn sich der Quellinhalt ändert?
Speichere einen Content-Hash (MD5 des Quellstrings ist ausreichend) zusammen mit jeder Übersetzung in deiner Datenbank. Wenn der Quellinhalt aktualisiert wird, ändert sich der Hash, wodurch die Übersetzung als veraltet gekennzeichnet wird. Deine Pipeline übersetzt dann nur die geänderten Strings neu, nicht die ganze Seite. Das hält die API-Kosten niedrig und verhindert unnötige Veränderungen an Strings, die bereits menschlich überprüft wurden.
---
Die DeepL API ist eines dieser Tools, das wirklich verändert hat, wie ich mehrsprachige Projekte angehe. Nicht, weil es die Notwendigkeit menschlicher Urteile wegfallen lässt, sondern weil es die Arbeit von mühsamer Erstübersetzung zu aussagekräftiger redaktioneller Überprüfung verschiebt. Das ist eine bessere Nutzung der Zeit von allen, auch des Budgets deines Kunden. Konfiguriere es sorgfältig, cache aggressiv, baue den Überprüfungsschritt von Anfang an ein, und es wird dir gute Dienste leisten.