Ich habe einen Benchmark zur Extraktion von Webinhalten mit 2.000 Seiten erstellt. Hier sind meine Ergebnisse.

Nach den Google-API-Leaks im Jahr 2024 begann ich, Ranking-Signale anders zu betrachten. Nicht die üblichen Titel-Tags und Backlinks – die tieferen Signale. Dinge wie contentEffort, Originality, TopicalCoherence. Die Art von Signalen, die Google verwendet, um herauszufinden, ob eine Seite echte Substanz hat oder nur gut formatiertes Rauschen ist.

Ich untersuchte eine Website und bemerkte etwas Interessantes: Ihre Seiten schnitten bei fast jeder Qualitätsachse, die mir einfiel, gut ab. Gute Überschriftenstruktur. Originäre Datenpunkte durchgehend. Inhalte, die aufeinander aufbauten, anstatt dieselben Keywords zu wiederholen. Starke thematische Kohärenz über die gesamte Seite hinweg. Es war nicht nur gut geschrieben – es war auf HTML-Ebene gut strukturiert.

Das brachte mich zum Nachdenken. In einer Welt, in der LLMs in Sekunden kompetente Texte zu jedem Thema produzieren können, was unterscheidet Webseiten tatsächlich voneinander? Schreibfähigkeit nähert sich den Nullkosten. Expertenwissen wird zur Massenware. Worauf kann Google also noch ranken?

Meine Antwort: Grundlegend wird sich nicht viel ändern. Es werden immer noch Links sein, die thematische Autorität einer Seite, und danach – originale Daten, persönliche Expertise und strukturelle Qualitätssignale, die in großem Maßstab schwer zu fälschen sind. Die Seiten, die gewinnen, werden diejenigen mit echten First-Party-Daten, echter Erfahrung und Inhaltsstrukturen sein, die tatsächliche Tiefe widerspiegeln und nicht template-getriebenes Füllmaterial.

Ich wollte das messen. In großem Maßstab. Über die SERPs hinweg.

Das Extraktionsproblem

Saubere Inhalte von einer einzelnen Seite zu extrahieren ist einfach mit Jaccard-Ähnlichkeit und Templates, aber das Web ist ein unordentlicher Ort, und der Versuch, es von 10 verschiedenen Seiten auf Seite 1 der SERPs zu tun, ist ein ganz anderes Problem. Um Inhaltsqualitätssignale über Tausende von Konkurrenzseiten hinweg zu analysieren, muss man zuerst den eigentlichen Inhalt von jeder Seite extrahieren. Klingt einfach – einfach den Artikeltext holen, oder?

Es ist einfach, wenn jede Seite ein Blogbeitrag ist. Trafilatura, Readability, Newspaper – alle leisten gute Arbeit bei standardmäßigen Artikel-Seiten. Gib ihnen einen WordPress-Post oder einen Nachrichtenartikel und sie liefern 90 % der Zeit sauberen Text zurück.

Aber das Web besteht nicht nur aus Artikeln. Vermischt man informative Inhalte mit einem Landing-Page-Design – eine SaaS-Features-Seite, eine Produktbeschreibungsseite, eine Dokumentations-Website – und diese Tools beginnen zu versagen. Sie wurden für Artikel gebaut und wenden Artikel-Extraktions-Heuristiken auf alles an.

Ich musste Inhalte extrahieren von:

• Produktseiten, wo die Beschreibung in einem JSON-LD-Blob steckt, nicht im sichtbaren DOM
• Service-/Landing-Pages, wo Inhalte über 10 verschiedene <section>-Elemente verteilt sind
• Hero, Features, Testimonials, Preise, FAQ
• Forum-Threads, wo die Benutzerbeiträge DER Inhalt sind, Extraktoren sie aber herausfiltern, weil sie class="comment"-Boilerplate-Mustern entsprechen
• Dokumentationsseiten, wo ich die eigentliche Dokumentation brauchte, nicht die Sidebar-Navigation
• Kollektions-/Kategorieseiten, wo der einzige sinnvolle Text ein Absatz über einem Produkt-Raster ist

Und ich brauchte es in Markdown – mit Überschriften, Links, Tabellen, fettem Text erhalten – weil ich das für SEO-Signale analysiere. Ein flacher Textdump verliert die strukturellen Informationen, die am wichtigsten sind.

Was als Port begann, wurde zu etwas Größerem

Es begann als schneller Rust-Port von Trafilatura, Adrien Barbaresis exzellenter Python-Extraktionsbibliothek. Ich brauchte Geschwindigkeit – die Verarbeitung Tausender Seiten durch eine Python-Pipeline war ein Engpass – und Rust erfüllte diesen Zweck.

