Mit Stand 7. Oktober 2026 verfügt Shifter über den größten Pool an aktiven US-IPs, mehr als Oxylabs und Bright Data, und das zu einem Bruchteil der Kosten.Shifter hat jetzt den größten Pool aktiver US-IPs

Benchmarks ansehen

Wissen

Lokalisierungs-QA im großen Maßstab: Fehler erkennen, die nur in einem Markt auftreten

Lokalisierte Websites brechen auf Arten, die in der Zentrale niemand je sieht. Wie man jeden Markt wie ein lokaler Besucher testet, und die Prüfungen, die solche Fehler aufdecken.

Daniel Okafor

13. Oktober 2026 · 8 Min. Lesezeit

Eine Website, die im Land ihrer Entwicklung einwandfrei funktioniert, kann in zwölf anderen leise defekt sein. Ein Checkout-Button, der in Italien nie übersetzt wurde, Preise, die deutschen Besuchern in Dollar angezeigt werden, ein Consent-Banner, das in Frankreich die ganze Seite bedeckt, eine Sprachversion, die Suchmaschinen nie finden, weil ihr hreflang auf die falsche URL zeigt. Keines dieser Probleme zeigt sich, wenn das Team vom Büro aus testet.

Der Grund ist einfach: Das meiste, was sich zwischen Märkten unterscheidet, wird durch den Standort des Besuchers bestimmt. Um zu sehen, was ein lokaler Kunde sieht, muss man aus diesem Markt heraus testen. Dieser Leitfaden behandelt, wie man Lokalisierungs-QA über Märkte hinweg im großen Maßstab durchführt: was zu prüfen ist, wie man jeden Markt wie ein lokaler Besucher betrachtet, und einen kleinen Checker, der die häufigsten Fehler automatisch erkennt.

Warum sich Lokalisierungsfehler verstecken

Lokalisierte Websites liefern selten eine feste Seite pro Sprache. Sie entscheiden zur Anfragezeit, was angezeigt wird, basierend auf Signalen, die der Besucher sendet:

  • Standort, aus der IP-Adresse: Währung, Preise, Versandoptionen, rechtliche Hinweise, Produktverfügbarkeit und manchmal die Sprache selbst.
  • Spracheinstellungen, aus dem Browser: welche Übersetzung angezeigt wird und wie Daten und Zahlen formatiert werden.
  • Die URL, etwa /de/ oder de.example.com: die Version, die bei der Website angefordert wurde, die mit den anderen beiden übereinstimmen kann oder nicht.

Tests aus der Zentrale decken meist eine Kombination ab: das eigene Land des Büros, einen englischsprachigen Browser und die Standard-URL. Übersetzungsprüfungen kontrollieren die Wörter, aber nicht die Seite, wie sie tatsächlich ausgeliefert wird. Die Fehler stecken in den Kombinationen, die niemand ausprobiert hat.

Was in einem Markt kaputtgeht

FehlerBeispielWie es meist passiert
Nicht übersetzte Zeichenketten”Add to cart” auf der italienischen WebsiteNeue Funktionen werden mit englischen Zeichenketten ausgeliefert, die nie in den Übersetzungsworkflow gelangen
Falsche Währung oder falsches Preisformat$49.99 wird deutschen Besuchern angezeigt, oder 49.99 € statt 49,99 €Währung wird an einer Stelle aus der URL, an anderer aus der IP bestimmt
Defektes hreflangEine Sprachversion zeigt auf eine 404-Seite oder auf eine andere SpracheURLs nach dem Launch geändert, Alternates nicht aktualisiert
Fehlendes oder falsches lang-Attributlang="en" auf der deutschen SeiteEine gemeinsame Vorlage mit fest codiertem Attribut
Redirect-Schleifen oder erzwungene WeiterleitungenEin Besucher in Österreich wird in den deutschen Shop geschickt und kann nicht zurückGeo-Weiterleitungen, die eine explizite Wahl ignorieren
Rechtliche Hinweise und Consent-EbenenEin Banner, das in einem EU-Land den Inhalt verdecktLänderspezifische Consent-Konfiguration
Layout-ÜberlaufDeutsche Bezeichnungen sprengen Buttons, Text von rechts nach links sprengt ein RasterDesigns, die nur mit kurzen englischen Zeichenketten getestet wurden

Mehrere dieser Probleme wirken sich direkt auf die Suche aus. Eine Seite mit falschem lang-Attribut oder defekten Alternates kann als falsche Sprache indexiert werden, oder gar nicht. Unser Leitfaden zum Verwenden von hreflang, um jede Sprachversion einer Seite zu finden zeigt, wie man die Alternates einer Website abbildet und erkennt, welche ins Leere führen.

