J'ai créé un benchmark d'extraction de contenu web de 2 000 pages. Voici ce que j'ai découvert.

Après les fuites de l'API Google en 2024, j'ai commencé à regarder les signaux de classement différemment. Pas les habituels balises title et backlinks — les signaux plus profonds. Des choses comme contentEffort, Originality, TopicalCoherence. Le genre de signaux que Google utilise pour déterminer si une page a une substance authentique ou si ce n'est que du bruit bien formaté.

J'enquêtais sur un site et j'ai remarqué quelque chose d'intéressant : leurs pages obtenaient de bons scores sur presque tous les axes de qualité auxquels je pouvais penser. Une bonne structure de titres. Des données originales partout. Un contenu qui se construisait sur lui-même plutôt que de répéter les mêmes mots-clés. Une forte cohérence thématique à travers le site. Ce n'était pas seulement bien écrit — c'était bien structuré au niveau HTML.

Cela m'a fait réfléchir. Dans un monde où les LLM peuvent produire en quelques secondes une prose compétente sur n'importe quel sujet, qu'est-ce qui différencie réellement les pages web ? La capacité d'écriture s'approche d'un coût zéro. Le savoir expert est en train d'être commoditisé. Alors, sur quoi peut encore se baser Google pour classer ?

Ma réponse : pas grand-chose ne changera fondamentalement. Ce seront toujours les liens, l'autorité thématique d'un site, et après cela — les données originales, l'expertise personnelle, et les signaux de qualité structurelle qui sont difficiles à falsifier à grande échelle. Les pages qui gagneront seront celles avec des données de première main authentiques, une réelle expérience, et des structures de contenu qui reflètent une véritable profondeur plutôt qu'un remplissage basé sur des modèles.

Je voulais mesurer cela. À grande échelle. À travers les SERPs.

Le Problème de l'Extraction

Extraire un contenu propre d'un site unique est facile avec la similarité de Jaccard et des modèles, mais le web est un endroit désordonné, et essayer de le faire à partir de 10 sites différents sur la première page d'un SERP est un problème d'un autre type et pour analyser les signaux de qualité de contenu à travers des milliers de pages concurrentes, vous devez d'abord extraire le contenu réel de chaque page. Cela semble simple — il suffit de récupérer le texte de l'article, non ?

C'est simple, si chaque page est un article de blog. Trafilatura, Readability, Newspaper — ils font tous un bon travail sur les pages d'article standard. Donnez-leur un article WordPress ou un article de presse et ils vous rendront un texte propre, plus de 90% du temps.

Mais le web n'est pas que des articles. Mélangez un contenu informatif avec un design de page de destination — une page de fonctionnalités SaaS, une page de description de produit, un site de documentation — et ces outils commencent à échouer. Ils ont été conçus pour les articles, et ils appliquent des heuristiques d'extraction d'article à tout.

J'avais besoin d'extraire le contenu de :

• Pages produits où la description vit dans un bloc JSON-LD, pas dans le DOM visible
• Pages de service/landing pages où le contenu est réparti sur 10 éléments <section> différents — héros, fonctionnalités, témoignages, tarifs, FAQ
• Fils de discussion où les messages des utilisateurs SONT le contenu, mais les extracteurs les filtrent car ils correspondent à des modèles de contenu standard de type class="comment"- Pages de documentation où j'avais besoin de la documentation réelle, pas de la navigation latérale
• Pages de collection/catégorie où le seul texte significatif est un paragraphe au-dessus d'une grille de produits

Et j'en avais besoin au format markdown — avec les titres, liens, tableaux, texte en gras préservés — car c'est ce que j'analyse pour les signaux SEO. Un vidage de texte plat perd les informations structurelles qui comptent le plus.

Ce Qui a Commencé Comme un Port est Devenu Quelque Chose de Plus Grand

