私は2000ページのWebコンテンツ抽出ベンチマークを構築した。発見したことを紹介。

Murrough Foley
Murrough Foley
Author·3 min read

2024年のGoogle APIリーク後、私はランキングシグナルを違う目で見るようになりました。よくあるタイトルタグやバックリンクといったものではなく、もっと深いシグナルです。contentEffortOriginalityTopicalCoherenceといったようなものです。Googleが、ページに真の実質があるのか、それとも単に形式ばったノイズに過ぎないのかを見極めるために使うようなシグナルです。

あるサイトを調査していて興味深いことに気づきました。そのサイトのページは、私が考えつくほぼすべての品質軸で高く評価されていたのです。良い見出し構造。随所に散りばめられた独自のデータポイント。同じキーワードを繰り返すのではなく、内容が積み上がっていくコンテンツ。サイト全体を通した強力なトピック的一貫性。単に文章が上手いだけでなく、HTMLレベルで 構造的に 優れていたのです。

それで私は考えました。LLMがあらゆるトピックについて数秒で有能な散文を生成できる世界で、ウェブページを実際に差別化するものは何なのでしょうか?文章作成能力のコストはゼロに近づいています。専門知識は商品化されつつあります。では、Googleがランキングの基準とすべきものは、いったい何が残っているのでしょうか?

私の答えは:根本的にはあまり変わらないだろう、というものです。依然としてリンクと、サイトのトピックに関する権威性、そしてその次に、独自のデータ、個人的な専門性、そして大規模には偽造が難しい構造的な品質シグナルが重要でしょう。勝ち残るページは、本物のファーストパーティデータ、実際の経験、そしてテンプレート駆動の埋め草ではなく実際の深みを反映したコンテンツ構造を持ったものになるでしょう。

私はこれを測定したかった。大規模に。SERP全体で。

抽出の問題

単一サイトからきれいなコンテンツを抽出するのは、ジャッカード類似度とテンプレートを使えば簡単ですが、ウェブは雑然とした場所であり、SERPの1ページ目にある10の異なるサイトからそれをやろうとするのは別種の問題です。数千もの競合ページにわたってコンテンツ品質シグナルを分析するには、まず各ページから実際のコンテンツを抽出する必要があります。簡単に聞こえますね — 記事テキストを取得するだけですよね?

標準的なブログ記事であれば、それは単純です。Trafilatura、Readability、Newspaper — これらはすべて標準的な記事ページではしっかり仕事をします。WordPressの投稿やニュース記事を与えれば、90%以上の確率でクリーンなテキストを返してくれます。

しかし、ウェブは記事だけではありません。情報提供コンテンツとランディングページデザインが混在する — SaaSの機能紹介ページ、商品説明ページ、ドキュメンテーションサイト — では、これらのツールは機能しなくなります。これらは記事用に作られており、記事抽出のヒューリスティックをすべてに適用してしまうのです。

私が抽出する必要があったのは:

  • 商品ページ:説明が表示用DOMではなくJSON-LDブロブ内にあるもの
  • サービス/ランディングページ:コンテンツが10の異なる<section>要素(ヒーロー、機能、レビュー、価格、FAQなど)に分散しているもの
  • フォーラムスレッド:ユーザー投稿そのものがコンテンツなのに、抽出器がclass="comment"のような定型パターンに一致するとして除外してしまうもの
  • ドキュメンテーションページ:サイドバーナビゲーションではなく、実際のドキュメントが必要なもの
  • コレクション/カテゴリページ:商品グリッドの上の段落だけが意味のあるテキストであるもの

しかも、私はそれを マークダウン 形式で必要としていました — 見出し、リンク、表、太字が保持された状態で — なぜなら、それが私がSEOシグナルを分析するための形式だからです。平文のテキストダンプでは、最も重要な構造的情報が失われてしまいます。

移植として始まったものが、より大きなものに

これは当初、アドリアン・バルバレシ氏の優れたPython抽出ライブラリ Trafilatura の迅速なRustポートとして始まりました。私は速度が必要でした — Pythonパイプラインで数千ページを処理するのはボトルネックでした — そしてRustはその要求にぴったりでした。

しかし、さまざまなページタイプでテストを始めると、同じ問題に繰り返しぶつかりました:現代のウェブでは、万能型の抽出は機能しないのです。商品ページとフォーラムスレッドでは、異なる処理が必要です。SaaSランディングページとAPIドキュメントでは、異なる処理が必要です。