Schritt 1: Jeden Markt wie ein lokaler Besucher sehen

Die Kernanforderung ist, jede Seite aus dem Markt heraus anzufordern, mit einem Browser, der wie bei einem lokalen Besucher eingerichtet ist. In der Praxis bedeutet das drei Dinge, die übereinstimmen müssen:

  1. Eine IP-Adresse im Markt. Residential Proxies mit Länder- oder Stadt-Targeting geben Ihnen eine Adresse auf einer lokalen Privatverbindung, was genau das ist, was die Geo-Logik der Website erwartet. Unsere Residential Proxies decken 195+ Länder ab, mit Stadt-Targeting, wo nötig.
  2. Die Sprache und das Gebietsschema des Marktes. Stellen Sie den Sprach-Header und das Gebietsschema des Browsers entsprechend ein.
  3. Die Zeitzone des Marktes, falls Sie in einem echten Browser testen, da manche Websites sie als weiteres Standortsignal nutzen.

Stimmen diese nicht überein, testen Sie eine Kombination, die kein echter Kunde hat, und jagen womöglich Fehlern nach, die gar nicht existieren. Unser Leitfaden zum Abstimmen von Proxy-Geo, Zeitzone und Gebietsschema beschreibt, wie man alle drei aus einer Einstellung ableitet.

Testen Sie außerdem mit einer frischen Sitzung für jeden Markt. Cookies von einem vorherigen Besuch können die Website auf das zuletzt getestete Land fixieren, was Geo-Logik-Fehler verbirgt.

Schritt 2: Jeden Markt auf die gleiche Weise prüfen

Visuelle Überprüfung lässt sich nicht auf Dutzende Märkte und Tausende Seiten skalieren, aber die meisten Lokalisierungsfehler lassen sich im HTML erkennen. Die folgende Funktion prüft eine lokalisierte Seite auf vier der häufigsten Probleme: das lang-Attribut, übriggebliebene englische Zeichenketten, Preise in der falschen Währung und einen fehlenden hreflang-Eintrag für den Markt.

import re

from lxml import html as lxml_html


def market_problems(page_html, market):
    """Things that only break in one market, checked on one localized page.

    market: {"lang": "de", "currency": "€", "leftovers": ["Add to cart", "Free shipping"]}
    """
    doc = lxml_html.fromstring(page_html)
    problems = []

    lang = (doc.get("lang") or "").lower()
    if not lang.startswith(market["lang"]):
        problems.append(f"html lang is {lang or 'missing'}, expected {market['lang']}")

    text = " ".join(" ".join(doc.itertext()).split())
    for phrase in market["leftovers"]:
        if phrase.lower() in text.lower():
            problems.append(f"untranslated text: {phrase!r}")

    prices = re.findall(r"[$€£¥₩R]\$?\s?\d[\d.,]*|\d[\d.,]*\s?[$€£¥₩]", text)
    wrong = [p for p in prices if market["currency"] not in p]
    if wrong:
        problems.append(f"{len(wrong)} of {len(prices)} prices not in {market['currency']}, e.g. {wrong[0]!r}")

    if not doc.xpath(f"//link[@rel='alternate'][starts-with(@hreflang, '{market['lang']}')]"):
        problems.append(f"no hreflang entry for {market['lang']}")
    return problems

Ausführung auf zwei Seiten (anschauliches HTML, keine echte Website):

from locqa import market_problems

markets = {
    "de": {"lang": "de", "currency": "€", "leftovers": ["Add to cart", "Free shipping"]},
    "fr": {"lang": "fr", "currency": "€", "leftovers": ["Add to cart", "Free shipping"]},
}
pages = {   # in practice: the same product page, fetched from inside each market
    "de": '<html lang="de"><head><link rel="alternate" hreflang="de" href="/de/p/1"></head>'
          '<body><h1>Wasserkocher</h1><p>49,99 €</p><p>Free shipping</p></body></html>',
    "fr": '<html lang="fr"><head><link rel="alternate" hreflang="fr" href="/fr/p/1"></head>'
          '<body><h1>Bouilloire</h1><p>$49.99</p><p>Ajouter au panier</p></body></html>',
}
for code, page in pages.items():
    print(code, market_problems(page, markets[code]) or "ok")
de ["untranslated text: 'Free shipping'"]
fr ["1 of 1 prices not in €, e.g. '$49.99'"]

Die deutsche Seite hat eine übriggebliebene englische Phrase; die französische Seite zeigt einen Dollarpreis. Beide würden eine Übersetzungsprüfung bestehen, weil die übersetzten Zeichenketten selbst in Ordnung sind.

