分别用Screaming Frog、Sitebulb和自己写的Python脚本爬同一个站，发现结构分析的差距不在工具在用法
2024年刚做SEO那会儿，同事跟我说你去把竞品网站结构爬一下，我打开Screaming Frog输入网址点了Start，然后对着几百条URL发呆——爬是爬出来了，但下一步该看什么？URL长度？状态码？页面标题？好像每列都挺重要的，但又不知道从哪里切入。
后来折腾了两年多，把Screaming Frog、Sitebulb、自己写Python脚本三种方式都跑熟了，才发现一个事实：工具能给你的都一样——URL列表、层级深度、链接关系——但不同的人用同一个工具看到的东西完全不一样。核心差距不在工具本身，在你拿着这些数据问什么问题。
三种方式的核心差异，一张表说清楚
| 1 | Screaming Frog：爬得快、数据全，但默认视图是"给机器看的"——几百列数据摊开，没有经验的人容易迷失 |
| 2 | Sitebulb：可视化报告是强项，Crawl Map一眼看出结构问题，但自定义抓取不如Frog灵活 |
| 3 | 自己写Python脚本：最灵活，能定制任何分析维度，但写一个靠谱的递归爬虫+去重+并发控制，代码量不小 |
一、Screaming Frog：不是功能不够用，是你不知道问什么
Screaming Frog免费版可以爬500个URL，对大多数中小网站够用了。输入网址点Start，几分钟后左边的Internal标签下会列出所有被抓取的页面。问题来了——你怎么看这些数据？
大部分人的用法是：按Status Code排序，找404；看Page Title列，找Missing和Duplicate；看H1列，找同样的重复问题。这没错，但这只是"体检报告"，不是"结构分析"。真正的结构分析要看三样东西：
Crawl Depth（抓取深度）
不是URL有几层斜杠，而是从首页出发需要点几次才能到达这个页面。深度超过3的页面，搜索引擎给它的权重会大幅下降
Inlinks（链入链接数）
每个页面被站内其他页面链接了多少次。这个数字为0的页面就是"内链孤岛"，搜索引擎爬得到但不会重视它
URL结构层级分布
把URL按目录分组统计，看看哪些目录页面多、哪些几乎是空的。这个分布直接反映了网站内容策略的侧重点
这三个维度交叉看，你会发现很多单看一列发现不了的问题。比如某个产品页面Crawl Depth只有2、URL在核心目录下，但Inlinks只有1——说明这个页面虽然结构上很近，实际上没有内链支撑，搜索引擎根本不会重视它。
一个很多人忽略的细节：Frog的Visualisations模块（需要付费版）里有一个Force-Directed Crawl Diagram，节点大小代表内链数量、颜色代表可索引状态。你把这张图截图下来和URL列表对照看，比单纯看表格直观得多。新版还接入了AI API，可以基于页面内容的语义向量做聚类——同一主题的页面在二维图上会自动聚在一起，偏题的页面会飘在外面，一眼就能看出来。
二、Sitebulb：可视化报告这件事，它做得比谁都好
如果Screaming Frog是一台显微镜，Sitebulb更像一个带标注的CT片子。它的核心卖点是Crawl Map——一张交互式的网站结构图，每个节点是一个页面，连线是链接关系，颜色表示页面类型，大小表示重要性。
Sitebulb最大的优势：Hints系统。它不只是告诉你"这个页面有问题"，而是告诉你"这个问题为什么重要"以及"先修哪个"。每一条Hint都附带了通俗的解释和修复建议，不像Frog那样给你一堆原始数据让你自己判断。对于刚接触技术SEO的人，这个设计把入门门槛拉低了一大截。
Sitebulb的Crawl Map有三种视图模式，对应不同的分析场景：
| 视图模式 | 适合看什么 | 典型发现 |
|---|---|---|
| Tree View（树状图） | 层级结构、点击深度 | 核心栏目被挤到第4层以下，首页到内容页路径过长 |
| Force-Directed（力导向图） | 内链密度、孤岛页面 | 某些页面完全没内链指向，在图上孤零零飘在边缘 |
| Directory Tree（目录树） | URL路径组织方式 | /blog/下面300篇文章，/products/只有15个产品页，内容策略严重偏科 |
Sitebulb还有一个Signal Conflict功能特别好用。它会交叉对比不同数据源——比如Google Search Console的点击数据和爬取数据——如果某个页面GSC显示有流量但Sitebulb显示它缺少H1标签，它会标出来：这个页面有问题但用户在访问它，修它的优先级应该比修那些既没流量又有问题的页面更高。这种"按影响程度排优先级"的思路，比单纯列问题清单实用太多了。
但Sitebulb不是没有短板。它的自定义抓取规则不如Frog灵活，XPath提取也不如Frog好用。如果你要做竞品网站的数据提取（比如批量抓取竞品的价格、库存状态），Frog的Custom Extraction功能更顺手。两款工具不是替代关系，更像互补。
三、自己写Python脚本：三个场景下比成品工具强，其他时候没必要
自己动手写一个网站结构爬取器的思路其实不复杂：从首页出发，用requests拿页面、BeautifulSoup解析HTML、提取所有a标签的href、去重后加入待爬队列、递归重复这个过程。核心代码不到100行就能跑起来。
# 最简版本的结构爬取器，不到50行
import requests
from bs4 import BeautifulSoup
from urllib.parse import urljoin, urlparse
visited = set()
to_visit = ["https://example.com"]
base_domain = "example.com"
while to_visit and len(visited) < 500:
url = to_visit.pop(0)
if url in visited: continue
try:
r = requests.get(url, timeout=10)
soup = BeautifulSoup(r.text, "html.parser")
visited.add(url)
print(f"深度:{url.count('/')-2} | {url}")
for a in soup.find_all("a", href=True):
link = urljoin(url, a["href"])
if base_domain in link and link not in visited:
to_visit.append(link)
except: pass但这只是最简版本，真正能用的爬取器至少还要加上：并发控制（asyncio + aiohttp）、robots.txt解析和遵守、User-Agent轮换、请求间隔控制、URL规范化去重、断点续爬、结果导出为JSON/CSV。把这些都加上，代码量会膨胀到500行以上。
什么时候值得自己写？三个场景：
需要批量爬几十个站点做对比
Frog和Sitebulb一次只能爬一个站，如果你要同时分析20个竞品站的结构差异，写个脚本批量跑更高效
分析维度成品工具没有
比如你想统计每个URL路径段的词频、计算页面之间的语义相似度、生成自定义格式的结构报告，这些只能自己写
需要集成到自动化流程里
比如每天定时爬取自己的站、检测结构变化、有异常自动发钉钉/企业微信通知。这种自动化运维场景，脚本比桌面软件好用
四、结构爬取完，然后呢？四个最有价值的分析方向
不管用什么工具，爬完的数据如果不做分析就是一堆URL列表。下面这四个分析方向，是实际工作中反复验证最有价值的：
| 分析方向 | 看什么数据 | 能发现什么 |
|---|---|---|
| 内链权重分布 | 每个页面的Inlinks数量排序 | 首页和栏目页拿走了80%的内链权重，内容页几乎分不到——你的内链策略严重向导航倾斜 |
| 目录层级膨胀 | 按URL第一级目录分组统计页面数 | /blog/下有2000篇文章但/products/只有30个——内容策略严重偏科，产品页没有被足够的内容支撑 |
| 点击深度断层 | Crawl Depth分布 + 页面类型交叉 | 60%的内容页需要点击4次以上才能到达——搜索引擎爬虫抓取频率低，新内容收录慢 |
| 竞品结构对比 | 同行业几个站的目录结构+页面数分布 | 竞品有专门的产品对比栏目和FAQ板块，你的站没有——这解释了为什么竞品长尾词覆盖比你多 |
这四个方向里，竞品结构对比是信息密度最高的。你把同行业排名靠前的三五个站分别爬一遍，导出各自的目录树结构，放在一起对比，能看到的东西比任何SEO工具的关键词报告都直观：竞品做了哪些内容板块、每个板块投入了多少页面、它们的URL命名逻辑是什么、哪些栏目是它们重点推的。
竞品结构对比的正确做法：不要只看URL数量和目录名。把竞品的URL列表导出后，按URL路径段拆开，看每一级目录的命名规律。比如竞品的所有产品页都是 /products/品牌-型号/ 这种格式，而你的产品URL是 /product/随机ID/——后者的SEO友好度差了一个级别。这种细节，不爬结构根本注意不到。
五、如果你要批量管理多个站的结构分析
前面说的都是单个站的分析流程。但如果你管着5个、10个甚至更多站点，每个站都要定期做结构爬取和分析，手动一个个打开Frog跑一遍再导出Excel汇总，这个流程的时间成本会随着站点数量线性增长。
这个时候需要的是系统化方案。比如用UC建站系统的多站看板功能，可以把多个站的结构数据统一汇总到一个监控面板里——每个站的页面数变化、新增目录、死链数量、内链分布变化，在一个界面里横向对比。某个站的结构突然出现异常（比如某个目录下页面数量骤降、死链激增），系统自动推送预警，不用等你自己爬完才发现。
更进一步的思路是把结构爬取和收录监控联动起来。单看结构数据只是一方面，结合百度/Google的索引量变化、排名波动、流量变化一起看，才能判断结构变化是否真的影响了SEO表现。比如你优化了某个栏目的内链结构后，该栏目下页面的索引量有没有涨、排名有没有变化——这些数据如果能在一个面板上联动展示，比单看爬取报告更有决策价值。
六、新手最容易踩的三个坑
爬太快被拉黑
默认并发设置下Screaming Frog每秒能发几十个请求，小网站服务器直接扛不住。爬别人网站之前先调低并发、加请求间隔，否则对方一看日志就知道你在爬他。Frog里在Config→Speed里把线程数调到2-3，间隔设500ms以上
只看URL不看链接关系
很多人爬完就导出URL列表，从不看链接关系图。URL列表只能告诉你"有什么"，链接图才能告诉你"这些东西之间怎么连的"。一个网站的问题往往不在页面数量，在连接方式
不区分动态URL和静态URL
很多网站URL里带参数（?page=2&sort=price），如果不做URL规范化处理，同一个页面会被当成多个URL重复爬取。Frog里Config→URL Rewriting可以去掉这些参数，Python脚本里用urlparse去掉query string
结尾
网站结构爬取分析器这件事，工具本身不是瓶颈。Screaming Frog一年149英镑、Sitebulb一个月15美元、自己写Python脚本免费——三种方式的成本和门槛差异很大，但最终产出的价值差距不在工具，在你怎么用数据。
一个只看出404和缺标题的人，和一个能通过内链分布反推内容策略、通过目录层级发现结构偏科、通过竞品对比找到内容缺口的人，用同一个工具看到的是两个完全不同的网站。工具的差距是一次性的，分析思路的差距会随着你做的站越来越多而越拉越大。
