Die meisten Ratschläge zu E-Commerce-SEO sind für Blogs geschrieben, die sich als Shop verkleiden. Title-Tags, Meta-Descriptions, „mehr Content veröffentlichen" — nichts davon rührt an das, was den organischen Umsatz eines Produktkatalogs wirklich deckelt: den Katalog selbst.
Ein Shopify-Store mit 500 SKUs und ein Headless-Storefront mit 50.000 SKUs haben eigentlich kein Content-Problem. Sie haben ein Kombinatorik-Problem, ein Duplicate-Content-Problem und ein Schema-Problem. Löst man diese drei, folgen die Rankings von selbst. Ignoriert man sie, gleicht auch der beste Blog-Output das nicht aus.
Facettennavigation ist im Handel weiterhin der größte Crawl-Budget-Fresser
Jede Collection-Seite mit Filtern ist ein URL-Generator. Vier Filtertypen — Größe, Farbe, Preis, Marke — mit je acht Optionen erzeugen aus einer einzigen Collection über 4.000 adressierbare Kombinationen. Multipliziert man das mit 40 Collections, hat man eine Website mit mehr indexierbaren URLs als SKUs gebaut — die meisten davon Near-Duplicates, die sich nur durch die Sortierreihenfolge oder einen vereinzelten ?filter.v.option.color=-Parameter unterscheiden.
Google hat Facettennavigation wiederholt als eine der Hauptursachen für Crawl-Budget-Verschwendung auf Handelsseiten genannt — und Crawl-Budget ist genau die Ressource, die sich kleine und mittelgroße Shops am wenigsten leisten können zu verschwenden. Verbringt Googlebot einen Besuch damit, 200 Permutationen von „black-shoes-size-9-under-50" zu crawlen, dann crawlt er in dieser Zeit weder Ihre Neuheiten noch Ihre wieder aufgefüllten Bestseller.
Die Lösung lautet nicht „einfach alles blockieren". Sie besteht in einer konsequent angewendeten Filter-Policy:
- Kombinationen mit nur einem, wenig aussagekräftigen Filter (Sortierreihenfolge, Ansichtstyp) auf die übergeordnete Collection kanonisieren.
- Kombinationen mit echter Suchnachfrage — etwa „wasserdichte Wanderschuhe Größe 10", falls diese Phrase tatsächlich gesucht wird — auf eine eigene, indexierbare, optimierte URL auflösen lassen.
- Den Long Tail von Multi-Filter-Kombinationen, nach denen niemand sucht, auf Noindex setzen, da sie nur das Relevanzsignal der übergeordneten Collection verwässern — das aber nicht mit einem robots.txt-Disallow auf denselben URLs kombinieren, denn eine per Disallow gesperrte Seite kann gar nicht erst gecrawlt werden, um das Noindex-Tag überhaupt zu sehen, und eine gesperrte, aber verlinkte URL kann trotzdem als nackter Eintrag ohne Beschreibung im Index auftauchen. Für ein gegebenes URL-Muster nur einen Mechanismus wählen, nicht beide.
- Facettierte URLs komplett aus der XML-Sitemap heraushalten. Eine Sitemap sollte die Seiten auflisten, die ranken sollen — nicht jede URL, die technisch existiert.
Das ist eine Ermessensentscheidung, kein einmaliges Häkchen — und sie muss jedes Mal neu getroffen werden, wenn das Merchandising-Team einen neuen Filtertyp hinzufügt.
Duplicate-Content-Fallen speziell für Produktkataloge
Duplicate Content in Blogs ist meist unabsichtlich. Duplicate Content in Katalogen ist meist strukturell bedingt.
Varianten-URLs. Ein T-Shirt in sechs Farben und fünf Größen kann 30 separate URLs für ein einziges Produkt erzeugen, wenn die Plattform Varianten nicht unter einer einzigen kanonischen URL zusammenführt. Shopify löst das standardmäßig recht gut; viele Headless-Builds machen es falsch, weil dynamische Routen eingerichtet werden, bevor überhaupt jemand eine Canonical-Strategie festgelegt hat.
Syndizierte Produktbeschreibungen. Vom Hersteller gelieferte Produkttexte tauchen wortwörtlich auf Dutzenden konkurrierenden Händlerseiten auf. Wenn Ihre PDP Wort für Wort mit fünfzehn anderen Shops identisch ist, die dieselbe SKU verkaufen, hat Google keinen Grund, Ihre Seite zu bevorzugen — und ein Shopper, der Tabs vergleicht, auch nicht. Das ist zudem eines der am leichtesten behebbaren und zugleich am meisten ignorierten Probleme im E-Commerce-SEO im mittleren Marktsegment. Schon die ersten 150 Wörter einer syndizierten Beschreibung umzuschreiben reicht oft aus, um die Seite zu differenzieren.
Sortierparameter, keine Paginierung. ?sort=price-asc und ?sort=newest auf derselben Collection zeigen dieselben Produkte nur in anderer Reihenfolge und sollten auf die Basis-URL kanonisieren. Bei Paginierung liegt der Fall anders: ?page=2 einer großen Collection zeigt meist tatsächlich andere Produkte als Seite 1 — kanonisiert man sie auf Seite 1 zurück, weist man Google an, Produkte zu ignorieren, die nur auf dieser Seite erscheinen. Seit Google rel=next/prev 2019 abgeschafft hat, lautet die eigene Empfehlung, jede paginierte Seite auf sich selbst kanonisieren zu lassen (oder auf eine „Alle anzeigen"-Seite, falls vorhanden) — Seite 2 und folgende niemals auf Seite 1 zusammenfassen.
Staging- und Locale-Duplizierung. Headless-Storefronts auf Next.js oder ähnlichen Frameworks lassen häufig eine Staging-Subdomain crawlbar, oder liefern nahezu identischen Content über /us/- und /en-us/-Pfade aus, ohne sie per Hreflang zu verknüpfen. Beides lässt sich mit einer fünfminütigen robots.txt- und Header-Prüfung vermeiden.
Produkt-Schema: Was heute tatsächlich Rich Results bringt
Strukturierte Daten auf einer Produktseite brauchen Product, Offer und — sofern echte Bewertungen vorliegen — AggregateRating. Das hat sich nicht geändert. Geändert hat sich die Durchsetzung: Google prüft heute strenger, ob strukturierte Daten mit dem übereinstimmen, was auf der Seite tatsächlich sichtbar ist. Markiert man einen Preis oder einen Verfügbarkeitsstatus, der nicht dem entspricht, was ein Shopper sieht, wird der Rich Result für diese Seite unterdrückt.
Regeln, die sich in der Praxis bewähren:
priceundavailabilitysollten im selben Takt aktualisiert werden wie der Warenbestand-Feed — nicht über Nacht per Batch-Job, während sich der Lagerbestand in Echtzeit ändert.- Niemals Bewertungszahlen aus einem Drittanbieter-Aggregator markieren, wenn diese Bewertungen nicht auf der Seite selbst angezeigt werden.
Product-Schema auf einer Kategorie- oder Collection-Seite ist gemäß Googles Richtlinie für Multi-Product-Listings möglich, aber jedes Produkt braucht weiterhin seine eigenen, vollständigen Pflichteigenschaften, und die Voraussetzungen für einen Rich Result sind in dieser Konfiguration enger gefasst und schwerer zu erfüllen als bei einer einzelnen Produkt-PDP — die meisten Shops fahren besser damit, den Aufwand in sauberes Markup pro Produkt auf den PDPs zu investieren.- Bei variantenreichen Produkten
ProductGroup-Schema einsetzen, damit Google die Farbe/Größe-Beziehung versteht, statt dreißig unabhängige Produkte zu lesen.
Schema ist eine Rendering-Anweisung an Google, kein Ranking-Trick. Es verschafft den Rich Result — Sterne, Preis, Verfügbarkeitsstatus —, der die Klickrate auf einer Seite steigert, die es ohnehin schon verdient, zu ranken. Rankings aus dem Nichts erzeugt es nicht.
Shopify vs. Headless: Wo die eigentlichen Einschränkungen liegen
Shopify hat die meisten seiner historischen SEO-Lücken geschlossen — robots.txt wurde 2021 direkt bearbeitbar, und Canonical-Tags auf Varianten-URLs werden standardmäßig gehandhabt. Die verbleibenden Einschränkungen sind struktureller Natur: Collection-URLs sind fest auf /collections/ festgelegt, und die Parameter-Verarbeitung der nativen Filter-App braucht in den meisten Themes weiterhin einen manuellen Kanonisierungs-Durchgang.
Headless-Setups (Hydrogen, Next.js Commerce, Vue Storefront) heben diese Plattform-Limits vollständig auf — volle Kontrolle über URL-Struktur, Canonical-Logik und Schema-Ausgabe —, aber sie heben auch die Leitplanken auf. Ein häufiges Fehlerbild: Produkt- und Kategorieseiten werden clientseitig gerendert, Meta-Tags und strukturierte Daten werden erst nach der JavaScript-Ausführung eingefügt. Googlebot rendert zwar JS, aber in einem verzögerten zweiten Durchgang statt sofort — wie lang diese Verzögerung ausfällt, hängt von Site-Größe und Crawl-Priorität ab und lässt sich nicht als feste Zahl einplanen. Alles Umsatzkritische auf einer PDP — Title, Preis, Schema — muss im serverseitig gerenderten HTML vorhanden sein und darf nicht erst clientseitig nach der Hydration zusammengesetzt werden.
Unser E-Commerce-Team behandelt diese Rendering-Frage als einen der ersten Punkte, die bei einem Headless-Projekt geprüft werden, weil sie im Browser unsichtbar bleibt und in der Search Console als reale Umsatzlücke auftaucht.
Was den organischen Umsatz tatsächlich antreibt
Meistens nicht der Blog-Content. Kategorie- und Collection-Seiten tragen die kommerzielle Suchintention und das Volumen der Head-Terms, und bei vielen Katalogen sind sie eine wesentliche Quelle des organischen Umsatzes, weil sie für Begriffe mit echter Kaufabsicht ranken — „wasserdichte Wanderschuhe", nicht „wie wasserdicht sind Wanderschuhe". Produktseiten konvertieren einzeln betrachtet mit einer höheren Rate, verteilen den Traffic aber auf Tausende Long-Tail-Anfragen, sodass ihr Gesamtbeitrag kleiner ausfällt, als die Seitenzahl vermuten lässt. Blog- und Kaufratgeber-Content liegt beim direkten Umsatz mit deutlichem Abstand auf Platz drei — seine Aufgabe ist es, Links und Top-of-Funnel-Sichtbarkeit zu gewinnen, die letztlich in die Kategorieseiten einfließt, nicht selbst zu konvertieren.
Die praktische Reihenfolge: zuerst Crawl- und Duplizierungsprobleme bei den Collections beheben, danach das Produkt-Schema korrekt aufsetzen, und Content als die Ebene behandeln, die Autorität verstärkt — nicht als die Ebene, die den Verkauf erzeugt.
Fazit
E-Commerce-SEO wird 2026 in den Teilen einer Website entschieden, die niemand als „Content" betrachtet: Filterlogik, Canonical-Tags, der Schema-Feed, die Rendering-Pipeline. Stimmen die, konvertiert Organic endlich wie der Kanal, der es sein soll. Stimmen sie nicht, behebt das kein noch so großer Blog-Output. Wenn Ihr Katalog mehr URLs als Verkäufe produziert, ist das der Ansatzpunkt — nicht der Blog-Kalender.
