Web Metadata, OpenGraph & Contact Extractor

粘贴 URL，几秒钟即可获得真实结果 — webmetadataextractor.com 会实时运行实际处理流程，无需 API 密钥。试试你自己的网站，或以下网站之一：

/demo/extract 是上方在线演示页面使用的同一个免密钥路由（详见“如实说明限制”——它按 IP 限流，并非有文档说明或稳定的 API 端点）。在代码中集成时，请使用 /api/v1/extract，并按下方说明提供 RapidAPI 密钥。

或者直接调用（在生产环境中使用时，将密钥替换为你从 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 脚本共享速率限制（一次往返中执行 INCR 和首次命中时的 EXPIRE，不会出现连接断开导致计数器没有 TTL 的窗口）。启动时会 ping Redis，并每隔 30 秒重新验证。发生故障时，服务会立即回退到按进程运行的 TTLCache，并在 /health/details 中将 redis_status 标记为 degraded_fallback。
• 拆分健康检查端点：/health 返回最精简的公开存活状态数据。/health/details 返回完整的运行状态（Redis 模式、trust_proxy、引擎），设置 HEALTH_DETAILS_SECRET 环境变量后，请求必须携带 X-Health-Secret 标头。
• 水平扩展：单实例 → 内存 TTLCache（每个 IP 每分钟 60 次请求）。多工作进程 → 分布式 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 调用两个不同的专用端点（或字段选择）时，会共享一次上游抓取，并合并到同一个缓存条目中。
• 技术特征预筛选：40 多种技术特征中的每一种都会先对页面的小写副本执行开销很低的子字符串检查，通过后才运行正则表达式，而不是无条件运行所有正则表达式。检测结果保持不变，但在包含大量 <script> 标签的页面上，CPU 开销会显著降低。
• 可观测性：GET /metrics 提供 Prometheus 计数器和延迟直方图（请求、缓存命中/未命中、SSRF 拦截、断路器触发、速率限制、下载字节数等）。默认公开（符合 Prometheus 的惯例），但如果你在自托管时将端口暴露到互联网，且前方没有反向代理规则，可通过 METRICS_SECRET/X-Metrics-Secret 添加访问限制。所有应用日志均为单行 JSON，并包含与 X-Request-ID 响应标头共用的 request_id，以便通过日志和指标关联请求。
• 基于属性的模糊测试：Hypothesis 驱动的测试每次运行都会生成数百个对抗性输入，用于测试 URL 规范化、SSRF IP 安全分类（覆盖所有 IPv4/IPv6 地址，而不只是固定列表），以及所有处理攻击者控制的页面内容的提取器；测试会断言它们不会崩溃，且 SSRF 逻辑不会放过危险地址。这发现并修复了两个实际漏洞：精心构造的 url=[ 查询字符串会触发未处理的 500 错误，而嵌入凭据检查（user:pass@host）可通过省略 URL 协议绕过。
• 真实场景准确率基准测试：benchmarks/bench_accuracy.py 使用经过人工筛选且独立验证的 29 个真实 URL 样本运行完整流程，涵盖电商/新闻/博客/SaaS/SPA/WordPress/多语言/小型/受机器人防护的网站。方法和真实局限请参见 benchmarks/README_ACCURACY.md。首次真实测试得分为 61%：Brotli 压缩响应（现代 CDN 前置网站的常见做法）被静默地直接传递，未进行解码，并被强制按 UTF-8 解码，整个过程中都没有报错——app/fetcher/client.py 声明了 Accept-Encoding: br，但未安装解码器包。在 requirements.txt 中添加 brotli 后，无需更改其他代码即可修复；相同的 29 个 URL 现在得分为 100%，且没有意外错误。

🎯 这个 API 适合做什么——不适合做什么

这个 API 可将URL 转换为该页面的结构化信息：SEO/OpenGraph 元数据、公开联系信息、社交资料、技术栈、Schema.org/产品数据、安全标头评级、链接分类和整洁的 Markdown，并通过一次快速 HTTP 请求汇总返回。它是普通服务端渲染 HTML 之上的元数据/情报层，并非通用抓取工具，也不能替代浏览器自动化。在判断它是否适合你的用例时，请牢记这一点。

✅ 适用场景：

• 公司/网站分析——一次调用即可获取指定网站的技术栈、CMS、社交资料、联系信息和 SEO 健康状况。
• 销售/外联工作流的输入——/api/v1/contacts 会查找页面中公开的电子邮箱/电话号码/社交链接；这是你可以输入到自建潜在客户开发流程中的原始信号（公司识别、职位核实、CRM 信息补充），本身并不是潜在客户信息补充产品——请参阅下文的“坦诚说明局限性”。
• 自动化 SEO 审核——14 项页面评分、结构化的 seo_checks 细分结果，以及分级安全标头审核正是为此设计的。
• 竞争对手/技术栈监控——随着时间推移，对已知 URL 集合中的技术栈、元数据或产品数据进行比较。你需要提供并重新检查 URL 列表；没有内置爬虫（见下文）。
• AI Agent / RAG 流水线——markdown_content 和结构化 JSON 字段专为整洁的大模型输入而设计，而非原始 HTML 杂乱内容。
• 电商数据提取——如果网站提供 Schema.org JSON-LD、OpenGraph 产品标签或 Microdata，则可提取产品名称/价格/货币/库存情况/品牌/SKU/评论，并通过逐字段置信度评分进行交叉核验。产品响应使用较短的 3 分钟缓存，因为价格数据比其他数据更容易过时。
• 链接预览——为聊天应用、社交卡片和书签工具提供标题、描述、图片和 favicon。

❌ 不适用场景：

• 复杂/交互式抓取——登录、多步表单、按钮点击、无限滚动、受 CAPTCHA 限制的内容。此 API 只会发送一次 HTTP GET 请求并解析收到的 HTML；它不会驱动浏览器，也不会模拟用户交互。
• 大量由 JS 渲染的网站——如果有意义的内容只在客户端完成 hydration 后才出现，此 API 看到的内容与普通 HTTP 客户端看到的空壳几乎相同。自适应字节限制能提高对服务端已发送内容的覆盖率，但不会执行 JavaScript。
• 大规模或分布式爬取——没有队列、爬取边界，也没有“给我一个域名，我来查找它的所有页面”模式。它按设计一次接收一个 URL，并返回一个页面的数据；保持无状态且快速，而不是逐渐发展成爬虫。
• 渗透测试或漏洞扫描——安全标头审核会对 HSTS、CSP 和 X-Frame-Options 等标头的存在与质量进行评级。它不会探测漏洞、扫描这些标头以外的配置错误，也不构成安全评估。较高的 security_score 表示“此页面发送了良好的安全标头”，而非“此网站是安全的”。
• “从任何网站提取任何内容”的抓取——此 API 提供一组固定且定义明确的提取器（SEO、联系信息、社交资料、技术、产品、链接、Markdown），不是可用于提取任意自定义字段或页面结构的可编程抓取工具。

有关这些界限背后的技术原因——为什么执行 JS、爬取和绕过机器人防护不在范围内，以及置信度/质量评分的含义与局限——请参阅下文的“坦诚说明局限性”。

想了解它与 ScrapingBee、Firecrawl 或 BuiltWith 的比较？ 请参阅 COMPETITOR_COMPARISON.md，其中诚实地逐项比较了各工具，并核实了价格信息，说明各自真正占优的场景。

⚠️ 坦诚说明局限性

此 API 会获取原始 HTTP 响应并解析 HTML——它不是浏览器。这是为了速度而有意做出的取舍（无需启动浏览器、无需等待 JS 执行、每个请求占用的内存极少），但它也有实际的能力上限，无论增加多少正则表达式或提取器，都无法彻底突破这些上限：

• 不执行 JavaScript。 只有在客户端渲染后才存在的内容（许多 SPA、部分需要登录才能访问的页面，以及隐藏在“加载更多”交互后的内容）会缺失或不完整。静态页面或 SSR 页面（大多数博客、电商产品页面、营销网站、GitHub、Wikipedia）效果很好；初始 HTML 只有 <div id="root"></div> 的客户端渲染单页应用则基本会返回空结果——API 无法执行填充页面内容的 JS。
• 检测到 JS 框架不代表 JS 问题已解决。 检测到 React/Next.js/Vue 等特征时，自适应字节限制（见下文）会扩大到 256 KB，从而提高初始 HTML 的覆盖率——但这并不会启动浏览器、执行 hydration，也不会等待客户端 API 调用。Next.js -> 更多字节 -> 更大的解析范围 并不等于 Next.js -> Chromium -> JS 执行 -> hydration -> 最终 DOM。应将其理解为“我们更努力地读取服务器已发送的内容”，而不是“我们解决了 SPA 问题”。
• 会检测机器人防护 / CAPTCHA，但不会绕过。 bot_protection_detected（见上文）会告知你 Cloudflare/Akamai/PerimeterX/CAPTCHA 是否阻止了请求——它不会解决挑战。除了运行真实浏览器外，没有其他办法。
• 提取结果是启发式证据，不是绝对事实——即使结果看起来很有把握也是如此。 技术检测、联系信息、社交链接和产品数据都基于模式 / 特征匹配。匹配到某项技术特征（例如图片 URL 中出现一个 CDN 主机名）只能证明抓取器查看的某处包含该字符串，并不能证明该技术确实在实际使用——它可能是废弃代码、共享 / 第三方资源、传递依赖，或意外匹配的子字符串。technology_details.confidence 反映的是有多少条独立信号达成一致，而不是检测正确的概率。请参阅上文的实时 GitHub 示例，其中从 og:image URL 中的单个 CDN 主机名检测到 "Contentful"，置信度为 0.75——这是合理的证据，但不能证明 GitHub 使用了 Contentful。
• quality.score 接近 1.0，意味着此 API 可获取的证据内部一致——并不意味着数据已验证准确。 当 JSON-LD、OpenGraph 和 Microdata 都报告相同价格时，这代表三种编码方式，不一定是三个独立来源——网站通常会从同一底层产品记录生成这三种数据，因此一致可能意味着“一个数据源，以三种方式表达”，而不是三条经过独立验证的事实。应将 confidence: 0.98 理解为“页面上没有任何内容与此矛盾”，而不是“此数据正确的概率为 98%”。
• 自适应的 64/256 KB 字节限制是一项实际取舍，不只是性能调节项。 它能让常见请求保持快速，但这也意味着大型页面后部的内容——例如靠近 </body> 结束标签的 JSON-LD，或很长的 CMS 生成页面深处的产品信息块——可能仅仅因为它在 HTML 中的位置而被漏掉，与页面看起来有多“复杂”无关。更大、脚本更多的页面，反而更可能把相关数据推到截断位置之后。在将字段缺失理解为“此页面没有该内容”，而不是“此 API 没有读到那么远”之前，请务必检查 quality.warnings 中是否有 CONTENT_TRUNCATED 条目——没有单独的顶层 content_truncated 布尔值，该信号位于 quality 中。
• Markdown 转换不等于语义理解。 markdown_content 是较为整洁的 HTML→Markdown 转换结果，并不是一个能“阅读并理解文章实际内容”的模型——它无法在所有页面布局中可靠地区分主要内容、导航、相关文章组件、付费墙预览或模板化文本。
• 缓存以牺牲新鲜度换取速度，而这种取舍对某些字段的影响更大。 过期 15 分钟的 <title> 无伤大雅；过期 15 分钟的价格则不然——因此，包含产品信息的响应会使用单独且短得多的 TTL（PRODUCT_CACHE_TTL_SECONDS，默认为 3 分钟），而不是与通用的 15 分钟缓存共用 TTL。其他所有内容仍遵循通用 TTL：若未考虑这一时间窗口，就不要直接基于通用缓存路径构建实时价格监控产品。
• 任意 URL 抓取本质上并不可靠，这与此 API 无关：页面可能响应缓慢、反复重定向、体积巨大、阻止自动化客户端、存在 TLS 问题、因地理位置 / User-Agent 返回不同内容、暂时不可用，或返回意外的状态码。SSRF 防护、超时、重定向限制、字节上限和熔断器（见上文）能限制损害，但无法让不可靠的目标变得可靠。
• “约 150–300 ms”描述的是实时抓取的网络阶段，而不是总响应时间上限。 服务端处理确实只需个位数毫秒（见 benchmarks/ 中的基准测试方法），但实时端到端耗时主要取决于目标网站的响应速度——如果目标需要 2.5 秒，你的请求也需要 2.5 秒。不要把醒目的数字理解为“无论目标如何，此 API 都会在 200 ms 内响应”。
• 没有爬虫。 工作单元是输入一个 URL，返回一个页面的数据，而不是“给我一个域名，我会替你发现 / 排定优先级 / 抓取其页面”。/api/v1/links 会对你提供的页面上的最多 100 个超链接进行分类，但不会跟进这些链接。分析整个网站（主页 + /about + /pricing + /blog，并进行去重、排序和抓取）需要在外部编排：每个 URL 调用一次 /extract——此项目有意不在原本旨在保持快速、无状态、按请求处理的 API 中加入队列 / 工作进程 / 爬取前沿系统。
• /api/v1/contacts 查找的是公开联系信息线索，而非公司或人员情报。 它会返回在页面 HTML 中找到的电子邮件 / 电话 / 社交链接——但不会识别这些信息属于谁、对方的职位，也不会验证任何信息。将 网站 -> 公开联系信息线索 转化为真正的潜在客户信息补全（域名 -> 公司识别 -> 人员 -> 职位 -> 验证 -> 置信度）不在此项目的范围内；该端点有意命名 / 标记为“联系人发现”，而非“潜在客户信息补全”，以免夸大其功能。
• 优先使用专用端点，而不是 /api/v1/extract——或者使用 fields=。 不带 fields 的 /extract 会运行完整流程。现在，/extract?fields=detected_technologies 运行的窄范围提取与 GET /api/v1/tech-stack 完全相同（并共用其缓存条目）——fields 确实会跳过不需要的工作，而不是先计算所有内容再进行筛选。
• 此项目的 API 接口仍在演进。 新字段经常推出（quality、product_field_confidence、bot_protection_detected 等都是最近新增的）——只会进行增量变更，现有字段永不改变类型（见下文的版本控制说明）。但如果你在进行深度集成，应以实时 /openapi.json 架构为准，而不是依赖 README 中的某个片段，因为它可能落后一两个提交。 这并不意味着这种底层方案不适合其预期用途（从普通网页中快速提取元数据、SEO 信息、联系方式和技术信息）——而是说，“通过一次 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

正在构建 Agent？针对三种最常见框架提供了工具包——每个工具包都附带可直接交给 Agent 使用的工具（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 还提供专用的 WebMarkdownReader，用于 RAG 数据导入（可直接将 URL 加载为 Document，而不只是调用 Agent 工具）：

from llamaindex_webmetadata_extractor import WebMarkdownReader

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

这四个软件包均采用 MIT 许可证并以开源方式发布：webmetadata-extractor、langchain-webmetadata-extractor、crewai-webmetadata-extractor、llamaindex-webmetadata-extractor。

想要完整可运行的示例，而不是代码片段？请参阅 agent-cookbooks/，其中包含基于这些软件包构建的三个真实工作流：CrewAI 竞品分析器、使用干净 Markdown 的 LlamaIndex RAG 流水线，以及只在价格或库存发生实际变化时才发出提醒的 LangGraph 监控器。

想不安装任何东西就试用？在 Hugging Face Spaces 上体验在线演示——粘贴 URL，即可在浏览器中查看完整响应。

🤖 MCP / AI Agent 支持

此 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"
      ]
    }
  }
}

