WooCommerce-SEO: Shop-Technik jenseits der WordPress-Basics

WordPress-SEO-Guides erklären Permalinks für Beiträge, die robots.txt und grundlegende On-Page-Einstellungen. Ein WooCommerce-Shop hat mit alldem zu tun, aber darüber hinaus eine eigene Baustelle: Produkt- und Kategorie-URLs, Attribut-Archive, Filter-Parameter, Produktvarianten, Lagerbestand und das strukturierte Markup, das eine Produktseite von einem gewöhnlichen Blogartikel unterscheidet. Wer nur die WordPress-Grundlagen abarbeitet, lässt genau die Stellen unberührt, an denen ein Onlineshop tatsächlich Sichtbarkeit verliert.
Dieser Artikel geht ausschließlich auf diese shopspezifischen Probleme ein: wie WooCommerce Produkt- und Kategorie-URLs aufbaut, was mit Attribut- und Filter-Seiten passiert, wie eine Variante mit vielen SKUs auf einer einzigen URL funktioniert, was mit einer Produktseite geschehen sollte, wenn der Bestand auf null fällt, und wie das Produkt-Markup korrekt gesetzt wird, ohne sich mit einem SEO-Plugin zu überschneiden.
Produkt- und Kategorie-URLs: eine stabile Basis wählen
In den WooCommerce-Einstellungen unter Produkte → Permalinks stehen mehrere Optionen zur Wahl: die Standardstruktur, die reine Shop-Basis, die Shop-Basis mit vorangestellter Kategorie, eine benutzerdefinierte Basis oder eine eigene Basis nur für die Produktkategorie-Taxonomie. Die Wahl wirkt wie eine reine Formsache, entscheidet aber darüber, ob eine Produkt-URL über Jahre stabil bleibt oder bei jeder Umsortierung im Kategoriebaum bricht.
Ein Detail, das regelmäßig übersehen wird: Die Taxonomie-Basis für Produktkategorien (standardmäßig „product-category“) ist von der Shop-Seite selbst (standardmäßig „shop“) getrennt konfiguriert. Ohne bewusste Anpassung entstehen zwei unterschiedliche Pfad-Präfixe für inhaltlich zusammengehörige Seiten, was weder Nutzern noch der internen Linkstruktur einen erkennbaren Vorteil bringt.
Kritischer ist die Option „Shop-Basis mit Kategorie“: Sie schreibt den Slug der zugeordneten Kategorie direkt in die Produkt-URL. Sobald ein Produkt eine neue Hauptkategorie bekommt oder eine Kategorie umbenannt wird, ändert sich die URL jedes betroffenen Produkts automatisch – bestehende Backlinks, Lesezeichen und in Suchergebnissen zwischengespeicherte Links laufen dann auf einen 404, sofern keine Weiterleitung eingerichtet wird. Eine benutzerdefinierte Basis ohne Kategorieanteil, etwa „/produkt/%product%/“, hält die Produkt-URL unabhängig von jeder späteren Umkategorisierung stabil.
Für die Kategorie-Hierarchie selbst gilt eine einfachere Regel: Zwei Ebenen reichen fast immer aus. Jede zusätzliche Verschachtelungsebene verlängert den Pfad, vergräbt die Unterkategorie tiefer in der internen Linkstruktur und verwässert das intern weitergegebene Relevanzsignal, ohne dass ein Nutzer diese zusätzliche Tiefe beim Navigieren tatsächlich braucht.
Attribut-Archive und Filter-URLs unter Kontrolle bringen
Globale Produktattribute wie „Farbe“ oder „Größe“ lassen sich unter Produkte → Attribute mit einer eigenen Archivseite versehen. Ist die Option zum Aktivieren des Attribut-Archivs eingeschaltet, erzeugt WooCommerce für jeden Attributwert eine eigene, öffentlich erreichbare und indexierbare Seite – unabhängig davon, ob dafür jemals redaktioneller Inhalt vorgesehen war.
Ohne eigenen Einleitungstext bestehen diese Archive nur aus einer Produktliste, die inhaltlich fast deckungsgleich mit der passenden Produktkategorie ist. Zwei nahezu identische Seiten konkurrieren dann um dieselben Suchbegriffe, statt sich gegenseitig zu stützen. Zwei Auswege bieten sich an: entweder das Attribut-Archiv mit eigenem Text zu einer echten Landingpage ausbauen, wenn für einen Begriff wie „blaue Sneaker“ tatsächlich eigenständige Nachfrage besteht, oder die Archivfunktion für Attribute ohne redaktionellen Mehrwert schlicht deaktivieren.
Ein zweites, unabhängiges Problem entsteht durch die Filterfunktion im Shop selbst. Sobald Besucher nach mehreren Attributen gleichzeitig filtern, hängt das verwendete Filter-Widget Parameter wie „?filter_farbe=blau&filter_groesse=m“ an die Kategorie-URL an. Jede Kombination aus Farbe, Größe und weiteren Attributen erzeugt eine technisch eigenständige URL – schon bei wenigen Attributen entstehen schnell einige hundert Varianten pro Kategorie, die alle denselben Grundbestand an Produkten in leicht unterschiedlicher Zusammenstellung zeigen.
Ein robots.txt-Disallow auf dieses Parametermuster wirkt naheliegend, löst das Problem aber nur oberflächlich: Eine gesperrte URL wird zwar nicht gecrawlt, kann aber trotzdem indexiert werden, sobald sie irgendwo verlinkt ist – dann erscheint sie in den Suchergebnissen ohne Beschreibung, weil Google den Inhalt nie sehen durfte. Zusätzlich verhindert die Sperre, dass Google jemals das Canonical-Tag auf dieser Seite zu Gesicht bekommt. Der zuverlässigere Weg ist, das Crawlen zuzulassen und auf jeder gefilterten URL ein Canonical-Tag auf die unbefilterte Kategorie-Seite zu setzen; WooCommerce selbst erledigt das für Filterparameter nicht automatisch, weshalb diese Logik über ein SEO-Plugin oder eigenen Code nachgerüstet werden muss.
Produktvarianten: viele SKUs, eine einzige URL
Ein variables Produkt legt für jede Variante einen eigenen Beitrag vom Typ „product_variation“ an, doch dieser Beitragstyp ist nicht öffentlich abfragbar und bekommt standardmäßig keine eigene, indexierbare URL. Für Suchmaschinen existiert also nur die eine Produktseite – jede SKU-spezifische Relevanz muss auf dieser einen URL untergebracht werden.
Das hat drei praktische Folgen. Erstens sollte der Beschreibungstext die Bandbreite der Varianten explizit benennen, etwa „erhältlich in sechs Farben und vier Größen“, damit die Seite auch für Suchanfragen relevant bleibt, die eine bestimmte Ausprägung nennen, obwohl dafür keine eigene URL existiert. Zweitens sollte die zuerst angezeigte beziehungsweise als Standard ausgewählte Variante eine tatsächlich lagernde, repräsentative Ausprägung sein – nicht die zufällig erste Variante in der Datenbank oder eine bereits ausgelaufene Farbe, denn genau dieser Zustand ist es, was beim Aufruf der Seite als Preis und Verfügbarkeit erfasst wird.
Drittens verhindert die einzelne URL zwar Duplicate Content zwischen Varianten, doch der umgekehrte Fehler ist beim Import aus einem Produktfeed oder Altsystem verbreitet: Ein Farbton wird als eigenständiges einfaches Produkt statt als Variante eines variablen Produkts angelegt. Aus einer sinnvollen Produktseite werden dadurch mehrere fast identische, die sich Backlinks, Bewertungen und Rankingsignale gegenseitig streitig machen, statt sie zu bündeln. Wurden solche Duplikate im Nachhinein zu einem variablen Produkt zusammengeführt, gehören die verwaisten Einzel-URLs per 301 auf die verbliebene Produktseite umgeleitet.
Für die Bildersuche zählt außerdem, dass jede Variante ihr eigenes Galeriebild mit einem eigenen, beschreibenden Alt-Text bekommt, statt dass alle Varianten dasselbe generische Produktfoto und denselben Alt-Text teilen.
Ausverkaufte Produkte: was mit der Seite passieren sollte
Unter den Produktdaten zum Lagerbestand stehen die entscheidenden Schalter: Lagerbestand verwalten, Rückstände erlauben und ausverkaufte Artikel im Katalog ausblenden. Diese Einstellungen bestimmen, was mit der einzelnen Produktseite passiert, sobald der Bestand auf null fällt – und genau hier entstehen einige der teuersten SEO-Fehler im gesamten Shop.
Der verbreitetste Fehler ist, ein ausverkauftes Produkt sofort zu depublizieren oder zu löschen. Die Seite hat unter Umständen über Monate Backlinks, Bewertungen und Rankingsignale aufgebaut; wird sie entfernt, verschwinden diese Signale zusammen mit ihr, und Besucher, die weiterhin über organische Ergebnisse oder gespeicherte Links darauf zugreifen, landen auf einem 404 – selbst wenn der Artikel in zwei Wochen wieder lagernd ist.
Für einen vorübergehenden Engpass ist die robustere Lösung, die Seite live und indexierbar zu lassen, den Kaufen-Button gegen ein Benachrichtigungsformular oder einen Verweis auf ein passendes Alternativprodukt auszutauschen und die Verfügbarkeit im strukturierten Markup korrekt auf „OutOfStock“ zu setzen. Ein ausverkauftes Produkt ist für sich genommen kein Qualitätsproblem; ein Snippet, das fälschlich „auf Lager“ zeigt, während die Seite tatsächlich nichts verkauft, ist es sehr wohl.
Bei endgültig eingestellten Produkten ist eine 301-Weiterleitung auf die passende Kategorie oder ein klares Nachfolgeprodukt der richtige Schritt – nicht pauschal auf die Startseite, was das vorhandene thematische Relevanzsignal verschenkt, und erst recht nicht ein Soft-404: eine Seite, die mit dem Statuscode 200 antwortet, aber nur noch „Produkt nicht mehr verfügbar“ anzeigt. Google stuft solche Seiten meist als Soft-404 ein und nimmt sie nicht in den Index auf, crawlt sie aber weiter, was unnötig Crawling-Budget bindet und keinerlei Signale an ein Nachfolgeprodukt weitergibt. Saisonale Artikel gehören eher ausgeblendet als gelöscht, damit URL und Historie bis zur nächsten Saison erhalten bleiben.
Produkt-Markup: Schema für Preis, Verfügbarkeit und Bewertungen
WooCommerce gibt über seine interne Klasse für strukturierte Daten bereits von sich aus Product- und Offer-Markup auf jeder Produktseite aus – inklusive Preis, Währung, Verfügbarkeit, SKU und, sofern Bewertungen aktiviert sind, einer aggregierten Bewertung. Das funktioniert nur zuverlässig, wenn das eingesetzte Theme die zugehörigen Hooks in seiner Produkt-Vorlage tatsächlich aufruft; ein individuell angepasstes Theme, das die Standardvorlage für die Einzelproduktseite überschreibt, lässt dieses Markup nicht selten stillschweigend verschwinden, ohne dass irgendwo eine Fehlermeldung erscheint.
Ein zweites, WooCommerce-spezifisches Risiko ist doppeltes Markup: Wird zusätzlich ein SEO-Plugin eingesetzt, das ebenfalls Product-Schema für dieselbe Seite ausgibt, entstehen zwei konkurrierende Product-Entitäten im selben Quellcode. Ein Blick in ein Tool zur Prüfung strukturierter Daten zeigt zuverlässig, ob genau eine Product-Entität vorhanden ist; findet sich das Markup doppelt, sollte eine der beiden Quellen abgeschaltet werden – in der Regel die des SEO-Plugins, weil das WooCommerce-eigene Markup direkt an die tatsächlichen Bestandsdaten gekoppelt ist.
Beim Preis muss der im Markup ausgezeichnete Wert exakt dem tatsächlich angezeigten Preis entsprechen, einschließlich der gewählten Steueranzeige als Brutto- oder Nettopreis – eine Abweichung zwischen sichtbarem und ausgezeichnetem Preis wird von Google erkannt und kann dazu führen, dass die Rich-Result-Darstellung für die betroffene Seite unterdrückt wird. Der Verfügbarkeitswert, ob InStock, OutOfStock, PreOrder oder BackOrder, sollte automatisch aus denselben Lagerbestands-Einstellungen abgeleitet werden, die auch die sichtbare Seite steuern, statt fest verdrahtet zu sein.
Eine aggregierte Bewertung gehört nur ins Markup, wenn tatsächlich echte Bewertungen vorliegen. Ein Produkt ohne eine einzige Rezension sollte keinen Bewertungsblock im strukturierten Markup tragen, auch wenn ein Theme oder Plugin diesen standardmäßig mit einem Platzhalterwert füllen würde.
Doppelte Inhalte durch Sortierung, Paginierung und Mehrfachkategorien
Shop- und Kategorieseiten erzeugen durch Sortieroptionen wie Preis oder Beliebtheit sowie durch Paginierung zusätzliche URL-Varianten derselben Produktliste. Jede dieser Varianten zeigt inhaltlich denselben Produktbestand in einer anderen Reihenfolge oder einem anderen Ausschnitt.
In der Standardkonfiguration setzen WooCommerce beziehungsweise das Theme auf diesen Archivseiten ein selbstreferenzierendes Canonical-Tag, das jede paginierte Seite auf sich selbst statt einheitlich auf Seite eins verweisen lässt – das entspricht der gängigen Empfehlung, weil jede Seite tatsächlich unterschiedliche Produkte listet. Verlassen sollte man sich darauf trotzdem nicht: Ein Seiten-Builder, ein Caching-Plugin oder ein individuell angepasstes Archiv-Template kann dieses Tag verschieben oder ganz entfernen, ohne dass es optisch auffällt. Ein Blick in den Quelltext einer paginierten und einer sortierten URL zeigt zuverlässig, ob das Canonical-Tag tatsächlich noch dort steht, wo es hingehört.
Die zweite Quelle für doppelte Pfade ist die Mehrfachzuordnung eines Produkts zu mehreren Kategorien in Kombination mit einer kategoriehaltigen Permalink-Struktur. Interne Links aus unterschiedlichen Kategorielisten können dann auf unterschiedliche, jeweils gültige URL-Varianten desselben Produkts zeigen. Eine kategorieunabhängige Produkt-URL löst dieses Problem an der Wurzel; ist das aus bereits bestehenden Links nicht mehr praktikabel, bleibt als zweitbeste Lösung ein konsequent gepflegtes Canonical-Tag auf die eine gewählte Ziel-URL.
Ein Crawl mit einem gängigen SEO-Crawler zeigt zuverlässiger als jede manuelle Stichprobe, ob gefilterte, sortierte und paginierte Varianten tatsächlich korrekt kanonisieren oder ob sich unter der Haube Hunderte selbstständig indexierbarer Seiten pro Kategorie angesammelt haben.
Häufige Fragen
Braucht jede Produktvariante eine eigene URL für gute Rankings?
Nein. Variationen sind kein öffentlich abfragbarer Beitragstyp und bekommen standardmäßig keine eigene URL; die gesamte Relevanz für unterschiedliche Farben, Größen oder Ausführungen muss auf der einen Produktseite abgebildet werden, etwa im Beschreibungstext und über variantenspezifische Bilder.
Sollte ich Attribut-Archivseiten wie /farbe/blau/ per robots.txt sperren?
Nur wenn du auf eine Konsolidierung per Canonical-Tag ganz verzichten willst. Eine robots.txt-Sperre verhindert das Crawlen, nicht zwingend die Indexierung, und blockiert zusätzlich jedes Canonical-Signal auf dieser Seite. In den meisten Fällen ist ein Canonical-Tag auf die passende Kategorie oder ein eigener redaktioneller Text die bessere Lösung.
Was passiert SEO-technisch, wenn ein Produkt vorübergehend ausverkauft ist?
Die Seite sollte online und indexierbar bleiben, mit dem Verfügbarkeitswert OutOfStock im strukturierten Markup und einer Alternative wie einem Benachrichtigungsformular anstelle des Kaufen-Buttons. Depublizieren oder Löschen kostet aufgebaute Backlinks und Rankingsignale, die sich nach einer Wiederauffüllung nicht automatisch zurückholen lassen.
Können WooCommerce und ein SEO-Plugin gleichzeitig Produkt-Schema ausgeben?
Technisch ja, aber dann entstehen zwei Product-Entitäten im selben Quellcode, was Prüfwerkzeuge für strukturierte Daten als Konflikt werten kann. Es sollte immer nur eine Quelle aktiv sein – meist die WooCommerce-eigene, weil sie unmittelbar mit den echten Bestandsdaten verknüpft ist.
Ändert sich die Produkt-URL, wenn ich die Hauptkategorie eines Produkts wechsle?
Nur bei der Permalink-Option Shop-Basis mit Kategorie, bei der der Kategorie-Slug Teil der Produkt-URL ist. Mit einer benutzerdefinierten, kategorieunabhängigen Basis bleibt die Produkt-URL bei jeder Umkategorisierung unverändert.
Aktualisiert: 17 Oktober 2026