Aber als ich begann, verschiedene Seitentypen zu testen, stieß ich immer wieder auf dasselbe Problem: Einheitsgrößen-Extraktion funktioniert im modernen Web nicht. Eine Produktseite benötigt eine andere Handhabung als ein Forum-Thread. Eine SaaS-Landing-Page benötigt eine andere Handhabung als API-Dokumentation.

Also fügte ich eine Seitentyp-Klassifizierung hinzu. Dann typenspezifische Extraktionsprofile. Dann einen Konfidenz-Score, damit ich wusste, wann die Extraktion wahrscheinlich Müll war und einen zweiten Durchlauf brauchte. Dann einen Markdown-Ausgabemodus. Dann einen ML-Klassifikator, als die regelbasierten Heuristiken an ihre Grenzen stießen.

Das Ergebnis ist rs-trafilatura – eine Rust-Webinhalts-Extraktionsbibliothek, die Seiten in 7 Typen klassifiziert und typenspezifische Extraktionsstrategien anwendet. Sie verarbeitet Seiten durchschnittlich in 44ms. Sie gibt Markdown mit erhaltenen Überschriften, Links, Tabellen und Formatierungen aus.

Aber um zu wissen, ob irgendetwas davon tatsächlich funktionierte, brauchte ich einen Benchmark. Und da begann der eigentliche Kaninchenbau.

Warum existierende Benchmarks nicht ausreichen

Als ich nach einem Benchmark suchte, um meinen Extraktor zu evaluieren, fand ich:

• ScrapingHub (2019): 181 Seiten. Alles Artikel.
• CleanEval (2007): 797 Seiten. Aus der Ära vor HTML5.
• Google-Trends (2017): 180 Seiten.
• L3S-GN1 (2010): 621 Nachrichtenartikel.

Jeder Benchmark war entweder winzig, alt oder nur auf Artikel beschränkt. Bei Artikeln sieht jeder Extraktor großartig aus – alle erreichen F1 > 0,90. Es ist, als würde man die Leistung eines Autos auf einer geraden Straße bewerten und schlussfolgern, dass alle gleich gut sind.

Die interessante Frage ist nicht „Kannst du einen Blogbeitrag extrahieren?“ – sondern „Kannst du die 40-50 % des Webs handhaben, die kein Blogbeitrag sind?“

Niemand hat das gemessen.

Den Benchmark aufbauen

Also habe ich den Web Content Extraction Benchmark (WCXB) aufgebaut. Es dauerte erheblich länger als erwartet.

2.008 Seiten von 1.613 Domains über 7 Seitentypen hinweg:

Seitentyp	Anzahl	Was er testet
Artikel	1.050	Die Baseline

• Blogs, News, Editorials | | Service | 224 | Landing Pages, SaaS-Features-Seiten, Marketing | | Forum | 164 | Diskussions-Threads, Q&A, Community-Beiträge | | Produkt | 147 | Produktbeschreibungen, Spezifikationen, Preise | | Kollektion | 151 | Kategorieseiten, Produkt-Raster | | Listing | 139 | Inhaltsverzeichnisse, Kurskataloge | | Dokumentation | 133 | API-Dokumentation, Tutorials, technische Referenzen |

Jede Seite hat eine vollständige Ground-Truth-Annotation

• Titel, Autor, Datum, vollständiger Hauptinhalt als Klartext, plus „muss enthalten“- und „darf nicht enthalten“-Snippet-Arrays, die Inhaltsgrenzen testen. Der Evaluierungsansatz wurde stark beeinflusst von Bevendorff et al.s vergleichender Studie auf der SIGIR 2023 – ihre Erkenntnis, dass „die Leistung sehr genreabhängig ist“, war eine direkte Motivation für diesen Benchmark. Ich habe versucht, ihren Standard der Strenge zu erreichen und gleichzeitig den Umfang auf Seitentypen auszuweiten, die ihr kombinierter Datensatz nicht abdeckte.

Der Annotationsprozess war... aufwändig. LLM-unterstütztes Erstellen, dann vier Überprüfungsdurchläufe mit Claude-Opus-Agenten zur Verifizierung und Behebung von Qualitätsproblemen, gefolgt von meiner eigenen manuellen Überprüfung. Automatisierte Qualitätsscans. Adversarische Überprüfung, bei der ich jede Datei untersuchte, bei der mein Extraktor von der Ground Truth abwich.

