← Zurück zum Blog

LLM oder CSS-Selektoren zum Parsen: Preis- und Zuverlässigkeitsvergleich 2026

Wir vergleichen drei Methoden zur Datenauswertung beim Parsen: CSS/XPath-Selektoren, LLM-Extraktion und hybrid, wo das Modell Selektoren schreibt. Wir berechnen die Kosten für 1.000 Seiten zu den Preisen von Gemini und Claude im Oktober 2026, analysieren das Risiko erfundener Daten und erklären, warum das Modell den Proxy-Traffic nicht spart.

📅1. Oktober 2026
LLM oder CSS-Selektoren zum Parsen: Preis- und Zuverlässigkeitsvergleich 2026

Der Parser auf CSS-Selektoren bricht zusammen, wenn die Website das Layout ändert. Der Parser auf LLM bricht nicht zusammen, stellt jedoch für jede Seite eine Rechnung aus. Im Jahr 2026 hörte die Wahl zwischen ihnen auf, eine Frage des Geschmacks zu sein: Die Preise der Modelle klafften um ein Vielfaches auseinander, und dieselbe Seite kann je nach dem, was Sie an das Modell gesendet haben, 3.000 oder 20.000 Tokens kosten. Im Folgenden finden Sie einen Vergleich der drei Ansätze hinsichtlich Kosten, Zuverlässigkeit und Proxy-Traffic, berechnet für 1.000 und eine Million Seiten.

Kurz gesagt: Was wählen

  • Selektoren (CSS/XPath) — ein Seitenlayout, große Volumina, stabiles Layout. Die Kosten für das Extrahieren sind nahezu null, aber die Unterstützung liegt beim Entwickler.
  • LLM-Extraktion — viele verschiedene Websites, instabiles Layout, einmalige Aufgaben. Sie zahlen für Tokens auf jeder Seite und müssen die Antwort validieren.
  • Hybrid — LLM schreibt einmal Selektoren, danach arbeiten die Selektoren, und das Modell wird nur aufgerufen, wenn die Datenvalidierung fehlschlägt. Für die meisten dauerhaften Parser ist dies die optimale Lösung.

Vergleichskriterien

Wir vergleichen anhand von fünf Punkten, die sich tatsächlich auf die Endabrechnung und die Datenqualität auswirken:

  1. Kosten der Extraktion für 1.000 Seiten;
  2. Verhalten bei Layoutänderungen;
  3. Genauigkeit und Risiko erfundener Werte;
  4. Geschwindigkeit und Verzögerung;
  5. Trafficverbrauch des Proxys — wie Sie sehen werden, hängt er fast nicht von der Wahl der Methode ab.

Was kostet LLM-Extraktion: Berechnung nach Preisen im Oktober 2026

Offizielle Preise für eine Million Tokens (Eingang / Ausgang) im Standardtarif:

  • Gemini 2.5 Flash-Lite — $0,10 / $0,40;
  • Gemini 3.1 Flash-Lite — $0,25 / $1,50;
  • Claude Haiku 4.5 — $1 / $5;
  • Gemini 3.5 Flash — $1,50 / $9.

Google und Anthropic bieten eine Batch-API mit 50% Rabatt auf Eingang und Ausgang — für das Parsen, bei dem die Antwort nicht sofort benötigt wird, ist dies der erste Hebel zur Kostensenkung.

Die Hauptvariable ist nicht das Modell, sondern das, was Sie ihm senden

Eine rohe HTML-Seite benötigt normalerweise 10–40 Tausend Tokens, wenn sie an das Modell übergeben wird. Cloudflare, das die Funktion Markdown for Agents einführte, gab ein Beispiel: derselbe Blogbeitrag wiegt 16.180 Tokens in HTML und 3.150 Tokens in Markdown — minus 80%. Andere Messungen zu Nachrichten, Dokumentationen und Produktkarten zeigen eine Reduzierung von 67 bis 94%.

Für die Berechnung nehmen wir Annahmen: rohe Seite — 20.000 Tokens, gereinigt auf Markdown — 3.000, plus 500 Tokens für Anweisungen und Schema, am Ausgang 300 Tokens JSON. Für 1.000 Seiten erhalten wir:

ModellRohe HTML (20,5 Mio Eingang)Markdown (3,5 Mio Eingang)
Gemini 2.5 Flash-Lite≈ $2,17≈ $0,47
Gemini 3.1 Flash-Lite≈ $5,58≈ $1,33
Claude Haiku 4.5≈ $22,00≈ $5,00
Gemini 3.5 Flash≈ $33,45≈ $7,95

Die Spanne beträgt das 70-fache zwischen der schlechtesten und der besten Option bei gleichem Ergebnis. Zwei Drittel dieser Differenz ergeben sich aus der Bereinigung des Eingangs und nicht aus der Wahl des Modells. Bei einer Million Seiten pro Monat sind das entweder etwa $470 oder mehr als $33.000.

