[Gelöst] Falsche Währungsangabe in strukturierten Daten auf Nicht-US-Seiten aufgrund der Geo-Lokalisierung v...
Dies ist das technische Support-Forum für WPML – das mehrsprachige WordPress-Plugin.
Mitlesen können alle, doch nur WPML-Kunden können hier Fragen veröffentlichen. Das WPML-Team antwortet im Forum an 6 Tagen pro Woche, 22 Stunden am Tag.
Hintergrund des Themas:
Ich versuche, sicherzustellen, dass die strukturierten Daten auf unserer mehrsprachigen und multiwährungsfähigen WooCommerce-Website die korrekte Währung entsprechend der Sprachversion bzw. dem URL-Pfad anzeigen. Unsere Website-Konfiguration umfasst eine Hauptdomain medicross.com mit sprachspezifischen Pfaden wie medicross.com/en und medicross.com/fr. Die Sprachen werden über WPML und die Währungen über WCML verwaltet. Die Währung wird automatisch per Geolokalisierung ermittelt. Link zur Seite, auf der das Problem zu sehen ist: versteckter Link
Die Symptome:
Wenn der Googlebot unsere Seiten crawlt, wird er als aus den USA kommend erkannt, was dazu führt, dass die Preise in den strukturierten Daten in USD und nicht in EUR ausgegeben werden. Dies führt zu falschen Währungsangaben in den Google-Suchergebnissen für Seiten außerhalb der USA.
Fragen:
Gibt es eine empfohlene Methode, um sicherzustellen, dass strukturierte Daten die korrekte Währung entsprechend der Sprachversion bzw. dem URL-Pfad anzeigen – unabhängig vom Standort des Crawlers?
Könnte dieses Problem umgangen werden, indem man einen Currency Switcher konfiguriert oder die Logik zur Generierung der strukturierten Daten überschreibt?
Gibt es Best Practices oder Filter-Hooks von WCML/WPML, mit denen man die Währung explizit anhand der Sprache oder des URL-Pfads – speziell für strukturierte Daten – festlegen kann?
da der Googlebot in der Regel mit einer US-amerikanischen IP-Adresse auf Ihre Website zugreift, wird er durch die Geolokalisierung als Besucher aus den USA erkannt. Dadurch wird die Währung automatisch auf USD gesetzt.
Um dieses Verhalten zu umgehen, empfehlen wir, die Währung sprachbasiert statt geolokalisiert festzulegen. Hierfür könnte der Hook wcml_client_currency verwendet werden, um die Währung explizit anhand der aktiven Sprache oder des URL-Pfads zu definieren.
vielen Dank für deine Rückmeldung und den Hinweis auf den wcml_client_currency-Hook.
Das ist tatsächlich eine Lösung, über die wir auch bereits nachgedacht haben. Allerdings stehen wir hier vor einem grundlegenden Problem: In unseren Zielmärkten ist die Sprache leider kein verlässlicher Indikator für die Währung.
Ein paar Beispiele zur Verdeutlichung:
In der Schweiz sprechen unsere Kunden Deutsch, Französisch und Italienisch, nutzen aber alle den Schweizer Franken (CHF).
In den USA gibt es viele spanischsprachige Nutzer, die aber natürlich in USD bezahlen.
In Spanien spricht man ebenfalls Spanisch, hier wird aber mit dem Euro (EUR) bezahlt.
Wenn wir also die Währung rein sprachbasiert setzen, riskieren wir gravierende Fehler – etwa, dass Nutzern in der Schweiz Euro angezeigt werden, nur weil sie Deutsch sprechen, oder spanischsprachigen US-Kunden der Euro statt USD.
Dieses Missverhältnis kann nicht nur zu Verwirrung bei den Nutzern führen, sondern vor allem auch zu schwerwiegenden Problemen in der Preis-Darstellung in den strukturierten Daten für Google.
Daher sind wir weiterhin auf der Suche nach einer Lösung, die sowohl die Geolokalisierung berücksichtigt als auch die strukturierten Daten korrekt abbildet – insbesondere in Hinblick auf Googlebot-Zugriffe mit US-IP.
Hast du eventuell eine Idee, wie man diesen Spagat lösen könnte? Lg Daniel
mir ist aktuell nur das Plugin von YITH bekannt, das sogenannte „Geolocation Rules“ unterstützt: versteckter Link
Falls das Plugin die gewünschte Funktionalität nicht bietet, wäre vermutlich eine individuelle Lösung notwendig. Dabei könnte man Standortdaten (z. B. über MaxMind GeoIP) nutzen, um Land oder Region des Besuchers zu ermitteln und darauf basierend z. B. Währung und Sprache dynamisch zu setzen. Eine optionale Erweiterung wäre, diese Daten in standardisierte Locale-Codes wie en_US oder es_MX umzuwandeln, falls dies für strukturierte Daten benötigt wird.
