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