Wer sich intensiver mit dem Bereich Technische SEO beschäftigt, stößt bei Onlineshops früher oder später auf ein Problem, das zunächst erstaunlich banal wirkt: Filter.
Ein Nutzer befindet sich beispielsweise in der Kategorie „Schuhe“ und filtert nach Nike, Größe 44, rot und sofortiger Lieferbarkeit. Technisch kann daraus problemlos eine URL wie diese entstehen:
/schuhe?marke=nike&groesse=44&farbe=rot&lieferbar=sofort
Für den Nutzer ist das sinnvoll. Er grenzt das Sortiment ein und erhält genau die Produkte, die ihn interessieren. Für eine Suchmaschine kann dieselbe Funktion jedoch schnell zu einem erheblichen Problem werden. Denn aus einigen wenigen Filtern entstehen nicht nur ein paar zusätzliche URLs. Je mehr Filter miteinander kombiniert werden können, desto größer wird der mögliche URL‑Raum. Aus einigen Kategorien und Attributen können so Tausende, Hunderttausende oder sogar Millionen verschiedener Varianten entstehen.
Google bezeichnet diese sog. Facettensuche (facettierte Navigation) deshalb ausdrücklich als eine häufige Ursache für Overcrawling. Jede neue Kombination kann eine zusätzliche URL erzeugen. Googlebot verbringt dann womöglich einen erheblichen Teil seiner Ressourcen damit, immer neue Varianten derselben Produktlisten abzurufen, während wichtigere neue oder aktualisierte Seiten langsamer entdeckt werden. Google beschreibt dieses Problem selbst ausführlich in seiner Dokumentation zur Facettensuche (Navigation).
Die offensichtliche Reaktion wäre nun, mit canonical, noindex oder der robots.txt gegenzusteuern. Genau dort beginnt allerdings häufig das eigentliche Missverständnis. Denn bevor ich entscheide, mit welchem technischen Signal ich eine URL behandle, muss ich zunächst klären, was diese URL innerhalb meiner Website überhaupt sein soll.
Crawling und Indexierung sind nicht dasselbe
Eine der wichtigsten Grundlagen im Bereich Technische SEO ist die Unterscheidung zwischen Crawling und Indexierung.
Wenn Google eine URL crawlt, bedeutet das zunächst lediglich, dass Googlebot diese URL aufruft und ihren Inhalt verarbeitet. Daraus folgt noch nicht, dass die Seite anschließend im Suchindex landet. Google selbst weist darauf hin, dass nicht jede gecrawlte Seite automatisch indexiert wird. Gerade bei großen Websites spielt diese Unterscheidung auch im Kontext des Crawl-Budgets eine wichtige Rolle.
Das wird besonders deutlich beim Umgang mit noindex. Wenn ich eine Seite mit
<meta name="robots" content="noindex">
versehe, teile ich Google mit, dass diese Seite nicht in den Suchergebnissen erscheinen soll. Damit Google dieses Signal erkennen kann, muss die Seite aber zunächst abrufbar sein. Sperre ich dieselbe URL oder das gesamte Verzeichnis, in dem sie liegt, gleichzeitig über die robots.txt, kann Googlebot die Seite unter Umständen gar nicht mehr aufrufen und das noindex damit auch nicht zuverlässig erkennen.
Google warnt ausdrücklich vor genau dieser Konstellation. Ein noindex kann nur verarbeitet werden, wenn der Crawler die entsprechende Seite auch abrufen darf.
Das klingt zunächst nach einem Detail. Tatsächlich steckt dahinter aber eine grundlegende SEO-Frage: Was möchte ich eigentlich steuern?
Mit der robots.txt steuere ich primär, welche Bereiche Googlebot crawlen darf. Mit noindex steuere ich dagegen, ob eine zugängliche Seite im Index erscheinen soll. Beide Instrumente können miteinander zusammenspielen, lösen aber nicht dasselbe Problem.
Dasselbe gilt für Canonicals.
Ein Canonical löst nicht jedes Filterproblem
Nehmen wir an, mein Shop erzeugt mehrere Varianten einer Kategorie:
/schuhe?farbe=rot
/schuhe?farbe=blau
/schuhe?groesse=44
Ich könnte all diese URLs mit einem Canonical auf
/schuhe/
verweisen lassen.
Damit sage ich Google sinngemäß: Diese Varianten gehören aus meiner Sicht zu einer gemeinsamen Gruppe ähnlicher Inhalte, und /schuhe/ ist die Version, die bevorzugt berücksichtigt werden soll.
Das kann sinnvoll sein. Google beschreibt Canonicalization als Verfahren, mit dem aus gleichen oder sehr ähnlichen URLs eine repräsentative Version bestimmt wird. Gleichzeitig macht Google deutlich, dass ein Canonical kein absolutes Kommando ist. Google kann aufgrund anderer Signale selbst zu einer anderen kanonischen URL kommen. Die Canonical-Dokumentation von Google beschreibt diese Logik ausführlich.
Gerade bei der Facettensuche entsteht dadurch aber eine zweite Frage. Selbst wenn Google meine Canonicals akzeptiert, müssen die entsprechenden URLs meist zunächst entdeckt und gecrawlt werden, damit diese Signale überhaupt verarbeitet werden können.
Wenn mein Shop also 1,5 Millionen Filterkombinationen erzeugt, löst ein Canonical zwar möglicherweise einen Teil meines Indexierungs- und Konsolidierungsproblems. Es beantwortet aber noch nicht die viel grundsätzlichere Frage:
Warum sollte Google diese 1,5 Millionen URLs überhaupt regelmäßig crawlen?
Genau an diesem Punkt wird aus einer technischen Detailfrage eine Frage der Informationsarchitektur.
Ist „Nike“ überhaupt ein Filter?
Nehmen wir erneut einen Schuhshop.
Technisch kann ich die Marke „Nike“ für Schuhe problemlos als Filter abbilden:
/schuhe?marke=nike
Aber ist „Nike“ in diesem Kontext wirklich nur ein Filter?
Wenn Nutzer regelmäßig nach „Nike Schuhe“ suchen, wenn diese Produktgruppe dauerhaft relevant ist und wenn ich genügend Produkte und Inhalte habe, um dieses Thema eigenständig abzubilden, spricht vieles dafür, daraus keine bloße Filtervariante zu machen.
Dann wäre möglicherweise eine eigene Landingpage sinnvoll:
/schuhe/nike/
Dasselbe gilt für Produkttypen. „Sneaker“ sind in vielen Shops nicht einfach irgendein Filter, sondern eine eigenständige Kategorie mit klarer Suchintention.
Daraus könnte beispielsweise entstehen:
/sneaker/
oder in einer tieferen Kombination:
/sneaker/nike/
Damit verändert sich die gesamte Perspektive. Ich versuche nicht mehr, lediglich technische Parameter möglichst elegant zu verstecken oder zu kanonisieren. Ich entscheide bewusst, welche Themen meine Website tatsächlich als eigenständige Seiten besitzen soll.
Google empfiehlt für E-Commerce-Websites grundsätzlich logisch aufgebaute, beschreibende und langfristig stabile URLs. Gleichzeitig weist Google darauf hin, dass sowohl Pfadsegmente als auch Parameter technisch legitim sein können. Die URL-Struktur allein entscheidet also nicht darüber, ob eine Seite SEO-tauglich ist.
Genau deshalb wäre es zu einfach, zu behaupten, dass /schuhe/nike/ automatisch „besser für SEO“ sei als /schuhe?marke=nike.
Entscheidend ist vielmehr, was ich mit dieser Seite mache.
Eine SEO-Landingpage muss auch wie eine Landingpage behandelt werden
Wenn ich entscheide, dass „Nike Schuhe“ eine eigenständige Suchintention abbildet, reicht es nicht, einfach nur aus einem Parameter eine hübschere URL zu machen.
Aus der Seite muss eine bewusst gepflegte Landingpage werden.
Sie bekommt einen stabilen URL-Pfad, einen eigenen Title, eine passende H1, eine sinnvolle Produktzusammenstellung, gegebenenfalls erläuternden Content, strukturierte Daten und vor allem einen festen Platz innerhalb der internen Verlinkung.
Genau diese interne Struktur ist für Google wesentlich wichtiger, als es auf den ersten Blick erscheint. Google erklärt ausdrücklich, dass Suchmaschinen die Bedeutung einer Seite nicht allein aus der URL-Struktur ableiten. Wie eine Seite intern verlinkt ist, wie viele Klicks sie von wichtigen Einstiegsseiten entfernt liegt (Klicktiefe) und welche anderen Seiten auf sie verweisen, hilft Google dabei, ihre Rolle innerhalb der Website zu verstehen. Gerade für E-Commerce-Websites empfiehlt Google deshalb eine klare Verlinkung von Kategorien zu Unterkategorien und Produkten.
Eine URL wie /schuhe/nike/ ist also nicht deshalb wertvoll, weil sie gut aussieht. Sie wird wertvoll, weil ich sie als Teil meiner Informations- und Websitearchitektur behandle.
Und genau hier entsteht für mich die eigentlich interessantere SEO-Frage:
Ist „Nike“ in diesem Fall wirklich ein Filter oder eigentlich eine Kategorie?
Nicht jede Kombination verdient eine eigene Seite
Natürlich führt diese Überlegung nicht dazu, dass nun jeder Filterzustand zu einer Landingpage werden sollte.
„Nike Sneaker“ kann eine sinnvolle Suchintention sein. Vielleicht gilt das auch für „Nike Laufschuhe“.
Bei „Nike Sneaker rot Größe 44 unter 70 Euro sofort lieferbar“ sieht die Sache schon anders aus.
Diese Kombination kann für einen einzelnen Nutzer äußerst hilfreich sein. Sie muss deshalb aber noch lange keine dauerhafte Suchintention darstellen. Genau hier liegt die Grenze zwischen Informationsarchitektur und Benutzeroberfläche.
Eine kontrollierte Struktur könnte beispielsweise so aussehen:
/schuhe/
/schuhe/nike/
/sneaker/
/sneaker/nike/
Der Nutzer kann auf diesen Seiten anschließend weiter filtern:
/sneaker/nike/?groesse=44&farbe=rot
Die ersten URLs sind bewusste SEO‑Ziele. Die letzte URL beschreibt lediglich einen temporären Zustand der Produktauswahl. Diese Trennung ist entscheidend, denn sie verhindert, dass die SEO-Struktur einer Website automatisch mit jeder neuen Filteroption wächst.
Wenn ich zwanzig Marken, fünfzehn Größen, zehn Farben, fünf Preissegmente und vier Sortieroptionen miteinander kombinieren kann, entsteht bereits daraus theoretisch ein enormer URL‑Raum. In realen Shops kommen häufig noch Material, Geschlecht, Verfügbarkeit, Kollektion, Bewertung oder Lieferbedingungen hinzu.
Genau diese kombinatorische Explosion beschreibt Google als Kernproblem facettierter Navigation. Je mehr Kombinationen erzeugt werden können, desto größer wird der potenzielle Crawl-Raum.
Spätestens auf großen Websites wird daraus keine kosmetische URL-Frage mehr, sondern eine Frage des Crawl-Budgets.
Gute Crawl-Steuerung beginnt nicht in der robots.txt
Wenn Millionen von URLs technisch erzeugt werden können, reicht es nicht, nur darüber nachzudenken, welche davon im Index landen sollen.
Ich muss mich auch fragen, welche URLs Google überhaupt regelmäßig entdecken soll.
Ein besonders wichtiger Hebel liegt dabei in der internen Verlinkung.
Wenn jede denkbare Filterkombination über normale HTML-Links erreichbar ist, erzeugt die Website selbst ständig neue Crawl-Pfade. Aus Sicht von Google wirken diese URLs damit wie reguläre Bestandteile der Websitearchitektur.
Bei einer wichtigen Landingpage wie /sneaker/nike/ ist genau das erwünscht. Diese Seite sollte intern erreichbar und sinnvoll eingebunden sein.
Bei einer Kombination wie
?farbe=rot&groesse=44&sort=preis&lieferbar=sofort
stellt sich dagegen die Frage, ob diese URL dieselbe strukturelle Bedeutung überhaupt erhalten sollte.
Google empfiehlt allgemein, die Zahl alternativer URLs mit gleichen oder sehr ähnlichen Inhalten gering zu halten. Der Grund ist trivial, aber wichtig: Die Suchmaschine erkennt häufig erst nach dem Abruf, dass zwei URLs nahezu denselben Inhalt liefern. Jede zusätzliche unnötige URL erzeugt damit potenziell zusätzlichen Crawl-Aufwand.
Technische SEO beginnt deshalb nicht erst beim Schreiben einer robots.txt.
Sie beginnt bereits bei der Frage, welche Pfade und Zustände eine Website überhaupt erzeugt.
Canonical, noindex und robots.txt sind keine austauschbaren Werkzeuge
An diesem Punkt wird auch deutlich, warum es keine universelle Konfiguration für Facettensuchen gibt.
Ein Canonical kann sinnvoll sein, wenn mehrere URLs denselben oder sehr ähnlichen Inhalt darstellen und Signale auf eine bevorzugte Variante konsolidiert werden sollen.
Ein noindex kann sinnvoll sein, wenn eine Seite für Nutzer zugänglich und crawlbar bleiben soll, aber nicht in den Suchergebnissen erscheinen soll.
Eine gezielte Steuerung über die robots.txt kann wiederum sinnvoll werden, wenn ein Filtersystem einen großen Crawl-Raum erzeugt, dessen URLs für die organische Suche keinen eigenen Wert besitzen. Google empfiehlt bei problematischen dynamischen URLs und unnötigen Filtervarianten ausdrücklich, eine Blockierung des Crawlers in Betracht zu ziehen, wenn diese URLs nicht gecrawlt werden müssen. Auch dabei muss allerdings bedacht werden, welche Signale Google anschließend noch auslesen können soll.
Deshalb ist die Reihenfolge wichtig.
Wenn Google zunächst ein noindex verarbeiten soll, darf ich den Zugriff nicht vorher blockieren. Wenn ich Canonicals verwende, darf ich nicht davon ausgehen, dass damit gleichzeitig mein Crawl-Problem verschwindet. Und wenn ich Filterbereiche über die robots.txt sperre, sollte ich sicher sein, dass diese URLs tatsächlich keinen eigenständigen Suchwert besitzen.
Die wichtigere Frage lautet: Welche Seiten soll meine Website besitzen?
Je länger man sich mit der Facettensuche beschäftigt, desto weniger interessant wird für mich letztlich die Diskussion „Parameter oder Verzeichnis?“.
Natürlich spricht viel für verständliche, stabile URLs. Eine Adresse wie
/schuhe/nike/
ist für Menschen unmittelbar verständlicher als
/schuhe?brand=23.
Aber die eigentliche SEO-Entscheidung findet vorher statt.
Welche Seiten möchte ich überhaupt als eigenständige Ziele meiner Website behandeln?
Wenn „Nike Schuhe“ eine relevante Suchintention darstellt, kann daraus eine bewusst gepflegte Landingpage werden.
Wenn „Größe 44“ lediglich dazu dient, einem Nutzer die Produktauswahl zu erleichtern, muss daraus nicht automatisch eine SEO-Seite entstehen.
Und wenn eine URL ausschließlich deshalb existiert, weil ein Nutzer gerade fünf Filter gleichzeitig aktiviert hat, sollte ich sehr genau überlegen, warum eine Suchmaschine diese URL dauerhaft entdecken, crawlen und möglicherweise indexieren können sollte.
Für mich liegt genau hier der Unterschied zwischen einem Filtersystem und einer SEO-Informationsarchitektur.
Eine gute Facettensuche erlaubt dem Nutzer, sein Ergebnis möglichst flexibel einzuschränken. Eine gute SEO-Architektur entscheidet dagegen bewusst, welche dieser möglichen Zustände tatsächlich als eigenständige Seiten existieren sollen.
Und genau deshalb ist Facettensuche kein rein technisches Thema. Hier treffen Technische SEO, Keyword- und Intent-Analyse, Informationsarchitektur, interne Verlinkung und Crawl-Steuerung unmittelbar aufeinander.
Die entscheidende Frage lautet am Ende nicht nur, welches Canonical gesetzt werden muss oder welche Parameter Google crawlen darf.
Sie lautet: Welche URLs möchte ich Google überhaupt als Teil meiner Website anbieten – und welche muss Google gar nicht erst kennenlernen?
Weiterführende Quellen
Google Search Central: Facettensuche und Crawling
Google Search Central: URL-Strukturen für E-Commerce-Websites
Google Search Central: E-Commerce-Seitenstruktur und interne Verlinkung
Google Search Central: Canonicalization und kanonische URLs
Google Search Central: Indexierung mit noindex verhindern
Google Search Central: Crawl-Budget verwalten