Ein weiterer Punkt: Die Modelle von Claude ab Version 4.7 verwenden einen neuen Tokenizer, der laut Anthropic etwa 30% mehr Tokens für denselben Text liefert. Wenn Sie die Rechnungen verschiedener Modellgenerationen vergleichen, berücksichtigen Sie dies — Haiku 4.5 arbeitet mit dem alten Tokenizer.

Selektoren: fast kostenlos, solange die Website nicht geändert wird

Die Ausführung eines CSS- oder XPath-Selectors auf einer bereits heruntergeladenen Seite kostet einen Bruchteil einer Millisekunde CPU-Zeit. Im Leitfaden von ScrapingBee wird geschätzt: Bei stabilem Layout ist ein gewöhnlicher Selector etwa 10 Mal günstiger und schneller als die LLM-Extraktion. In der Praxis ist der Unterschied noch größer, da der Selector keine Netzwerkabfrage an die API des Modells hat.

Die Kosten der Selektoren liegen in der Unterstützung:

  • Die Website hat eine Klasse umbenannt oder einen Block in ein neues div gewickelt — der Parser gibt stillschweigend leere Felder zurück;
  • A/B-Tests zeigen verschiedenen Besuchern unterschiedliche Vorlagen, und einige Seiten werden nicht geparst;
  • Auf 50 verschiedenen Websites unterstützen Sie 50 Sets von Selektoren.

Das gefährlichste Szenario ist nicht der Ausfall, sondern die stille Datenverfälschung: Der Selector greift auf ein benachbartes Element zu, und in die Datenbank wird wochenlang der alte Preis anstelle des aktuellen geschrieben.

LLM: widerstandsfähig gegenüber Layoutänderungen, kann aber erfinden

Modelle benötigen keinen genauen Pfad zum Element — sie suchen den „Preis“ nach Bedeutung. Dies löst das Problem umbenannter Klassen und unterschiedlicher Vorlagen. Aber es treten drei typische Fehler auf, die alle beschreiben, die solche Parser in der Produktion eingesetzt haben:

  • erfundene Werte — das Modell „errät“ einen Preis oder Artikel, die auf der Seite nicht vorhanden sind;
  • fehlende Felder — ein Teil der Daten wurde nicht extrahiert;
  • Drift der Struktur — eine Zeichenfolge anstelle einer Zahl, ein anderer Schlüsselname.

Schutz ist unerlässlich: strenges Antwortschema, Validierung (z.B. Pydantic), Temperatur = 0 und Wiederholung bei Fehlern. Eine Temperatur von null reduziert die Streuung, beseitigt jedoch nicht vollständig die Halluzinationen. Für Preise und Bestände ist es sinnvoll, eine Überprüfung hinzuzufügen: „Der Wert kommt tatsächlich im Text der Seite vor“.

Die Verzögerung ist ebenfalls höher: Zur Ladezeit der Seite über den Proxy kommt die Antwort des Modells — von Bruchteilen einer Sekunde bis zu mehreren Sekunden. Für die Überwachung einmal täglich ist das unwichtig, für das Verfolgen von Drops ist es kritisch.

Hybrid: LLM schreibt Selektoren, extrahiert aber keine Daten

Der dritte Weg wird direkt von beliebten Bibliotheken unterstützt. In Crawl4AI gibt es eine Funktion zur Generierung von Schemas: Das Modell sieht sich einmal Muster von HTML an und gibt ein Set von CSS/XPath-Selektoren zurück, danach erfolgt die Extraktion ohne Aufrufe an LLM. In der Dokumentation wird betont, dass dies eine einmalige Kosten ist und das Schema ohne Einschränkungen wiederverwendet werden kann; bei mehreren Mustern wählt das Modell oft stabilere Selektoren basierend auf Attributen anstelle von fragilen positionellen wie nth-child.

Das Arbeitschema des Hybriden:

  1. LLM generiert Selektoren anhand von 3–5 Mustern von Seiten eines Layouts.
  2. Der Parser arbeitet mit Selektoren, jede Aufzeichnung wird vom Validator überprüft: Felder sind vorhanden, Typen sind korrekt, Preis liegt im vernünftigen Bereich.
  3. Wenn der Anteil ungültiger Aufzeichnungen den Schwellenwert überschreitet (sagen wir, 2–5%), wird die Seite zur LLM-Extraktion geschickt, und das Schema wird zur Regenerierung geschickt.
  4. Das neue Schema wird an einer Kontrollstichprobe getestet und ersetzt erst dann das alte.

So zahlen Sie für das Modell nur in den Momenten, in denen Layoutänderungen auftreten, und nicht für jede der Millionen Seiten.