Cela a commencé comme un port rapide en Rust de Trafilatura, l'excellente bibliothèque d'extraction Python d'Adrien Barbaresi. J'avais besoin de vitesse — traiter des milliers de pages via un pipeline Python était un goulot d'étranglement — et Rust correspondait parfaitement.

Mais en commençant les tests sur différents types de pages, je suis tombé encore et encore sur le même problème : l'extraction universelle ne fonctionne pas sur le web moderne. Une page produit nécessite un traitement différent d'un fil de forum. Une page de destination SaaS nécessite un traitement différent d'une documentation API.

J'ai donc ajouté une classification du type de page. Puis des profils d'extraction spécifiques au type. Puis un score de confiance pour savoir quand l'extraction était probablement mauvaise et nécessitait une deuxième passe. Puis un mode de sortie markdown. Puis un classifieur ML lorsque les heuristiques basées sur des règles atteignaient leurs limites.

Le résultat est rs-trafilatura — une bibliothèque d'extraction de contenu web en Rust qui classe les pages en 7 types et applique des stratégies d'extraction spécifiques au type. Elle traite les pages en 44ms en moyenne. Elle produit du markdown avec les titres, liens, tableaux et la mise en forme préservés.

Mais pour savoir si tout cela fonctionnait réellement, j'avais besoin d'un benchmark. Et c'est là que le vrai terrier du lapin a commencé.

Pourquoi les Benchmarks Existants ne Sont Pas Suffisants

En cherchant un benchmark pour évaluer mon extracteur, j'ai trouvé :

• ScrapingHub (2019) : 181 pages. Toutes des articles.
• CleanEval (2007) : 797 pages. De l'ère pré-HTML5.
• Google-Trends (2017) : 180 pages.
• L3S-GN1 (2010) : 621 articles de presse.

Chaque benchmark était soit minuscule, soit vieux, soit uniquement des articles. Sur les articles, chaque extracteur semble excellent — ils ont tous un F1 > 0.90. C'est comme évaluer la performance d'une voiture sur une route droite et conclure qu'elles sont toutes aussi bonnes.

La question intéressante n'est pas "pouvez-vous extraire un article de blog ?" — c'est "pouvez-vous gérer les 40-50% du web qui ne sont pas des articles de blog ?"

Personne ne mesurait cela.

Construire le Benchmark

J'ai donc construit le Web Content Extraction Benchmark (WCXB). Cela a pris beaucoup plus de temps que prévu.

2 008 pages de 1 613 domaines à travers 7 types de pages :

Type de Page	Nombre	Ce Qu'il Teste
Article	1 050	La référence — blogs, actualités, éditoriaux
Service	224	Pages de destination, pages de fonctionnalités SaaS, marketing
Forum	164	Fils de discussion, Q&R, messages communautaires
Produit	147	Descriptions de produits, spécifications, tarifs
Collection	151	Pages de catégorie, grilles de produits
Listing	139	Index de contenu, catalogues de cours
Documentation	133	Docs API, tutoriels, références techniques

Chaque page a une annotation de vérité terrain complète — titre, auteur, date, contenu principal complet en texte brut, plus des tableaux d'extraits "doit inclure" et "ne doit pas inclure" qui testent les limites du contenu. L'approche d'évaluation a été fortement influencée par l'étude comparative de Bevendorff et al. à SIGIR 2023 — leur conclusion que "les performances dépendent fortement du genre" a été une motivation directe pour ce benchmark. J'ai essayé de correspondre à leur niveau de rigueur tout en étendant la portée aux types de pages que leur ensemble de données combiné ne couvrait pas.

Le processus d'annotation était... complexe. Rédaction assistée par LLM, puis quatre passes de relecture utilisant des agents Claude Opus pour vérifier et corriger les problèmes de qualité, suivies de ma propre relecture manuelle. Scans de qualité automatisés. Relecture contradictoire où j'enquêtais sur chaque fichier où mon extracteur n'était pas d'accord avec la vérité terrain.

