[{"data":1,"prerenderedAt":414},["ShallowReactive",2],{"blog-merge-similar-posts-301":3,"blog-prev-merge-similar-posts-301":130,"blog-next-merge-similar-posts-301":226},{"id":4,"title":5,"author":6,"body":7,"canonical":114,"category":115,"cover":114,"date":116,"description":117,"draft":118,"extension":119,"keywords":114,"meta":120,"navigation":121,"noindex":118,"ogImage":114,"path":122,"seo":123,"seoDescription":114,"seoTitle":114,"stem":124,"tags":125,"updated":114,"__hash__":129},"blog\u002Fblog\u002Fmerge-similar-posts-301.md","两篇相似文章合并，301 该怎么做才不漏权重","元析智能",{"type":8,"value":9,"toc":101},"minimark",[10,14,18,21,24,27,30,33,36,39,42,45,48,52,55,58,62,65,68,71,74,77,80,83,86,89,92,95,98],[11,12,13],"p",{},"两篇内容高度重叠的文章，留着等于自己跟自己抢。合并是对的，但 301 做错一次就能把两个页面的权重一起弄丢。2025 年 12 月我们合并过一对文章，第一次 301 指向了分类页，第一周流量掉了 40%，改回来之后第二周才恢复。",[15,16,17],"h2",{"id":17},"先判断该不该并",[11,19,20],{},"两个页面打同一个核心词，或者解决的是同一个待办，就该并。",[11,22,23],{},"但如果两篇都还有排名、外链都不少，合并风险很大。这种情况先观察，把其中一篇改成更细的角度，别急着动。",[15,25,26],{"id":26},"主文选谁",[11,28,29],{},"看外链数和现有排名，不看发布新旧。老文外链多、排名稳，就该当主文，把新内容并进去。",[11,31,32],{},"2025 年 12 月那次，主文是一篇 2023 年的老文，外链 14 个，另一篇是 2024 年新写的，外链 1 个。选了老的，虽然内容旧，但权重在。",[15,34,35],{"id":35},"操作顺序",[11,37,38],{},"第一步，把主文内容补齐，覆盖次文所有有价值的信息点。这一步没做完，不要动 301。",[11,40,41],{},"第二步，次文正文顶部加一行提示，链到主文，挂两周。让搜索引擎和用户都先看到关系。",[11,43,44],{},"第三步，做 301，指向主文的完整 URL，不带参数。",[11,46,47],{},"第四步，把站内指向次文的内链全部换成主文。这步最容易被漏，漏了之后次文还会被反复抓取。",[15,49,51],{"id":50},"_301-指向哪","301 指向哪",[11,53,54],{},"指向主文，别指首页，别指分类页，也别指 404。",[11,56,57],{},"指向首页是懒办法，等于告诉搜索引擎这个页面的权重给全站，不给具体内容。我们那次就是图省事指了分类页，结果那个分类页跟内容不相关，权重等于白给。",[15,59,61],{"id":60},"三篇并一篇别新写","三篇并一篇，别新写",[11,63,64],{},"如果两个页面内容都一般，有人会想“新写一篇更好的，把两篇都 301 过去”。这个做法听起来干净，实际上三篇的权重都归零。",[11,66,67],{},"正确做法是从两篇里选一篇当主文，改到足够好。",[15,69,70],{"id":70},"怎么验证并对了",[11,72,73],{},"合并后第 28 天，看主文的关键词覆盖数，应该接近两篇原来覆盖的合并值，能到 70% 就算成功。",[15,75,76],{"id":76},"内链要一起改",[11,78,79],{},"站内指向次文的链接，在 301 之后会跳到主文，但锚文本还写着次文的主题。这些锚文本本身指向性很强，不改等于浪费。",[11,81,82],{},"我们的做法是合并后一周内，把次文的内链锚文本统一改成主文的核心词，改不完的先记进清单。",[15,84,85],{"id":85},"合并之后要不要重写主文",[11,87,88],{},"要。合并的本质是把两个页面的信息合到一个页面，主文必须比原来任何一篇都完整。",[11,90,91],{},"我们一般会给主文加两到三个小节，把次文里独有的例子、数据、问答搬进去。搬完之后字数通常比原来多 40%。",[15,93,94],{"id":94},"别做的三件事",[11,96,97],{},"别把 301 指向首页。别在两篇之外新写第三篇当主文。别在合并当天同时改 URL 结构，两个变量一起动，出问题查不出来。",[11,99,100],{},"排名先掉后回是正常的，通常两到四周。四周后还持续下滑，检查内链和 301 有没有漏。",{"title":102,"searchDepth":103,"depth":103,"links":104},"",2,[105,106,107,108,109,110,111,112,113],{"id":17,"depth":103,"text":17},{"id":26,"depth":103,"text":26},{"id":35,"depth":103,"text":35},{"id":50,"depth":103,"text":51},{"id":60,"depth":103,"text":61},{"id":70,"depth":103,"text":70},{"id":76,"depth":103,"text":76},{"id":85,"depth":103,"text":85},{"id":94,"depth":103,"text":94},null,"内容运营","2026-01-31","合并文章最贵的错误是把 301 指向首页。我们合并过一次，第一周流量掉了 40%，第二周才回来。这篇写清判断标准、主文选择、301 顺序和验证方法。",false,"md",{},true,"\u002Fblog\u002Fmerge-similar-posts-301",{"title":5,"description":117},"blog\u002Fmerge-similar-posts-301",[126,127,128],"内容合并","301重定向","内容审计","MmSL8CjCnZRWIojDyBSiRCwgm1pI_f8aYENgguGRAks",{"id":131,"title":132,"author":6,"body":133,"canonical":114,"category":214,"cover":114,"date":215,"description":216,"draft":118,"extension":119,"keywords":114,"meta":217,"navigation":121,"noindex":118,"ogImage":114,"path":218,"seo":219,"seoDescription":114,"seoTitle":114,"stem":220,"tags":221,"updated":114,"__hash__":225},"blog\u002Fblog\u002Flazy-loading-placement.md","懒加载不是越多越好，首屏和折叠线要分开处理",{"type":8,"value":134,"toc":206},[135,143,146,149,152,155,158,164,168,171,178,182,185,188,191,194,197,200,203],[11,136,137,138,142],{},"懒加载不是越多越好。今年 1 月我们给一个文档站做首屏优化，把三张首屏图的 ",[139,140,141],"code",{},"loading=\"lazy\""," 去掉，LCP 从 2.9 秒降到 2.0 秒。同一个页面，代码只删了三个属性。",[15,144,145],{"id":145},"首屏一律不用懒加载",[11,147,148],{},"原理不复杂：懒加载让浏览器把图片下载推迟到布局计算之后，首屏图本来最该先下载，结果排在最后。移动端这一步的代价是 300 到 600 毫秒。",[11,150,151],{},"判断首屏别靠感觉。用 375×667 的视口截图，能看到的都算。注意边界会随设备变化，iPhone SE 和 iPhone 15 Pro Max 差了两屏，我们按最小视口来定\"必须立即加载\"的范围。",[15,153,154],{"id":154},"折叠线附近要提前加载",[11,156,157],{},"第二类错误是等进了视口才加载。用户往下滚 200 像素图片才开始下载，等待感很明显。",[11,159,160,161,163],{},"做法是 ",[139,162,141],{}," 加 IntersectionObserver 的 rootMargin，提前 300 到 500 像素开始加载。这个文档站的侧边目录有 12 张缩略图，原来滚到才加载，滚快了会看到空白。加 400 像素预载后，滚动过程里再没出现空位。",[15,165,167],{"id":166},"iframe-要单独处理","iframe 要单独处理",[11,169,170],{},"第三类错误是把视频、地图、客服 iframe 都设成 lazy。副作用是用户点击播放时才开始加载播放器，第一次点击要等 1 到 2 秒，这个延迟会被记进 INP。",[11,172,173,174,177],{},"做法是首屏 iframe 用 ",[139,175,176],{},"srcdoc"," 放一个静态封面，点击后再换 src。既省了首屏体积，又不让点击变慢。",[15,179,181],{"id":180},"和图片-cdn-的配合","和图片 CDN 的配合",[11,183,184],{},"用图片 CDN 的站要注意参数别打架。CDN 按 URL 生成不同尺寸，懒加载按视口决定何时请求，两边都配错会出现\"小图被放大\"或者\"下载了 2000 像素宽的图放进 300 像素的框\"。",[11,186,187],{},"我们的做法是让 CSS 和 HTML 的 sizes 声明对齐，再由 CDN 按 UA 和 DPR 返回合适尺寸。这个文档站改完后，移动端图片平均体积从 180KB 降到 62KB，首屏三张图的请求时间提前了 400 毫秒。",[15,189,190],{"id":190},"一个反例",[11,192,193],{},"我们也见过相反的站：所有图立即加载，一个文档页 40 张截图，首屏请求 6MB。这种站要做的是分页或者折叠，而不是调懒加载参数。真正的浪费不是\"懒加载太少\"，是\"内容一次性全给\"。",[11,195,196],{},"所以正确用法就三句：首屏立即加载，折叠线下提前加载，非内容型 iframe 延迟到交互。这三句能覆盖九成情况。",[15,198,199],{"id":199},"怎么验收",[11,201,202],{},"改完别只看 Lighthouse 分数，看网络面板里首屏图片的加载顺序和开始时间。首屏图的开始时间应该排在前三个请求里，如果不是，说明有别的东西在抢带宽，先解决抢的那个。",[11,204,205],{},"这个站我们改完复查了三次，第一次首屏图还是排在第 6 位，原因是字体 CSS 阻塞了 HTML 解析。把字体改成 preload 之后，顺序才真正提上来。",{"title":102,"searchDepth":103,"depth":103,"links":207},[208,209,210,211,212,213],{"id":145,"depth":103,"text":145},{"id":154,"depth":103,"text":154},{"id":166,"depth":103,"text":167},{"id":180,"depth":103,"text":181},{"id":190,"depth":103,"text":190},{"id":199,"depth":103,"text":199},"技术SEO","2026-01-30","删掉三张首屏图的 loading=\"lazy\"，LCP 从 2.9 秒降到 2.0 秒。首屏立即加载、折叠线下提前 400 像素预载、视频 iframe 等点击再加载，三句话覆盖九成情况。",{},"\u002Fblog\u002Flazy-loading-placement",{"title":132,"description":216},"blog\u002Flazy-loading-placement",[222,223,224],"懒加载","首屏优化","LCP","UriQnTMflLup-QaZVe4nVs8Od7HU_wt9n3MUoWOLdLA",{"id":227,"title":228,"author":6,"body":229,"canonical":114,"category":402,"cover":114,"date":403,"description":404,"draft":118,"extension":119,"keywords":114,"meta":405,"navigation":121,"noindex":118,"ogImage":114,"path":406,"seo":407,"seoDescription":114,"seoTitle":114,"stem":408,"tags":409,"updated":114,"__hash__":413},"blog\u002Fblog\u002Fconversational-query-rewrite.md","对话式查询改写：12 个关键词扩成 68 个整句问题",{"type":8,"value":230,"toc":394},[231,234,237,240,243,246,249,252,271,274,277,280,348,351,355,358,361,364,367,370,373,376,379,382,385,388,391],[11,232,233],{},"关键词是搜索框逼出来的产物，AI 搜索收的是整句话。2026 年 2 月我们把一个客户的 12 个核心关键词按四问法改写，得到 68 个整句问题，其中 57 个现有页面答不了。这个缺口就是接下来半年的选题表。",[15,235,236],{"id":236},"关键词和问题的差别",[11,238,239],{},"\"日志分析工具\"是关键词。它没有主语、没有场景、没有约束。",[11,241,242],{},"\"我们是 30 人的 SaaS 团队，每天 200G 日志，预算有限，用哪家日志分析合适\"是问题。这句里包含了规模、数据量、预算三个筛选条件，AI 要答它，必须找同时覆盖这三点的内容。",[11,244,245],{},"关键词只能覆盖品类，问题才能覆盖决策。",[15,247,248],{"id":248},"四问法",[11,250,251],{},"一个关键词拆四个方向：",[11,253,254,258,259,262,263,266,267,270],{},[255,256,257],"strong",{},"谁在问。"," 团队规模、角色、行业。\n",[255,260,261],{},"什么场景。"," 迁移、扩容、排障、合规审计。\n",[255,264,265],{},"担心什么。"," 成本、锁定、迁移难度、能不能私有部署。\n",[255,268,269],{},"要什么结果。"," 降本、过审、缩短排障时间。",[11,272,273],{},"四个方向各出 1 到 2 个问法，一个词能出 4 到 6 句。12 个词出 68 句，符合预期。",[15,275,276],{"id":276},"一个词的改写示例",[11,278,279],{},"从\"日志分析工具\"出发：",[281,282,283,296],"table",{},[284,285,286],"thead",{},[287,288,289,293],"tr",{},[290,291,292],"th",{},"类型",[290,294,295],{},"改写后的问法",[297,298,299,308,316,324,332,340],"tbody",{},[287,300,301,305],{},[302,303,304],"td",{},"规模",[302,306,307],{},"30 人团队用哪家日志分析工具合适",[287,309,310,313],{},[302,311,312],{},"场景",[302,314,315],{},"从 ELK 迁到别的日志平台要注意什么",[287,317,318,321],{},[302,319,320],{},"担心",[302,322,323],{},"日志分析工具按量计费还是按节点计费",[287,325,326,329],{},[302,327,328],{},"结果",[302,330,331],{},"怎么把排障时间从 2 小时压到 10 分钟",[287,333,334,337],{},[302,335,336],{},"对比",[302,338,339],{},"日志分析和可观测平台是一回事吗",[287,341,342,345],{},[302,343,344],{},"边界",[302,346,347],{},"私有部署的日志分析工具有哪些",[11,349,350],{},"这 6 句都能写成一篇文章，而且互不重复。原来那个关键词只能写一篇。",[15,352,354],{"id":353},"_57-个缺口的分布","57 个缺口的分布",[11,356,357],{},"我们把 68 句逐条对照现有页面，能答的 11 句，答不了的 57 句。",[11,359,360],{},"缺口集中在三块：计费与成本 14 句、迁移与兼容 12 句、团队规模与选型 11 句。这三块恰好都是销售在电话里反复解释的内容。",[11,362,363],{},"有意思的是，客户自己写过 4 篇\"行业趋势\"，一句缺口都没填上。趋势文带来的是品牌感，不是答案。",[15,365,366],{"id":366},"怎么排优先级",[11,368,369],{},"三个筛子过一遍：",[11,371,372],{},"能不能被回答成一句话？能，优先。需要三千字才能说清的，往后放。",[11,374,375],{},"销售会不会被问到？会，优先。让销售把最近 20 通电话里被问的问题写下来，比任何工具准。",[11,377,378],{},"竞品有没有写？没写，机会大；写了但写得差，机会更大。",[11,380,381],{},"排完，57 句里能立刻动手的 18 句。这 18 句做完，够撑三个月。",[15,383,384],{"id":384},"别把它当关键词工具用",[11,386,387],{},"这套改写的产出不是关键词列表，是问题清单。问题清单要能直接拿去问 AI，测出来它现在怎么答、引了谁。",[11,389,390],{},"拿 68 句去跑 4 个引擎，你会看到一张很有意思的图：哪些问题已经有答案但答案里没你，哪些问题压根没有像样的答案。前者改内容，后者抢首发。",[11,392,393],{},"改写这一步只花两小时，值。",{"title":102,"searchDepth":103,"depth":103,"links":395},[396,397,398,399,400,401],{"id":236,"depth":103,"text":236},{"id":248,"depth":103,"text":248},{"id":276,"depth":103,"text":276},{"id":353,"depth":103,"text":354},{"id":366,"depth":103,"text":366},{"id":384,"depth":103,"text":384},"GEO","2026-02-01","关键词是搜索框的产物，AI 搜索收的是整句。把 12 个核心词按四问法改写，得到 68 个真实问法，其中 57 个现有页面答不了。改写表可以直接抄。",{},"\u002Fblog\u002Fconversational-query-rewrite",{"title":228,"description":404},"blog\u002Fconversational-query-rewrite",[410,411,402,412],"对话式查询","关键词","内容规划","AmKjOdYlyiHFqI2VNr3NdeEp6N4HTGLXNm8Me-uwiIE",1794088108764]