そこで、ページタイプの分類を追加しました。次にタイプ固有の抽出プロファイルを。次に信頼度スコアを追加し、抽出結果がおそらくゴミである場合や再処理が必要な場合がわかるようにしました。次にマークダウン出力モードを。次に、ルールベースのヒューリスティックが限界に達した際のためにML分類器を追加しました。

その結果が rs-trafilatura です — ページを7タイプに分類し、タイプ固有の抽出戦略を適用するRust製ウェブコンテンツ抽出ライブラリです。平均44msでページを処理します。見出し、リンク、表、フォーマットを保持したマークダウンを出力します。

しかし、これらが実際に 機能している かどうかを知るには、ベンチマークが必要でした。そして、そこから本当の深みにはまり始めたのです。

既存のベンチマークが役に立たない理由

抽出器を評価するベンチマークを探しに行くと、以下のものを見つけました:

  • ScrapingHub (2019年):181ページ。すべて記事。
  • CleanEval (2007年):797ページ。HTML5以前の時代のもの。
  • Google-Trends (2017年):180ページ。
  • L3S-GN1 (2010年):621のニュース記事。

どのベンチマークも、小規模か古いか、記事専用かのいずれかでした。記事については、どの抽出器も素晴らしく見えます — すべてF1 > 0.90を達成します。まるで直線道路での車の性能を評価して、すべて同じくらい優れていると結論づけるようなものです。

興味深い疑問は、「ブログ記事を抽出できるか?」ではなく、「ブログ記事ではないウェブの40〜50%を処理できるか?」なのです。

誰もそれを測定していませんでした。

ベンチマークの構築

そこで、Web Content Extraction Benchmark (WCXB) を構築しました。予想以上にかなりの時間がかかりました。

2,008ページ1,613ドメインから、7つのページタイプにわたる:

ページタイプ件数何をテストするか
記事1,050ベースライン — ブログ、ニュース、論説
サービス224ランディングページ、SaaS機能ページ、マーケティング
フォーラム164ディスカッションスレッド、Q&A、コミュニティ投稿
商品147商品説明、仕様、価格
コレクション151カテゴリページ、商品グリッド
リスト139コンテンツインデックス、コースカタログ
ドキュメンテーション133APIドキュメント、チュートリアル、技術リファレンス

各ページには完全なグランドトゥルース注釈があります — タイトル、著者、日付、平文での完全なメインコンテンツに加え、コンテンツの境界をテストする「含めるべきスニペット」と「含めるべきでないスニペット」の配列です。評価アプローチは、SIGIR 2023でのBevendorffらによる比較研究に大きく影響を受けています — 彼らの「性能はジャンルに大きく依存する」という発見は、このベンチマークの直接的な動機となりました。彼らの厳密さの標準に合わせつつ、彼らの統合データセットがカバーしていないページタイプに範囲を拡大しようと試みました。

注釈プロセスは…複雑でした。LLM支援による草案作成、Claude Opusエージェントを使った4回のレビューと修正による品質検証、そして私自身の手動レビューが続きました。自動化された品質スキャン。私の抽出器がグランドトゥルースと異なる結果を出したすべてのファイルを調査する敵対的レビュー。

データセットを、1,497ページの開発セットと、ページタイプ分布を合わせた511ページのホールドアウトテストセットに分割しました。テストセットは開発中には一切触れていません — そのため、テストセットで評価を行うと、結果は本物のものになります。

全体はCC-BY-4.0で公開されています:GitHub | Zenodo (DOI: 10.5281/zenodo.19316874) | HuggingFace。そして、私のこの小さな貢献が誰かの役に立つことを願っています。

結果が示すもの

WCXBで12の抽出システムを実行しました — ヒューリスティックベース10システム、ニューラル(LLMベース)2システムです。全体像は以下の通りです:

システムF1タイプ速度
rs-trafilatura0.859ヒューリスティック + ML44ms/ページ
MinerU-HTML (0.6B)0.827ニューラル (A100)1,570ms/ページ
Trafilatura0.791ヒューリスティック94ms/ページ
dom-smoothie0.762ヒューリスティック27ms/ページ
ReaderLM-v2 (1.5B)0.741ニューラル (A100)10,410ms/ページ

