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