Ich teilte den Datensatz in einen 1.497-seitigen Entwicklungsdatensatz und einen 511-seitigen zurückgehaltenen Testdatensatz mit angeglichenen Seitentyp-Verteilungen auf. Der Testdatensatz wurde während der Entwicklung nie angefasst – wenn ich also darauf evaluiere, sind die Ergebnisse echt.

Das Ganze ist unter CC-BY-4.0 veröffentlicht: GitHub | Zenodo (DOI: 10.5281/zenodo.19316874) | HuggingFace. Und ich hoffe, mein kleiner Beitrag hilft jemandem.

Was die Ergebnisse zeigen

Ich habe 12 Extraktionssysteme auf dem WCXB laufen lassen – 10 heuristische und 2 neuronale (LLM-basierte). Hier ist das Gesamtbild:

System	F1	Typ	Geschwindigkeit
rs-trafilatura	0,859	Heuristisch + ML	44ms/Seite
MinerU-HTML (0,6B)	0,827	Neural (A100)	1.570ms/Seite
Trafilatura	0,791	Heuristisch	94ms/Seite
dom-smoothie	0,762	Heuristisch	27ms/Seite
ReaderLM-v2 (1,5B)	0,741	Neural (A100)	10.410ms/Seite

Aber die Gesamtzahlen verbergen die wahre Geschichte. Hier ist, was passiert, wenn man es nach Seitentyp aufschlüsselt:

Seitentyp	rs-trafilatura	MinerU-HTML	Trafilatura	Readability
Artikel	0,932	0,928	0,926	0,825
Dokumentation	0,931	0,838	0,888	0,736
Service	0,843	0,824	0,763	0,604
Forum	0,792	0,794	0,585	0,466
Kollektion	0,713	0,506	0,553	0,445
Listing	0,704	0,710	0,589	0,496
Produkt	0,670	0,619	0,567	0,407

Bei Artikeln liegen alle innerhalb von 1-3 Punkten voneinander. Bei Foren? Eine 33-Punkte-Spanne. Bei Kollektionen? 27 Punkte. Bei Produkten? 26 Punkte.

Das ist, was nur auf Artikel ausgelegte Benchmarks verbergen. Testet man auf Nachrichtenartikeln, sieht alles gut aus. Testet man auf der tatsächlichen Vielfalt des Webs, zeigen sich die Risse.

Die überraschende Erkenntnis über LLMs

Ich erwartete, dass die neuronalen/LLM-basierten Extraktoren

• MinerU-HTML und ReaderLM-v2 – die Vielfalt der Seitentypen besser handhaben würden als heuristische Systeme. Sie sind auf vielfältige Daten trainiert, sie verstehen Kontext, sie sollten generalisieren.

Tun sie nicht.

MinerU-HTML (ein feinabgestimmtes 0,6B-Modell, das auf einer A100 GPU läuft) erreicht 0,928 bei Artikeln – fast gleichauf mit heuristischen Systemen. Aber bei Kollektionen fällt es auf 0,506. Bei Produkten auf 0,619. Bei Foren auf 0,794.

ReaderLM-v2 (1,5 Milliarden Parameter – ein größeres Modell) schneidet noch schlechter ab: 0,417 bei Kollektionen, 0,463 bei Produkten. Und bei Listings übertrifft MinerU-HTML tatsächlich rs-trafilatura (0,710 vs. 0,704) – es ist der einzige Seitentyp, bei dem der neuronale Ansatz gewinnt.

Diese neuronalen Systeme wurden überwiegend auf artikelähnliche Inhalte trainiert. Sie haben gelernt, Artikel wirklich gut zu extrahieren. Sie haben nicht gelernt, mit Produktseiten umzugehen, wo Inhalte in JSON-LD leben, oder mit Service-Seiten, wo Inhalte über ein Dutzend DOM-Sektionen verteilt sind, oder mit Foren, wo class="comment"-Elemente DER Inhalt SIND. Es ist erwähnenswert, dass MinerU-HTMLs Team einen größeren internen Benchmark (WebMainBench, 7.809 Seiten) aufgebaut hat, aber meines Wissens wurde der vollständige Datensatz nicht öffentlich freigegeben – nur eine 100-seitige Evaluierungs-Teilmenge ist verfügbar. Ohne Zugang zur Verteilung ihrer Trainingsdaten ist schwer zu sagen, ob diese Artikel-Voreingenommenheit im Trainingsset oder in der Architektur verankert ist.

Ein größeres Modell hilft auch nicht. ReaderLM-v2 mit 1,5B schneidet bei jedem einzelnen Seitentyp schlechter ab als MinerU-HTML mit 0,6B.