J'ai divisé l'ensemble de données en un ensemble de développement de 1 497 pages et un ensemble de test retenu de 511 pages avec des distributions de types de pages correspondantes. L'ensemble de test n'a jamais été touché pendant le développement — donc lorsque j'évalue dessus, les résultats sont authentiques.

Le tout est publié sous licence CC-BY-4.0 : GitHub | Zenodo (DOI : 10.5281/zenodo.19316874) | HuggingFace. Et j'espère que ma petite contribution à la communauté aidera quelqu'un.

Ce que Montrent les Résultats

J'ai exécuté 12 systèmes d'extraction sur WCXB — 10 basés sur des heuristiques et 2 neuronaux (basés sur LLM). Voici l'image globale :

Système	F1	Type	Vitesse
rs-trafilatura	0.859	Heuristique + ML	44ms/page
MinerU-HTML (0.6B)	0.827	Neuronal (A100)	1 570ms/page
Trafilatura	0.791	Heuristique	94ms/page
dom-smoothie	0.762	Heuristique	27ms/page
ReaderLM-v2 (1.5B)	0.741	Neuronal (A100)	10 410ms/page

Mais les chiffres globaux cachent la véritable histoire. Voici ce qui se passe lorsque vous les décomposez par type de page :

Type de Page	rs-trafilatura	MinerU-HTML	Trafilatura	Readability
Article	0.932	0.928	0.926	0.825
Documentation	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
Collection	0.713	0.506	0.553	0.445
Listing	0.704	0.710	0.589	0.496
Produit	0.670	0.619	0.567	0.407

Sur les articles, tout le monde est à 1-3 points près. Sur les forums ? Un écart de 33 points. Sur les collections ? 27 points. Sur les produits ? 26 points.

C'est ce que les benchmarks uniquement sur les articles cachent. Vous testez sur des articles de presse, tout semble bien. Vous testez sur la diversité réelle du web, et les failles apparaissent.

La Découverte Surprenante sur les LLMs

Je m'attendais à ce que les extracteurs neuronaux/LLM — MinerU-HTML et ReaderLM-v2 — gèrent mieux la diversité des types de page que les systèmes heuristiques. Ils sont entraînés sur des données diversifiées, ils comprennent le contexte, ils devraient généraliser.

Ils ne le font pas.

MinerU-HTML (un modèle de 0.6B affiné fonctionnant sur un GPU A100) obtient 0.928 sur les articles — approchant les systèmes heuristiques. Mais sur les collections, il descend à 0.506. Sur les produits, 0.619. Sur les forums, 0.794.

ReaderLM-v2 (1.5 milliards de paramètres — un modèle plus grand) fait encore pire : 0.417 sur les collections, 0.463 sur les produits. Et sur les listings, MinerU-HTML dépasse en fait rs-trafilatura (0.710 contre 0.704) — c'est le seul type de page où l'approche neuronale l'emporte.

Ces systèmes neuronaux ont été entraînés principalement sur du contenu de type article. Ils ont appris à extraire les articles vraiment bien. Ils n'ont pas appris à gérer les pages produit où le contenu vit dans du JSON-LD, ou les pages de service où le contenu est distribué sur une douzaine de sections DOM, ou les forums où les éléments class="comment" SONT le contenu. Il est à noter que l'équipe de MinerU-HTML a construit un benchmark interne plus large (WebMainBench, 7 809 pages) mais à ma connaissance, l'ensemble de données complet n'a pas été publié publiquement — seulement un sous-ensemble d'évaluation de 100 pages est disponible. Sans accès à la distribution de leurs données d'entraînement, il est difficile de dire si ce biais en faveur des articles est intégré à l'ensemble d'entraînement ou à l'architecture.

Un modèle plus grand n'aide pas non plus. ReaderLM-v2 avec 1.5B obtient un score inférieur à MinerU-HTML avec 0.6B sur chaque type de page.