连接后，Agent 可以直接将提取器作为工具调用，例如将 markdown_content 导入 RAG 流水线，或在自主研究/外联工作流中检查 detected_technologies 和 seo_score_percentage。请先从 RapidAPI 页面获取免费密钥。

🧩 在 Dify、Flowise 或 Langflow 中使用

这些工具都无需安装插件——可视化 Agent 构建器可以直接调用此 API。

**约 60 秒内在 Dify 或 Flowise 中完成设置：**两者都支持直接从 OpenAPI 架构导入自定义工具。前往 RapidAPI listing 获取免费密钥，然后：

1. Dify：工具 → 自定义工具 → 从 OpenAPI 创建。Flowise：添加一个“OpenAPI Toolkit”节点，并将其指向该架构。
2. 粘贴 dify-flowise-openapi.json——这是完整 API 中经过筛选的 3 个端点（extract、markdown、`schema），已预先配置为通过 RapidAPI 网关调用。
3. 在工具的身份验证设置中，将请求头 X-RapidAPI-Key 设为你的密钥。规范中已将 X-RapidAPI-Host 固定为正确的值——无需进行其他配置。

需要使用这 3 个端点以外的其他端点？完整 OpenAPI 规范包含全部 11 个端点——导入流程相同，只需改为指向该 URL，并添加相同的两个请求头。

**Langflow：**无需进行上述设置以外的其他配置——Langflow 原生支持 MCP（自 v1.8.4 起，可同时作为客户端和服务端）。添加一个 MCP Tools 组件，使用上方“MCP / AI Agent 支持”部分所示的相同 x-api-host / x-api-key 请求头，将其连接到 https://mcp.rapidapi.com，每个端点都会显示为一个工具。

📊 API 响应示例（JSON）

说明

这是 GET /api/v1/extract?url=https://github.com 的真实实时输出，于 2026-08-11 捕获，并非手动编辑的示例。我们特意保留了原始格式，包括那些不太好看的部分：detected_technologies 在一个几乎可以肯定并非由 Contentful 驱动的页面上包含 "Contentful"（见下文的 technology_details——证据只是 og:image URL 中的一个 CDN 主机名，因此置信度只有 0.75，而不是 0.98）；由于 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），为缩短内容而删减——上方显示的每个字段都是真实的。模型中有四个字段未显示：phone_details 和 product_field_confidence（此处两者均为空——此页面没有电话号码或 product_data）、seo_checks（以结构化的逐项检查形式呈现上方已有的 seo_passed_checks/seo_warnings），以及 external_links（共 5 个 URL，根据 total_external_count 得出，省略方式与截断的 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 schema 中有了文档化的 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，则为 true）。/api/v1/seo-audit 和 /api/v1/extract 新增了 readability 对象（sentence_count、paragraph_count、avg_words_per_sentence、heading_structure）。还新增了三个端点：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

打开 http://localhost:8000/docs 以使用交互式 Swagger UI。

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。