> ## Documentation Index
> Fetch the complete documentation index at: https://www.octoparse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# XPath- und CSS-Selektoren

> CSS-Selektoren und XPath finden Seitenelemente, versagen aber unterschiedlich. Erfahren Sie, wann Sie welche robusten Selektoren einsetzen sollten.

Selektoren bilden die Grundlage jedes regelbasierten Web-Scrapers: Sie geben dem Tool genau vor, aus welchen Seitenelementen Daten extrahiert werden sollen. Ein gut geschriebener Selektor funktioniert auch nach kleineren Website-Aktualisierungen; ein anfälliger Selektor versagt, sobald ein Entwickler einen Klassennamen oder das Layout ändert. Robuste Selektoren schreiben zu können, gehört zu den praktischsten Fähigkeiten beim Web Scraping und lohnt sich selbst dann, wenn Sie ein visuelles Tool verwenden, das Selektoren generiert.

Es gibt zwei zentrale Selektorsprachen: **CSS-Selektoren** und **XPath**. Beide können [Elemente in einem HTML-Dokument finden](/docs/de/academy/anatomy-of-a-web-scraper), funktionieren jedoch unterschiedlich und besitzen jeweils eigene Stärken.

## CSS-Selektoren

CSS-Selektoren verwenden dieselbe Syntax, die Webentwickler in Stylesheets schreiben, und wirken daher bei Frontend-Erfahrung intuitiv. Sie wählen Elemente anhand von Tag-Namen, Klassen, IDs, Attributen und Beziehungen zu anderen Elementen aus. `div.product-card h2` wählt beispielsweise alle `h2`-Elemente innerhalb von div-Elementen mit der Klasse `product-card` aus. CSS-Selektoren sind im Allgemeinen kürzer, leichter lesbar und für Browser schneller auszuwerten. Für die meisten einfachen Extraktionsaufgaben sind sie die bessere Standardwahl.

## XPath

XPath ist leistungsfähiger, aber ausführlicher. Es behandelt das HTML-Dokument als Baum und ermöglicht die Navigation in jede Richtung: abwärts zu Kindelementen, aufwärts zu Elternelementen, seitwärts zu Geschwisterelementen und durch das gesamte Dokument. Entscheidend ist, dass XPath Elemente anhand ihres Textinhalts auswählen kann – `//a[contains(text(), "Next Page")]` –, was mit CSS-Selektoren nicht möglich ist. Daher ist XPath unverzichtbar, um etwa eine Schaltfläche anhand ihrer Beschriftung oder eine Tabellenzelle anhand ihres Inhalts zu finden. Bedingungen, Funktionen und komplexe Prädikate verleihen XPath zudem mehr Ausdruckskraft für ungewöhnliche Seitenstrukturen.

## Wann eignet sich welche Sprache?

Der Kompromiss liegt zwischen Einfachheit und Flexibilität. CSS bildet die meisten gängigen Fälle übersichtlicher ab. XPath eignet sich bei einer unhandlichen HTML-Struktur, für textbasierten Abgleich oder wenn ein Element nur über seine Beziehung zu einem Geschwister- oder Vorfahrenelement statt zu einem direkten Elternelement identifiziert werden kann.

## Robuste Selektoren schreiben

Unabhängig von der Sprache beruht Robustheit auf einigen Grundsätzen:

* **Automatisch generierte Klassennamen vermeiden.** Frameworks wie [React, Vue und Angular](/docs/de/academy/scrape-javascript-pages) erzeugen oft Klassennamen, die sich bei jedem Build ändern. `.css-1a2b3c` und ähnliche Namen sind daher riskant.
* **Semantische Attribute bevorzugen.** `id`, `data-*`, `role` und `aria-label` ändern sich seltener, da sie über die Darstellung hinaus Bedeutung besitzen. Ein auf `[data-product-id]` beruhender Selektor übersteht eine Stylesheet-Überarbeitung, einer mit `.flex-row__inner--lg` nicht.
* **Selektoren kurz halten.** Je länger die Kette von Eltern-Kind-Beziehungen, desto wahrscheinlicher unterbricht eine Änderung des Zwischenlayouts die gesamte Kette.
* **Positionsselektoren vermeiden.** `nth-child` und absolute XPath-Pfade wie `/html/body/div[3]/div[2]/ul/li[1]` setzen voraus, dass ein Element genau an derselben Stelle im DOM bleibt, was fast nie dauerhaft zutrifft.
* **Am nächstgelegenen stabilen Bezugspunkt verankern.** Suchen Sie statt einer Navigation von der Dokumentwurzel aus das nächstgelegene Element mit einer aussagekräftigen, stabilen Kennung und wählen Sie relativ dazu aus.