La leçon : l'approche "lancez un LLM dessus" fonctionne pour les articles mais ne résout pas le problème de la diversité. Pour cela, vous avez besoin d'une extraction consciente du type — savoir quel type de page vous regardez et ajuster votre stratégie en conséquence.

Ce Que Cela Signifie pour l'Analyse SEO

Pour en revenir à mon point de départ — analyser les signaux de qualité de contenu à travers les SERPs — ce travail m'a donné trois choses :

1. Une extraction fiable à travers les types de pages. Je peux maintenant extraire un contenu structuré propre des pages produit, pages de service, documentation, forums — pas seulement des articles. Cela compte car les SERPs pour les requêtes commerciales sont pleines de pages non-articles.

2. Une sortie Markdown avec la structure préservée. Titres, liens, tableaux, texte en gras — tous les signaux structurels qui comptent pour l'analyse SEO. Je peux mesurer la profondeur de la hiérarchie des titres, les modèles de liens internes, les ratios contenu/éléments standard, et la cohérence structurelle à grande échelle.

3. Un score de confiance pour la qualité de l'extraction. Lorsque l'extracteur n'est pas sûr d'avoir obtenu un bon contenu (SPA, mises en page inhabituelles, JavaScript lourd), il me le dit. Je peux acheminer ces pages vers un pipeline différent — ou simplement les signaler pour une relecture manuelle.

Pour les flux de travail d'analyse SEO — où je recherche des données originales, des recherches propriétaires, et des signaux d'expertise de première main à travers le contenu des concurrents — une extraction propre est la fondation sur laquelle tout le reste se construit. Vous ne pouvez pas mesurer l'originalité du contenu si vous mesurez des éléments standard.

En utilisant ce pipeline, j'ai fait des recherches intéressantes sur la corrélation entre les signaux de qualité de contenu et les classements. J'ai évalué 44 000 résultats SERP sur l'effort de contenu, l'originalité et la cohérence thématique — voici ce que j'ai trouvé.

Travail en Cours

Je dois être honnête — bien que le benchmark soit terminé et publié, rs-trafilatura a encore besoin de travail. L'extraction des pages produit (F1 = 0.670) et des pages de collection (0.713) sont des domaines où je ne suis pas satisfait des résultats. Le classifieur ML fait un travail décent avec une précision de 87%, mais les types de pages minoritaires — listings, services — sont ceux où il a le plus de mal. Il y a aussi l'extraction du titre à améliorer, et le pipeline de sortie markdown a besoin d'une autre passe sur les tableaux et les blocs de code.

L'ensemble de ce projet a été un travail d'amour. Ce qui a commencé comme un port rapide en Rust pour la vitesse s'est transformé en des mois de travail d'annotation, d'expérimentation ML et d'infrastructure de benchmark. Mais je suis heureux de le partager. Si cela aide quelqu'un à construire un meilleur extracteur, ou évite à une équipe de devoir construire son propre ensemble d'évaluation à partir de zéro, alors l'effort en valait la peine.

Essayez-le Vous-même

Le benchmark est open source. Si vous construisez ou évaluez des outils d'extraction de contenu :

• Site du benchmark : webcontentextraction.org — classement, méthodologie, téléchargements
• Ensemble de données : GitHub | HuggingFace | Zenodo
• rs-trafilatura : crates.io | PyPI — Rust ou Python
• Guides d'intégration : rs-trafilatura + Crawl4AI | rs-trafilatura + Spider-rs | rs-trafilatura + Scrapy | rs-trafilatura + Firecrawl
• Article : prépublication arXiv (à venir)

Si vous êtes un SEO travaillant avec l'analyse de contenu à grande échelle, ou construisant des pipelines RAG, ou entraînant des LLM sur des données web — ce benchmark vous montrera où votre pipeline d'extraction échoue réellement.

Le web n'est pas que des articles. Vos benchmarks d'extraction ne devraient pas l'être non plus.