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