しかし、全体の数字は真の姿を隠しています。ページタイプごとに分解すると何が起こるか見てみましょう:

ページタイプrs-trafilaturaMinerU-HTMLTrafilaturaReadability
記事0.9320.9280.9260.825
ドキュメンテーション0.9310.8380.8880.736
サービス0.8430.8240.7630.604
フォーラム0.7920.7940.5850.466
コレクション0.7130.5060.5530.445
リスト0.7040.7100.5890.496
商品0.6700.6190.5670.407

記事では、全システムが1〜3ポイント差の範囲内です。フォーラムでは?33ポイントの開き。コレクションでは?27ポイント。商品では?26ポイント

これが、記事のみのベンチマークが隠していることです。ニュース記事でテストすると、すべてが問題ないように見えます。実際の多様性を持つウェブでテストすると、亀裂が見えてくるのです。

LLMに関する意外な発見

ニューラル/LLMベースの抽出器 — MinerU-HTMLとReaderLM-v2 — が、ヒューリスティックシステムよりもページタイプの多様性をうまく処理するだろうと期待していました。彼らは多様なデータで訓練され、文脈を理解し、一般化できるはずです。

しかし、そうではありませんでした。

MinerU-HTML(A100 GPU上で動作するファインチューニングされた0.6Bモデル)は記事で0.928を達成 — ヒューリスティックシステムにほぼ匹敵します。しかし、コレクションでは0.506に低下。商品では0.619。フォーラムでは0.794。

ReaderLM-v2(15億パラメータ — より大きなモデル)はさらに悪い結果です:コレクションで0.417、商品で0.463。そしてリストでは、MinerU-HTMLは実際にrs-trafilaturaを僅差で上回りました(0.710対0.704) — これはニューラルアプローチが勝った唯一のページタイプです。

これらのニューラルシステムは主に記事のようなコンテンツで訓練されています。彼らは記事を抽出することを非常にうまく学習しました。しかし、コンテンツがJSON-LD内にある商品ページや、コンテンツが多数のDOMセクションに分散しているサービスページ、class="comment"要素そのものがコンテンツであるフォーラムを処理することを学習していません。MinerU-HTMLのチームはより大規模な内部ベンチマーク(WebMainBench、7,809ページ)を構築しましたが、私の知る限り完全なデータセットは公開されていません — 100ページの評価サブセットのみが利用可能です。彼らのトレーニングデータの分布にアクセスできないため、この記事バイアスがトレーニングセットに組み込まれているのか、アーキテクチャによるものなのかを断定するのは難しいです。

モデルを大きくしても役に立ちません。15億パラメータのReaderLM-v2は、すべてのページタイプで0.6BのMinerU-HTMLよりも低いスコアです。

教訓:「LLMに任せればいい」というアプローチは記事には有効ですが、多様性の問題を解決はしません。そのためには、タイプを意識した抽出 — どの種類のページを見ているかを知り、それに応じて戦略を調整すること — が必要です。

これがSEO分析に意味すること

話を始めたところに戻ります — SERP全体でのコンテンツ品質シグナルの分析 — この作業は私に3つのものを与えました:

1. ページタイプを超えた信頼性の高い抽出。 これで、記事だけでなく、商品ページ、サービスページ、ドキュメンテーション、フォーラムからもクリーンで構造化されたコンテンツを抽出できるようになりました。これは、商用クエリのSERPが記事以外のページで溢れているので重要です。

2. 構造を保持したマークダウン出力。 見出し、リンク、表、太字 — SEO分析に重要なすべての構造的シグナル。大規模に見出し階層の深さ、内部リンクパターン、コンテンツ対定型文の比率、構造的一貫性を測定できます。

3. 抽出品質の信頼度スコア。 抽出器が良いコンテンツを取得できたか確信が持てない場合(SPA、珍しいレイアウト、重いJavaScript)、それがわかります。それらのページを別のパイプラインに回すか、単に手動レビューのためにフラグを立てることができます。

SEO分析ワークフローにおいて — 競合コンテンツ全体から独自のデータポイント、独自の研究、ファーストパーティの専門性シグナルを探している場合 — クリーンな抽出は、その他すべてを構築する基礎です。定型文を測定していては、コンテンツの独自性を測定できません。

