[{"data":1,"prerenderedAt":294},["ShallowReactive",2],{"blog-robots-txt-google-baidu":3,"blog-prev-robots-txt-google-baidu":123,"blog-next-robots-txt-google-baidu":203},{"id":4,"title":5,"author":6,"body":7,"canonical":107,"category":108,"cover":107,"date":109,"description":110,"draft":111,"extension":112,"keywords":107,"meta":113,"navigation":114,"noindex":111,"ogImage":107,"path":115,"seo":116,"seoDescription":107,"seoTitle":107,"stem":117,"tags":118,"updated":107,"__hash__":122},"blog\u002Fblog\u002Frobots-txt-google-baidu.md","robots.txt 在百度和 Google 下的三个不同行为","元析智能",{"type":8,"value":9,"toc":97},"minimark",[10,14,19,22,25,28,32,35,38,41,45,48,51,54,57,73,76,79,82,85,88,91,94],[11,12,13],"p",{},"robots.txt 不是一份通用配置。百度和 Google 对它的解读至少有三处不一样，照着一份抄，容易在另一边翻车。",[15,16,18],"h2",{"id":17},"差异一crawl-delay","差异一：Crawl-delay",[11,20,21],{},"百度认 Crawl-delay 指令，可以在 robots.txt 里限制抓取间隔；Google 明确不支持这条，写了也会忽略。",[11,23,24],{},"这件事有实际影响：我们一个客户在 robots.txt 里写了 Crawl-delay: 10，本意是减轻服务器压力。Google 不理它，继续按自己的节奏抓；百度按 10 秒一条慢慢爬，收录周期从 5 天拖到 12 天。",[11,26,27],{},"后来改成用服务器限速加后台的抓取频次设置，两边都正常了。这件事我们做成了一条规则：凡是限速需求，一律用服务器和 CDN 处理，不写进 robots.txt。",[15,29,31],{"id":30},"差异二屏蔽后重新放开的恢复速度","差异二：屏蔽后重新放开的恢复速度",[11,33,34],{},"去年 8 月我们做过一次测试：同一个站，把整站 Disallow 三天，然后放开。Google 大约 2 天恢复抓取，百度用了 18 天。",[11,36,37],{},"百度这边的恢复还受站点评价影响。我们另一个站（内容质量一般）同样操作，百度用了 30 多天才恢复。",[11,39,40],{},"结论：别用 robots.txt 做临时屏蔽，尤其是整站。测试环境用密码保护或者单独的域名，别在主站上折腾。",[15,42,44],{"id":43},"差异三sitemap-声明的读取","差异三：sitemap 声明的读取",[11,46,47],{},"Google 会读 robots.txt 里的 Sitemap 指令，也会用 Search Console 提交。百度两边都支持，但我们的经验是百度更依赖后台提交，robots 里的声明只作为辅助。",[11,49,50],{},"所以我们的写法是：robots.txt 里保留 Sitemap 指令，同时在两边的后台都提交一次。不费事，但能避免\"以为提交了其实没提交\"。",[15,52,53],{"id":53},"一份我们自己的模板",[11,55,56],{},"一个标准的软件公司站点，我们现在的 robots.txt 大概这样写：",[58,59,60,64,67,70],"ul",{},[61,62,63],"li",{},"允许抓取全站，只屏蔽后台、搜索参数页、购物车这类无价值路径",[61,65,66],{},"保留 sitemap 声明，指向一份按栏目拆分的 sitemap 索引",[61,68,69],{},"不写 Crawl-delay，不写单方支持的扩展指令",[61,71,72],{},"屏蔽规则用前缀匹配，不用复杂的通配符组合",[11,74,75],{},"这套写法我们在 11 个站上跑了一年多，两边都没出过抓取问题。",[15,77,78],{"id":78},"改完之后怎么验证",[11,80,81],{},"先在 Google Search Console 的 robots 测试工具和百度搜索资源平台的抓取诊断各跑一次，两边都通过再上线。",[11,83,84],{},"再加一步：用 curl 请求几个核心 URL，确认返回 200、正文完整。这一步能抓到\"规则允许但服务器挡了\"的情况。",[11,86,87],{},"上线后观察一周抓取频次。掉 20% 以上就回滚，别等流量掉了才反应。",[15,89,90],{"id":90},"一个提醒",[11,92,93],{},"别在 robots.txt 里屏蔽 CSS 和 JS 文件。Google 渲染页面需要它们，屏蔽了会误判页面内容。百度对渲染的支持本来就弱，屏蔽了更糟。",[11,95,96],{},"robots.txt 是最容易被改坏的文件之一，改之前先备份，改完一定测。这套流程我们用了两年，没再出过因为 robots 造成的抓取事故。",{"title":98,"searchDepth":99,"depth":99,"links":100},"",2,[101,102,103,104,105,106],{"id":17,"depth":99,"text":18},{"id":30,"depth":99,"text":31},{"id":43,"depth":99,"text":44},{"id":53,"depth":99,"text":53},{"id":78,"depth":99,"text":78},{"id":90,"depth":99,"text":90},null,"技术SEO","2026-04-23","robots.txt 不是一份通用配置。百度和 Google 对它的解读至少有三处不一样：Crawl-delay 认不认、屏蔽后重新放开要多久、sitemap 声明怎么读。我们两边各踩过一次坑，也写了一版两边都能用的写法，11 个站跑了一年多没出问题。照着抄之前，先看这三处差异。",false,"md",{},true,"\u002Fblog\u002Frobots-txt-google-baidu",{"title":5,"description":110},"blog\u002Frobots-txt-google-baidu",[119,120,121],"robots.txt","爬虫","百度与Google","uD-CjjmGALK6Rk1qajNB1CS4KGpI6ySgfihsjrOYyNY",{"id":124,"title":125,"author":6,"body":126,"canonical":107,"category":191,"cover":107,"date":192,"description":193,"draft":111,"extension":112,"keywords":107,"meta":194,"navigation":114,"noindex":111,"ogImage":107,"path":195,"seo":196,"seoDescription":107,"seoTitle":107,"stem":197,"tags":198,"updated":107,"__hash__":202},"blog\u002Fblog\u002Freview-site-listings-crossborder.md","G2、Capterra 这些评测站，跨境软件的第二个官网",{"type":8,"value":127,"toc":185},[128,131,134,137,140,143,146,149,152,155,158,161,164,170,173,176,179,182],[11,129,130],{},"海外 B2B 买家选软件，第一站经常不是官网，是评测站。2025 年 10 月到 2026 年 3 月，我们帮三个出海 SaaS 整理 G2、Capterra、TrustRadius 上的页面，其中一个客户到 2026 年 4 月，来自评测站的线索占新客的 31%。",[15,132,133],{"id":133},"评测站的实际作用",[11,135,136],{},"两个作用。一是被搜索。这些站权重高，用户搜“best XX software”时，结果里一半是评测站的榜单页。二是被 AI 引用。我们测过几个主流回答引擎，问“推荐 XX 类工具”时，引用的来源里评测站出现频率很高。",[11,138,139],{},"所以评测站上的信息准确度，直接影响 AI 怎么描述你。这已经不是可选项了。",[15,141,142],{"id":142},"我们的整理顺序",[11,144,145],{},"第一步，认领并补全资料。公司信息、产品截图、定价档位、支持语言。这三项经常缺，缺了榜单页就没法把你归到正确的类目。",[11,147,148],{},"第二步，分类目。一个产品可以挂在多个类目下，挂错类目等于没挂。“项目管理”和“团队协作”是两个类目，用户搜索路径不同。",[11,150,151],{},"第三步，邀请真实客户写评价。这里有个原则：别刷。评测站的风控很严，刷出来的评价会被删，账号还可能被标记。我们让客户在客户成功流程里加一个节点，上线 90 天且续费的客户才邀请。",[11,153,154],{},"第四步，回应负面评价。一条被认真回应的差评，比十条好评有说服力。回应要具体，说清问题和处理方式，别写公关话术。",[15,156,157],{"id":157},"一个具体的数",[11,159,160],{},"有个客户原本在 G2 上只有 6 条评价，评分 4.1。补到 38 条、评分 4.6 之后，榜单页排名从第三页到第一页，官网来自 G2 的引荐流量每月 700 多次。",[11,162,163],{},"另一个反常识的点：评价数量比评分更重要。4.6 分 38 条，比 5.0 分 5 条有效得多，因为买家知道 5.0 不真实。",[11,165,166],{},[167,168,169],"strong",{},"别忽略本地化评测站",[11,171,172],{},"出海到日本看的是 Boxil 和 ITreview，到法国有 Appvizer，德国有 OMR Reviews。这些站流量不如 G2，但用户更精准，竞争也小。我们给一个做发票识别的客户登记了日本的两个站，三个月带来 11 条线索，成本是填表和请两个日本客户写评价。",[11,174,175],{},"这些站大多有免费的基础收录，付费推广可以先不做。先把资料填全，把评价攒到 5 条以上，再看要不要投。",[15,177,178],{"id":178},"时间成本",[11,180,181],{},"还有一条：评价里的关键词也会被搜索。用户写“导出的 CSV 能直接用”，比你写十遍“支持导出”有用。邀请评价时给一句提示，比如“说说你用它解决了什么问题”，回收的内容质量会不一样。",[11,183,184],{},"这套整理，一个产品初期要投入 3 到 5 天，之后每月维护 2 小时。相比投广告，这是便宜得多的信任资产。我们现在的做法是，出海客户签约第一周就把评测站页面列进任务清单，别等产品成熟了再补。",{"title":98,"searchDepth":99,"depth":99,"links":186},[187,188,189,190],{"id":133,"depth":99,"text":133},{"id":142,"depth":99,"text":142},{"id":157,"depth":99,"text":157},{"id":178,"depth":99,"text":178},"行业观察","2026-04-22","海外买家选软件先看评测站，但很多中国团队的 listing 是空的。我们把三个 SaaS 的评测站页面补齐，来自评测站的线索占了新客的三成。",{},"\u002Fblog\u002Freview-site-listings-crossborder",{"title":125,"description":193},"blog\u002Freview-site-listings-crossborder",[199,200,201],"评测站","跨境软件","品牌建设","J3uqLE-8K9XpbrywBGdCps8ak6cXwputn3gW7vWFb4g",{"id":204,"title":205,"author":6,"body":206,"canonical":107,"category":282,"cover":107,"date":283,"description":284,"draft":111,"extension":112,"keywords":107,"meta":285,"navigation":114,"noindex":111,"ogImage":107,"path":286,"seo":287,"seoDescription":107,"seoTitle":107,"stem":288,"tags":289,"updated":107,"__hash__":293},"blog\u002Fblog\u002Fdashboard-build-vs-buy.md","自建看板还是买现成工具，我们算了笔账",{"type":8,"value":207,"toc":274},[208,211,214,217,220,223,226,229,232,235,238,241,244,247,250,253,256,259,262,265,268,271],[11,209,210],{},"2026 年 5 月我们算了一笔账：自建一个 SEO 数据看板，第一年大约 3 个人天，之后每月 2 小时维护；买现成工具，一年几千块。结论是按团队规模分三档，不是一句自建好或买好。",[15,212,213],{"id":213},"自建的真实成本",[11,215,216],{},"3 个人天只是写代码的时间。加上对接数据源、调口径、和客户确认需求，实际是 5 个人天。",[11,218,219],{},"之后每月 2 小时维护，包括数据源授权过期、接口字段变化、客户要加指标。一年下来是 24 小时，三天。",[11,221,222],{},"还有隐性成本：写代码的人离职，接手的人要花两天读懂。",[15,224,225],{"id":225},"买工具的成本",[11,227,228],{},"主流的 SEO 报表工具，一年几千到一万多不等，看站点数量和功能。它省掉开发和维护，但定制能力有限。",[11,230,231],{},"最大的问题是口径不好改。你的品牌词正则、你的页面分组逻辑，未必能塞进工具的筛选器里。塞不进去就只能手工后处理。",[15,233,234],{"id":234},"按团队规模分三档",[11,236,237],{},"一个人做 SEO，站点不超过 5 个，买。时间和维护成本都不划算。",[11,239,240],{},"三到五个人，站点十几个，自建。这个规模下需求已经稳定，自建一次能复用到所有客户，边际成本很低。",[11,242,243],{},"大团队或者代理公司，混合。核心指标自建，保证口径可控；客户看的展示层用工具，省设计时间。",[15,245,246],{"id":246},"一个折中方案",[11,248,249],{},"我们最后用的是折中：数据层自建，展示层用低价工具。",[11,251,252],{},"数据层就是几张固定的表，每周脚本更新。展示层用工具连过去，改改样式就能给客户看。这样口径在自己手里，界面不用自己写。",[11,254,255],{},"算下来一年成本是纯自建的三分之一，比纯买贵一点，但改起来自由。",[15,257,258],{"id":258},"别为了看板自建",[11,260,261],{},"还有一类需求根本不需要看板。客户每周只看三个数字，一封邮件就够了。我们见过为了三个数字搭一套系统的项目，上线之后没人登录。",[15,263,264],{"id":264},"别忽略的机会成本",[11,266,267],{},"自建看板的那 5 个人天，本来可以用来做内容或者修技术问题。我们算过，同样的时间能产出 4 篇稿子，或者把一个站的加载速度从 6 秒压到 3 秒。",[11,269,270],{},"这笔账很少有人算。技术团队喜欢自己造东西，觉得可控、觉得省钱，实际是把最贵的人力投在了最不产生差异的地方。",[11,272,273],{},"先用手工报表跑三个月，确认大家都看、都讨论，再决定要不要做成系统。这个顺序反过来，做出来的东西大概率没人用。",{"title":98,"searchDepth":99,"depth":99,"links":275},[276,277,278,279,280,281],{"id":213,"depth":99,"text":213},{"id":225,"depth":99,"text":225},{"id":234,"depth":99,"text":234},{"id":246,"depth":99,"text":246},{"id":258,"depth":99,"text":258},{"id":264,"depth":99,"text":264},"工具评测","2026-04-24","一个 SEO 看板自建要 3 人天加每月维护，买现成工具一年几千块。这篇按团队规模分三档给结论，附我们踩过的维护成本明细，按团队规模给结论。",{},"\u002Fblog\u002Fdashboard-build-vs-buy",{"title":205,"description":284},"blog\u002Fdashboard-build-vs-buy",[290,291,292],"数据看板","成本","工具选型","UInKcd2QuFiTEP7Gh6hDTFatzwC81MGcH5x1J5JI6-8",1794088106528]