crawl-site 用于执行一次有边界的站点爬取，作为多数技术 SEO 报告的基础。它只反映配置的抓取器在一次运行中能发现和获取的内容，并不等同于索引、流量来源，也不保证覆盖整站。使用前应设定明确的页面数与深度预算，在后续分析需要共享同一份证据时保存快照。
用法：通过 MCP 调用时，先用 seo_list_reports 且 category 为 crawl 进行发现；调用 seo_describe_report 传入 { "id": "crawl-site" }，再调用 seo_run_report，参数如 { "id": "crawl-site", "params": { "url": "https://example.com/", "maxPages": 100, "maxDepth": 3, "saveReport": true } }。检查 isError 并读取 MCP 的 structuredContent。同样可用 CLI：seo reports describe crawl-site --json 与 seo reports run crawl-site --params '{"url":"https://example.com/","maxPages":100,"maxDepth":3,"saveReport":true}' --json。在添加 include、exclude、sitemap、robots、JavaScript 或抓取速率控制前，先查看 schema，因为这些选项的相互作用会改变所收集的证据。
判断顺序应先看爬取本身再评估站点：关注 status、requestEvidenceStatus、attempted 与 fetched 计数、失败数、保留页面数、pageLimitReached、数据源状态、警告与注意事项。部分或受上限限制的爬取无法支撑“全部正常”或“确为零”的结论。原始页面、请求与完整问题列表为按需开启，因体积可能较大，只请求下一步决策所需内容。
应区分观察与缺陷：响应失败和相互矛盾的可索引性信号值得排查，而 canonical、robots 规则、noindex 与摘要长度限制可能是刻意设置。可先用紧凑的 top fixes 做分诊，再运行 affected-urls 和 explain-issue 后创建任务。保留报告 id 与爬取设置以便核验。如果禁用了 JavaScript 渲染，或发现依赖 sitemap 或内部链接，总结结果时应说明这一边界。