Web Metadata, OpenGraph & Contact Extractor

URL を貼り付ければ、数秒で実際の結果が得られます — webmetadataextractor.com では、API キー不要で実際のパイプラインをその場で実行できます。ご自身のサイト、または以下のサイトをお試しください。

/demo/extract は、上記のライブデモページで使われているものと同じ、API キー不要のルートです（「正直な制限事項」を参照 — IP ごとにレート制限されており、ドキュメント化された安定版 API エンドポイントではありません）。コードに組み込む場合は、以下に示すように RapidAPI キーを使用して /api/v1/extract を利用してください。

または、直接呼び出すこともできます（本番環境で使う場合は、RapidAPI で取得したキーに置き換えてください）。

curl "https://web-metadata-and-contact-extractor.p.rapidapi.com/api/v1/extract?url=github.com" \
  -H "X-RapidAPI-Key: YOUR_KEY" -H "X-RapidAPI-Host: web-metadata-and-contact-extractor.p.rapidapi.com"

🎯 ユースケース

import requests

RAPIDAPI_KEY = "YOUR_RAPIDAPI_KEY"
HEADERS = {
    "X-RapidAPI-Key": RAPIDAPI_KEY,
    "X-RapidAPI-Host": "web-metadata-and-contact-extractor.p.rapidapi.com",
}
BASE = "https://web-metadata-and-contact-extractor.p.rapidapi.com/api/v1/extract"

for url in ["shop-a.com", "shop-b.com", "shop-c.com"]:
    data = requests.get(BASE, headers=HEADERS, params={"url": url}).json()
    if "Shopify" in data["detected_technologies"] and data["seo_score_percentage"] < 60:
        print(f"{url}: Shopify + {data['seo_score_percentage']}% SEO -> outreach candidate")

import requests

def read_url_as_markdown(url: str) -> str:
    """Tool function an LLM agent can call to read any public webpage."""
    resp = requests.get(
        "https://web-metadata-and-contact-extractor.p.rapidapi.com/api/v1/markdown",
        headers={"X-RapidAPI-Key": "YOUR_KEY", "X-RapidAPI-Host": "web-metadata-and-contact-extractor.p.rapidapi.com"},
        params={"url": url},
    ).json()
    return resp["markdown_content"]

🌟 主な機能

🎯 Performance SLA & Technical Architecture Notes

メモ

