返回技术手记

Yaomancy · 技术决策

搜索流量为零,是被我们自己的配置挡住的

Yaomancy 上线后搜索访问几乎为零。一次可达性体检发现,真正的问题来自 robots、sitemap 与网络层默认配置,并由此重定修复优先级。

约 6 分钟

产品上线后有稳定的自然使用,回访与口碑都不差,但来自搜索的访问几乎为零。第一反应是内容不够、外链太少——按这个方向该做的是补内容。做完一次完整体检才发现,判断错了:问题根本不在内容侧。

证据

  • robots.txt 里由托管平台默认写入的一段,逐个点名禁止了几乎全部 AI 爬虫,并声明了不允许用于训练的信号。一个面向海外华人的中文产品,把中文 AI 检索的入口一并挡在了门外。
  • 首页与 sitemap.xml 对非白名单 UA 直接返回 403——检索爬虫与我们自己的自查工具同时被拦在网络层,连“被拒绝”这件事都要绕一圈才看得见。
  • robots.txt 末行规规矩矩声明了 sitemap 地址,而那个地址本身取不到。声明与可取不一致,比不声明更糟:爬虫按声明去取,拿到的是拒绝。
  • 同一份 robots.txt 里存在两个 User-agent: * 段。不同爬虫对重复段的合并策略并不一致,于是实际生效的规则不可预测——这类配置最麻烦的地方是它不报错。

判断

四条合起来指向同一件事:不是没人来,是来不了。这直接改变了优先级——在补内容之前,先把门打开。补内容是长期工程,开门是几行配置,而后者不做,前者的投入拿不到任何回报。

另一个判断更要紧,也更值得记下来:这些配置没有一条是有意设置的,全部来自托管平台的默认值与历史遗留。我们从没决定过“不让 AI 爬虫进来”,但结果和决定过一样。默认值也是决定,只是没人做过它。

由此定下的口径

  • 放行已通过验证的检索与 AI 爬虫,而不是笼统地把平台防护整个关掉。防脚本和放行爬虫是两件事,不该用一个开关解决。
  • sitemap 的“声明”与“可取”必须一致。宁可不声明,也不要声明一个取不到的地址。
  • robots.txt 只保留一个 User-agent: * 段,消除合并歧义——规则要可预测,不能靠猜。
  • 改配置之前先跑一次基线。

结论

先量,再改。最后那条看着像流程洁癖,其实是这次真正的教训:原始状态一旦放行就永久不可复现,而改动前后的对照是判断“到底有没有效”的唯一依据。基线只有一次机会,错过了就再也补不回来——我们差点就先改了。