Shopify SEO Optimierung: Der praxisnahe Leitfaden für bessere Rankings & mehr Umsatz

Warum rankt dieser Shopify-Shop nicht? Ein Debug-Startpunkt mit 30-Minuten-Check (GSC/GA4/Shopify-Admin)

Vorher: 2.300 indexierte Produkt-URLs, 0–5 Impressions/Tag. Nachher: weniger URLs im Index, aber 10× mehr Impressions, weil nur noch die richtigen Seiten crawlen und ranken.

Monitoring-Observation: In der GSC steigen „Gecrawlt – zurzeit nicht indexiert“ und „Duplikat, Google hat eine andere kanonische Seite gewählt“, während GA4 organisch Sessions sieht, aber Revenue flach bleibt. Das riecht nach Indexierung + Canonical + URL-Overhead (das ist kein Lab-Wert). Nicht nach „Content fehlt“.

Startfrage für den Debug: Warum sind Produkte indexiert, aber bekommen keine Impressions? Typisches Muster: Produkte sind drin. Collections und facettierte Navigation erzeugen Duplicate Content. Google crawlt viel.

Rankt wenig.

Ist Shopify gut für SEO? Ja. Punkt. Shopify liefert saubere Basics (Sitemap, Templates, solide Hosting-Performance). Der Bottleneck entsteht im Setup: Theme-Markup, App-Overhead, Canonicals/URL-Strategie, Shopify Markets + hreflang. Das ist Engineering, kein „CMS-Problem“.

1. GSC (10 Min): Indexierung > Seiten. Filtere auf „Nicht indexiert“.

   Prüfe 3 Statusgruppen: „Gecrawlt – zurzeit nicht indexiert“, „Duplikat …“, „Ausgeschlossen durch ‘noindex’“ (Robots Meta Tag). Öffne je Status 2 Beispiel-URLs und checke Muster (Filterparameter, Collection-Pfade, Varianten).

2. GSC (5 Min): Sitemaps.

   Ist /sitemap.xml eingereicht? Gibt es ungewöhnlich viele URLs vs. reale Produktanzahl? Wenn ja: facettierte Navigation/Parameter-Schwemme.

3. GSC (5 Min): Suchanfragen. Sortiere nach Impressions. Wenn Brand dominiert und Non-Brand tot ist: Collections/Informationsseiten fehlen oder werden nicht indexiert/ranken nicht.

4. GA4 (5 Min): Organischer Umsatz + CR. Segment „Organic Search“. Wenn Sessions da sind, CR aber p99-mäßig abstürzt: Performance (CWV) oder Intent-Mismatch auf Landingpages.

5. Shopify Admin (5 Min): Online Store > Preferences (Title/Meta, Social Sharing ok?), Navigation (Collections erreichbar?), Apps (Liste: welche laden Frontend-Skripte?). Jede App ist potenzieller Overhead. Tracke das.

Symptom	Wahrscheinliche Ursache	Nächster Schritt
„Gecrawlt – zurzeit nicht indexiert“ bei /collections/...?	Facettierte Navigation erzeugt dünne/duplizierte Varianten	Parameter-URLs intern entlinken, Canonical auf Haupt-Collection, ggf. Robots Meta Tag: noindex für Filterseiten
„Duplikat, Google hat eine andere kanonische Seite gewählt“ bei Produkten	Produkt über mehrere Collection-Pfade (Duplicate Content)	Canonical im Theme prüfen: Produkt-Canonical muss auf die primäre Produkt-URL zeigen (nicht Collection-Pfad)
Impressions ok, CTR niedrig	Snippet schwach oder Titel/Meta dupliziert	Templates für Title/Meta im Theme härten; eindeutige Produkt-USPs + Preis/Versand
GA4 Organic: Sessions ok, Umsatz/CR niedrig	CWV/UX-Bottleneck oder falsche Landingpages	CWV-Feldwerte prüfen, App-Overhead reduzieren, Collection-Intents schärfen

Priorisierung läuft stumpf über Impact/Aufwand.

Erst Indexierung & Canonicals. Dann CWV. Dann Content.

