[{"data":1,"prerenderedAt":318},["ShallowReactive",2],{"blog-hreflang-config-three-checks":3,"blog-prev-hreflang-config-three-checks":150,"blog-next-hreflang-config-three-checks":225},{"id":4,"title":5,"author":6,"body":7,"canonical":134,"category":135,"cover":134,"date":136,"description":137,"draft":138,"extension":139,"keywords":134,"meta":140,"navigation":141,"noindex":138,"ogImage":134,"path":142,"seo":143,"seoDescription":134,"seoTitle":134,"stem":144,"tags":145,"updated":134,"__hash__":149},"blog\u002Fblog\u002Fhreflang-config-three-checks.md","hreflang 配错比不配更糟，三个必查点","元析智能",{"type":8,"value":9,"toc":123},"minimark",[10,14,19,31,35,42,46,89,93,96,99,102,105,108,111,114,117,120],[11,12,13],"p",{},"hreflang 的作用是告诉搜索引擎：这几个页面是同一内容的不同语言版本，请按用户的语言和地区展示对应的那个。配错的后果不是报错，而是本该给中文用户看的页面展示了英文版，或者两个版本互相抢排名，哪边都上不去。",[15,16,18],"h2",{"id":17},"必查点一自引用","必查点一：自引用",[11,20,21,22,26,27,30],{},"每个语言版本都要把自己的 hreflang 写进列表。只写\"另一个版本\"是最高频的错，蜘蛛看到不完整的组，会直接忽略整组标记。比如中文页写 ",[23,24,25],"code",{},"hreflang=\"en\""," 指英文页，英文页写 ",[23,28,29],{},"hreflang=\"zh-Hans\""," 指中文页，两页都没写自己——这组等于没配。",[15,32,34],{"id":33},"必查点二x-default","必查点二：x-default",[11,36,37,38,41],{},"没有匹配到语言时展示哪个版本，就靠 ",[23,39,40],{},"hreflang=\"x-default\"","。多语言站常漏这条，结果俄罗斯用户搜到的是中文页。x-default 一般指向英文版，或者一个语言选择页。",[15,43,45],{"id":44},"必查点三语言和地区代码","必查点三：语言和地区代码",[11,47,48,51,52,51,55,51,58,51,61,64,65,68,69,72,73,76,77,80,81,84,85,88],{},[23,49,50],{},"zh-Hans","、",[23,53,54],{},"zh-Hant",[23,56,57],{},"en",[23,59,60],{},"en-US",[23,62,63],{},"pt-BR","，写错一个字母整组失效。常见错误：",[23,66,67],{},"zh-CN"," 和 ",[23,70,71],{},"zh"," 混用、",[23,74,75],{},"en-UK","（正确是 ",[23,78,79],{},"en-GB","）、把地区当语言（",[23,82,83],{},"jp"," 不是语言代码，日语是 ",[23,86,87],{},"ja","）。",[15,90,92],{"id":91},"_2025-年-9-月那次修正","2025 年 9 月那次修正",[11,94,95],{},"一个开发者工具站做中英双语，hreflang 用插件自动生成。查下来模板变量反了：英文页标着指向中文页，中文页指向自己，x-default 完全没有。三个月里英文关键词的搜索结果展示的是中文页，跳出率 78%。修正后第 5 周，英文版的点击率从 2.1% 提到 5.6%。",[15,97,98],{"id":98},"怎么验证",[11,100,101],{},"Screaming Frog 的 hreflang 报告能一次看全站的互相指向关系，重点看两个指标：有没有指向 404 或重定向页、有没有缺回指。再人工抽 10 个页面看源码，确认 HTML head 里的 link 标签和页面语言一致。",[11,103,104],{},"Google 官方没有专门的 hreflang 报错报告，配错了不会提醒你，只能自己查。百度对 hreflang 的支持有限，中文站之间别指望它。",[15,106,107],{"id":107},"我们最常纠正的一种组合错",[11,109,110],{},"把 canonical 和 hreflang 搅在一起。有人觉得\"英文页是主版本\"，就让中文页的 canonical 指向英文页——这在多语言站里是灾难。中文用户搜到中文页，蜘蛛按 canonical 把它归并到英文页，中文页永远不单独排名。正确做法：canonical 指向同语言版本自己，语言关系交给 hreflang。",[11,112,113],{},"我们还有一个习惯，hreflang 上线前在测试环境把整组关系导成表格核对一遍，左边放页面、右边放它应该指向的四个语言版本，缺哪个补哪个。比上线后在源码里找错快得多。",[15,115,116],{"id":116},"两个判断",[11,118,119],{},"只有两个语言版本、内容量不大的站，hreflang 的收益有限，先把两边的页面内容做扎实。五个以上语言版本、每个版本几百页的站，hreflang 是必需品，而且要进发布流程，新增页面时自动带上。",[11,121,122],{},"最后一条：canonical 指向同语言版本的自己，不要跨语言指。canonical 和 hreflang 管的是两件事，混用会让蜘蛛不知道你到底想要哪个版本。",{"title":124,"searchDepth":125,"depth":125,"links":126},"",2,[127,128,129,130,131,132,133],{"id":17,"depth":125,"text":18},{"id":33,"depth":125,"text":34},{"id":44,"depth":125,"text":45},{"id":91,"depth":125,"text":92},{"id":98,"depth":125,"text":98},{"id":107,"depth":125,"text":107},{"id":116,"depth":125,"text":116},null,"技术SEO","2025-11-08","hreflang 不是翻译插件自动生成就完事。我们查过 20 多个多语言软件站，最常见的错是缺自引用、缺 x-default、语言代码写错。这篇给三个必查点和一份验证方法。",false,"md",{},true,"\u002Fblog\u002Fhreflang-config-three-checks",{"title":5,"description":137},"blog\u002Fhreflang-config-three-checks",[146,147,148],"hreflang","多语言","国际化","Sr63tcEPE0GveohvCkh6ZTTxZLW6WF8Xhsl4ZjFZOkU",{"id":151,"title":152,"author":6,"body":153,"canonical":134,"category":213,"cover":134,"date":214,"description":215,"draft":138,"extension":139,"keywords":134,"meta":216,"navigation":141,"noindex":138,"ogImage":134,"path":217,"seo":218,"seoDescription":134,"seoTitle":134,"stem":219,"tags":220,"updated":134,"__hash__":224},"blog\u002Fblog\u002Fkeyword-difficulty-not-schedule.md","关键词难度分不能当排期依据，它只算了一半",{"type":8,"value":154,"toc":206},[155,158,161,164,167,170,173,176,179,182,185,188,191,194,197,200,203],[11,156,157],{},"2025 年 9 月我们按关键词难度分排了一个季度的内容计划，12 篇稿子三个月后只有 3 篇进到前 20 名。问题不在写得好不好，而在难度分没算两件事：你的站有多重，以及这个词的搜索结果页长什么样。",[15,159,160],{"id":160},"难度分是怎么算出来的",[11,162,163],{},"Ahrefs 的 KD 主要看排在前十的页面有多少引用域名、这些域名的强度，加上 SERP 的整体竞争度。它是拿全球索引算的，对中文词、对 B2B 软件这种小搜索量的词，参考价值很低。一个词在全球索引里没什么数据，分数可能显示为低难度，你一头扎进去，发现前十全是厂商官网和行业媒体。",[11,165,166],{},"Semrush 的难度分同理，两家算法不同，但都不认识你的站。同样一个 KD 20 的词，新站做三个月进不了前 50，老站一周就能上。",[15,168,169],{"id":169},"被漏掉的三件事",[11,171,172],{},"第一，你站的权重。新站和老站做同一个词的难度完全不是一回事，这个差距比 KD 从 20 到 40 的差距还大。",[11,174,175],{},"第二，SERP 的结果类型。搜一个词，如果前十里有 4 个是文档页、3 个是问答站，说明搜索引擎认为这类内容能解决问题；如果前十里 8 个是商品页和价格页，你写一篇教程排不上去，因为意图不对。",[11,177,178],{},"第三，有没有非官网位置。前十要是被厂商官网包圆了，说明这个词是导航型需求，做内容很难挤进去。前十里有独立博客、论坛帖、对比站，才说明有内容空间。",[15,180,181],{"id":181},"我们现在的评估法",[11,183,184],{},"拿到一个词，先手动搜一次，把前十名按类型记账：官网几个、文档站几个、博客几个、点评站几个、论坛几个。再按目标域名的 DR 估一个外链缺口，我们通常用 20 到 40 这个区间判断需不需要外部推动。",[11,186,187],{},"然后给这个词写一句判断：三个月内能不能进 20 名，理由是什么。这句话必须写，写不出来就说明还没想清楚，别排进计划。",[15,189,190],{"id":190},"排期规则",[11,192,193],{},"难词不排第一季。第一个月先做能进前 20 的词，把点击和转化拿到，同时给站积累主题相关性。中难度的词排第二、三个月，一个季度最多排 4 到 5 个中难词，多了做不完。",[15,195,196],{"id":196},"一个具体的例子",[11,198,199],{},"2025 年 10 月我们评估「API 监控工具」这个词，Ahrefs 给的 KD 是 31，看起来中等。手动搜一遍，前十里有 5 个厂商官网、2 个点评站、2 篇独立博客、1 个 Reddit 帖。厂商官网占了半数，说明商业意图很强，独立博客能进去说明内容有空间。我们把它排在第三个月，先写了 3 篇接入教程铺垫，最后才打这个词。",[11,201,202],{},"另一个词 KD 只有 12，搜出来前十全是知乎问答和文库。这种词不难，但排上去也带不来注册，用户看完回答就走了。我们直接没做。",[11,204,205],{},"还有一条：别一次性排 20 个 TOD 1 级别的词。排期表上看起来很充实，执行时每个都做一半，一个都上不去。我们现在的规矩是一个季度只设 3 个主攻词，其余都是辅助。",{"title":124,"searchDepth":125,"depth":125,"links":207},[208,209,210,211,212],{"id":160,"depth":125,"text":160},{"id":169,"depth":125,"text":169},{"id":181,"depth":125,"text":181},{"id":190,"depth":125,"text":190},{"id":196,"depth":125,"text":196},"SEO","2025-11-07","我们按 KD 排过一个季度的内容计划，12 篇只上去 3 篇。难度分没算站点权重、没有算 SERP 结果类型。这篇写我们改用的评估法和排期规则。",{},"\u002Fblog\u002Fkeyword-difficulty-not-schedule",{"title":152,"description":215},"blog\u002Fkeyword-difficulty-not-schedule",[221,222,223],"关键词难度","内容排期","SERP分析","fh1lZe-rqSKy5ZwulWZwvyVKgWSDR3q1pzAj23AiYuQ",{"id":226,"title":227,"author":6,"body":228,"canonical":134,"category":135,"cover":134,"date":307,"description":308,"draft":138,"extension":139,"keywords":134,"meta":309,"navigation":141,"noindex":138,"ogImage":134,"path":310,"seo":311,"seoDescription":134,"seoTitle":134,"stem":312,"tags":313,"updated":134,"__hash__":317},"blog\u002Fblog\u002Fcls-real-causes.md","CLS 高不一定是图片没尺寸，我们查到的四类真凶",{"type":8,"value":229,"toc":298},[230,233,236,239,242,245,248,251,254,257,260,263,267,270,274,277,280,283,286,289,292,295],[11,231,232],{},"CLS 高，很多人第一反应是图片没写宽高。这个原因确实存在，但在我们今年查的 14 个软件站里，它不是主因：CLS 超过 0.25 的 5 个站，有 4 个的真凶是字体切换和动态插入的组件。图片没尺寸只占 1 个，而且那个站的 CLS 只有 0.18。",[11,234,235],{},"先把概念说清楚。CLS 是 Cumulative Layout Shift，衡量页面元素在加载过程中意外移动的幅度，0.1 以下算好，0.25 以上算差。注意\"意外\"两个字：用户点击后展开的内容不算，只有没人操作时自己跳的才计分。",[15,237,238],{"id":238},"字体切换导致的位移",[11,240,241],{},"中文站高发。回退字体和自定义字体的字宽不一样，字体一到位，整段文字重新换行，下面的内容全部移动。这种位移往往发生在首屏正文，分值很高。",[11,243,244],{},"一个做低代码平台的公司，CLS 0.29。移动端 h1 加两行副标题，字体到位后标题从两行变三行，下面按钮下移 48 像素。改法是把字体子集化和预加载做好，再用 size-adjust 校准回退字体的字宽，字号和行高都写死。",[15,246,247],{"id":247},"动态插入的组件",[11,249,250],{},"AB 测试、营销横幅、cookie 提示，这些组件在 JS 执行后往 DOM 里插东西，插在页面顶部就整页下移。",[11,252,253],{},"一个数据工具站的 CLS 是 0.31，查下来是 AB 测试脚本给导航条多加了一个\"免费试用\"按钮，导航从一行变两行，整页下移 64 像素。这种位移最隐蔽，因为产品经理认为那只是换了个版本。",[15,255,256],{"id":256},"懒加载内容的位置",[11,258,259],{},"用户往下读，上面的图片才开始加载，加载完撑开高度，把正在读的段落顶走。这种位移最招人烦，因为它发生在阅读过程中，而不是页面刚打开的时候。",[11,261,262],{},"改法是给懒加载的图片和广告位预留高度，或者用 content-visibility 配合 intrinsic size。",[15,264,266],{"id":265},"图片和-iframe-没尺寸","图片和 iframe 没尺寸",[11,268,269],{},"这个原因还在，主要是 iframe 和嵌入视频。img 现在大部分框架会带 width\u002Fheight，但第三方 iframe（地图、演示视频、客服）经常没有。",[15,271,273],{"id":272},"第五类单页应用的路由切换","第五类：单页应用的路由切换",[11,275,276],{},"这一点常被忽略。SPA 切换路由时，如果新页面先渲染一个空容器再填内容，或者旧页面在数据回来前先清空，中间会有一段时间页面高度不对，浏览器就记一次位移。文档站、控制台这类站高发。",[11,278,279],{},"查法是录一段站内跳转的 Performance，看路由切换后有没有连续两次布局变化。改法是用路由级的骨架屏，并且保证骨架和真实内容高度一致。",[15,281,282],{"id":282},"为什么中文站更容易中招",[11,284,285],{},"三条原因叠在一起：中文字体文件大、回退字体和自定义字体的字宽差异明显、正文行数多。同样一处字体切换，英文站位移 20 像素，中文站可能整段重排、位移 100 像素以上。",[11,287,288],{},"我们给中文站排优先级时，字体相关的位移永远排第一。先把字体加载路径修好，再去看图片和组件，顺序反过来会白干。",[15,290,291],{"id":291},"查法",[11,293,294],{},"Lighthouse 的 CLS 归因会给到具体元素，Chrome Performance 面板的 Experience 轨道能录到每一次位移和它的来源，真实用户数据那边用 web-vitals 库能拿到 largest shift 的元素。",[11,296,297],{},"我们一般先修移动端，因为移动端 CLS 通常是桌面端的两倍。修的顺序按\"移动端面积最大的一次位移\"来，不要按 Lighthouse 列出的顺序，前者是用户真正看到的，后者只是权重排序。",{"title":124,"searchDepth":125,"depth":125,"links":299},[300,301,302,303,304,305,306],{"id":238,"depth":125,"text":238},{"id":247,"depth":125,"text":247},{"id":256,"depth":125,"text":256},{"id":265,"depth":125,"text":266},{"id":272,"depth":125,"text":273},{"id":282,"depth":125,"text":282},{"id":291,"depth":125,"text":291},"2025-11-09","今年查的 14 个软件站里，CLS 超 0.25 的 5 个有 4 个主因是字体切换和动态组件，图片没尺寸只占 1 个。四类真凶按实际占比排序，附上每类的查法。",{},"\u002Fblog\u002Fcls-real-causes",{"title":227,"description":308},"blog\u002Fcls-real-causes",[314,315,316],"CLS","布局偏移","前端性能","5KIVOlLHlXCt8Pe7xtOlTgVHSUszsTJiPyIRnyvE6UQ",1794088111017]