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