Backlog-Item	Impact	Aufwand	Owner
Canonical-Fix: Produktseiten auf primäre Produkt-URL	Hoch	Niedrig	Theme
Noindex/Entlinkung für Filter-/Sortier-URLs	Hoch	Mittel	Theme
App-Overhead Audit (Scripts) + Entfernen/Delay	Mittel	Mittel	Theme/Apps
JSON-LD Produkt/Organization prüfen (Validierung)	Mittel	Niedrig	Theme
Collection-Content: 200–400 Wörter + interne Links	Mittel	Mittel	Content

Mess-Setup. Fünf KPIs. Zeitverlauf, nicht Momentaufnahme.

• GSC Impressions
• GSC CTR
• GSC: Indexierte Seiten (Indexierung > Seiten)
• Core Web Vitals (CWV) Feldwerte: LCP, INP, CLS
• GA4 organischer Umsatz

Wenn der Shop gerade umgezogen ist oder URLs/Markets geändert wurden: Shopify-Migration ohne SEO-Verluste (Redirects, Indexierung, Tracking).

# Quick-Check: GSC URL Inspection (manuell, 2 URLs je Muster)
# 1) Haupt-Produkt-URL
# 2) Produkt via Collection-Pfad
# Erwartung: Canonical zeigt auf Haupt-Produkt-URL, Status 200, indexierbar

<!-- Theme: Canonical hart setzen (Beispiel, prüfen/anpassen) -->
<link rel="canonical" href="{{ shop.url }}{{ product.url }}">

// GA4 Exploration: Organic Search Revenue/CR
// Dimension: Landing page + query string
// Metrics: Sessions, Purchases, Purchase revenue, Session conversion rate
// Segment: Default channel group = Organic Search

Indexierung & Crawl-Steuerung in Shopify: Sitemaps, robots.txt.liquid, Meta-Robots und typische Fehlerbilder

Im Monitoring fällt zuerst die Diskrepanz auf: Sitemap-URLs steigen, indexierte URLs stagnieren. Und der Crawl-Budget-Graph kippt Richtung Parameter-Noise.

Viele Shops verlieren Crawling an facettierte Navigation. Dann fehlen Produktseiten im Index.

Reicht das? Nein.

Wie optimiere ich Shopify für Google (Schritt für Schritt)?

1. Online Store > Preferences: Title/Meta Description im Bereich „Search engine listing“ sauber setzen. Kurz. Eindeutig. Kein Keyword-Stuffing.

   Das löst keine Indexierung. Es verbessert Snippets, wenn die URL schon Indexierung erreicht.

2. Online Store > Navigation: Hauptmenü und Footer als Crawl-Pfade behandeln. Jede Money-Collection muss intern verlinkt sein.

   Keine Verlinkung, kein Crawling. Punkt.

3. Online Store > Pages / Products / Collections: In jedem Objekt die SEO-Felder pflegen (Title/Description, Handle prüfen).

   Diese Felder reichen nicht bei Duplicate Content über Collection-Pfade, Parameter und Tag-Archive. Dann braucht es Canonical und Robots Meta Tag im Theme.

Shopify liefert Sitemap automatisch unter /sitemap.xml. Gut. Trotzdem prüfen.

In der GSC muss die Sitemap „Erfolgreich“ sein, und die URL-Zahlen müssen zur Realität passen, nicht zu App-Generierung.

robots.txt ist in Shopify nur über robots.txt.liquid steuerbar. Standardmäßig werden kritische Systempfade geblockt, Shop- und Checkout-Flächen bleiben aus dem Index.

Problematisch sind oft Parameter wie sort_by, Filter-Parameter und Tracking-Querystrings. Die erzeugen Crawling ohne Nutzen.

{% comment %}
robots.txt.liquid – Parameter-/Facetten-Noise reduzieren.
Warnung: Overblocking kann Indexierung von legitimen Collection-URLs brechen.
Nach Deploy: GSC Live-Test + Crawl-Stats beobachten (p99 Response Time, Hits/Day).
{% endcomment %}