• レイテンシとパフォーマンスのSLA：サーバー側の処理オーバーヘッド（DOMのクリーニング、C-Lexborによる解析、Rustによるシリアライズ）は平均 < 5ms です。実際の実行時間は、対象ウェブサイトのネットワークレイテンシとオリジンサーバーの応答時間によって異なります。同じURLへのリクエストを繰り返すと、インメモリーキャッシュが使用され、< 0.01ms で応答します。
• IPv6とIPv4マップドアドレスに対応したSSRFシールド：Anti-SSRF検証エンジンは、IPv4とIPv6の両方で厳格な名前解決チェックを実施し、ループバック（127.0.0.1、::1）、リンクローカル（169.254.169.254、fe80::/10）、IPv4マップドIPv6（::ffff:127.0.0.1）アドレスをブロックします。
• Redisレートリミッター（固定ウィンドウ、自動再接続）：REDIS_URL が設定されている場合、単一のアトミックなRedis Luaスクリプト（1回のラウンドトリップで INCR と初回ヒット時の EXPIRE を実行するため、接続が切断されてカウンターにTTLが設定されないままになる時間帯はありません）を使用して、すべてのワーカー間でレート制限を分散します。Redisは起動時にpingされ、30秒ごとに再検証されます。障害時には、サービスはすぐにプロセスごとのTTLCacheにフォールバックし、/health/details の redis_status: degraded_fallback でその状態を示します。
• ヘルスエンドポイントの分離：/health は最小限の公開ライブネス情報を返します。/health/details は完全な運用ステータス（Redisモード、trust_proxy、エンジン）を返します。HEALTH_DETAILS_SECRET 環境変数が設定されている場合は、X-Health-Secret ヘッダーが必要です。
• 水平スケーリング：単一インスタンスではインメモリーTTLCache（IPあたり60 req/min）を使用します。マルチワーカーでは分散Redisを使用します。エンタープライズ規模ではRapidAPI GatewayまたはNginxを使用します。
• ゼロトラストのセルフホスティング：セルフホスト可能な本番デプロイメント向けに、完全なDockerfile（uvicornのマルチワーカー）とテストスイートが含まれています。
• モジュール化されたコードベース：サービスは単一ファイルではなく、app/ パッケージ（security/、fetcher/、cache/、ratelimit/、extraction/、observability/、api/）として構成されています。main.py は後方互換性を保つための薄いシムであり、uvicorn main:app / gunicorn main:app は変更なしで引き続き動作します。
• 検証済みの設定：app/config.py は pydantic-settings によって管理されています。調整可能なすべての設定（レート制限、キャッシュサイズ／TTL、バイト単位のフェッチ制限、ヘッダー制限など）は、以前とまったく同じデフォルト値で起動時に検証され、環境変数による上書きにも柔軟に対応します。不正な値（負のサイズ、STREAM_SOFT_LIMIT が STREAM_HARD_LIMIT を超える場合など）は、後から実行時エラーとして発生するのではなく、明確なエラーとともに直ちに失敗します。
• 遅延抽出：fields= を指定せずに /api/v1/extract を呼び出すと、完全なパイプラインが実行されます。一方、特化型エンドポイントと /api/v1/extract?fields=... は、必要な抽出器グループのみを実行します。たとえば、/api/v1/security はHTML解析を完全にスキップしてヘッダーのみを処理し、/api/v1/tech-stack はメタデータ／リンク／Markdown／SEOの処理をスキップします。同じURLに対して異なる特化型エンドポイント（またはフィールド選択）を2つ呼び出すと、上流へのフェッチが共有され、1つのキャッシュエントリーに統合されます。
• 技術シグネチャの事前フィルタリング：40種類以上ある各技術シグネチャは、正規表現を実行する前に、ページを一度小文字化したコピーに対する低コストの部分文字列チェックで判定されます。すべての正規表現を無条件に実行する方式と同じ検出結果を維持しつつ、<script> タグが多いページでのCPU使用量を大幅に削減します。
• オブザーバビリティ：GET /metrics は、Prometheusのカウンターとレイテンシーヒストグラム（リクエスト、キャッシュのヒット／ミス、SSRFブロック、サーキットブレーカーの作動、レート制限、ダウンロードしたバイト数など）を公開します。標準的なPrometheusの運用慣行に従い、デフォルトで公開されていますが、ポートをインターネットに公開し、手前にリバースプロキシのルールがない環境でセルフホストする場合は、METRICS_SECRET／X-Metrics-Secret を使ってアクセスを制限できます。すべてのアプリケーションログは1行のJSON形式で、レスポンスヘッダー X-Request-ID と共有される request_id が含まれており、ログとメトリクスをまたいでリクエストを追跡できます。
• プロパティベースのファズテスト：Hypothesisを利用したテストでは、実行ごとに何百もの敵対的な入力を生成し、URLの正規化、SSRFのIP安全性分類（固定リストだけでなく、すべてのIPv4／IPv6アドレスが対象）、および攻撃者が制御するページコンテンツを処理するすべての抽出器を検証します。これらのテストでは、クラッシュが発生しないこと、およびSSRFロジックが危険なアドレスを決して許可しないことを確認します。その結果、実際のバグが2件見つかり、修正されました。細工された url=[ クエリ文字列で未処理の500エラーを引き起こせる問題と、URLスキームを省略すると埋め込み認証情報のチェック（user:pass@host）を回避できる問題です。
• 実環境における精度ベンチマーク：benchmarks/bench_accuracy.py は、ECサイト／ニュースサイト／ブログ／SaaS／SPA／WordPress／多言語サイト／小規模サイト／ボット対策サイトにまたがる、厳選され独立して検証された稼働中URL 29件のサンプルに対して実際のパイプラインを実行します。評価方法と率直な制限事項については、benchmarks/README_ACCURACY.md を参照してください。最初の実環境での実行結果は61％でした。現代のCDN経由のサイトで一般的なBrotli圧縮レスポンスが、デコードされないまま気づかれずに渡され、UTF-8として強制的にデコードされていました。エラーはどこでも発生していませんでした。app/fetcher/client.py は Accept-Encoding: br を指定していましたが、デコーダーパッケージがインストールされていなかったためです。requirements.txt に brotli を追加すると、他のコード変更なしで修正され、同じURL 29件での実行結果は100％となり、予期しないエラーは0件になりました。

🎯 この API が適している用途と、適していない用途

この API は、URL をそのページに関する構造化された情報に変換します。SEO／OpenGraph メタデータ、公開されている連絡先情報、ソーシャルプロフィール、技術スタック、Schema.org／商品データ、評価付きセキュリティヘッダー、リンクの分類、整形済み Markdown を、1 回の高速な HTTP リクエストにまとめます。これは通常のサーバー生成 HTML に対するメタデータ／インテリジェンスレイヤーであり、汎用スクレイピングツールやブラウザー自動化の代替ではありません。用途に合うかどうかを判断する際は、この点を念頭に置いてください。

✅ 適している用途：

• 企業／ウェブサイトの分析 — 対象サイトの技術スタック、CMS、ソーシャル情報、連絡先情報、SEO の状態を 1 回の呼び出しで取得できます。
• 営業／アウトリーチのワークフローへの入力 — /api/v1/contacts は、ページ上に公開されているメールアドレス／電話番号／ソーシャルリンクを見つけます。これは、構築するリード獲得プロセス（企業の特定、役職の確認、CRM の情報拡充）に渡す生の情報であり、それ自体がリード情報の拡充を行う製品ではありません。詳しくは、以下の「制約について」を参照してください。
• 自動 SEO 監査 — 14 項目のページ内スコア、構造化された seo_checks の内訳、評価付きセキュリティヘッダー監査は、まさにこの用途のために設計されています。
• 競合／技術スタックのモニタリング — 既知の URL のリストを対象に、技術スタック、メタデータ、商品データを継続的に比較できます。URL のリストは利用者が用意して再確認する必要があります。組み込みのクローラーはありません（以下を参照）。
• AI エージェント／RAG パイプライン — markdown_content と構造化 JSON フィールドは、生の HTML の寄せ集めではなく、LLM に入力しやすい形式として設計されています。
• E コマースデータの抽出 — サイトが Schema.org JSON-LD、OpenGraph の商品タグ、または Microdata を公開している場合に、商品名／価格／通貨／在庫状況／ブランド／SKU／レビューを抽出し、フィールドごとの信頼度スコアで照合します。商品レスポンスには、価格データは他のデータより早く古くなることを考慮して、特に短い 3 分間のキャッシュを使用します。
• リンクプレビュー — チャットアプリ、ソーシャルカード、ブックマークツール向けに、タイトル、説明、画像、ファビコンを取得できます。

❌ 適していない用途：

• 複雑／インタラクティブなスクレイピング — ログイン、複数ステップのフォーム、ボタンのクリック、無限スクロール、CAPTCHA で保護されたコンテンツ。この API は HTTP GET を 1 回送信し、取得した HTML を解析します。ブラウザーを操作したり、ユーザー操作をシミュレートしたりはしません。
• JavaScript への依存度が高いサイト — 意味のあるコンテンツがクライアントサイドのハイドレーション後にしか存在しない場合、この API に見えるのは通常の HTTP クライアントが見るものとほぼ同じ、空のページ構造です。適応型のバイト制限によって、サーバーがすでに送信した内容をより多く取得できますが、JavaScript を実行するわけではありません。
• 大規模または分散型のクロール — キュー、フロンティア、または「ドメインを渡せばページを見つける」モードはありません。設計上、URL を 1 つ入力すると、1 ページ分のデータを出力します。クローラーへと機能を拡大するのではなく、ステートレスで高速な状態を保ちます。
• 侵入テストまたは脆弱性スキャン — セキュリティヘッダー監査では、HSTS、CSP、X-Frame-Options などのヘッダーの有無と品質を評価します。脆弱性の調査や、それらのヘッダー以外の設定ミスのスキャンは行わず、セキュリティ評価を行うものでもありません。security_score が高いというのは「このページは適切なセキュリティヘッダーを送信している」という意味であり、「このサイトは安全である」という意味ではありません。
• 「あらゆるサイトからあらゆるものを抽出する」スクレイピング — 対象は、明確に定義された抽出機能（SEO、連絡先、ソーシャル情報、技術情報、商品、リンク、Markdown）です。任意のカスタムフィールドやページ構造に対応する、プログラム可能なスクレイパーではありません。

こうした境界を設けている技術的な理由（JavaScript の実行、クロール、ボット保護の回避を対象外としている理由や、信頼度／品質スコアが示すものと示さないもの）については、以下の「制約について」を参照してください。

ScrapingBee、Firecrawl、BuiltWith との違いを知りたいですか？ それぞれが実際にどのような場合に優れているのかを、価格を確認したうえで率直に比較した COMPETITOR_COMPARISON.md をご覧ください。

⚠️ 制約について

この API は HTTP の生レスポンスを取得して HTML を解析します。ブラウザーではありません。これは速度を優先した意図的なトレードオフです（ブラウザーの起動が不要、JavaScript の実行待ちが不要、リクエストごとのメモリ使用量が最小限）。そのため、正規表現や抽出器をいくら追加しても完全には解消できない、実際の制約があります。

• JavaScript は実行されません。 クライアント側のレンダリング後にのみ存在するコンテンツ（多くの SPA、一部のログインが必要なページ、「さらに読み込む」操作の背後にあるコンテンツ）は、欠落したり不完全になったりします。静的ページ／SSR ページ（ほとんどのブログ、EC の商品ページ、マーケティングサイト、GitHub、Wikipedia）は問題なく動作します。一方、初期 HTML が <div id="root"></div> だけのクライアントレンダリング型シングルページアプリでは、ほとんど空の結果が返されます。この API は、ページにコンテンツを埋め込む JavaScript を実行できません。
• JavaScript フレームワークを検出しても、JavaScript の問題が解決したわけではありません。 React／Next.js／Vue などのシグネチャが検出された場合に適応型バイト制限（以下を参照）が 256 KB に拡大されることで、初期 HTML の カバレッジ は向上しますが、ブラウザーを起動したり、ハイドレーションを実行したり、クライアント側の API 呼び出しを待ったりするわけではありません。Next.js -> より多くのバイト -> より大きな解析 は、Next.js -> Chromium -> JavaScript の実行 -> ハイドレーション -> 最終 DOM ではありません。「サーバーからすでに送信された内容を、より念入りに読み取ろうとした」と捉えてください。「SPA の問題を解決した」わけではありません。
• ボット対策／CAPTCHA は検出しますが、回避はしません。 bot_protection_detected（上記を参照）によって、Cloudflare／Akamai／PerimeterX／CAPTCHA がリクエストをブロックしたことは分かりますが、チャレンジを解決することはできません。実際のブラウザーを実行する以外に回避策はありません。
• 抽出結果はヒューリスティックに基づく証拠であり、確定的な事実ではありません。確信度が高く見える場合も同様です。 技術、連絡先情報、ソーシャルリンク、商品データの検出は、パターン／シグネチャに基づいています。技術シグネチャが一致しても（たとえば、画像 URL に CDN ホスト名が 1 つ含まれている場合）、取得処理が調べたどこかにその文字列が存在したことを示すだけで、その技術が実際に 使用されている ことの証明にはなりません。未使用のコード、共有／サードパーティのアセット、推移的依存関係、偶然含まれた部分文字列の可能性があります。technology_details.confidence は、いくつの独立したシグナルが一致したかを示すものであり、検出が正しい確率ではありません。上記の実際の GitHub の例では、og:image URL にある単一の CDN ホスト名から "Contentful" が 0.75 の信頼度で検出されています。妥当な証拠ではありますが、GitHub が Contentful を利用している証明ではありません。
• quality.score が 1.0 に近くても、それは この API が利用できる証拠 に一貫性があったことを意味するだけで、データの正確性が検証済みであることを意味しません。 JSON-LD、OpenGraph、Microdata がすべて同じ価格を報告している場合、それは 3 つの エンコーディング であり、必ずしも 3 つの 独立した 情報源ではありません。多くのサイトは、同じ基礎となる商品レコードからこれら 3 つすべてを生成するため、一致していても「1 つのデータソースを 3 通りに表現している」のであって、独立して検証された 3 つの事実とは限りません。confidence: 0.98 は「ページ内にこれと矛盾する情報がない」と読み、「正しい確率が 98％」とは解釈しないでください。
• 適応型の 64／256 KB バイト制限は、単なるパフォーマンス調整ではなく、実際のトレードオフです。 これにより通常のリクエストを高速に保てますが、大きなページの後半に配置されたコンテンツ（</body> の終了タグ近くに置かれた JSON-LD、長い CMS 生成ページのかなり下にある商品ブロックなど）は、ページの「複雑さ」とは関係なく、HTML 内の 位置 のために見落とされることがあります。皮肉なことに、大きくスクリプトの多いページほど、関連データが上限を超えた位置に押し出されやすくなります。欠落フィールドを「このページには存在しない」と判断する前に、必ず quality.warnings に CONTENT_TRUNCATED があるか確認してください。「この API がそこまで読み取らなかった」可能性があります。トップレベルに独立した content_truncated ブール値はなく、この情報は quality 内にあります。
• Markdown への変換は、意味を理解することとは異なります。 markdown_content は比較的きれいな HTML→Markdown 変換であり、「記事の本題が何かを読んで理解する」モデルではありません。どのレイアウトでも、主要コンテンツとナビゲーション、関連記事ウィジェット、有料記事の予告、定型文を確実に見分けられるわけではありません。
• キャッシュは速度と引き換えに鮮度を犠牲にします。そのトレードオフの重要度はフィールドによって異なります。 15 分前の <title> は問題ありませんが、15 分前の価格情報は問題です。そのため、商品情報を含むレスポンスには、一般的な 15 分のキャッシュとは別に、より短い TTL（デフォルトで 3 分の PRODUCT_CACHE_TTL_SECONDS）が設定されています。それ以外は引き続き一般的な TTL に従います。この時間差を考慮せずに、一般的なキャッシュ経由でリアルタイムの価格監視サービスを直接構築しないでください。
• 任意の URL の取得は、この API に限らず本質的に信頼性に欠けます。 ページの応答が遅い、何度もリダイレクトする、非常に大きい、自動化されたクライアントをブロックする、TLS に問題がある、地域や User-Agent によって異なるコンテンツを配信する、一時的に停止している、予期しないステータスコードを返す、といったことがあります。SSRF 対策、タイムアウト、リダイレクト制限、バイト数上限、サーキットブレーカー（上記を参照）によって影響は抑えられますが、信頼性の低い対象を信頼できる対象に変えることはできません。
• 「約 150～300ms」はライブ取得時のネットワーク区間を示すもので、レスポンス全体の上限ではありません。 サーバー側の処理は実際に 1 桁ミリ秒で完了します（ベンチマーク方法については benchmarks/ を参照）が、ライブ のエンドツーエンド時間は対象サイトが応答するまでの時間に左右されます。対象サイトに 2.5 秒かかれば、リクエストにも同じだけかかります。見出しの数値を「対象にかかわらず、この API は 200ms で応答する」と解釈しないでください。
• クローラーはありません。 処理単位は「URL を 1 つ入力し、1 ページ分のデータを出力する」ことであり、「ドメインを渡せば、そのページを発見／優先順位付け／クロールしてくれる」ものではありません。/api/v1/links は、指定されたページ上のハイパーリンクを最大 100 件分類しますが、そのリンクをたどることはありません。サイト全体（ホームページ＋/about＋/pricing＋/blog）を分析し、重複排除、優先順位付け、クロールを行うには、URL ごとに /extract を 1 回呼び出す処理を外部で調整する必要があります。このプロジェクトでは、高速でステートレスなリクエスト単位の API として維持することを重視しているため、キュー／ワーカー／クロール対象管理システムはあえて追加していません。
• /api/v1/contacts が見つけるのは、公開されている連絡先の 手がかり であり、企業や人物に関するインテリジェンスではありません。 ページの HTML から見つかったメールアドレス／電話番号／ソーシャルリンクを返しますが、それらが誰に属するのか、その人の役職、あるいは情報の検証は行いません。「ウェブサイト → 公開されている連絡先の手がかり」を、実際のリード情報拡充（domain -> 企業の特定 -> 人物 -> 役職 -> 検証 -> 信頼度）に変換することは対象外です。このエンドポイントは、機能以上のことを示唆しないよう、意図的に「リード情報拡充」ではなく「連絡先の発見」と名付け、タグ付けしています。
• /api/v1/extract よりも用途に合った個別のエンドポイントを優先するか、fields= を使用してください。 fields を指定せずに /extract を呼び出すと、完全なパイプラインが実行されます。/extract?fields=detected_technologies は、現在 GET /api/v1/tech-stack と同じ限定的な抽出を実行し、キャッシュエントリーも共有します。fields は不要な処理を実際に省略し、すべてを計算した後で結果を絞り込むものではありません。
• このプロジェクトの API は現在も進化しています。 新しいフィールドが頻繁に追加されています（quality、product_field_confidence、bot_protection_detected などは、いずれも最近追加されました）。変更は追加のみで、既存フィールドの型が変わることはありません（以下のバージョニングに関する注意を参照）。ただし、深く統合する場合は、コミットが 1～2 回分遅れることのある README の記述よりも、最新の /openapi.json スキーマを信頼できる情報源として扱ってください。 このことは、想定されている用途（一般的な Web ページからメタデータ、SEO 情報、連絡先、技術情報をすばやく抽出すること）に対して、基盤となるアプローチに欠陥があることを意味するわけではありません。「1 回の HTTP リクエストですべての URL からすべてを抽出する」には限界があり、その限界を引き上げられるのはブラウザー自動化（Playwright/Puppeteer）だけです。ただし、その場合、この API を高速にしているスピードとリソース消費の少なさが犠牲になります。

⚡ クイックスタート

Python

import requests

url = "https://web-metadata-and-contact-extractor.p.rapidapi.com/api/v1/extract"
headers = {
    "X-RapidAPI-Key": "YOUR_RAPIDAPI_KEY_HERE",
    "X-RapidAPI-Host": "web-metadata-and-contact-extractor.p.rapidapi.com"
}
params = {"url": "https://github.com"}

data = requests.get(url, headers=headers, params=params).json()

print(f"Title:        {data['metadata']['title']}")
print(f"OG Type:      {data['metadata']['og_type']}")
print(f"Robots:       {data['metadata']['robots']}")
print(f"hreflang:     {data['metadata']['hreflang_tags']}")
print(f"Product:      {data['product_data']}")
print(f"Emails:       {data['contacts']['emails']}")
print(f"Tech Stack:   {data['detected_technologies']}")
print(f"Time:         {data['execution_time_ms']} ms")

JavaScript / Node.js

const url = 'https://web-metadata-and-contact-extractor.p.rapidapi.com/api/v1/extract?url=https%3A%2F%2Fgithub.com';
const response = await fetch(url, {
  headers: {
    'X-RapidAPI-Key': 'YOUR_RAPIDAPI_KEY_HERE',
    'X-RapidAPI-Host': 'web-metadata-and-contact-extractor.p.rapidapi.com'
  }
});
const data = await response.json();
console.log('Title:', data.metadata.title);
console.log('OG Type:', data.metadata.og_type);
console.log('Product:', data.product_data);
console.log('Time:', data.execution_time_ms, 'ms');

cURL

curl --request GET \
  --url 'https://web-metadata-and-contact-extractor.p.rapidapi.com/api/v1/extract?url=https%3A%2F%2Fgithub.com' \
  --header 'X-RapidAPI-Host: web-metadata-and-contact-extractor.p.rapidapi.com' \
  --header 'X-RapidAPI-Key: YOUR_RAPIDAPI_KEY_HERE'

📦 クライアントライブラリ

Python では、requests を直接呼び出すより公式クライアントをおすすめします。同じ 11 個のエンドポイントを利用でき、型付き例外に対応しているほか、同期クライアントと非同期クライアントの両方が用意されています。

pip install webmetadata-extractor

from webmetadata_extractor import WebMetadataClient

client = WebMetadataClient(api_key="YOUR_RAPIDAPI_KEY_HERE")
data = client.extract("https://github.com")

ターミナルを使う場合は、同じパッケージで web-inspect CLI もインストールできます（または Homebrew から単体で入手できます。Python は不要です）。

brew tap josejux/webmetadata && brew install web-inspect   # or: pip install webmetadata-extractor

web-inspect example.com --security
web-inspect example.com --markdown > article.md

エージェントを構築していますか？ よく使われる 3 つのフレームワーク向けにツールパッケージが用意されています。いずれも、エージェントにすぐ渡せるツール（extract、markdown/reader、contacts、seo_audit）が含まれています。

pip install langchain-webmetadata-extractor    # LangChain / LangGraph
pip install crewai-webmetadata-extractor       # CrewAI
pip install llamaindex-webmetadata-extractor   # LlamaIndex (reader + tools)

from langchain_webmetadata_extractor import get_tools

tools = get_tools(api_key="YOUR_RAPIDAPI_KEY_HERE")

LlamaIndex には、RAG への取り込み用に専用の WebMarkdownReader も用意されています（URL をエージェントのツール呼び出しに使うだけでなく、直接 Document に読み込みます）。

from llamaindex_webmetadata_extractor import WebMarkdownReader

documents = WebMarkdownReader(api_key="YOUR_RAPIDAPI_KEY_HERE").load_data(["https://example.com"])

4 つのパッケージはすべて MIT ライセンスのオープンソースです：webmetadata-extractor、langchain-webmetadata-extractor、crewai-webmetadata-extractor、llamaindex-webmetadata-extractor。

コードスニペットではなく、実際に動作する完全な例をお探しですか？ これらのパッケージを使った 3 つの実用的なワークフロー（CrewAI による競合分析、クリーンな Markdown を取り込む LlamaIndex RAG パイプライン、実際の変化があった場合にのみ通知する LangGraph の価格・在庫モニター）を agent-cookbooks/ でご覧ください。

何もインストールせずに試してみたいですか？ Hugging Face Spaces のライブデモで URL を貼り付けると、ブラウザーで完全なレスポンスを確認できます。

🤖 MCP / AI エージェントのサポート

この API は、RapidAPI のホスト型ゲートウェイを通じて、すぐに使える MCP サーバーとして利用できます。追加のセットアップやセルフホストは不要です。Claude Desktop、Claude Code、Cursor、または MCP 対応クライアントに追加してください。

{
  "mcpServers": {
    "RapidAPI Hub - Web Metadata and Contact Extractor": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://mcp.rapidapi.com",
        "--header",
        "x-api-host: web-metadata-and-contact-extractor.p.rapidapi.com",
        "--header",
        "x-api-key: YOUR_RAPIDAPI_KEY_HERE"
      ]
    }
  }
}

