Yaomancy · 技术决策
搜索流量为零,是被我们自己的配置挡住的
Yaomancy 上线后搜索访问几乎为零。一次可达性体检发现,真正的问题来自 robots、sitemap 与网络层默认配置,并由此重定修复优先级。
产品上线后有稳定的自然使用,回访与口碑都不差,但来自搜索的访问几乎为零。第一反应是内容不够、外链太少——按这个方向该做的是补内容。做完一次完整体检才发现,判断错了:问题根本不在内容侧。
证据
robots.txt里由托管平台默认写入的一段,逐个点名禁止了几乎全部 AI 爬虫,并声明了不允许用于训练的信号。一个面向海外华人的中文产品,把中文 AI 检索的入口一并挡在了门外。- 首页与
sitemap.xml对非白名单 UA 直接返回 403——检索爬虫与我们自己的自查工具同时被拦在网络层,连“被拒绝”这件事都要绕一圈才看得见。 robots.txt末行规规矩矩声明了 sitemap 地址,而那个地址本身取不到。声明与可取不一致,比不声明更糟:爬虫按声明去取,拿到的是拒绝。- 同一份
robots.txt里存在两个User-agent: *段。不同爬虫对重复段的合并策略并不一致,于是实际生效的规则不可预测——这类配置最麻烦的地方是它不报错。
判断
四条合起来指向同一件事:不是没人来,是来不了。这直接改变了优先级——在补内容之前,先把门打开。补内容是长期工程,开门是几行配置,而后者不做,前者的投入拿不到任何回报。
另一个判断更要紧,也更值得记下来:这些配置没有一条是有意设置的,全部来自托管平台的默认值与历史遗留。我们从没决定过“不让 AI 爬虫进来”,但结果和决定过一样。默认值也是决定,只是没人做过它。
由此定下的口径
- 放行已通过验证的检索与 AI 爬虫,而不是笼统地把平台防护整个关掉。防脚本和放行爬虫是两件事,不该用一个开关解决。
- sitemap 的“声明”与“可取”必须一致。宁可不声明,也不要声明一个取不到的地址。
robots.txt只保留一个User-agent: *段,消除合并歧义——规则要可预测,不能靠猜。- 改配置之前先跑一次基线。
结论
先量,再改。最后那条看着像流程洁癖,其实是这次真正的教训:原始状态一旦放行就永久不可复现,而改动前后的对照是判断“到底有没有效”的唯一依据。基线只有一次机会,错过了就再也补不回来——我们差点就先改了。