Erstellen Sie die Liste übriggebliebener Phrasen aus Ihrer eigenen Oberfläche: Button-Bezeichnungen, Versand- und Checkout-Meldungen, Fehlermeldungen. Dies sind die Zeichenketten, die am häufigsten spät hinzugefügt werden. Preisformate erfordern mehr Sorgfalt als nur das Währungssymbol, da dasselbe Symbol auf verschiedene Weisen geschrieben werden kann; unser Leitfaden zum Normalisieren von Preisen, Zahlen und Daten über Gebietsschemata hinweg behandelt deren zuverlässiges Parsen.

Schritt 3: Nach einem Zeitplan ausführen

Lokalisierung bricht nicht nur beim Launch, sondern auch danach. Eine neue Funktion, eine Vorlagenänderung oder eine Preisaktualisierung kann einen Markt beschädigen, während alle anderen einwandfrei aussehen. Ein praktischer Rhythmus:

  • Bei jedem Release: eine kleine Gruppe von Schlüsselseiten (Startseite, eine Kategorie, ein Produkt, Warenkorb, Checkout) in jedem Markt.
  • Wöchentlich: eine breitere Stichprobe von Seiten pro Markt, einschließlich kürzlich geänderter.
  • Nach jeder Änderung an Geo-Logik, Preisgestaltung oder Consent: ein vollständiger Durchlauf.

Melden Sie Ergebnisse pro Markt und pro Prüfung, sodass jedes Team seine eigenen Probleme sieht. Der Markt mit den meisten Fehlern ist meist derjenige mit den wenigsten lokalen Tests.

Dinge, die Automatisierung nicht erfasst

Manche Probleme brauchen weiterhin eine Person, die den Markt kennt: eine Übersetzung, die korrekt ist, sich aber falsch anhört, ein Bild oder eine Farbe mit einer unglücklichen lokalen Bedeutung, eine rechtliche Anforderung, die die Vorlage nicht abdeckt. Automatisierte Prüfungen geben Menschen die Freiheit, ihre Prüfzeit darauf zu verwenden, anstatt nach Dollarzeichen zu suchen.

Manche Websites zeigen auch je nach Land unterschiedliche Consent- und Datenschutzebenen, die sowohl ändern, was Nutzer sehen, als auch, was ein automatisierter Test erreichen kann. Unsere Studie zu Consent-Walls nach Land zeigt, wie stark das innerhalb der EU variiert.

FAQ

Was ist Lokalisierungs-QA?

Das Testen, ob jede Sprach- und Marktversion einer Website für lokale Besucher korrekt funktioniert und sich richtig liest: Übersetzungen, Währungs- und Preisformate, Layout, rechtliche Hinweise, Weiterleitungen und die Signale, die Suchmaschinen nutzen, um jede Version zu finden.

Warum kann ich andere Märkte nicht mit einem VPN testen?

Für einen schnellen Blick können Sie das schon, aber viele Websites erkennen VPN- und Rechenzentrumsadressen und behandeln sie anders als Heimverbindungen, sodass Sie möglicherweise nicht sehen, was ein echter lokaler Kunde sieht. Residential IPs im Markt kommen der echten Erfahrung näher.

Welche Seiten sollte ich in jedem Markt testen?

Mindestens die Startseite, eine Kategorieseite, eine Produktseite, den Warenkorb und den Checkout, sowie jede Seite mit Preisen oder rechtlichen Texten. Erweitern Sie dies um eine rotierende Stichprobe kürzlich geänderter Seiten.

Wie wirken sich Lokalisierungsfehler auf SEO aus?

Falsche lang-Attribute, defekte hreflang-Alternates und erzwungene Geo-Weiterleitungen können dazu führen, dass Suchmaschinen die falsche Sprachversion indexieren oder eine Version ganz übersehen, was Sichtbarkeit in diesem Markt kostet.

Fazit

Lokalisierungsfehler verstecken sich in den Märkten, aus denen niemand testet. Betrachten Sie jeden Markt wie ein lokaler Besucher, mit einer IP, Sprache und Zeitzone, die übereinstimmen, und führen Sie nach jedem Release dieselben automatisierten Prüfungen in jedem Markt durch. Erfassen Sie die mechanischen Probleme (Sprachattribute, übriggebliebene Zeichenketten, Währungen, hreflang) maschinell, und sparen Sie die menschliche Überprüfung für das auf, was nur ein lokaler Leser beurteilen kann.

Bereit, loszulegen?

Testen Sie Shifters Residential-Proxys, 205M+ IPs, 195+ Länder, ab 0,75 $/GB.

Jetzt starten