接続すると、エージェントは抽出ツールを直接呼び出せます。たとえば、RAG パイプラインに markdown_content を取り込んだり、自律型の調査・アウトリーチワークフローの一環として detected_technologies や seo_score_percentage を確認したりできます。まずはRapidAPI の掲載ページから無料のキーを取得してください。

🧩 Dify、Flowise、または Langflow での使用

いずれもプラグインのインストールは不要です。ビジュアルエージェントビルダーから、この API を直接呼び出せます。

Dify または Flowise なら、約 60 秒で設定できます： どちらも、OpenAPI スキーマからカスタムツールを直接インポートできます。RapidAPI の掲載ページから無料のキーを取得してから、次の手順に進みます。

1. Dify：ツール → カスタムツール → OpenAPI から作成。Flowise：「OpenAPI Toolkit」ノードを追加し、スキーマを指定します。
2. dify-flowise-openapi.json を貼り付けます。これは、RapidAPI ゲートウェイ経由で呼び出すように事前設定された、完全な API の 3 エンドポイント（extract、markdown、schema）をまとめたものです。
3. ツールの認証設定で、ヘッダー X-RapidAPI-Key に取得したキーを設定します。X-RapidAPI-Host は仕様内ですでに適切な値に固定されているため、ほかに設定は不要です。

