Warum Facetten einen URL-Raum erzeugen
Faceted Navigation erlaubt Nutzern, Bestände nach Attributen zu filtern. Technisch problematisch wird sie, wenn Filter und Reihenfolgen sehr viele crawlbare URL-Kombinationen erzeugen, ohne dass jede Kombination einen stabilen Search-Zweck besitzt.
Eine Facette kann für Nutzer wertvoll sein und trotzdem keine eigene Landingpage benötigen. Umgekehrt kann eine stabile Kombination einen klaren Suchintent und eigenständigen Bestand abbilden. Beides mit derselben pauschalen Regel zu behandeln, erzeugt entweder unnötige Crawl-Flächen oder verhindert sinnvolle Seiten.
Zuerst die URL-Klasse entscheiden
- Welchen stabilen Nutzer- und Search-Zweck erfüllt die Kombination?
- Ist der resultierende Bestand ausreichend und dauerhaft genug?
- Unterscheidet sich die Seite in Inhalt, Titel, interner Einbindung und Nutzen?
- Wer besitzt Zweck, Qualitätskriterien und Lifecycle?
- Wie wird die URL intern gefunden und später überwacht?
Diese Fragen stammen aus derselben Logik wie die URL Ownership & Indexation Policy. Eine technische Regel ohne diese Entscheidung kann nur Symptome verwalten.
Drei praktische Zustände
| Zustand | Rolle | Technische Konsequenz |
|---|---|---|
| Stabile Landingpage | eigenständiger, dauerhaft betriebener Search- und Nutzerzweck | crawlbar, indexierbar, selbstkonsistent, intern eingebunden und überwacht |
| Interaktionszustand | temporäre Filterung ohne eigenen Landingpage-Zweck | möglichst keinen unbegrenzten crawlbaren URL-Raum erzeugen |
| Ungeklärter Zustand | technisch vorhanden, Policy und Nutzen offen | nicht regulär indexierbar freigeben, bis Zweck und Regeln geklärt sind |
Crawl- und Indexierungssteuerung
Google empfiehlt, Facetten-URLs ohne Search-Bedarf am Crawling zu hindern. Das kann über passende robots.txt-Regeln oder eine Implementierung mit Fragmenten erfolgen. Canonicals und `nofollow` können Signale geben, gelten in Googles aktueller Dokumentation aber als weniger wirksam für eine langfristige Crawl-Begrenzung.
Wenn Facetten potenziell indexierbar sein sollen, brauchen URL-Parameter eine logische, konsistente Reihenfolge und stabile Kodierung. Leere Ergebnisse, Soft-404-Zustände, endlose Kombinationen und Session- oder Trackingparameter gehören nicht in denselben indexierbaren Raum.
`noindex` und robots.txt sind nicht austauschbar. Wird Crawling blockiert, kann ein Crawler ein auf der Seite gesetztes `noindex` nicht zuverlässig lesen. Ein Canonical auf die ungefilterte Kategorie ist zudem keine Aussage, dass jede gefilterte Seite inhaltlich ein Duplikat ist.
Ein Regelwerk statt einzelner Tags
Für jede Kombination von Filtertyp und Anzahl aktiver Filter braucht es einen Sollzustand. Dieser kann bereits in der Anwendung entscheiden, ob eine crawlbare URL entsteht, ob ein Link ein echtes `href` erhält und ob eine kuratierte Landingpage in Navigation oder Sitemap aufgenommen wird. Technische Directives bilden diese Entscheidung ab; sie ersetzen sie nicht.
| Frage | Beispielhafte Evidence | Verantwortungsraum |
|---|---|---|
| Soll die Kombination als Landingpage bestehen? | stabiler Nutzerzweck, unterscheidbarer Bestand, reale Suchfragen | URL-Class Owner mit SEO Governance |
| Wie wird sie erzeugt? | Routing, Parameterreihenfolge, erlaubte Kombinationen | Product und Technical Owner |
| Wie wird sie entdeckt? | Navigation, Kontextlinks, Sitemap | Product, Content und SEO |
| Wann endet sie? | leerer Bestand, Sortimentswechsel, fehlender Zweck | URL-Class Owner |
Ein Filter kann so weiterhin vollständig für Nutzer funktionieren, während nur ein kleiner, absichtlich betriebener Teil der Kombinationen Search-Landingpages bildet. Die konkrete Implementierung hängt von Plattform, Rendering und Produktanforderungen ab.
Interne Links und Sitemaps
Indexierbare Facetten brauchen normale crawlbare Links aus einer passenden Navigation oder einem Kontextmodul. Nicht indexierbare Zustände sollten nicht durch tausende Template-Links als wichtiger Bestand angeboten werden. Sitemaps enthalten die kuratierten Canonical-Landingpages, nicht jede erzeugbare Filterkombination.
Im Betrieb überwachen
- Anzahl und Wachstum bekannter Facetten-URLs nach Muster,
- Bot-Requests und Statuscodes pro Kombinationstyp,
- Indexierungs- und Canonical-Signale der freigegebenen Klassen,
- leere oder schwache Bestände,
- neue Parameter nach Releases,
- interne Links und Sitemap-Konsistenz.
Jede neue Filterfunktion ist eine mögliche Änderung des URL-Raums. Deshalb gehört sie in die risikobasierte Release Governance, wenn sie systemweit URLs erzeugt oder Indexierungslogik verändert.