[{"data":1,"prerenderedAt":293},["ShallowReactive",2],{"blog-internal-link-depth-four":3,"blog-prev-internal-link-depth-four":97,"blog-next-internal-link-depth-four":189},{"id":4,"title":5,"author":6,"body":7,"canonical":81,"category":82,"cover":81,"date":83,"description":84,"draft":85,"extension":86,"keywords":81,"meta":87,"navigation":88,"noindex":85,"ogImage":81,"path":89,"seo":90,"seoDescription":81,"seoTitle":81,"stem":91,"tags":92,"updated":81,"__hash__":96},"blog\u002Fblog\u002Finternal-link-depth-four.md","内链深度超过四层，产品页基本抓不到","元析智能",{"type":8,"value":9,"toc":70},"minimark",[10,14,18,21,25,28,31,34,37,40,43,46,49,52,55,58,61,64,67],[11,12,13],"p",{},"点击深度超过 4 层，抓取频次下降很明显；超过 6 层，基本只能靠 sitemap 兜底。这不是理论，是我们从 6 个客户站的日志里统计出来的。",[15,16,17],"h2",{"id":17},"深度和抓取的关系",[11,19,20],{},"把日志里的 URL 按路径层级分组，算日均抓取次数，6 个站的曲线形状都差不多：1 到 2 层是基准，3 到 4 层降到六成，5 到 6 层只剩两成，7 层以上约百分之五。不同站的绝对值差很多，但拐点都在 4 层附近。",[15,22,24],{"id":23},"_2025-年-12-月那个文档站","2025 年 12 月那个文档站",[11,26,27],{},"3000 个页面，功能文档的路径是 \u002Fdocs\u002F产品\u002F模块\u002Fv2\u002F指南\u002F页面，五层。点击深度平均 5.2 层，深层页面收录率 34%。",[11,29,30],{},"改了三处：版本号从路径里拿掉，版本切换做成页面内的选项；补了模块归档页；侧边栏加\"本模块全部文档\"的链接。深度压到 2.8 层，两个月后收录率 71%，长尾词进前 10 的多了 180 个。",[11,32,33],{},"内容一个字没改，纯结构调整。",[15,35,36],{"id":36},"怎么查",[11,38,39],{},"Screaming Frog 的 Crawl Depth 报告直接给每个页面的点击深度。日志可以按路径层级和请求量做交叉表。GSC 里按目录看收录率，哪个目录的收录率明显低，往往就是深度问题。",[15,41,42],{"id":42},"内链该加在哪",[11,44,45],{},"优先级：主导航和侧边栏 > 面包屑 > 相关文章\u002F相关文档（每篇 3 到 5 条）> 正文内链（每 500 字 1 到 2 条）。主导航的一条链接，权重抵得上正文里十条。",[15,47,48],{"id":48},"两个注意",[11,50,51],{},"别为压深度硬塞链接。相关性差的链接会稀释页面主题，蜘蛛也会降低对链接的信任。一个页面的内链超过 100 条，单条能传递的权重就很小了，还不如拆成两页。",[11,53,54],{},"还有，内链要跟着用户路径走。用户从文档点进产品页、从博客点进方案页，这种链接蜘蛛认，用户也真的会用。为了 SEO 硬造的\"相关阅读\"列表，长期看没什么价值。",[15,56,57],{"id":57},"一个反例",[11,59,60],{},"有个客户听说内链重要，在每篇文章底部塞了 30 条\"相关阅读\"，全是自动生成的同目录文章。结果这些链接互相指向，形成了一个内部小循环，蜘蛛在里面绕来绕去，反而更少去产品页。这是典型的\"内链数量上去了，结构更差了\"。",[11,62,63],{},"我们也遇到过另一种情况：客户把 200 个产品页全部放在首页导航里，点击深度都是 1 层，但首页只有 3 个产品卖得动。深度浅不等于布局合理，还要看用户会不会点。",[15,65,66],{"id":66},"立场",[11,68,69],{},"结构问题优先于内容数量。同样是写 100 篇文章，挂在一个深目录里，效果可能只有挂在浅目录、有归档页的一半。先修结构，再堆内容。",{"title":71,"searchDepth":72,"depth":72,"links":73},"",2,[74,75,76,77,78,79,80],{"id":17,"depth":72,"text":17},{"id":23,"depth":72,"text":24},{"id":36,"depth":72,"text":36},{"id":42,"depth":72,"text":42},{"id":48,"depth":72,"text":48},{"id":57,"depth":72,"text":57},{"id":66,"depth":72,"text":66},null,"技术SEO","2026-05-13","我们从 6 个站的日志里统计出点击深度和抓取频次的关系，4 层是分水岭。这篇讲怎么查深度、怎么用内链把重要页面拉浅，附一个文档站把深度从 5.2 压到 2.8 的改造数据。",false,"md",{},true,"\u002Fblog\u002Finternal-link-depth-four",{"title":5,"description":84},"blog\u002Finternal-link-depth-four",[93,94,95],"内链","站点结构","抓取","aeSWyhDLtUWvn5-6Sxub98xpbt2DjW3txEEpkwwh4no",{"id":98,"title":99,"author":6,"body":100,"canonical":81,"category":82,"cover":81,"date":179,"description":180,"draft":85,"extension":86,"keywords":81,"meta":181,"navigation":88,"noindex":85,"ogImage":81,"path":182,"seo":183,"seoDescription":81,"seoTitle":81,"stem":184,"tags":185,"updated":81,"__hash__":188},"blog\u002Fblog\u002Fduplicate-content-merge.md","站内 70% 相似的页面，该合并还是保留，我们有个判断标准",{"type":8,"value":101,"toc":171},[102,105,108,111,114,117,120,123,126,129,132,135,138,141,144,147,150,153,156,159,162,165,168],[11,103,104],{},"站内相似页面处理错了，比不处理更伤。我们用\"搜索意图是否相同\"做判断：意图相同就合并，意图不同就保留并做差异化。这条标准比相似度百分比好用。",[15,106,107],{"id":107},"先定义什么叫相似",[11,109,110],{},"工具报的相似度是按文本算的，70% 相似只说明文字重合多。但 SEO 关心的是：这两个页面在搜索结果里抢的是不是同一批词。",[11,112,113],{},"我们一般做两步判断。第一步，把两个页面各自排名前 20 的词拉出来，看重合度。第二步，看这些词的搜索意图是不是同一类。",[11,115,116],{},"词重合 80% 以上、意图相同，才算真正重复；文字相似但词不重合，那是两篇不同的内容。",[15,118,119],{"id":119},"三种该合并的",[11,121,122],{},"第一种，同一产品的不同版本页。比如\"项目管理工具\"和\"项目管理软件\"，内容 80% 一样，抢的是同一批词，合并成一个主页面。",[11,124,125],{},"第二种，同一问题的多篇回答。博客里写了三篇\"API 限流怎么办\"，发布时间不同、观点重复，合并成一篇大的，其余 301 过去。",[11,127,128],{},"第三种，模板生成的薄页。地区页、标签页、参数页，内容只差一个地名或参数，合并或者 noindex。",[15,130,131],{"id":131},"两种不该合并的",[11,133,134],{},"第一种，意图不同但文字相似。比如\"什么是 API 网关\"和\"API 网关怎么选\"，文字重合可能 60%，但一个是学习意图、一个是选型意图，合并了反而两边都不讨好。",[11,136,137],{},"第二种，面向不同人群的页面。同一个功能，给开发者和给管理者的落地页，文字有重合，但转化路径完全不同，保留并做差异化更好。",[15,139,140],{"id":140},"合并的操作",[11,142,143],{},"先定主页面，把副页面里有价值的内容并进来，副页面 301 到主页面，不要用 canonical 吊着。",[11,145,146],{},"内链要一起改：原来指向副页面的链接，全部改到主页面。外链改不了的，靠 301 接住。",[11,148,149],{},"合并后观察 4 周，看主页面的排名和流量。我们一般按流量排序，一批合 5 到 10 个，别一次合几百个。",[15,151,152],{"id":152},"一个案例",[11,154,155],{},"一个做数据平台的客户，博客里有 14 篇讲\"数据仓库选型\"的文章，都是不同年份写的。我们合并成 3 篇：一篇讲概念、一篇讲选型标准、一篇讲实施。",[11,157,158],{},"14 篇的流量加起来是每月 1200，合并后 3 篇每月 2100，而且排名更稳。剩下的 11 篇 301 到对应的主页面，没有掉流量。",[15,160,161],{"id":161},"一次翻车",[11,163,164],{},"2026 年 1 月我们给一个客户合并了 60 个\"功能对比页\"，理由都相似度 75%。合完两个月，这批页面的总流量掉了 40%。",[11,166,167],{},"复盘发现：这些对比页面向的是不同竞品的搜索词，用户搜\"我们 vs A\"和\"我们 vs B\"意图不同，合并后反而丢了长尾。后来拆回 25 个，流量慢慢回来。",[11,169,170],{},"这件事之后我们把\"意图判断\"放在相似度前面。工具给的是线索，不是结论。",{"title":71,"searchDepth":72,"depth":72,"links":172},[173,174,175,176,177,178],{"id":107,"depth":72,"text":107},{"id":119,"depth":72,"text":119},{"id":131,"depth":72,"text":131},{"id":140,"depth":72,"text":140},{"id":152,"depth":72,"text":152},{"id":161,"depth":72,"text":161},"2026-05-12","站内相似页面处理错了，比不处理更伤。我们用“搜索意图是否相同”做判断：意图相同就合并，意图不同就保留并做差异化。合并的三种做法、两个不该合的例子和一次翻车都在篇里，最后有个判断标准可以直接用。",{},"\u002Fblog\u002Fduplicate-content-merge",{"title":99,"description":180},"blog\u002Fduplicate-content-merge",[186,187,94],"重复内容","页面合并","XkzQ5WOp9o4FerUadrW2sXM6Gnm2Wzn3SR7PLXjfywA",{"id":190,"title":191,"author":6,"body":192,"canonical":81,"category":82,"cover":81,"date":282,"description":283,"draft":85,"extension":86,"keywords":81,"meta":284,"navigation":88,"noindex":85,"ogImage":81,"path":285,"seo":286,"seoDescription":81,"seoTitle":81,"stem":287,"tags":288,"updated":81,"__hash__":292},"blog\u002Fblog\u002Fttfb-diagnosis-steps.md","TTFB 超过 800 毫秒，先别急着换服务器",{"type":8,"value":193,"toc":273},[194,197,201,204,207,210,213,216,219,222,225,228,231,234,237,240,243,246,249,252,255,258,261,264,267,270],[11,195,196],{},"2026 年 6 月一个客户说 TTFB 到了 1.4 秒，要换服务器。我们让他先别换，拆开时间一看，后端处理只占 180 毫秒，剩下全是 DNS 和跨地域连接。换机器花钱，解决不了问题。",[15,198,200],{"id":199},"ttfb-由五段组成","TTFB 由五段组成",[11,202,203],{},"DNS 解析、TCP 连接、TLS 握手、请求排队、后端处理。这五段加起来才是 TTFB。",[11,205,206],{},"国内访问一个没做优化的站，DNS 可能 80 毫秒，TCP 加 TLS 又是 200 多毫秒，后端 300 毫秒，加起来就超过 600 了。",[11,208,209],{},"很多人只盯着后端，其实前三段在网络层，换服务器不一定能改善。",[15,211,212],{"id":212},"怎么把时间拆开",[11,214,215],{},"一条 curl 命令就够，加 -w 参数输出各阶段耗时，重点看 time_namelookup、time_connect、time_appconnect、time_starttransfer 四个值。",[11,217,218],{},"差值的含义很清楚：nameLookup 是 DNS，connect 减 nameLookup 是 TCP，appconnect 减 connect 是 TLS，starttransfer 减 appconnect 就是后端处理加首字节。",[11,220,221],{},"我们的习惯是同一个 URL 在不同城市测三次，取中位数。单次数据没意义，网络抖动太常见。",[15,223,224],{"id":224},"后端慢的三种情况",[11,226,227],{},"第一种，慢查询。列表页、搜索页、详情页，一个 SQL 没走索引就能把 TTFB 拖到一秒以上。",[11,229,230],{},"第二种，串行调用。服务端渲染时依次请求三个外部接口，每个 200 毫秒，加起来就是 600。",[11,232,233],{},"第三种，没缓存。每次请求都重新拼页面、重新查数据库，明明内容十分钟才变一次。",[15,235,236],{"id":236},"缓存能解决多少",[11,238,239],{},"页面缓存是最有效的，命中时 TTFB 能压到 50 毫秒以内。对象缓存次之，能省掉数据库查询。",[11,241,242],{},"但要看清缓存命中率。我们见过一个站配了 CDN 缓存，命中率只有 12%，因为缓存键里带了用户 ID，等于没缓存。",[15,244,245],{"id":245},"什么时候换服务器有用",[11,247,248],{},"三种情况：CPU 长期打满、单机磁盘 IO 成为瓶颈、用户和机房跨地域。",[11,250,251],{},"跨地域这条最容易被忽略。服务器在美西、用户在国内，TCP 和 TLS 的往返就有 300 毫秒起步，换更贵的机器也没用，得加节点或者用 CDN。",[15,253,254],{"id":254},"一次真实的拆段",[11,256,257],{},"2026 年 4 月我们给一个文档站拆 TTFB，总时长 1.2 秒：DNS 180 毫秒、TCP 220、TLS 260、后端 480。前三段加起来 660 毫秒，比后端还多。",[11,259,260],{},"换了 DNS 服务商、把 TLS 升到 1.3、加了一个国内节点之后，前三段降到 210 毫秒。后端一行代码没改，TTFB 变成 690 毫秒。",[11,262,263],{},"这件事的教训很直接：网络层和后端层要分开算账，不然会误以为要重写服务。",[15,265,266],{"id":266},"一个判断标准",[11,268,269],{},"TTFB 800 毫秒是我们的分界线。低于这个数，先把 LCP 里的图片和渲染问题解决；高于这个数，先拆时间，别急着动代码。",[11,271,272],{},"拆完你会发现，真正需要改代码的情况不到一半，大多数是网络路径和缓存策略的问题。这两件事改起来比重构便宜得多。",{"title":71,"searchDepth":72,"depth":72,"links":274},[275,276,277,278,279,280,281],{"id":199,"depth":72,"text":200},{"id":212,"depth":72,"text":212},{"id":224,"depth":72,"text":224},{"id":236,"depth":72,"text":236},{"id":245,"depth":72,"text":245},{"id":254,"depth":72,"text":254},{"id":266,"depth":72,"text":266},"2026-05-14","TTFB 由五段组成，换服务器只解决其中一段。这篇写怎么用 curl 把五段时间拆开、后端慢的三种典型情况，以及什么情况下换机器才有用。",{},"\u002Fblog\u002Fttfb-diagnosis-steps",{"title":191,"description":283},"blog\u002Fttfb-diagnosis-steps",[289,290,291],"TTFB","服务器","页面体验","-mW0Tyot_vRvlXA9tFYpYcDh2gcp50w8k5XAdKCuP8o",1794088106007]