これら 3 つ以外のエンドポイントが必要ですか？完全な OpenAPI 仕様には 11 個すべてが含まれています。同じ手順でインポートし、代わりにその URL を指定して、同じ 2 つのヘッダーを追加してください。

Langflow： 上記の設定が済んでいれば、追加のセットアップは不要です。Langflow は MCP にネイティブ対応しています（v1.8.4 以降、クライアントとサーバーの両方に対応）。MCP Tools コンポーネントを追加し、上記の「MCP / AI エージェント対応」セクションに記載されているのと同じ x-api-host / x-api-key ヘッダーを使用して https://mcp.rapidapi.com に接続すると、すべてのエンドポイントがツールとして表示されます。

📊 API レスポンスのサンプル（JSON）

メモ

これは、2026-08-11 に取得した GET /api/v1/extract?url=https://github.com の実際のライブ出力であり、手作業で編集した例ではありません。見栄えのよくない部分も含め、意図的に整形していません。detected_technologies には、ほぼ間違いなく Contentful を利用していないページで "Contentful" が含まれています（下記の technology_details を参照してください。根拠は og:image の URL にある CDN ホスト名ひとつだけなので、信頼度は 0.98 ではなく 0.75 です）。また、GitHub のホームページは JavaScript を多用したシェルで、初期 HTML にこの API が検出できる <article> のようなコンテンツがないため、markdown_content と word_count は空で返されます。どちらも下記の「正直な制限事項」が実際に表れたものであり、この例で問題を取り繕っているわけではありません。social_links には合計 20 個のキーがあります（上記の主な機能の表を参照してください）。読み取る価値があるのは null でないものだけなので、長さを抑えるため、ここでは省略しています。実際のレスポンスには 20 個すべてが含まれます。

