AI für 700+ Produkttexte in DE/NL/EN: wo Automation hilft, wo sie den Shop ruiniert

Warum roher AI-Output den Shop ruiniert

Das Versprechen klingt verführerisch: Modell auf den Produktfeed loslassen, 700 Beschreibungen raus, fertig. In der Praxis produziert genau dieser Ansatz drei vorhersehbare Schäden — und sie treffen alle dort, wo Geld verdient wird.

• Generik: Ohne Marken-, Material- und Zielgruppen-Kontext schreibt das Modell austauschbare Floskeln („hochwertiges Material, perfekt für jeden Anlass"). Das liest sich wie jeder andere Shop und differenziert nichts.
• Locale-Blindheit: „Englisch" ist kein Markt. Ein Modell, das nicht weiß, ob es für en-GB oder en-US schreibt, mischt colour/color, trousers/pants, basket/cart. Dasselbe gilt für nl-NL vs. nl-BE (Vlaams) und für DE-Register (Du/Sie). Das ist die Sub-Locale-Disziplin aus unseren operativen Artikeln — AI macht den Fehler nur schneller und 700-fach.
• SEO-Risiko: Variantenreiche Kataloge verleiten zu fast identischen Texten je Produkt. Google bewertet dünne, weitgehend gleiche Seiten als Thin- bzw. Duplicate-Content; solche Seiten werden seltener gut gerankt oder aus dem Index gehalten. Massen-AI ohne Differenzierung läuft genau in dieses Muster.

Der Workflow: vier Stufen, ein menschliches Gate

Das Ziel ist nicht „weniger AI", sondern AI an der richtigen Stelle. Die Arbeitsteilung:

1. AI-Draft — die Maschine schreibt den Rohbau

Hier ist Automation klar im Vorteil. Das Modell bekommt strukturierte Eingaben statt eines vagen Prompts: Produktattribute aus den Shopify-Metafeldern (Material, Passform, Maße, Pflege), die Markenstimme als festes Briefing und die Ziel-Locale als expliziten Parameter. Aus „Schreib eine Produktbeschreibung" wird „Schreib für nl-BE, Register formell, max. 90 Wörter, Pflichtangaben X/Y/Z". Pro Sprache ein eigener Draft — nicht eine Übersetzung des deutschen Texts, denn maschinelle Weiterübersetzung schleppt deutsche Satzbau-Muster mit.

2. Sub-Locale-Override + Locale-Linter — die Region kommt rein

Diese Stufe entscheidet, ob aus „drei Sprachen" echte Märkte werden. Der Draft läuft gegen ein Glossar pro Sub-Locale und wird dort überschrieben, wo Region ≠ Sprache ist:

Ein Locale-Linter ist die automatisierbare Hälfte dieser Stufe: ein regelbasierter Check, der verbotene/falsche Begriffe je Locale flaggt (US-Spelling im en-GB-Text, „pants" im UK-Shop, Du-Anrede im Sie-Register). Der Linter korrigiert nicht autonom — er macht Abweichungen sichtbar und priorisiert die Review. Das ist exakt dieselbe Logik wie hreflang-Disziplin auf Code-Ebene, nur auf Text angewandt.

3. Menschliches Gate — der Punkt, an dem nichts automatisch durchgeht

Kein AI-Text geht ungeprüft live. Aber das Gate ist nicht „alles Wort für Wort neu schreiben" — das würde den Skalierungsvorteil zunichtemachen. Es ist eine Review-Queue, die nach Risiko sortiert: Linter-Flags zuerst, dann Hero-/Bestseller-Produkte (hoher Traffic, hohe Marge), dann der Long Tail im Stichprobenmodus. Die menschliche Rolle ist Urteil, nicht Tipparbeit: Stimmt die Marke? Stimmen Pflichtangaben? Liest sich das wie ein Mensch aus der Zielregion? Faktencheck bei Maßen, Material, Compliance — denn dafür haftet kein Modell.

4. SEO-Check — gegen Thin & Duplicate Content

• Differenzierung messen: Ähnlichkeit der Texte über Varianten/Produkte prüfen; bei nahezu identischen Beschreibungen entweder echte Unterschiede einarbeiten oder kanonisieren.
• Keyword je Locale, nicht je Sprache: Suchbegriffe driften regional (siehe Synonyme je Markt); das Draft-Briefing trägt das Fokus-Keyword der Ziel-Locale.
• Substanz statt Füllung: Pflichtangaben, echte Produktdaten und Nutzungskontext schlagen generische Adjektive — auch gegen Thin-Content-Bewertung.
• Struktur: Title/Meta/Heading pro Locale konsistent, hreflang sauber, keine versehentliche Index-Konkurrenz zwischen en-GB und en-US.

Wo Automation klar hilft — und wo sie ruiniert

Operativ in Shopify

Die Bausteine existieren bereits: der Bulk-Editor und Metafelder als strukturierte Datenquelle, Translate & Adapt für getrennte Locale-Einträge (Sub-Locales lassen sich pro Markt anlegen und separat befüllen statt eine Sprache global zu spiegeln). AI sitzt davor als Draft-Generator, der Linter dazwischen, das Gate dahinter. Der eigentliche Aufwand ist nicht das Generieren — das ist billig geworden — sondern Glossarpflege, Review-Kapazität und SEO-Kontrolle. Genau hier entscheidet sich, ob 700 Texte ein Asset oder eine Index-Belastung werden.

Fazit

AI skaliert den Entwurf, nicht das Urteil. Behandle sie als Draft-Maschine mit Sub-Locale-Overrides und menschlichem Gate — dann gewinnst du Geschwindigkeit ohne Qualität zu opfern. Behandle sie als Selbstläufer, und du veröffentlichst 700-fach denselben generischen, locale-blinden Text.

Du willst Produkttexte über mehrere Sub-Locales skalieren, ohne den Shop zu verwässern? Content-Automation mit leitwert.digital besprechen. Verwandt: en-GB ≠ en-US und nl-NL ≠ nl-BE.