Zusammenfassungstabelle

KriteriumSelektorenLLM-ExtraktionHybrid
Kosten der Extraktionnahezu null$0,5–33 für 1.000 Seitennahezu null + einmalige Aufrufe
Layoutänderungenbricht zusammen, oft stillschweigendübersteht normalerweisewird automatisch repariert
Risiko erfundener Datennicht vorhanden (aber es gibt „nicht das Element“)vorhanden, Validierung erforderlichminimal
Geschwindigkeitmaximal+ Antwort des Modells auf jeder Seitewie bei Selektoren
Viele verschiedene Websitesteuer in der Unterstützungstarke Seitegut, Schema für jedes Layout
Proxy-Trafficgleich — das Modell reduziert nicht die heruntergeladenen Bytes

Über Proxys: LLM spart keinen Traffic

Ein häufiger Fehler in Berechnungen ist die Annahme, dass ein „intelligenter“ Parser im Netzwerk günstiger ist. Nein: Die Umwandlung von HTML in Markdown erfolgt nach dem Herunterladen, sodass bei jeder Methode der Extraktion die gesamte Seite über den Proxy läuft. Eine Ausnahme sind Websites, bei denen der Eigentümer selbst die Ausgabe von Markdown über den Accept-Header: text/markdown aktiviert hat (wie in der Funktion von Cloudflare), aber das ist die Entscheidung der Website, nicht Ihre.

Zur Größenordnung: Bei einem HTML-Gewicht von 200 KB ohne Bilder sind 1.000 Seiten etwa 0,2 GB oder ungefähr $0,54 für residential Proxys zu $2,70 pro GB. Vergleichen Sie dies mit der obigen Tabelle: Wenn Sie rohe HTML an Claude Haiku 4.5 senden, wird die Rechnung für das Modell 40 Mal höher sein als die Rechnung für den Proxy, während sie bei Markdown und Flash-Lite vergleichbar sind. Wenn Sie Seiten mit einem Headless-Browser rendern, wird der Traffic um ein Vielfaches steigen — Messungen finden Sie in unserem Vergleich zum Trafficverbrauch von Playwright, Puppeteer und requests auf 1.000 Seiten.

Was den Traffic bei jeder Methode wirklich beeinflusst:

  • keine Bilder, Schriftarten und Analytik herunterladen, wenn sie nicht benötigt werden;
  • internes JSON-API anstelle von HTML suchen;
  • keine unnötigen Wiederholungen: jeder Bann und Retry — das sind bezahlte Bytes. Mehr dazu, warum der Preis pro GB irreführend ist, finden Sie in der Analyse der realen Kosten einer erfolgreichen Aufzeichnung.

Für einfache Kataloge ohne strenge Anti-Bot-Schutzmaßnahmen genügen Datacenter-Proxys zu $1,50 pro GB; residential Proxys sind dort erforderlich, wo die IP des Hostings am Eingang geschnitten wird.

Empfehlungen für Szenarien

  • Überwachung der Preise von ein bis drei Marktplätzen, Hunderttausende von Karten. Hybrid oder reine Selektoren mit Validator. LLM nur für die Regenerierung des Schemas einbinden.
  • Daten sammeln von Hunderten heterogener Websites (Leads, Stellenangebote, Kontakte). LLM-Extraktion auf Markdown über ein günstiges Modell im Batch-Modus. Ohne strenges Schema und Validierung nicht starten.
  • Einmalige Untersuchung von mehreren Tausend Seiten. LLM: für ein paar Dollar sparen Sie Tage beim Schreiben von Selektoren.
  • Daten, bei denen ein Fehler Geld kostet (Preise für Repricing, Bestände). Selektoren oder Hybrid plus Überprüfung des Wertes mit dem ursprünglichen Text der Seite.
  • RAG und Wissensdatenbanken. Hier ist keine Struktur erforderlich, sondern reiner Text: Umwandlung in Markdown ohne Extraktion von Feldern, Modell nur in der Antwortphase.

Fazit

Die LLM-Extraktion hat die Selektoren nicht ersetzt, sondern den Entscheidungspunkt verschoben. Am günstigsten ist der Hybrid: Das Modell schreibt und repariert Selektoren, anstatt jede Seite zu lesen. Wenn Sie nicht umhin kommen, das Modell auf jeder Seite zu verwenden, reinigen Sie zuerst den Eingang auf Markdown und verwenden Sie Batch: Diese beiden Schritte reduzieren die Rechnung um das 5–10-fache, bevor Sie mit der Auswahl des Modells beginnen. Und denken Sie daran, dass der Proxy-Traffic von der Extraktionsmethode unabhängig ist: Sie sollten ihn bei dem sparen, was Sie herunterladen, und nicht bei dem, wie Sie es analysieren.