{
  "url": "https://github.com",
  "final_url": "https://github.com",
  "status_code": 200,
  "execution_time_ms": 130.43,
  "bot_protection_detected": false,
  "metadata": {
    "title": "GitHub · Change is constant. GitHub keeps you ahead. · GitHub",
    "description": "Join the world's most widely adopted, AI-powered developer platform where millions of developers, businesses, and the largest open source community build software that advances humanity.",
    "og_image": "https://images.ctfassets.net/8aevphvgewt8/4pe4eOtUJ0ARpZRE4fNekf/f52b1f9c52f059a33170229883731ed0/GH-Homepage-Universe-img.png",
    "og_type": "object",
    "canonical_url": "https://github.com",
    "language": "en",
    "favicon": "https://github.githubassets.com/favicons/favicon.svg",
    "theme_color": "#1e2327",
    "hreflang_tags": [
      {"lang": "en-us", "url": "https://github.com"},
      {"lang": "pt-br", "url": "https://github.com?locale=pt-br"}
    ],
    "h1_tags": [],
    "links_count": 51,
    "content_length_bytes": 109075
  },
  "social_links": { "github": "https://github.com/features/copilot", "twitter": null, "linkedin": null, "...": "17 more platforms, all null here" },
  "contacts": { "emails": [], "phones": [] },
  "detected_technologies": ["Contentful"],
  "technology_details": [
    { "name": "Contentful", "confidence": 0.75, "evidence": ["ctfassets.net"], "category": "cms" }
  ],
  "product_data": null,
  "quality": {
    "score": 0.85,
    "rendered": false,
    "sources_used": ["meta"],
    "warnings": [{ "field": null, "type": "CONTENT_TRUNCATED" }]
  },
  "rss_feeds": ["https://github.com/opensearch.xml", "https://github.githubassets.com/favicons/favicon.svg"],
  "json_ld_schemas": [],
  "security_score_percentage": 64.2,
  "seo_score_percentage": 75.0,
  "seo_passed_checks": ["Title tag present with optimal length (10-70 chars)", "Canonical link tag present", "OpenGraph image present for social sharing", "Favicon icon present"],
  "seo_warnings": ["Meta description present but sub-optimal length (186 chars)", "Missing <h1> primary heading", "No structured data (JSON-LD) found"],
  "internal_links": ["https://github.com/", "https://github.com/login", "https://github.com/features/copilot"],
  "total_internal_count": 44,
  "total_external_count": 5,
  "word_count": 0,
  "reading_time_minutes": 0.0,
  "markdown_content": ""
}