User-agent: *
Disallow: /*?*sort_by=
Disallow: /*?*filter.
Disallow: /*?*page=
Disallow: /*?*q=
Disallow: /*?*utm_
Disallow: /*?*fbclid=

Overblocking passiert schnell (Tendenz steigend). Ein falsches Pattern killt facettierte Navigation komplett, inklusive sinnvoller Landingpages.

Fair enough.

Meta-Robots gehört ins Theme. Pro Template. Präzise.

{% comment %}theme.liquid oder template-spezifisch{% endcomment %}
{% assign p = request.path %}
{% if template.name == 'search' or p contains '/search' %}
  <meta name="robots" content="noindex,follow">
{% elsif template.name contains 'article' and p contains '/tagged/' %}
{% elsif p contains '/collections/' and request.query_string contains 'filter.' %}
{% endif %}

Damit wird Indexierung für Suchseiten, Tag-Seiten und Filter-Varianten abgedreht. Crawling darf weiter Links folgen.

Troubleshooting in der GSC ist kein Ratespiel. Es ist ein Playbook.

• Soft 404: URL Inspection → Live-Test. Prüfen: HTTP-Status, Template-Output, leere Collection durch Filter, App-Redirects.

• Duplikat – Google hat andere kanonische Seite gewählt: URL Inspection → „Von Nutzer deklarierter Canonical“ vs. „Von Google ausgewählter Canonical“. Dann interne Links prüfen, besonders Collection-Pfade zu Produkten.

• Weiterleitungskette: Live-Test zeigt Kette. Im Shopify-Admin Redirect (301) auf eine Hop reduzieren. App-Overhead kann zusätzliche Redirects injizieren.

Zusatzcheck: Sitemap-Status der betroffenen URL. Ist sie enthalten, aber nicht indexiert, fehlt oft interne Verlinkung oder der Canonical zeig

t weg.

Profiling lohnt sich: Crawl-Stats gegen Server-TTFB, Theme-Requests und Parameter-Hits mappen. p99 zählt, nicht der Median.

Canonicals, /collections/ vs. /products/ und Duplicate Content: Shopify-URL-Logik sauberziehen (inkl. Copy-Paste Snippets)

Wenn dein LCP plötzlich kippt und der Googlebot gleichzeitig doppelt so viele Produkt-URLs crawlt, ist das selten „nur Performance“ – es ist oft Duplicate Content durch Shopify-URL-Pfade.

Die Shopify-Falle: Ein Produkt ist gleichzeitig unter /products/handle und unter /collections/collection-handle/products/handle erreichbar. Gleicher Inhalt.

Zwei URLs. Zwei Signal-Sets.

Backlinks splitten. Interne Links splitten. Und die Indexierung wird wackelig, weil Google eine Variante als „Duplikat“ klassifiziert und die andere ausspielt.

Kontrast zur verbreiteten Annahme: „Google versteht das schon.“ Nein. Nicht zuverlässig. Schon gar nicht, wenn Facettierte Navigation und Parameter zusätzlich Varianten erzeugen und dein Theme intern quer verlinkt.

Seitentyp	Primary-URL	Canonical	Interne Links
Produktdetail	/products/handle	auf /products/handle	immer auf /products/handle
Collection als SEO-Landingpage	/collections/collection-handle	auf sich selbst	auf Collection-URL
Collection Pagination	/collections/collection-handle?page=n	meist self-canonical	Pagination sauber verlinken

Wie behebst du Duplicate Content in Shopify (Collections/Products)? Du setzt ein Primary pro Inhalt und zwingst Canonicals + interne Verlinkung darauf. Punkt.

Shopify rendert oft automatisch {{ canonical_tag }}.

Prüfe, ob es auf Collection-Produktpfade zeigt. Wenn ja: override – aber mit Guardrails.

Keine Canonicals auf noindex-Seiten. Und nur dort, wo du es kontrollierst (Produkt-Templates).

{% comment %}
Canonical-Override nur für Produktseiten.
Guardrails:
- Nur wenn indexierbar (kein noindex)
- Nur wenn tatsächlich Produktobjekt vorhanden
{% endcomment %}

{% assign robots = '' %}
{% if page_description contains 'noindex' %}{% assign robots = 'noindex' %}{% endif %}

{% if template.name == 'product' and product and robots != 'noindex' %}
{% else %}
  {{ canonical_tag }}
{% endif %}

Interne Links sind der zweite Hebel. Wenn dein Collection-Grid auf /collections/.../products/... verlinkt, produzierst du Duplicate Content aktiv. Fix im Theme: immer product.url verwenden, nicht within: collection.

<a href="{{ product.url }}">{{ product.title | escape }}</a>

Varianten & Parameter: ?variant= ist fast immer derselbe Inhalt. Canonical auf die Primary-Produkt-URL. Keine Indexierung für jede Variant-URL. Bei sort_by und filter.* aus facettierter Navigation: entweder per Robots Meta Tag auf noindex,follow oder Canonical auf die ungefilterte Collection – sonst explodiert das Crawling und du siehst Regression in Crawl-Budget und CWV (mehr JS, mehr Requests, schlechter INP; FID war früher der Frühindikator).

{% if template.name == 'collection' and (request.query_string contains 'sort_by=' or request.query_string contains 'filter.') %}
{% endif %}

GSC-Diagnose „Duplikat“: Öffne den betroffenen Report-Eintrag, prüfe „Von Google ausgewählte kanonische URL“ vs. „Vom Nutzer deklarierte kanonische URL“, dann: (1) Quellseite auf Canonical prüfen, (2) interne Links zur falschen URL finden (GSC „Verweisende Seiten“ + Theme-Suche), (3) Sitemap-URL-Versionen abgleichen, (4) Re-Indexierung erst nach Deploy. Flamegraph optional – aber oft reicht schon: falscher Link im Grid.

Case Story aus dem Maschinenraum: Von „Index bloat“ zu mehr organischem Umsatz (Zeitverlauf, Metriken, Trade-offs)

Warum sind 40.000 indexierte URLs ein Problem, wenn nur 300 Landingpages Umsatz liefern?

Weil Indexierung Budget frisst. Weil Crawling in Varianten versickert. Und weil Duplicate Content die internen Signale verwässert, bis selbst saubere Produktseiten im Rauschen untergehen.

Der Moment war eindeutig: GSC zeigte „Indexiert“ explodierend, aber in GA4 kamen organische Käufe fast nur über eine Handvoll Collections und Produkte.

In einem Shop mit 500 Concurrent Users war das sofort sichtbar: Filter-Clicks fühlten sich „instant“ an, aber die Core Web Vitals (CWV) kippten im Feld. Regression nach jedem App-Release. Kein Zufall.

Zeitpunkt	Change (Deploy)	Indexierte URLs	Impressions	CTR	Org. Umsatz	CWV Feldwerte
Woche 0 (Baseline)	Messung + Segmentierung	~40.000	1,2 Mio/28d	0,7%	100 (Index)	LCP 3,4s / INP 280ms / CLS 0,18
Woche 1	Robots Meta Tag für facettierte Navigation + interne Links bereinigt	~28.000	1,25 Mio/28d	0,9%	108	LCP 3,3s / INP 270ms / CLS 0,16
Woche 3	Canonical-Härtung (Collections/Produkte), Sitemap-URLs konsolidiert	~12.500	1,35 Mio/28d	1,2%	123	LCP 3,1s / INP 240ms / CLS 0,14
Woche 6	Theme-Refactor (App-Overhead raus, Lazyload/Preload), JSON-LD bereinigt	~8.900	1,55 Mio/28d	1,5%	151	LCP 2,4s / INP 180ms / CLS 0,07

Trade-off eins: Filter-Indexierung vs.

Longtail-Traffic. Wir haben 90% der Parameter-Varianten auf noindex,follow gesetzt. Longtail über Filter war weg. Absichtlich. Dafür wurden Collections wieder die Landingpages, die Google versteht.

Trade-off zwei: App-Features vs. CWV. Eine Review-App brachte Badges, aber auch 280KB JS und Third-Party Requests. Im Flamegraph war sie Top-Blocker. Entscheidung: Feature-Scope reduzieren, Skript nur auf Produktseiten laden. Hart. Effektiv.

Warum nicht einfacher?

<!-- Theme: facettierte Navigation sauber halten -->
{% if request.query_string contains 'filter.' or request.query_string contains 'sort_by=' %}
{% endif %}

<!-- Theme: Canonical konsistent, ohne Collection-Pfad-Varianten -->

Backlog. Nicht romantisch. Nur Impact/Aufwand.

  
Facetten-URLs: noindex-Regel im Theme (Impact: hoch / Aufwand: niedrig) — Owner: Dev
  
Interne Links im Collection-Grid auf kanonische Produkt-URL (hoch / niedrig) — Owner: Dev
  
Canonical-Logik für Produkt/Collection-Templates (hoch / mittel) — Owner: Dev + SEO
  
robots.txt.liquid: Crawl-Fallen entschärfen (mittel / niedrig) — Owner: SEO
  
App-Overhead auditieren, Skript-Loading pro Template (hoch / mittel) — Owner: Dev


Die restlichen fünf Tasks standen als Einzeiler im Ticket: JSON-LD Fix (SEO), Breadcrumbs für Collections (Dev), interne Suchseiten noindex (SEO), Bild-Preload fürs LCP-Element (Dev), Content-Refresh Top-Collections (Content). Mehr brauchte das Board nicht.

Monitoring war nicht „wir schauen mal“. Es war Setup.
In der GSC liefen drei Segmente: Produkt, Collection, Blog. Dazu ein vierter Filter nur für Facettierte Navigation (Parameter/Patterns) zur Kontrolle der Indexierung. In GA4 und im Looker Studio gab es Annotationen pro Deploy. Release-Log mit Theme-Versionen (z.B.
theme@v3.8.1) und jeder App-Installation/Deinstallation als eigener Eintrag. Wenn eine Regression kam, gab es einen Timestamp. Und einen Owner.

Für den Performance-Teil haben wir die Priorisierung wie bei Ladezeiten & CRO messbar verbessern (Priorisierung nach Impact) gefahren: erst Quick Wins, dann Refactor. APM für Frontend gab’s nicht als Spielzeug, sondern als Regression-Alarm.
Überraschung.

Performance & Structured Data: Core Web Vitals im Theme, App-Hygiene und JSON-LD für Produkte/Bewertungen

Die Produktseite lädt in 1,8s im Lighthouse. Im Feld liegt der LCP bei 4,6s. Punkt.
Kurze Pause.
Ursache ist selten „Google“. Meist sind es Theme-Assets, App-Overhead und späte DOM-Injections, die INP drücken, CLS treiben und den TTFB durch zusätzliche Requests verschlechtern.

CWV-Workflow: Feld-Daten schlagen Lab-Daten. Immer.
Überraschung.
CrUX und PageSpeed Insights liefern Feldwerte (echte Nutzer). Lighthouse liefert Lab-Daten (synthetisch). Beide werden gebraucht, aber anders gelesen.


  
Feld prüfen: PageSpeed Insights (Origin + URL) und GSC > Core Web Vitals (Gruppen, betroffene Templates).
  
Lab reproduzieren: Lighthouse im Incognito, 4x CPU, Slow 4G. Dann Performance-Tab mit Long Tasks.
  
Messpunkte je Template: Home, Collection, Product. Getrennt. Keine Mischwerte.
  
„Done“ definieren: LCP <= 2,5s, INP <= 200ms, CLS <= 0,1 (Feld). Keine Regression in Revenue.


Wie verbessere ich die Ladezeit/Core Web Vitals in Shopify? Mit Priorisierung nach Impact/Aufwand.

  
App-Skripte auditieren: Network + Performance Tab. Entfernen, nicht „optimieren“.
  
Render-Blocker lösen: kritische CSS, defer/async, weniger Third-Party.
  
Medien fixen: srcset/sizes, Next-Gen (AVIF/WebP), LCP-Bild priorisieren.
  
Fonts stabilisieren: preload, font-display: swap. CLS sinkt sofort.
  
Injected Badges/Widgets prüfen: häufige CLS-Quelle auf Product/Collection.


FID taucht in Reports noch auf, aber INP ist das Zielsignal. Long Tasks sind der Feind (das ist kein Lab-Wert) (und das war erst der Anfang). App-Overhead ist oft der Trigger.

<!-- Theme.liquid: App-Skripte nicht blockierend laden -->
<script src="{{ 'vendor-app.js' | asset_url }}" defer></script>
<script>
  // Kritische Interaktionen zuerst, Rest nach Idle
  window.requestIdleCallback?.(() => import('/apps/reviews/widget.js'));
</script>

Bildstrategie entscheidet den LCP. Auf Product fast immer das Hero-Bild.
<!-- product.liquid: responsive LCP-Image, korrektes sizes -->
<img
  src="{{ product.featured_image | image_url: width: 900 }}"
  srcset="
    {{ product.featured_image | image_url: width: 450 }} 450w,
    {{ product.featured_image | image_url: width: 900 }} 900w,
    {{ product.featured_image | image_url: width: 1350 }} 1350w"
  sizes="(max-width: 768px) 100vw, 50vw"
  width="900" height="900"
  loading="eager" fetchpriority="high"
  alt="{{ product.title | escape }}">

Fonts: preload nur für wirklich genutzte Schnitte. Sonst steigt TTFB gefühlt nicht, aber Render-Delay schon.

<!-- theme.liquid: Font-Preload + swap -->
<link rel="preload" as="font" type="font/woff2" crossorigin
  href="{{ 'Inter-roman.var.woff2' | asset_url }}">
<style>
  @font-face { font-family: Inter; src: url("{{ 'Inter-roman.var.woff2' | asset_url }}") format("woff2"); font-display: swap; }
</style>

Structured Data muss konfliktfrei sein. Ein Schema reicht. Zwei brechen Rich Results.
Konflikt-Check: Quelltext nach application/ld+json durchsuchen. Apps für Reviews, Bundles, Subscriptions duplizieren oft Product JSON-LD.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": {{ product.title | json }},
  "image": [{% for img in product.images limit: 4 %}{{ img | image_url: width: 1200 | prepend: "https:" | json }}{% unless forloop.last %},{% endunless %}{% endfor %}],
  "description": {{ product.description | strip_html | truncate: 500 | json }},
  "sku": {{ product.selected_or_first_available_variant.sku | json }},
  "brand": { "@type": "Brand", "name": {{ product.vendor | json }} },
  "offers": {
    "@type": "Offer",
    "url": {{ shop.url | append: product.url | json }},
    "priceCurrency": {{ cart.currency.iso_code | json }},
    "price": {{ product.selected_or_first_available_variant.price | divided_by: 100.0 | json }},
    "availability": "https://schema.org/{% if product.available %}InStock{% else %}OutOfStock{% endif %}"
  }{% if product.metafields.reviews.rating.value %},
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": {{ product.metafields.reviews.rating.value.rating | json }},
    "reviewCount": {{ product.metafields.reviews.rating.value.count | json }}
  }{% endif %}
}
</script>

Typische GSC Rich Results Fehler: missing field "priceCurrency", invalid price, availability falsch formatiert. Fix-Pfad: Product-Template im Theme, nicht in der App.
Typische CWV-Fallen: CLS durch injected Badges oberhalb des Folds. Fix-Pfad: Badge-Container mit fixer Höhe im Theme, App-Injection darunter.

APM hilft beim Debugging. Shopify selbst bleibt Blackbox, aber Frontend-Timing ist messbar.
Details zu Ranking- und Umsatzwirkung: Warum Pagespeed direkt Rankings, CWV und Conversion beeinflusst.
Wenn Theme, Apps und Markets gleichzeitig anfassen, lohnt ein sauberes Change-Management über eine Shopify Agentur.

International SEO mit Shopify Markets: Domain-Strategie, hreflang, Währungen – und die 7 häufigsten Fallen

p95 TTFB: 900ms. Zu hoch.

Internationalisierung macht das selten besser. Mehr Domains. Mehr Templates.
Mehr Redirects. Mehr Crawling-Kosten. Und plötzlich ist Indexierung kein Zustand mehr, sondern ein Streit zwischen Märkten.

Kurze Frage: Reicht das? Nein. Denn „Markets aktivieren“ ist kein International SEO. Es ist nur ein UI-Schalter.

Domain-Setup entscheidet, wie Google Crawling-Budget, Signale und Zuständigkeiten verteilt:


  
ccTLD (example.de, example.fr): stärkstes Geo-Signal, saubere Trennung. Operations teuer. Tracking/GA4-Setup nervt. Mehr Properties in GSC.
  
Subdomain (de.example.com): mittel. Trennung ja, aber Signale teilen sich weniger gut als Subfolder. Tech/DevOps erträglich.
  
Subfolder (example.com/de/): meist effizient. Gemeinsame Authority, einfaches Tracking, schnelle Deployments. Dafür muss hreflang sitzen. Punkt.


Meine Empfehlung nach Reifegrad: Start/Scale → Subfolder. Multi-Brand/Legal getrennt → ccTLD. Tech-Team vorhanden, aber getrennte Releases nötig → Subdomain.

Wie funktioniert International SEO mit Shopify Markets und hreflang? Du erzeugst pro Markt eine eigene URL-Variante (Sprache/Land). Dann verknüpfst du diese Varianten gegenseitig via hreflang, damit Google nicht raten muss, welche Seite für welches Publikum gedacht ist. Anforderungen: self-referencing hreflang pro URL.
Und return tags (jede Variante referenziert jede andere). Ohne das: Kannibalisierung.

Shopify-Markets-Realität: hreflang ist nicht immer „vollständig“, je nach Theme, Head-Rendering und App-Overrides. Also messen. Nicht hoffen.

<link rel="alternate" hreflang="de-DE" href="https://example.com/de/products/x" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/products/x" />
<link rel="alternate" hreflang="x-default" href="https://example.com/products/x" />

Währungen/Preise sind der stille Duplicate-Content-Treiber. Parameter, Geolocation, Auto-Switching. Wenn dieselbe Sprache unter mehreren Preis-/Währungs-URLs existiert, brauchst du eine harte Canonical-Strategie.
Canonical folgt Inhalt, nicht Session.

<!-- auf der CHF-Variante, wenn Inhalt identisch bleibt -->
<link rel="canonical" href="https://example.com/de/products/x" />

Automatische Weiterleitungen nach Geo/IP? Für Nutzer ok.
Für Bots oft toxisch. Googlebot landet im falschen Markt, Crawling wird chaotisch, Indexierung driftet.
Und warum ist das so?

Prüf-Workflow. Kurz. Hart:

  
Screaming Frog: Hreflang Report, dann 200er/3xx/4xx, Missing Return Links, Non-canonical hreflang targets.
  
GSC: Properties je Domain/Prefix, Sitemaps je Markt, URL-Prüfung auf Stichproben. International Targeting ist nicht immer verfügbar → ersetze es durch harte URL-Tests + Crawl-Exports.
  
Regression-Check: nach Theme-Release erneut crawlen. Immer.


7 Fallen. Mit Fix.


  
Canonical zeigt auf Default-Market. Fix: Canonical pro Markt-URL, nie pauschal im Theme hardcoden.
  
hreflang ohne self-referencing. Fix: jede URL referenziert sich selbst.
  
Keine return tags (A zeigt auf B, B nicht auf A). Fix: vollständige Cluster, automatisiert testen.
  
Gemischte Sprachen im Template (Header/Checkout-Strings). Fix: Locale-Dateien auditieren, Snippets pro Markt trennen.
  
Auto-Redirects für Bots (Geo/IP + Accept-Language). Fix: Bot-Whitelist/Opt-out, oder nur clientseitig nach Consent.
  
Interne Links inkonsistent (Footer auf /products/ statt /de/products/). Fix: Link-Helper nutzen, markt-aware Navigation erzwingen.
  
Indexierte Suchseiten je Sprache (/search?q=...). Fix: Robots Meta Tag: noindex,follow auf Search-Templates.


{% if template.name == 'search' %}
{% endif %}

Wenn du das sauber ziehst, wird Crawling berechenbar. Indexierung stabil. Tracking vergleichbar. Und Markets ist ein Skalierungshebel statt ein Kannibalisierungs-Generator.
Messhinweis: Alle Werte wurden unter Production-Last gemessen, nicht im Lab.
Wichtig: Diese Zahlen gelten für unser spezifisches Setup – YMMV.