Die Lektion: Der „Wirf ein LLM darauf“-Ansatz funktioniert für Artikel, löst aber nicht das Vielfaltsproblem. Dafür braucht man typbewusste Extraktion – zu wissen, welche Art von Seite man vor sich hat und die Strategie entsprechend anzupassen.

Was das für die SEO-Analyse bedeutet

Zurück zum Ausgangspunkt – der Analyse von Inhaltsqualitätssignalen über die SERPs hinweg – gab mir diese Arbeit drei Dinge:

1. Zuverlässige Extraktion über Seitentypen hinweg. Ich kann jetzt saubere, strukturierte Inhalte von Produktseiten, Service-Seiten, Dokumentation, Foren extrahieren – nicht nur von Artikeln. Das ist wichtig, weil die SERPs für kommerzielle Anfragen voll von Nicht-Artikel-Seiten sind.

2. Markdown-Ausgabe mit erhaltener Struktur. Überschriften, Links, Tabellen, fetter Text – all die strukturellen Signale, die für die SEO-Analyse wichtig sind. Ich kann die Überschriftenhierarchie-Tiefe, interne Linkmuster, Inhalts-zu-Boilerplate-Verhältnisse und strukturelle Kohärenz im großen Maßstab messen.

3. Ein Konfidenz-Score für die Extraktionsqualität. Wenn der Extraktor nicht sicher ist, ob er guten Inhalt erhalten hat (SPAs, ungewöhnliche Layouts, schweres JavaScript), sagt er mir das. Ich kann diese Seiten an eine andere Pipeline weiterleiten – oder sie einfach zur manuellen Überprüfung markieren.

Für SEO-Analyse-Workflows – bei denen ich nach originalen Datenpunkten, proprietärer Forschung und First-Party-Expertise-Signalen in Konkurrenzinhalten suche – ist saubere Extraktion das Fundament, auf dem alles andere aufbaut. Man kann nicht die Originalität von Inhalten messen, wenn man Boilerplate misst.

Mit dieser Pipeline habe ich einige interessante Forschungen dazu angestellt, wie Inhaltsqualitätssignale mit Rankings korrelieren. Ich habe 44.000 SERP-Ergebnisse auf Content-Effort, Originalität und thematische Kohärenz bewertet – hier ist, was ich gefunden habe.

Arbeit in Fortschritt

Ich sollte ehrlich sein – während der Benchmark fertig und veröffentlicht ist, benötigt rs-trafilatura noch Arbeit. Produktseiten-Extraktion (F1 = 0,670) und Kollektionsseiten (0,713) sind Bereiche, mit denen ich nicht zufrieden bin. Der ML-Klassifikator leistet mit 87 % Genauigkeit eine anständige Arbeit, aber bei den Minderheits-Seitentypen

• Listings, Services – kämpft er am meisten. Es gibt auch die Titel-Extraktion zu verbessern, und die Markdown-Ausgabepipeline benötigt einen weiteren Durchlauf bei Tabellen und Codeblöcken.

Dieses gesamte Projekt war eine Herzensangelegenheit. Was als schneller Rust-Port für Geschwindigkeit begann, wurde zu Monaten von Annotationsarbeit, ML-Experimentieren und Benchmark-Infrastruktur. Aber ich bin froh, es zu teilen. Wenn es jemandem hilft, einen besseren Extraktor zu bauen, oder ein Team davor bewahrt, seinen eigenen Evaluierungssatz von Grund auf zu bauen, dann hat es sich gelohnt.

Probieren Sie es selbst aus

Der Benchmark ist Open Source. Wenn Sie Inhalts-Extraktions-Tools bauen oder evaluieren:

• Benchmark-Website: webcontentextraction.org
• Bestenliste, Methodik, Downloads
• Datensatz: GitHub | HuggingFace | Zenodo
• rs-trafilatura: crates.io | PyPI
• Rust oder Python
• Integrations-Anleitungen: rs-trafilatura + Crawl4AI | rs-trafilatura + Spider-rs | rs-trafilatura + Scrapy | rs-trafilatura + Firecrawl
• Paper: arXiv-Preprint (in Kürze verfügbar)

Wenn Sie ein SEO sind, der mit Inhaltsanalyse im großen Maßstab arbeitet, oder RAG-Pipelines baut, oder LLMs auf Webdaten trainiert – dieser Benchmark wird Ihnen zeigen, wo Ihre Extraktionspipeline tatsächlich versagt.

Das Web besteht nicht nur aus Artikeln. Ihre Extraktions-Benchmarks sollten es auch nicht.