このレスポンスは、MetadataResponse（app/models/responses.py）をシリアライズし、長さを抑えるために一部を省略したものです。上記に表示されているフィールドはすべて実際のものです。モデルのフィールドのうち、表示されていないものが 4 つあります。phone_details と product_field_confidence（このページには電話番号も product_data もないため、どちらもここでは空です）、seo_checks（上記にすでに表示されている seo_passed_checks／seo_warnings をチェックごとに構造化したもの）、そして external_links（total_external_count によると URL は 5 個で、internal_links が途中で省略されているのと同様に省略されています）です。トップレベルに content_truncated／bytes_downloaded はありません。その情報は quality.warnings 内にあります。

v4.0.0 以降、metadata には viewport、twitter_card、h1_count も含まれます。また、/api/v1/tech-stack は technology_details（信頼度スコア、一致した根拠、テクノロジーごとのカテゴリ）を追加で返し、product_data（存在する場合）には sku、mpn、gtin／isbn、seller、condition、価格帯のフィールドが含まれます。追加はすべて既存フィールドへの影響がない形で行われており、既存のフィールドが削除されたり、型が変更されたりすることはありません。以前は型が指定されていなかった Dict／List[Dict] のデータ（metadata、technology_details、seo_checks、phone_details）には、OpenAPI スキーマにドキュメント化された Pydantic モデルが追加されました。また、ここでは表示されていたにもかかわらず、以前は /api/v1/extract に含まれていなかった product_data が、実際に返されるようになりました。さらに、product_field_confidence とトップレベルの quality オブジェクトも追加されています。たとえば、JSON-LD が €39.99、OpenGraph が €29.99 を示すページでは、次のようになります。"product_field_confidence": {"price": {"value": "39.99", "confidence": 0.5, "source": "json_ld", "agreement": ["json_ld", "microdata", "opengraph"]}} および "quality": {"score": 0.9, "rendered": false, "sources_used": ["json_ld", "microdata", "opengraph", "meta"], "warnings": [{"field": "product.price", "type": "SOURCE_CONFLICT", "values": {"json_ld": "39.99", "microdata": "39.99", "opengraph": "29.99"}, "chosen_source": "json_ld", "chosen_value": "39.99"}]}。

