[{"data":1,"prerenderedAt":315},["ShallowReactive",2],{"blog-keyword-cannibalization":3,"blog-prev-keyword-cannibalization":104,"blog-next-keyword-cannibalization":209},{"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\u002Fkeyword-cannibalization.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",{},"站内两个页面抢同一个词，表现是排名来回跳、流量没涨。我们查过 18 个站，平均每个站有 6 组蚕食。判断方法不复杂，麻烦的是处理。",[15,16,17],"h2",{"id":17},"怎么判断是不是蚕食",[11,19,20],{},"三个信号。第一，同一个词在排名监测里出现两个 URL，交替上榜。第二，两个页面的目标词高度重合，内容主题也重合。第三，两个页面互相内链，或者都被同一个栏目页链着。",[11,22,23],{},"我们的做法是把 GSC 里同一个查询对应的所有 URL 拉出来，按曝光排序，看前两名是不是都在自己站内。",[11,25,26],{},"一个客户搜\"项目管理工具\"时，首页和一篇博客同时出现在前 20，交替上下，三个月都是这样。",[15,28,29],{"id":29},"三种处理方式",[11,31,32],{},"第一种，合并。两个页面主题高度重合，把内容并到一个页面，另一个 301 过去。最彻底，也最常用。",[11,34,35],{},"第二种，分工。两个页面面向不同意图，把目标词拆开：一个主打\"是什么\"，一个主打\"怎么选\"，内链互相指向，各自做自己的词。",[11,37,38],{},"第三种，降权。把次要页面从导航和内链里拿掉，或者 noindex，让它退出竞争。适合那个页面本来就没价值的情况。",[15,40,41],{"id":41},"一个常被误判的情况",[11,43,44],{},"不是所有\"两个页面都有排名\"都是蚕食。如果一个页面排第 5、另一个排第 40，那不叫蚕食，叫正常的长尾覆盖。",[11,46,47],{},"真正的蚕食是：两个页面都排在前 20，而且排名交替。处理之前先确认这一点，别把正常的长尾结构改坏。",[15,49,50],{"id":50},"一次处理后的数据",[11,52,53],{},"2026 年 2 月，一个做数据平台的客户，产品页和博客页抢\"数据仓库选型\"这个词。产品页排 11，博客排 14，交替了两个月。",[11,55,56],{},"我们判断博客页的内容更深、外链更多，决定合并：把博客里的选型标准并进产品页，博客 301 到产品页。",[11,58,59],{},"第 3 周产品页排到第 6，第 6 周第 4。流量涨了 2.1 倍，因为原来两个页面分着的点击，现在集中到一个。",[15,61,62],{"id":62},"处理时的两个注意",[11,64,65],{},"第一，合并前看外链。两个页面都有外链的，要保留外链多的那个 URL，或者做 301 把权重接住。",[11,67,68],{},"第二，合并后别马上改内链。观察两周，确认新页面的排名稳定，再统一改内链。",[15,70,71],{"id":71},"一句判断",[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":41,"depth":80,"text":41},{"id":50,"depth":80,"text":50},{"id":62,"depth":80,"text":62},{"id":71,"depth":80,"text":71},null,"SEO","2026-05-15","站内两个页面抢同一个词，表现是排名来回跳、流量没涨。我们查过 18 个站，平均每个站有 6 组蚕食。判断方法、三种处理方式和一次处理后的数据都在这篇，也附了一个常被误判的情况，照着查能少走弯路。",false,"md",{},true,"\u002Fblog\u002Fkeyword-cannibalization",{"title":5,"description":91},"blog\u002Fkeyword-cannibalization",[100,101,102],"关键词蚕食","站内竞争","内容结构","UsIUvZReVSeEhio_77pnEcwSgA51bzcJ4tgZPWmsTgk",{"id":105,"title":106,"author":6,"body":107,"canonical":88,"category":197,"cover":88,"date":198,"description":199,"draft":92,"extension":93,"keywords":88,"meta":200,"navigation":95,"noindex":92,"ogImage":88,"path":201,"seo":202,"seoDescription":88,"seoTitle":88,"stem":203,"tags":204,"updated":88,"__hash__":208},"blog\u002Fblog\u002Fttfb-diagnosis-steps.md","TTFB 超过 800 毫秒，先别急着换服务器",{"type":8,"value":108,"toc":188},[109,112,116,119,122,125,128,131,134,137,140,143,146,149,152,155,158,161,164,167,170,173,176,179,182,185],[11,110,111],{},"2026 年 6 月一个客户说 TTFB 到了 1.4 秒，要换服务器。我们让他先别换，拆开时间一看，后端处理只占 180 毫秒，剩下全是 DNS 和跨地域连接。换机器花钱，解决不了问题。",[15,113,115],{"id":114},"ttfb-由五段组成","TTFB 由五段组成",[11,117,118],{},"DNS 解析、TCP 连接、TLS 握手、请求排队、后端处理。这五段加起来才是 TTFB。",[11,120,121],{},"国内访问一个没做优化的站，DNS 可能 80 毫秒，TCP 加 TLS 又是 200 多毫秒，后端 300 毫秒，加起来就超过 600 了。",[11,123,124],{},"很多人只盯着后端，其实前三段在网络层，换服务器不一定能改善。",[15,126,127],{"id":127},"怎么把时间拆开",[11,129,130],{},"一条 curl 命令就够，加 -w 参数输出各阶段耗时，重点看 time_namelookup、time_connect、time_appconnect、time_starttransfer 四个值。",[11,132,133],{},"差值的含义很清楚：nameLookup 是 DNS，connect 减 nameLookup 是 TCP，appconnect 减 connect 是 TLS，starttransfer 减 appconnect 就是后端处理加首字节。",[11,135,136],{},"我们的习惯是同一个 URL 在不同城市测三次，取中位数。单次数据没意义，网络抖动太常见。",[15,138,139],{"id":139},"后端慢的三种情况",[11,141,142],{},"第一种，慢查询。列表页、搜索页、详情页，一个 SQL 没走索引就能把 TTFB 拖到一秒以上。",[11,144,145],{},"第二种，串行调用。服务端渲染时依次请求三个外部接口，每个 200 毫秒，加起来就是 600。",[11,147,148],{},"第三种，没缓存。每次请求都重新拼页面、重新查数据库，明明内容十分钟才变一次。",[15,150,151],{"id":151},"缓存能解决多少",[11,153,154],{},"页面缓存是最有效的，命中时 TTFB 能压到 50 毫秒以内。对象缓存次之，能省掉数据库查询。",[11,156,157],{},"但要看清缓存命中率。我们见过一个站配了 CDN 缓存，命中率只有 12%，因为缓存键里带了用户 ID，等于没缓存。",[15,159,160],{"id":160},"什么时候换服务器有用",[11,162,163],{},"三种情况：CPU 长期打满、单机磁盘 IO 成为瓶颈、用户和机房跨地域。",[11,165,166],{},"跨地域这条最容易被忽略。服务器在美西、用户在国内，TCP 和 TLS 的往返就有 300 毫秒起步，换更贵的机器也没用，得加节点或者用 CDN。",[15,168,169],{"id":169},"一次真实的拆段",[11,171,172],{},"2026 年 4 月我们给一个文档站拆 TTFB，总时长 1.2 秒：DNS 180 毫秒、TCP 220、TLS 260、后端 480。前三段加起来 660 毫秒，比后端还多。",[11,174,175],{},"换了 DNS 服务商、把 TLS 升到 1.3、加了一个国内节点之后，前三段降到 210 毫秒。后端一行代码没改，TTFB 变成 690 毫秒。",[11,177,178],{},"这件事的教训很直接：网络层和后端层要分开算账，不然会误以为要重写服务。",[15,180,181],{"id":181},"一个判断标准",[11,183,184],{},"TTFB 800 毫秒是我们的分界线。低于这个数，先把 LCP 里的图片和渲染问题解决；高于这个数，先拆时间，别急着动代码。",[11,186,187],{},"拆完你会发现，真正需要改代码的情况不到一半，大多数是网络路径和缓存策略的问题。这两件事改起来比重构便宜得多。",{"title":79,"searchDepth":80,"depth":80,"links":189},[190,191,192,193,194,195,196],{"id":114,"depth":80,"text":115},{"id":127,"depth":80,"text":127},{"id":139,"depth":80,"text":139},{"id":151,"depth":80,"text":151},{"id":160,"depth":80,"text":160},{"id":169,"depth":80,"text":169},{"id":181,"depth":80,"text":181},"技术SEO","2026-05-14","TTFB 由五段组成，换服务器只解决其中一段。这篇写怎么用 curl 把五段时间拆开、后端慢的三种典型情况，以及什么情况下换机器才有用。",{},"\u002Fblog\u002Fttfb-diagnosis-steps",{"title":106,"description":199},"blog\u002Fttfb-diagnosis-steps",[205,206,207],"TTFB","服务器","页面体验","-mW0Tyot_vRvlXA9tFYpYcDh2gcp50w8k5XAdKCuP8o",{"id":210,"title":211,"author":6,"body":212,"canonical":88,"category":89,"cover":88,"date":304,"description":305,"draft":92,"extension":93,"keywords":88,"meta":306,"navigation":95,"noindex":92,"ogImage":88,"path":307,"seo":308,"seoDescription":88,"seoTitle":88,"stem":309,"tags":310,"updated":88,"__hash__":314},"blog\u002Fblog\u002Frefresh-losing-rankings.md","排名集体下滑时，我们按这六步清单处理老文",{"type":8,"value":213,"toc":295},[214,217,221,224,227,231,234,237,241,244,247,251,254,257,261,264,267,271,274,277,280,283,286,289,292],[11,215,216],{},"2026 年 4 月，一个客户的 47 个页面在三周内排名集体下滑，技术侧没动，外链没少，内容也没删。我们按一份六步清单过了一遍，六周后 31 个回到原位，12 个确认救不回来，剩下 4 个还在观察。",[15,218,220],{"id":219},"第一步先分清是不是技术原因","第一步：先分清是不是技术原因",[11,222,223],{},"查收录、查抓取、查 robots、查 5xx。技术问题会一次性影响大量页面，特征很明显：所有页面一起掉，而且掉得很深。",[11,225,226],{},"那次排查只用了半天，技术侧正常，所以往下走内容。",[15,228,230],{"id":229},"第二步看查询覆盖有没有变","第二步：看查询覆盖有没有变",[11,232,233],{},"把下滑页面的查询导出来，和三个月前对比。有些页面不是排名掉了，是它原来承接的一批查询跑到别的页面去了。",[11,235,236],{},"这种情况改页面没用，要做的是内链和标题的区分。",[15,238,240],{"id":239},"第三步看竞品页面变没变","第三步：看竞品页面变没变",[11,242,243],{},"把前 10 名翻一遍，看有没有新增的、改版的、换了页面类型的。",[11,245,246],{},"那次我们发现 9 个词的前十里多了官方文档和视频，这是搜索结果页结构变了，不是我们内容变差。",[15,248,250],{"id":249},"第四步补内容别改-url","第四步：补内容，别改 URL",[11,252,253],{},"确认是内容过时或不够完整，就补。补的部分放在对应小节里，不要整篇重写。",[11,255,256],{},"URL、标题主词、H1 都不动。动这三个东西，等于告诉搜索引擎这是新页面，前面的积累全废。",[15,258,260],{"id":259},"第五步加内链","第五步：加内链",[11,262,263],{},"下滑的页面通常内链也弱。从相关的支柱页和高流量页补两三条内链，锚文本用目标核心词。",[11,265,266],{},"这一步见效比补内容快，通常两周能看到变化。",[15,268,270],{"id":269},"第六步更新日期并提交","第六步：更新日期并提交",[11,272,273],{},"更新页面上的日期，在搜索后台提交一次。不是为了催收录，是为了让重抓有个触发点。",[11,275,276],{},"之后再观察四周。四周内没动静，基本可以判断这篇救不回来。",[15,278,279],{"id":279},"救不回来的怎么办",[11,281,282],{},"12 个救不回来的页面里，7 个是意图被别的页面类型占了，4 个是需求本身在萎缩，1 个是内容方向错了。",[11,284,285],{},"还有一种情况值得单独说：页面排名掉了，但流量没掉。这说明用户还在从别的地方进来，可能是外链、可能是社交，那这篇就不用救，先观察。",[11,287,288],{},"我们的判断是，只看排名不看流量，会把很多正常波动当成事故。",[11,290,291],{},"还有一类页面掉得很平均，每天掉一点，两周下来掉五个位置。这种通常是竞品在稳定投入，不是事故，按季度规划去应对就行。",[11,293,294],{},"最怕的是一下滑就改标题。2025 年我们接过一个客户，三个月里改了 20 次标题，页面权重被反复重置，最后连原来的词都排不回去。",{"title":79,"searchDepth":80,"depth":80,"links":296},[297,298,299,300,301,302,303],{"id":219,"depth":80,"text":220},{"id":229,"depth":80,"text":230},{"id":239,"depth":80,"text":240},{"id":249,"depth":80,"text":250},{"id":259,"depth":80,"text":260},{"id":269,"depth":80,"text":270},{"id":279,"depth":80,"text":279},"2026-05-16","2026 年 4 月一个客户 47 个页面三周内排名下滑，技术没动、外链没少。我们按六步清单处理，六周后 31 个回到原位，12 个确认救不回来。",{},"\u002Fblog\u002Frefresh-losing-rankings",{"title":211,"description":305},"blog\u002Frefresh-losing-rankings",[311,312,313],"排名下滑","内容更新","旧文翻新","6vuLskeGODpgPdIm1nitVR--_oTY4O_PcHZa9f9yYlY",1794088105943]