このパイプラインを使って、コンテンツ品質シグナルとランキングがどのように相関するかについて興味深い研究を行いました。44,000のSERP結果をコンテンツ努力度、独自性、トピック的一貫性でスコアリングしました — その結果はこちらです

進行中の作業

率直に言うべきです — ベンチマークは完成し公開されていますが、rs-trafilaturaにはまだ作業が必要です。商品ページ抽出(F1 = 0.670)とコレクションページ(0.713)は、結果に満足していない領域です。ML分類器は87%の精度でまずまずの仕事をしますが、マイノリティのページタイプ — リスト、サービス — で最も苦戦しています。タイトル抽出も改善が必要で、マークダウン出力パイプラインも表とコードブロックに関してもう一度手を加える必要があります。

このプロジェクト全体は、愛情を込めた労作でした。速度のための迅速なRustポートとして始まったものが、数か月に及ぶ注釈作業、ML実験、ベンチマーク基盤の構築へと発展しました。しかし、公開できて嬉しく思います。これが誰かのより良い抽出器の構築に役立ったり、チームがゼロから独自の評価セットを作る手間を省けたりすれば、その努力は報われたことになります。

自分で試す

ベンチマークはオープンソースです。コンテンツ抽出ツールを構築または評価している場合:

大規模なコンテンツ分析を扱うSEO、またはRAGパイプラインを構築している、あるいはウェブデータでLLMを訓練している方にとって、このベンチマークは抽出パイプラインが実際にどこで失敗しているかを示してくれるでしょう。

ウェブは記事だけではありません。あなたの抽出ベンチマークも、そうあるべきではないのです。

Extraktionssysteme

  • Trafilatura — Barbaresi, A. (2021). «Trafilatura: Eine Bibliothek und Kommandozeilenwerkzeug zur Texterkennung und -extraktion im Web-Scraping» ACL 2021. GitHub
  • MinerU-HTML (Dripper) — Liu, M., et al. (2025). «Dripper: Token-effiziente Extraktion von Hauptinhalt aus HTML durch leichte Sprachmodelle» arXiv:2511.23119 | GitHub
  • ReaderLM-v2 — Jina AI (2025). «ReaderLM-v2: HTML-zu-Markdown-Konvertierung durch ein kleines Sprachmodell» arXiv:2503.01151 | HuggingFace
  • Boilerpipe — Kohlschutter, C., Fankhauser, P., Nejdl, W. (2010). «Boilerplate-Text-Erkennung mit oberflächlichen Textmerkmalen» WSDM 2010.
  • BoilerNet — Leonhardt, J., Anand, A., Khosla, M. (2020). «Boilerplate-Entfernung mit neuronalen Sequenzmodellen und Token-Labels» WWW 2020 Companion.
  • Web2Text — Vogels, T., Ganea, O.E., Eickhoff, C. (2018). «Web2Text: Tiefgehende und strukturierte Boilerplate-Text-Entfernung» ECIR 2018.

Bestehende Benchmarks

  • Bevendorff et al. — Bevendorff, J., Gupta, S., Kiesel, J., Stein, B. (2023). «Ein empirischer Vergleich von Web-Content-Extraktionsalgorithmen» SIGIR 2023. GitHub — Integriert 8 Datensätze, umfasst etwa 3.100 Seiten. Die Erkenntnis, dass «die Leistung stark vom Genre abhängt», war eine direkte Motivation für die Erstellung von WCXB.
  • ScrapingHub — (2019). Benchmark zur Artikelextraktion. 181 Artikel-Seiten. GitHub
  • CleanEval — Baroni, M., et al. (2008). «CleanEval: Ein Wettbewerb zur Bereinigung von Webseiten» LREC 2008. 797 Seiten.
  • WebMainBench — OpenDataLab (2025). 7.809 Seiten mit Tag-level Annotationen. Der veröffentlichte Evaluierungssubdatensatz umfasst 100 Seiten. GitHub
  • L3S-GN1 — Kohlschutter, C., Nejdl, W. (2008). «Ein dichtebasierter Ansatz zur Segmentierung von Webseiten» CIKM 2008. 621 Nachrichtenseiten.

Diese Benchmark

マロウ・フォーリー
つながりましょう

ご質問やお仕事のご相談は、SNSでお気軽にどうぞ。