最新の追加機能：すべてのエンドポイントのレスポンスに redirect_count（final_url に到達するまでにたどった HTTP リダイレクトの回数）と is_shortened_url（渡された URL が final_url ではなく bit.ly などの既知の URL 短縮ドメインにある場合は true）が含まれるようになりました。/api/v1/seo-audit と /api/v1/extract には、readability オブジェクト（sentence_count、paragraph_count、avg_words_per_sentence、heading_structure）が追加されています。新しいエンドポイントも 3 つあります。POST /api/v1/batch（最大 10 個の URL を対象に、URL ごとに軽量なリンクプレビューを抽出）、GET /api/v1/domain（ページを取得せずに DNS／WHOIS を照会）、/api/v1/security?include_tls_details=true（既定では無効の、オプトイン方式によるライブ TLS 証明書の検査）です。すべて追加のみで、既存フィールドの形や型は変更されていません。

さらに、/api/v1/security（および /api/v1/extract の security_headers）は Content-Security-Policy-Report-Only を、欠落として扱うのではなく、独自の "report-only" グレードとして検出するようになりました。また、グレードが付与されたすべてのヘッダーに、重要な理由を説明する security_header_explanations エントリが含まれるようになりました。

📖 API エンドポイントのドキュメント

クエリパラメーター

