Im Rahmen eines Internationalisierungsprojekts, das wir betreuten, kam eine der traditionsreichsten Teppichmarken der Türkei mit folgender Frage auf uns zu: Unser türkischer Shop bedient den türkischen Markt seit Jahren reibungslos, und wir haben für den Auslandsmarkt einen separaten Shopify-Shop eingerichtet, aber Google erkennt beide als zwei unabhängige, voneinander isolierte Websites. Als wir das Projekt übernahmen, verkaufte der englischsprachige Shop über eine eigene, unabhängige Domain; zu Beginn des Projekts leiteten wir diese Domain per CNAME auf die bestehende Subdomain um. Doch die Lösung der Domain-Seite reichte nicht aus, damit Google die beiden Shops als eine zusammengehörige Website erkennt; das Problem war bekannt, aber die Lösung war nicht standardisiert. Die Shopify-Dokumentation und die meisten Leitfäden beschreiben hreflang als eine Funktion, die in einem einzigen Shopify-Konto über Shopify Markets automatisch eingerichtet wird; wir hatten es jedoch mit zwei völlig getrennten Konten, zwei separaten Datenbanken und zwei unterschiedlichen Produktkatalogen zu tun. In diesem Artikel beschreiben wir Schritt für Schritt, wie wir die hreflang-Infrastruktur zwischen diesen beiden Shops durch den Abgleich von 9.091 Produkten über deren SKU-Codes aufgebaut haben, welche technischen Entscheidungen wir warum getroffen haben und wie ein Shop-Betreiber, der vor demselben Problem steht, diese Methode auf sein eigenes Projekt übertragen kann.
Was ist hreflang und wie funktioniert es im Standard-Shopify-Szenario?
Hreflang ist ein HTML-Tag, das Suchmaschinen darüber informiert, dass verschiedene Sprach- oder Regionalversionen einer Seite miteinander in Beziehung stehen; ohne diese Information betrachtet Google die türkischen und englischen Versionen desselben Produkts als zwei konkurrierende Inhalte und stuft beide schlechter ein. In einer Standard-Shopify-Einrichtung (ein Konto, Mehrsprachigkeit verwaltet über Shopify Markets) werden diese Tags automatisch generiert; Sie fügen die Sprache hinzu, verknüpfen sie mit Markets, und Shopify schreibt den Rest selbstständig in den <head>-Bereich der Seite. Diesen Standardprozess haben wir Schritt für Schritt in unserem Leitfaden zur Einrichtung mehrsprachiger Shopify-Shops bereits ausführlich erläutert; auch beim Thema Übersetzungsmanagement in unserem Artikel über Shop-Übersetzungen und mehrsprachige Unterstützung behandeln wir die Nutzung der App Translate & Adapt.
Das Thema dieses Artikels ist nicht dieses Standardszenario. Shopify Markets setzt voraus, dass Sie innerhalb eines einzigen Shopify-Kontos mehrere Märkte definieren; wenn Sie bereits zwei unabhängige Shopify-Konten besitzen (zum Beispiel einen vor Jahren gegründeten lokalen Shop und einen später eröffneten internationalen Shop), kann der automatische hreflang-Mechanismus von Markets nicht greifen, da diese aus Sicht von Shopify zwei völlig beziehungslose Websites sind. In diesem Szenario müssen Sie hreflang manuell über einen gemeinsamen Datenpunkt einrichten, der die beiden Shops miteinander verbindet; genau das ist das Thema dieser Fallstudie.
Wichtiger Hinweis: Wenn Sie zwei separate Shopify-Konten haben und beide unter demselben Markennamen verkaufen, sind diese beiden Seiten in den Augen von Google faktisch Konkurrenten; bis zur Einrichtung von hreflang wird Ihr organischer Traffic zwischen den beiden Shops aufgeteilt, und keiner von beiden kann sein volles Potenzial entfalten. Dies ist ein Risiko, das bei Setups mit nur einem Shop nicht auftritt und spezifisch für Wachstumsstrategien mit mehreren Shops ist.
Das Problem: Warum zwei separate Shopify-Shops eine andere Herausforderung darstellen
Die Schwierigkeit bei der Einrichtung von hreflang zwischen zwei separaten Shopify-Konten war nicht technischer, sondern struktureller Natur: Es gab keine Verbindung zwischen den beiden Shops, die Google hätte verstehen können, und selbst die Produkt-URLs stimmten nicht überein. Während der Handle (die Produktkennung in der URL) eines Teppichprodukts im türkischen Shop mit einer völlig anderen Bezeichnung gespeichert war, hatte dasselbe Produkt im englischen Shop eine ganz andere Struktur; beide Seiten waren über Jahre hinweg unabhängig gewachsen, ohne dass jemand die Produktbenennung nach einem gemeinsamen Standard konfiguriert hätte.
Das konkrete Ergebnis dieser Situation war messbar: Türkische Seiten erschienen gelegentlich in englischen Suchanfragen, und der englische Shop konkurrierte bei Suchanfragen aus der Türkei mit dem lokalen Shop. Obwohl beide Shops dasselbe Produkt derselben Marke verkauften, waren sie in den Augen von Google zwei separate Konkurrenten, die sich gegenseitig den Traffic stahlen. Dies unterscheidet sich vom klassischen Problem des "Duplicate Content"; der Inhalt ist nicht wortwörtlich identisch (da die Sprachen unterschiedlich sind), aber die Suchmaschine weiß auf Entitätsebene nicht, dass es sich um dasselbe Produkt handelt.
Hintergrund: Die Domain-Historie des internationalen Shops
Der englischsprachige Shop verkaufte bereits vor Beginn des hreflang-Projekts über eine eigene, unabhängige Domain; im Rahmen des Projekts leiteten wir diese Domain per CNAME-Eintrag auf die bestehende Subdomain en.ihreseite.com um. Besucher, die die alte Domain aufriefen, wurden automatisch auf die neue Adresse weitergeleitet; wir definierten für die Root-Domain sowie für die Version mit www-Präfix jeweils eigene Weiterleitungsregeln, um sicherzustellen, dass keine Regel fehlte und kein Traffic verloren ging.
Dieser Umzug barg zwei SEO-Risiken: den Verlust des Backlink-Profils der alten Domain und einen Traffic-Einbruch während der Umstellung. Beides trat nicht ein; das Backlink-Profil der alten Domain wurde auf die neue Adresse übertragen, und in der Google Search Console war nach dem Umzug kein Traffic-Rückgang zu verzeichnen. Das bedeutete, dass bei Beginn des hreflang-Projekts auf Domain-Ebene kein Problem mehr zu lösen war; die hreflang-Arbeit konnte auf einer bereits korrekt weitergeleiteten Domain aufbauen, ohne dass eine zusätzliche hreflang-Domain-Komplexität zwischen zwei verschiedenen Domains verwaltet werden musste.
Laut Daten von Nodus Works: Der häufigste Grund für Traffic-Verluste bei Domain-Umzügen ist die Weiterleitung nur der Root-Domain unter Vernachlässigung der www-Version (oder umgekehrt). Die Einbeziehung beider Varianten in separate Weiterleitungsregeln verhindert bereits viele Szenarien, in denen es nach einem Domain-Umzug zu Traffic-Einbußen kommt.
Warum klassische Lösungen nicht funktionierten?
Bei einer klassischen mehrsprachigen Shopify-Einrichtung wird hreflang innerhalb eines Kontos über eine Unterverzeichnis- (`/en/`) oder Subdomain-Struktur (`en.site.com`) verwaltet und von Shopify automatisch generiert. Hier hatten wir es jedoch mit zwei völlig getrennten Shopify-Konten, zwei separaten Datenbanken und zwei unterschiedlichen Produktkatalogen zu tun; die Markets-Infrastruktur von Shopify kann nicht wissen, dass diese beiden Konten "Teile derselben Marke" sind, da es technisch gesehen keinen Mechanismus dafür gibt. Auch eine mehrsprachige SEO-App eines Drittanbieters unterstützte dieses spezifische Szenario (zwei unabhängige Shopify-Konten) nicht direkt; daher war es notwendig, die Lösung manuell über die Datenebene der Shops mittels Admin-API zu implementieren.
Lösungsansatz: Die SKU als gemeinsamer Schlüssel
Der einzige konstante Wert, der die beiden Shops miteinander verbinden konnte, war der SKU-Code. Auch wenn sich Produktnamen, URLs und Titel zwischen den Shops unterschieden, war die SKU jedes Produkts in beiden Katalogen identisch. Dies ist ein Detail, das bei Internationalisierungsprojekten oft übersehen wird: Marken passen Produktnamen, Beschreibungen und sogar Bilder an den lokalen Markt an, aber der SKU-Code bleibt als operative Identität unverändert. Genau das war auch in dieser Fallstudie der Fall; die SKU war die einzige zuverlässige Brücke zwischen den beiden unabhängigen Datenbanken.
Der auf diesem gemeinsamen Nenner basierende Lösungsansatz bestand aus drei Schritten: Zuerst wurden die SKUs aller Produkte aus beiden Shops abgerufen, dann wurde die Schnittmenge der beiden Mengen ermittelt (welche SKUs in beiden Shops vorhanden sind) und schließlich wurde für jedes übereinstimmende Produktpaar ein Metafield geschrieben, das auf das jeweilige Gegenstück verweist. Dieser dritte Schritt ist entscheidend: Anstatt das hreflang-Tag statisch zu hinterlegen, sorgt das Speichern des Handles der Zielsprache im jeweiligen Metafield des Produkts dafür, dass das System bei zukünftigen Katalogänderungen (neue Produkte, entfernte Produkte) eigenständig aktuell bleibt.
Hinweis: Wenn das SKU-Matching funktioniert, ignoriert der hreflang-Mechanismus den Produktnamen oder die URL-Struktur vollständig; er betrachtet ausschließlich die operative Identität (SKU). Daher bleibt die Lösungsmethode konsistent, unabhängig davon, wie inkonsistent die Produktbenennung zwischen den Shops ist.
Technische Umsetzung Schritt 1: Produktabgleich über die Admin API
Die praktische Umsetzung des SKU-Matchings gliederte sich in vier Teilschritte: Abrufen der Produkte, Extrahieren der SKUs, Ermitteln der Schnittmenge und Schreiben des Ergebnisses als Metafield. Der /products.json-Endpunkt der Shopify Admin API gibt pro Anfrage maximal 250 Produkte zurück und arbeitet nicht mit Seitenzahlen, sondern cursorbasiert: Durch die Übertragung des page_info-Werts aus dem Header jeder Antwort auf die nächste Anfrage wurde der gesamte Katalog in mehr als 35 Anfragen abgerufen; in diesem Fall wurden 8.733 Produkte aus dem TR-Shop und 8.766 aus dem EN-Shop extrahiert.
- Alle Produkte beider Shops wurden inklusive ihrer Varianten über die Admin API abgerufen.
- Die SKUs aller Varianten jedes Produkts wurden in einer separaten Menge zusammengefasst; da ein Produkt mehrere Varianten (z. B. verschiedene Größen) haben kann, wurde die Zuordnung von SKU zu Produkt-ID/Handle auf Variantenebene verarbeitet.
- Die Schnittmenge der beiden Mengen wurde gebildet: 9.091 SKUs wurden in beiden Shops gefunden. 5.403 Produkte waren nur im TR-Shop und 1.492 nur im EN-Shop vorhanden; diese Produkte wurden vom hreflang-Geltungsbereich ausgeschlossen, da sie kein echtes Gegenstück in der anderen Sprache hatten.
- Für jedes übereinstimmende Produktpaar wurde ein Cross-Metafield geschrieben: custom.en_handle für das TR-Produkt und custom.tr_handle für das EN-Produkt.
# Her iki mağazadaki SKU'ları karşılaştır
tr_skus = {sku for p in tr_products for v in p["variants"]
if (sku := v.get("sku", "").strip())}
en_skus = {sku for p in en_products for v in p["variants"]
if (sku := v.get("sku", "").strip())}
matched = tr_skus & en_skus # -> 9.091
# TR ürününe EN handle yaz
write_meta(TR_STORE, product_id, "en_handle", en_handle)
# EN ürününe TR handle yaz
write_meta(EN_STORE, product_id, "tr_handle", tr_handle)
Dieser Vorgang erforderte insgesamt 18.182 API-Aufrufe (ein Schreibvorgang pro Richtung, 9.091 Paare × 2) und dauerte etwa 3-4 Stunden. Bei langwierigen Batch-API-Prozessen sind Verbindungsabbrüche und Timeouts unvermeidlich; um dieses Risiko zu minimieren, wurden eine Exponential-Backoff-Logik und eine Fortschrittsdatei implementiert, sodass das Skript nach einem Fehler an der Stelle fortgesetzt werden konnte, an der es unterbrochen wurde, ohne von vorne beginnen zu müssen.
Zu vermeidendes Risiko: Führen Sie bei Batch-API-Vorgängen mit Tausenden von Produkten niemals ein Skript ohne Fortschrittsprotokollierung aus. Das Rate Limit der Shopify Admin API und Netzwerkunterbrechungen können dazu führen, dass ein 3-4-stündiger Prozess abbricht; ohne Fortschrittsdatei bedeutet dies, dass die stundenlange Arbeit komplett wiederholt werden muss.
Technische Umsetzung Schritt 2: Bedingte hreflang-Injektion mit Liquid
Nachdem die Metafields geschrieben waren, wurde ein bedingter hreflang-Block in den Themencode beider Shops eingefügt; die Logik war einfach, enthielt aber eine entscheidende Regel für das Ergebnis: Wenn das Metafield leer ist, wird das hreflang-Tag gar nicht erst gerendert. Ohne diese Regel würden auch die 5.403 TR-Produkte, die kein echtes Gegenstück in der anderen Sprache haben, ein fehlerhaftes oder leeres hreflang-Tag erzeugen; das wäre für Google so, als würde man sagen: "Schau hier nach, aber da ist nichts", was das hreflang-Tag aus technischer SEO-Sicht unzuverlässig machen würde.
{% if product and product.metafields.custom.en_handle != blank %}
<link rel="alternate" hreflang="tr"
href="https://www.siteniz.com/products/{{ product.handle }}" />
<link rel="alternate" hreflang="en"
href="https://en.siteniz.com/products/{{ product.metafields.custom.en_handle }}" />
<link rel="alternate" hreflang="x-default"
href="https://www.siteniz.com/products/{{ product.handle }}" />
{% endif %}
Ein Detail, auf das bei diesem Code geachtet werden muss, ist der Wert x-default: Dies ist kein Sprachcode für Türkisch oder Englisch, sondern ein Signal für eine Weiterleitung, das bedeutet: "Zeige dies an, wenn die Sprache oder Region des Nutzers mit keiner der Sprachen in dieser Liste übereinstimmt." In diesem Fall wurde der Standard-Shop (Türkisch) als x-default markiert, da dort die Markenidentität und die Lagertiefe primär angesiedelt waren; diese Entscheidung ist möglicherweise nicht für jede Marke gleich, manchmal ist die englische Version als x-default die korrektere Wahl.
Tipp: Wenn Sie entscheiden, welchem Shop Sie x-default zuweisen, stellen Sie sich weniger die Frage "In welcher Sprache erhalten wir den meisten Traffic?", sondern vielmehr "Welche Version ist für die Marke am vorteilhaftesten, einem neuen Besucher mit unbestimmter Sprache zu zeigen?". Dies ist eine strategische Entscheidung, die unabhängig von der aktuellen Traffic-Verteilung getroffen werden sollte.
hreflang auf Kollektions- und Seitenebene
Die gleiche bedingte Logik wurde über die einzelnen Produkte hinaus auch auf Kollektionen und statische Seiten angewendet, da hreflang nicht nur bei Produktseiten, sondern auch bei Kategorie- (Kollektions-) Seiten und statischen Seiten wie „Über uns“ dasselbe Risiko für Duplicate Content birgt. Die Anzahl der Kollektionen unterschied sich bereits zwischen den beiden Shops, was dazu führte, dass die Übereinstimmungsrate niedriger ausfiel als bei den Produkten.
Der Unterschied in der Tabelle ist bemerkenswert: Während der TR-Shop 215 Kollektionen aufwies, waren es im EN-Shop nur 165, von denen lediglich 150 ein echtes Pendant hatten. Dies war nicht nur ein technisches Matching-Problem, sondern auch ein Signal für eine Content-Lücke: Kollektionen, die im TR-Shop existierten, aber kein Gegenstück im EN-Shop hatten, deuteten auf eine Produktgruppe hin, die für den englischsprachigen Markt noch nicht kategorisiert war. Diese Lücke bildete den Ausgangspunkt für die Content-Arbeit, die im nächsten Schritt angegangen wurde.
Behebung von Nebeneffekten: Duplicate URLs, Paginierung und defekte Links
Während die hreflang-Infrastruktur aufgebaut wurde, traten drei weitere technische Probleme rund um das Hauptthema auf. Keines davon war direkt auf hreflang zurückzuführen, doch hätten sie, wenn sie ungelöst geblieben wären, den Nutzen von hreflang weitgehend zunichtegemacht.
Problem 1: /en/-URLs erzeugen Duplicate Content
Aufgrund der Shopify-Spracheinstellungen im TR-Shop waren URLs mit dem Präfix /en/ bereits aktiv und erhielten Traffic in der Google Search Console. Da diese Seiten inhaltlich identisch mit dem separaten EN-Shop waren, entstand ein klassisches Duplicate-Content-Problem. Die Lösung war eine über Metafields gesteuerte JavaScript-Weiterleitung: Produkte mit einem EN-Gegenstück wurden direkt auf die entsprechende Produktseite im echten EN-Shop geleitet, während Produkte ohne Entsprechung statt einer 404-Fehlerseite auf die Startseite des EN-Shops weitergeleitet wurden. Diese Unterscheidung war wichtig, da ein blindes Weiterleiten aller Nutzer auf die Startseite bei passenden Produkten zu unnötigen Klickverlusten geführt hätte.
Problem 2: Indexierung von Paginierungsseiten
URLs der Kollektions-Paginierung (wie ?page=2, ?page=3) wurden von Google indexiert. Da diese Seiten keinen eigenständigen Suchwert besitzen, verbrauchten sie unnötig Crawl-Budget (die begrenzten Ressourcen, die Google für das Crawlen einer Website bereitstellt). Durch das Hinzufügen eines noindex, follow-Tags wurde die Indexierung dieser Seiten durch Google gestoppt, während das Folgen der Links (und damit das Erreichen der Produkte) beibehalten wurde.
{% if paginate.current_page > 1 %}
<meta name="robots" content="noindex, follow">
{% endif %}
Problem 3: Massenhaft defekte interne Links
Ein mit Semrush durchgeführter Website-Scan identifizierte 6.856 defekte interne Links. Auf den ersten Blick sah dies nach einer Arbeit aus, die Wochen in Anspruch nehmen würde. Bei genauerer Betrachtung stellte sich jedoch heraus, dass 92 % dieser Links (6.289 Stück) auf eine einzige URL verwiesen, nämlich eine zuvor gelöschte Seite. Eine einzige Weiterleitungsregel löste den Großteil der defekten Links auf einen Schlag; die verbleibende kleine Anzahl wurde einzeln bearbeitet.
Hinweis: Wenn Sie einen Bericht mit Tausenden defekten Links sehen, ist die erste Reaktion oft: „Das dauert Wochen“. Schätzen Sie diesen Zeitaufwand jedoch nicht, ohne die defekten Links nach Ziel-URL zu gruppieren. Oft sind nur wenige Quellseiten für eine unverhältnismäßig hohe Anzahl defekter Links verantwortlich.
Ergebnisse: Vorher und Nachher
In diesem Fall teilen wir den Anstieg des organischen Traffics nicht als isolierte Kennzahl, da die hreflang-Einrichtung keine isolierte Änderung war, sondern zusammen mit allen in diesem Artikel beschriebenen technischen Korrekturen (Duplicate Content, Paginierung, defekte Links) umgesetzt wurde. Daher zeigt die folgende Tabelle nicht den Traffic, sondern den strukturellen Zustand vor und nach der Optimierung. Eine strukturelle Verbesserung ist die Voraussetzung für eine Traffic-Steigerung, aber kein alleiniger Beweis dafür. Diese Unterscheidung dem Leser klar zu vermitteln, ist der einzige Weg, die Ergebnisse nicht zu übertreiben.
Der eigentliche strukturelle Gewinn ist folgender: Google weiß nun direkt, dass beide Shops Teil derselben Marke sind und welches Produkt das Pendant zu welchem ist. Vor diesem Wissen waren die beiden Shops Konkurrenten; jetzt sind sie als Sprachversionen derselben Entität (Marke/Produktpräsenz) markiert, die sich gegenseitig ergänzen.
Wie setzen Sie das in Ihrem eigenen Shop um?
Bevor Sie diese Methode auf Ihr eigenes Projekt anwenden, müssen Sie klären, ob Sie sich tatsächlich in diesem Szenario befinden. Wenn Sie nur ein einziges Shopify-Konto haben, gibt es bereits eine viel einfachere Lösung (Shopify Markets), und die Methode in diesem Artikel wäre eine unnötige Komplexität.
Zuerst prüfen
- Haben Sie zwei (oder mehr) völlig separate Shopify-Konten oder verwalten Sie verschiedene Sprachen innerhalb eines einzigen Kontos? Falls Letzteres zutrifft: Unser Leitfaden zu Shopify Markets für Sie ausreicht, ist die manuelle Methode in diesem Artikel nicht erforderlich.
- Haben Ihre Produkte in beiden Shops eine konsistente SKU? Wenn die SKUs inkonsistent sind (oder gar nicht verwendet werden), müssen Sie zunächst eine Strategie für einen gemeinsamen Identifikator zur Verknüpfung festlegen; anstelle der SKU können auch Barcodes, Produktcodes oder ähnliche Felder verwendet werden.
- Haben Sie Zugriff auf die Admin-API und eine technische Ressource (Ihr eigenes Team oder eine Agentur), die Massendaten verarbeiten kann? Diese Aufgabe erfordert eine Datenverarbeitung, die über das Shopify-Admin-Panel manuell nicht durchführbar ist.
Implementierungsreihenfolge
- Rufen Sie alle Produkte und Varianten-SKUs aus beiden Shops über die Admin-API ab.
- Ermitteln Sie die Schnittmenge der SKUs und halten Sie nicht übereinstimmende Produkte (die nur in einem Shop vorhanden sind) in einer separaten Liste; diese fallen nicht unter den hreflang-Geltungsbereich.
- Schreiben Sie für jedes übereinstimmende Paar gegenseitige Metafields (ein benutzerdefiniertes Feld, das den Handle des jeweils anderen Shops speichert).
- Fügen Sie Ihrem Theme-Code einen bedingten Block hinzu, der kein hreflang generiert, wenn das Metafield leer ist.
- Entscheiden Sie strategisch, welchem Shop Sie den x-default-Wert zuweisen.
- Erweitern Sie dieselbe Logik auf Kollektionen und statische Seiten.
- Überprüfen Sie zusätzlich auf Nebenwirkungen (doppelte URLs, Paginierungs-Indexierung, defekte Links); eine hreflang-Einrichtung löst diese Probleme nicht automatisch.
Der riskanteste Teil dieses Prozesses ist die Durchführung von Massen-API-Vorgängen für Tausende von Produkten; Ratenbegrenzungen, Teilfehler und Datenkonsistenz erfordern ein erfahrenes technisches Team. Unser Service für Shopify-Integration und individuelle App-Entwicklung, setzt solche Projekte zur Massendatenverknüpfung und API-Integration von Anfang bis Ende um; im Bereich technisches SEO hingegen unser Service für technische SEO-Analyse und Optimierung identifiziert solche strukturellen Probleme, einschließlich hreflang, bereits zu Projektbeginn.
Häufig gestellte Fragen
Wie richtet man hreflang zwischen zwei separaten Shopify-Shops ein?
Sie verknüpfen die Produkte beider Shops über einen gemeinsamen Identifikator (in der Regel die SKU) und schreiben für die übereinstimmenden Produktpaare ein Metafield, das auf das Gegenstück im anderen Shop verweist. In den Theme-Code fügen Sie einen bedingten Block ein, der ein hreflang-Tag generiert, wenn dieses Metafield gefüllt ist, und andernfalls nichts ausgibt.
Warum ist manuelles hreflang erforderlich, wenn es Shopify Markets gibt?
Shopify Markets verwaltet Märkte innerhalb eines einzigen Shopify-Kontos und generiert hreflang-Tags automatisch. Wenn Sie zwei völlig separate Shopify-Konten besitzen (zwei separate Abonnements, zwei separate Admin-Panels), kann Markets nicht erkennen, dass diese Konten miteinander verknüpft sind; in diesem Fall muss hreflang manuell eingerichtet werden.
Was soll ich tun, wenn die SKUs meiner Produkte in beiden Shops nicht übereinstimmen?
Wenn die SKUs nicht konsistent sind, müssen Sie zunächst eine Strategie für einen gemeinsamen Identifikator festlegen; anstelle der SKU können auch Barcodes, Lieferantencodes oder ein benutzerdefiniertes Feld für Produktcodes verwendet werden. Wenn kein gemeinsames Feld vorhanden ist, müssen Sie die Zuordnung über eine manuelle Mapping-Tabelle beginnen und die SKU-Konsistenz zukünftig als Prozess korrigieren.
Welchem Shop sollte ich den x-default-Wert zuweisen?
Nicht dem Shop, aus dem der Großteil Ihres aktuellen Traffics stammt, sondern dem Shop, den Sie einem neuen Besucher ohne spezifische Sprachzuordnung zeigen möchten. Der Shop, der Ihre Markenidentität am besten repräsentiert und die größte Lagertiefe aufweist, ist in der Regel der geeignetere Kandidat für x-default.
Ab wie vielen Produkten ist diese Methode sinnvoll?
Für einen Katalog mit weniger als ein paar hundert Produkten kann eine manuelle Mapping-Tabelle ausreichen; bei tausenden Produkten ist ein automatisiertes Skript über die Admin-API unerlässlich. Unabhängig von der Kataloggröße ist das entscheidende Kriterium, ob es sich tatsächlich um zwei separate Shopify-Konten handelt.
Fazit: Das richtige Problem auf der richtigen Ebene lösen
Die wichtigste Lektion dieser Fallstudie war nicht nur hreflang selbst, sondern die Ebene, auf der nach einer Lösung gesucht wurde; da der automatische Mechanismus von Shopify dieses Szenario nicht abdeckt, musste die Lösung auf der Datenebene der Shops (SKU-Mapping und Metafields) aufgebaut werden. Wenn Sie eine Marke mit demselben strukturellen Problem sind, überprüfen Sie zuerst, ob Sie sich tatsächlich in diesem Szenario befinden; bei einem einzigen Shopify-Konto reicht Markets aus, bei zwei separaten Konten bietet die hier beschriebene Methode einen gangbaren Fahrplan.
Wenn Sie die grundlegenden Schritte für eine mehrsprachige Shopify-Einrichtung durchgehen möchten, können Sie einen Blick auf unseren Leitfaden zur Einrichtung mehrsprachiger Shopify-Shops, und wenn Sie sich mit dem Übersetzungsmanagement befassen möchten, auf unseren Artikel über Shop-Übersetzungen werfen. Wenn Sie diese Zuordnung für Ihre eigene Struktur mit zwei Shops einrichten möchten, können Sie Kontakt mit Nodus Works aufnehmen.
