robots.txt 不是一份通用配置。百度和 Google 对它的解读至少有三处不一样，照着一份抄，容易在另一边翻车。
差异一：Crawl-delay
百度认 Crawl-delay 指令，可以在 robots.txt 里限制抓取间隔；Google 明确不支持这条，写了也会忽略。
这件事有实际影响：我们一个客户在 robots.txt 里写了 Crawl-delay: 10，本意是减轻服务器压力。Google 不理它，继续按自己的节奏抓；百度按 10 秒一条慢慢爬，收录周期从 5 天拖到 12 天。
后来改成用服务器限速加后台的抓取频次设置，两边都正常了。这件事我们做成了一条规则：凡是限速需求，一律用服务器和 CDN 处理，不写进 robots.txt。
差异二：屏蔽后重新放开的恢复速度
去年 8 月我们做过一次测试：同一个站，把整站 Disallow 三天，然后放开。Google 大约 2 天恢复抓取，百度用了 18 天。
百度这边的恢复还受站点评价影响。我们另一个站（内容质量一般）同样操作，百度用了 30 多天才恢复。
结论：别用 robots.txt 做临时屏蔽，尤其是整站。测试环境用密码保护或者单独的域名，别在主站上折腾。
差异三：sitemap 声明的读取
Google 会读 robots.txt 里的 Sitemap 指令，也会用 Search Console 提交。百度两边都支持，但我们的经验是百度更依赖后台提交，robots 里的声明只作为辅助。
所以我们的写法是：robots.txt 里保留 Sitemap 指令，同时在两边的后台都提交一次。不费事，但能避免"以为提交了其实没提交"。
一份我们自己的模板
一个标准的软件公司站点，我们现在的 robots.txt 大概这样写：
- 允许抓取全站，只屏蔽后台、搜索参数页、购物车这类无价值路径
- 保留 sitemap 声明，指向一份按栏目拆分的 sitemap 索引
- 不写 Crawl-delay，不写单方支持的扩展指令
- 屏蔽规则用前缀匹配，不用复杂的通配符组合
这套写法我们在 11 个站上跑了一年多，两边都没出过抓取问题。
改完之后怎么验证
先在 Google Search Console 的 robots 测试工具和百度搜索资源平台的抓取诊断各跑一次，两边都通过再上线。
再加一步：用 curl 请求几个核心 URL，确认返回 200、正文完整。这一步能抓到"规则允许但服务器挡了"的情况。
上线后观察一周抓取频次。掉 20% 以上就回滚，别等流量掉了才反应。
一个提醒
别在 robots.txt 里屏蔽 CSS 和 JS 文件。Google 渲染页面需要它们，屏蔽了会误判页面内容。百度对渲染的支持本来就弱，屏蔽了更糟。
robots.txt 是最容易被改坏的文件之一，改之前先备份，改完一定测。这套流程我们用了两年，没再出过因为 robots 造成的抓取事故。
元析智能
为软件公司做 SEO 和 GEO 优化