🔧 セルフホスティングとローカル開発

# 1. Clone
git clone https://github.com/JosejuX/rapidapi-metadata-extractor.git
cd rapidapi-metadata-extractor/rapidapi_service

# 2. Install
pip install -r requirements.txt

# 3. Fixture-based test suite (SSRF matrix, circuit breaker, single-flight, rate-limit atomicity, ...)
pip install pytest
pytest tests/ -q

# 3b. Live-network smoke suite (14 SSRF vectors + 12 global domains)
python test_api.py

# 4. Load test (concurrent requests benchmark)
python load_test.py

# 5. Dev server
uvicorn main:app --reload --port 8000

インタラクティブな Swagger UI を利用するには、http://localhost:8000/docs を開いてください。

Docker

# Pull the published image (built + pushed by .github/workflows/docker-publish.yml on every version tag)
docker pull ghcr.io/josejux/rapidapi-metadata-extractor:latest
docker run -p 8000:8000 ghcr.io/josejux/rapidapi-metadata-extractor:latest

# Or build it yourself
cd rapidapi_service
docker build -t rapidapi-metadata-extractor .
docker run -p 8000:8000 rapidapi-metadata-extractor

🏷️ キーワード

metadata-extractor • opengraph-parser • email-scraper • contact-extractor • social-links-finder • tech-stack-detector • seo-parser • fastapi • rapidapi • python-web-scraper • link-preview-generator • lead-generation-api • hreflang • schema-org • product-data-extractor • ssrf-protection

🤝 開発への協力

この API は、人間による設計、レビュー、テストの判断と並行して、AI コーディングアシスタントである Google の Gemini 3.6 Flash と Anthropic の Claude Sonnet 5 と協力しながら開発・改良されました。

📄 ライセンス

MIT License の下で配布されています。詳しくは LICENSE をご覧ください。