## Die Herausforderung Shadow DOM

Ein zunehmendes Hindernis ist **Shadow DOM**, eine Web-Component-Funktion, die einen DOM-Abschnitt innerhalb einer geschlossenen Grenze kapselt. Standardmäßige XPath- und CSS-Selektoren können nicht in eine Shadow Root hineinreichen. Elemente in Web Components bleiben traditionellen Scraping-Ansätzen dadurch verborgen. Da mehr Websites Web Components für modulare Benutzeroberflächen einsetzen, wird dies zu einem praktischen Problem: Ein Web-Scraper sieht möglicherweise die äußere Hülle einer Komponente, nicht aber deren gerenderten Inhalt. Abhilfe schafft ein Tool, das Shadow Roots durchdringen kann. Playwright erweitert Standardselektoren dafür um die Syntax `>>`; Octoparse erweitert XPath mit einer eigenen Syntax für denselben Zweck. Ein generierter Selektor kann damit eine Shadow Root wie einen gewöhnlichen DOM-Unterbaum erreichen.

## Der Selektoransatz von Octoparse

Octoparse verwendet zur Elementauswahl hauptsächlich **XPath**. Das Baumnavigationsmodell von XPath entspricht der Denkweise nicht technischer Benutzer über Seitenstrukturen: „der Preis in dieser Produktkarte“ lässt sich direkter in einen XPath-Ausdruck als in eine CSS-Selektorkette übertragen. Benutzer ohne Entwicklungserfahrung können einen Selektor dadurch leichter prüfen oder anpassen.

Beim Anklicken eines Elements erzeugt Octoparse nicht einfach irgendeinen funktionierenden XPath, sondern nutzt einen **intelligenten Algorithmus zur Attributpriorisierung**. Das System bewertet verfügbare Attribute nach ihrer semantischen Stabilität: Aussagekräftige Kennungen wie `id`, `data-*` und `role` werden veränderlichen Klassennamen oder anfälligen Positionsindizes vorgezogen. Der automatisch erzeugte XPath soll kleinere Website-Änderungen überstehen. Ein verändertes Layout oder Stylesheet beeinträchtigt einen auf dem stabilen Attribut `data-product-id` beruhenden Selektor nicht so leicht wie einen Pfad zum „dritten div im zweiten Abschnitt“.

Dieser Algorithmus wurde in **Octoparse 10.1.0** vollständig neu entwickelt und zählt bei der Genauigkeit automatisch generierter Selektoren zur Spitzengruppe. Bei den meisten Seiten erzeugt er mit dem ersten Klick einen korrekten, robusten XPath, sodass Benutzer weniger Selektoren manuell korrigieren müssen.

Für Seiten mit Web Components erzeugt derselbe Generator Selektoren mit der **benutzerdefinierten XPath-Erweiterung von Octoparse für Shadow DOM**. Ein Element in einer Shadow Root kann damit wie ein Element im normalen DOM angesprochen werden, ohne zu einer anderen Selektorsprache zu wechseln.

Zusätzlich zum neuen Generator bietet Octoparse zwei KI-Funktionen:

* **KI-gestützte XPath-Erstellung**, die einen umfassenderen Seitenkontext auswertet, um robustere Selektoren zu erzeugen
* **KI-gestützte Selbstreparatur** (demnächst verfügbar), die defekte Selektoren erkennt und aus der geänderten Seitenstruktur neu erstellt. Dies umfasst sowohl die **Paginierung** (eine verschobene oder umbenannte „Weiter“-Steuerung) als auch **Feldselektoren** (ein im Layout verschobener Wert), sodass eine andernfalls angehaltene Aufgabe weiterläuft

Diese Ergänzungen tragen der Entwicklung des modernen Webs Rechnung: Seiten werden dynamischer, komponentenbasierter und stärker gekapselt. Scraping-Tools müssen damit Schritt halten.

## Fazit

Investieren Sie auch bei einem visuellen Tool Zeit in die Grundlagen von Selektoren. Wenn Sie verstehen, was Selektoren anfällig oder robust macht, können Sie automatisch generierte Ausgaben beurteilen, Fehler in Aufgaben beheben und Web-Scraper erstellen, die Wochen und Monate statt nur beim ersten Lauf funktionieren. Sobald Ihre Selektoren die Rohwerte liefern, besteht der nächste Schritt darin, [den Text zu bereinigen und in die tatsächlich benötigten Daten umzuformen](/docs/de/academy/refining-data-with-regex).