企业官网建设流程全解析

fastCRW（crw）是一个用 Rust 编写的高速轻量级爬虫与搜索 API，它的Map 功能可以只扫描网站链接、不抓取任何页面正文，几秒内列出全站 URL 清单。相比直接跑一个全站 crawl，Map 的请求量几乎可以忽略不计——按官方计费规则，一次map请求固定 1 credit，而 crawl 每落地一页就记 1 credit，抓 100 页的站点成本相差一个数量级，这就是「1/10 成本」的来源。

💡 为什么先「发现 URL」再「抓正文」？

直接对大站开 crawl，常见的翻车场景是：跑到一半发现目标内容其实在另一个目录、或者站点有 5000 个页面而你只需要其中 20 个。这时候 crawl 已经白白烧掉了一堆 credit。

Map 的解决思路是先用最低成本摸清站点地形：

官方技能文档里有一句很到位的建议：一次 3 秒的 map 调用，能省下一次 10 分钟的 crawl 中断（见 skills/crw-map/SKILL.md）。

🚀 快速上手：3 步拿到全站 URL 清单

步骤 1：一行命令输出 URL 列表

把crw放进 PATH 后（仓库提供单二进制发布与 Docker 部署），直接执行：

crw map "https://docs.example.com"

stdout 是干净的「一行一个 URL」，可以直接管道给wc -l、grep；发现总数、被过滤的动作 URL 数、解析到的 sitemap 等统计信息则打到 stderr，不污染列表。

步骤 2：切换 JSON 输出，方便程序处理

crw map "https://docs.example.com" --format json > urls.json

步骤 3：通过 REST API 调用（Firecrawl 兼容）

Map 同时是标准 HTTP 路由POST /v1/map，Firecrawl 系 SDK 只需换掉 base URL 即可复用（参数说明见 docs/docs/map.md）：

curl -X POST "$CRW_API_URL/v1/map" \ -H "Authorization: Bearer $CRW_API_KEY" \ -H 'Content-Type: application/json' \ -d '{"url":"https://docs.example.com","maxDepth":2,"limit":200}'

响应结构里data.links是发现的页面 URL，data.sitemaps是解析过的 sitemap 文档（sitemap 不是页面，所以单独列出）：

{ "success": true, "data": { "links": ["https://docs.example.com", "https://docs.example.com/about"], "sitemaps": ["https://docs.example.com/sitemap.xml"] } }

🎛️ 关键参数：三个旋钮决定「全不全」和「快不快」

CLI 完整参数定义在 crates/crw-cli/src/commands/map.rs，最常用的只有三个：

几点实战经验：

• 默认策略 = sitemap 优先 + BFS 补漏，是最完整的组合：sitemap 给出规范 URL，广度优先扫描兜住 sitemap 漏掉的页面。只有当你确信 sitemap 完整时，才用--sitemap-only换取速度。
• 深度 2 层能覆盖大多数文档站；深层 wiki 调到 3~4 层；只想列一级栏目用 1 层。
• URL 越多 ≠ 发现得越准。仓库的召回率基准（bench/MAP_RECALL.md）发现：某电商站 map 返回约 5082 个 URL，但真正的商品页只有 20 个，其余全是外语 locale 的分类 sitemap。所以拿到清单后一定要先抽样检查，而不是盲目扩大深度。

🔄 推荐工作流：map → 筛选 → scrape/crawl

最省钱的姿势不是「map 完就 crawl 全站」，而是map 之后只打你需要的子集：

# 1. 先盘点（1 credit） crw map "https://docs.example.com" --format json > urls.json # 2. 在 shell 里筛选，而不是把几千个 URL 塞进 LLM 上下文 grep '"authentication"' urls.json # 3a. 单页用 scrape；整节用 crawl crw scrape "https://docs.example.com/api/authentication" crw crawl "https://docs.example.com/api" -d 2 -l 50

如果你的 AI Agent 接入了 fastCRW 的 MCP 服务器，一轮对话里就能完成同样的事：先crw_map(url=..., limit=0)拿到全量清单，检查links挑出/changelog/*子集，再对这一个目录发起crw_crawl。

📊 性能与准确性：benchmark 数据

Map 的价值前提是「又快又全」。在 1000 URL 的抓取基准中，fastCRW 的 p90 延迟为4348ms，优于 Crawl4AI（4754ms）与 Firecrawl（6937ms）：

在「返回内容是否正确」的 truth-recall 指标上，fastCRW 同样领先（63.74% vs 59.95% / 56.04%），意味着 map 发现 URL 后接 scrape/crawl，内容质量也更有保障：

底层实现上，URL 发现逻辑位于 crates/crw-crawl/src/crawl.rs 的discover_urls（sitemap 阶段 + 带预算控制的 BFS 阶段），HTTP 路由封装在 crates/crw-server/src/routes/map.rs。

⚠️ 5 个避坑提示

1. Always map before crawl——先盘点再决定抓哪，尤其是你不确定起始 URL 范围时。
2. Map 不返回正文，别指望它直接给出内容；要正文请接力crw scrape/crw crawl。
3. 深度别盲目拉高：某托管环境实测maxDepth拉到 5、10 会直接 502（默认 2 正常）。深分页是「page-2 → page-3 → …」的链条，深度墙之外的分页页码会被截断，这是 map 的已知边界。
4. 筛选放在 shell 里做（grep、jq '.data.links[]'、wc -l），不要整表灌进模型上下文浪费 token。
5. URL 过滤是白送的：map 会自动剥离 UTM 等跟踪参数、丢弃加购/结算等动作 URL，响应里附带droppedActionCount、strippedTrackingCount统计，拿到手就是干净的清单。

📁 延伸阅读

• Map 技能全文（含 MCP/CLI/REST 三端写法）：skills/crw-map/SKILL.md
• Map API 官方文档：docs/docs/map.md
• 召回率基准方法与结论：bench/MAP_RECALL.md
• Map CLI 命令实现：crates/crw-cli/src/commands/map.rs
• URL 发现核心算法：crates/crw-crawl/src/crawl.rs

一句话总结：先用 fastCRW Map 花 1 credit 看清全站地形，再把 crawl 的预算精准花在刀刃上——这是用爬虫 API 控制成本最有效的习惯。