[{"data":1,"prerenderedAt":316},["ShallowReactive",2],{"blog-diagnosis-conversion-path":3,"blog-prev-diagnosis-conversion-path":116,"blog-next-diagnosis-conversion-path":217},{"id":4,"title":5,"author":6,"body":7,"canonical":100,"category":101,"cover":100,"date":102,"description":103,"draft":104,"extension":105,"keywords":100,"meta":106,"navigation":107,"noindex":104,"ogImage":100,"path":108,"seo":109,"seoDescription":100,"seoTitle":100,"stem":110,"tags":111,"updated":100,"__hash__":115},"blog\u002Fblog\u002Fdiagnosis-conversion-path.md","诊断最容易漏的一块，是转化路径这一环","元析智能",{"type":8,"value":9,"toc":90},"minimark",[10,14,18,21,24,27,30,33,36,39,42,45,48,51,54,57,60,63,66,69,72,75,78,81,84,87],[11,12,13],"p",{},"2026 年 6 月我们诊断一个 SaaS 站，技术没问题、收录正常、一批词排在前 20，但自然流量带来的留资一个月只有个位数。查到最后是转化路径的问题：40 个有自然流量的页面里，只有 3 个有明确的转化入口。",[15,16,17],"h2",{"id":17},"为什么会漏掉",[11,19,20],{},"因为大部分人查的是关键词和排名，看的是流量从哪来，很少看流量进来之后发生了什么。",[11,22,23],{},"GSC 只给曝光和点击，转化数据在 GA4 或者业务系统里。两边不在一个界面上，很容易只查一边。",[11,25,26],{},"还有一个原因：转化路径涉及产品、设计、开发，不属于 SEO 的职责范围。做 SEO 的人默认这块不归自己管。",[15,28,29],{"id":29},"怎么查",[11,31,32],{},"第一步，拉出有自然流量的落地页，按流量排序，取前 20 个。",[11,34,35],{},"第二步，逐个打开，问三个问题：这页有没有告诉用户下一步做什么、这个动作在不在首屏附近、点了之后要填几个字段。",[11,37,38],{},"第三步，在 GA4 里看这 20 个页面的转化事件，看哪些有、哪些完全没有埋点。",[11,40,41],{},"第四步，走一遍真实流程，用手机走，别用电脑。移动端的表单体验经常是灾难。",[11,43,44],{},"第五步，算一个数：自然流量到留资的转化率。软件行业通常低得超出预期，个位数很常见。",[15,46,47],{"id":47},"常见的四种断裂",[11,49,50],{},"页面没有 CTA。文档页、博客文章看完就结束了，没有“预约演示”或者“免费试用”的入口。",[11,52,53],{},"CTA 只在页面底部。文档页动辄几千字，用户看到一半想试用，得滚到底。",[11,55,56],{},"表单字段太多。要填公司名、职位、电话、需求描述，七项起步，填完意愿也没了。",[11,58,59],{},"移动端按钮被遮。浮层、cookie 提示、客服气泡叠在一起，按钮点不到。",[15,61,62],{"id":62},"修的顺序",[11,64,65],{},"先修流量最大的 3 个页面，别一次改 20 个。改完两周看数据，有效果再推广。",[11,67,68],{},"每次只改一个变量。先加 CTA，再看表单字段能不能减。两个一起改，出了效果也不知道是哪个起的作用。",[11,70,71],{},"还有个低成本动作：在文章中间插一个轻量的转化入口，比如“想看完整的配置示例，留个邮箱”。这类软入口的转化率往往比底部按钮高。",[15,73,74],{"id":74},"转化路径要定期复查",[11,76,77],{},"上线不是结束。产品改版、表单换工具、CTA 位置调整，都会让路径断掉。我们每季度用同样的五个步骤查一次，成本一小时。",[11,79,80],{},"上个月复查发现一个页面的表单被开发临时下线，三周没人发现。这种事不会自己暴露，只能靠定期查。",[15,82,83],{"id":83},"我的立场",[11,85,86],{},"不做转化路径诊断的 SEO，等于只做了一半。排名上去了、流量进来了、用户走了，客户最后还是觉得没效果。",[11,88,89],{},"我们现在的诊断报告固定有一页讲转化，哪怕客户没要求。这一页经常是客户第一次意识到问题不在 SEO 而在承接页。",{"title":91,"searchDepth":92,"depth":92,"links":93},"",2,[94,95,96,97,98,99],{"id":17,"depth":92,"text":17},{"id":29,"depth":92,"text":29},{"id":47,"depth":92,"text":47},{"id":62,"depth":92,"text":62},{"id":74,"depth":92,"text":74},{"id":83,"depth":92,"text":83},null,"SEO","2026-05-31","40 个有自然流量的页面，只有 3 个有明确的转化入口。技术、收录、排名都查完了，流量进来了却没人留资，问题往往在这里，我们怎么查、先修哪几页都写在这。",false,"md",{},true,"\u002Fblog\u002Fdiagnosis-conversion-path",{"title":5,"description":103},"blog\u002Fdiagnosis-conversion-path",[112,113,114],"转化路径","站点诊断","落地页","dboMYkLSNSLFFkp575UnOIOKWIM83bFxrsf-UwZoCjw",{"id":117,"title":118,"author":6,"body":119,"canonical":100,"category":205,"cover":100,"date":206,"description":207,"draft":104,"extension":105,"keywords":100,"meta":208,"navigation":107,"noindex":104,"ogImage":100,"path":209,"seo":210,"seoDescription":100,"seoTitle":100,"stem":211,"tags":212,"updated":100,"__hash__":216},"blog\u002Fblog\u002Fsearch-engine-index-priority.md","六个搜索引擎的收录优先级，我们这么排",{"type":8,"value":120,"toc":197},[121,124,127,130,133,136,139,143,146,149,152,155,158,161,164,167,170,173,176,179,182,185,188,191,194],[11,122,123],{},"六个引擎不能平均用力。我们的收录优先级是 Google、Bing、百度、360、搜狗、神马和头条，理由不是流量大小，是抓取效率、收录确定性、流量价值的综合排序。",[15,125,126],{"id":126},"为什么是这个顺序",[11,128,129],{},"2025 年 8 月我们把两年来记的提交和收录数据拉齐，才排出这个顺序，不是拍脑袋。",[11,131,132],{},"排序看三个数：从提交到收录的平均天数、收录率、带来的有效访问。",[11,134,135],{},"Google：3 天、88%、最高。Bing：9 天、71%、中等。百度：5 天、64%、国内最高。360：12 天、43%、低。搜狗：16 天、38%、很低。神马头条：不确定，图文站接近零。",[11,137,138],{},"三个数综合下来，顺序就出来了。",[15,140,142],{"id":141},"google-和-bing-为什么在前","Google 和 Bing 为什么在前",[11,144,145],{},"这两家的抓取机制最透明：sitemap、IndexNow、日志都能看到细节，出了问题能定位。",[11,147,148],{},"Google 的日志里能看到抓取预算、响应码、渲染情况，Bing 的后台能看到发现和抓取的时间点。对技术团队来说，这两家最好调，改一处能看到反馈。",[11,150,151],{},"所以新站上线，先让 Google 和 Bing 收，验证技术配置没问题，再推给百度。顺序反了，百度那边出问题，你不知道是技术问题还是内容问题。",[15,153,154],{"id":154},"百度为什么排第三",[11,156,157],{},"不是不重要，是它最难。国内流量价值最高，但抓取最慢、门槛最多：备案、站点评价、内容审核，每一项都会卡住收录。",[11,159,160],{},"我们的做法是把百度放在技术验证之后，因为百度对技术问题的容忍度低——一个 JS 渲染问题，Google 能渲染，百度直接不收。先用 Google 把技术修干净，再提交百度，能少走弯路。",[15,162,163],{"id":163},"后面的四个",[11,165,166],{},"360 和搜狗适合顺手做，sitemap 加一次提交就够，不单独写内容。",[11,168,169],{},"神马和头条看品类：移动工具、C 端产品可以花点时间，To B 软件把基础适配做好就行。",[15,171,172],{"id":172},"一个例外",[11,174,175],{},"如果站点面向海外，Google 和 Bing 的顺序要换一下：先 Bing 后 Google。因为 Bing 对新站的收录门槛低，能更快验证技术配置，再用这个结果去调 Google 那边的日志。",[11,177,178],{},"反过来，面向国内的站，不要先提交百度。百度的审核周期长，一旦因为技术问题被卡，要等很久才能重新提交。先用 Google 把技术问题清掉，是更稳的做法。",[15,180,181],{"id":181},"我们的操作顺序",[11,183,184],{},"新站上线第一周：Google 提交 + Bing 提交 + IndexNow 接入。",[11,186,187],{},"第二周：看 Google 和 Bing 的收录和抓取日志，修技术问题。",[11,189,190],{},"第三周：百度提交 sitemap + 普通收录 API，同时提交 360 和搜狗。",[11,192,193],{},"一个月后：按收录数据决定要不要给神马、头条做适配。",[11,195,196],{},"这个顺序我们跑了两年，比\"六个引擎同时提交\"省至少两周排查时间，后面的工作都是顺的。",{"title":91,"searchDepth":92,"depth":92,"links":198},[199,200,201,202,203,204],{"id":126,"depth":92,"text":126},{"id":141,"depth":92,"text":142},{"id":154,"depth":92,"text":154},{"id":163,"depth":92,"text":163},{"id":172,"depth":92,"text":172},{"id":181,"depth":92,"text":181},"技术SEO","2026-05-30","六个引擎不能平均用力。我们的收录优先级是 Google、Bing、百度、360、搜狗、神马头条。理由不是流量大小，是抓取效率、收录确定性、流量价值的综合排序，附具体操作顺序，还有一个我们遇到的例外情况，照着排能省两周排查时间。",{},"\u002Fblog\u002Fsearch-engine-index-priority",{"title":118,"description":207},"blog\u002Fsearch-engine-index-priority",[213,214,215],"多引擎","收录","优先级","1WskdB2ZpAYXsWgHEoSrS4-kMO-qqft01Yt-yCzI6nw",{"id":218,"title":219,"author":6,"body":220,"canonical":100,"category":205,"cover":100,"date":305,"description":306,"draft":104,"extension":105,"keywords":100,"meta":307,"navigation":107,"noindex":104,"ogImage":100,"path":308,"seo":309,"seoDescription":100,"seoTitle":100,"stem":310,"tags":311,"updated":100,"__hash__":315},"blog\u002Fblog\u002Fhreflang-pipeline-validation.md","多语言站 hreflang 落地：从生成到校验的流程",{"type":8,"value":221,"toc":295},[222,225,228,231,234,237,240,253,261,265,268,271,274,277,280,283,286,289,292],[11,223,224],{},"hreflang 要工程化，别靠人工。页面超过 200 个，手写一定漏，而且漏了不会报错。我们现在的做法是生成器加校验脚本，接进发布流程，漏了就不让上线。",[15,226,227],{"id":227},"三种实现位置",[11,229,230],{},"HTML head 里的 link 标签、HTTP 响应头、sitemap 里的 xhtml:link。我们统一用 HTML head 加 sitemap 双写，两处必须一致，冲突时以 HTML 为准。非 HTML 资源（PDF 白皮书之类）才用响应头。",[15,232,233],{"id":233},"生成器怎么设计",[11,235,236],{},"输入是页面 ID、语言、地区、这个页面有哪些翻译版本，输出是每个语言版本页面上的完整 link 标签组。数据来自内容库里的翻译关联表，不是从 URL 字符串猜。这点很重要：URL 规则一改，猜出来的关系就全错了。",[15,238,239],{"id":239},"三条校验规则",[241,242,243,247,250],"ol",{},[244,245,246],"li",{},"每个页面必须包含自身语言的 hreflang，自引用不能缺。",[244,248,249],{},"A 指向 B，B 必须指向 A，双向关系。",[244,251,252],{},"一个语言组里 x-default 有且只有一个。",[11,254,255,256,260],{},"再加两条容错：指向的 URL 必须返回 200 且不是 noindex；语言代码必须在合法列表里，",[257,258,259],"code",{},"en-UK"," 这种拼错要拦住。",[15,262,264],{"id":263},"_2025-年-11-月那次接入","2025 年 11 月那次接入",[11,266,267],{},"一个出海 SaaS，14 个语言、8000 个翻译页面。原来人工维护 sitemap 里的 hreflang，抽查发现漏了 23%。接入生成器后，校验脚本全量跑一遍 8 分钟，一次通过；新增语言版本的上线时间从两天缩到半天。",[15,269,270],{"id":270},"发布流程",[11,272,273],{},"语言版本上线，生成器写入 hreflang，校验脚本跑，通过才允许发布。失败时输出具体页面和缺失的语言，直接给到开发。这套流程跑了一年多，没再出现过整组失效的问题。",[15,275,276],{"id":276},"校验脚本长什么样",[11,278,279],{},"输入是爬虫导出的全站 HTML，输出是三张表：缺自引用的页面、单向指向的页面、语言组合法但 URL 异常的页面。用 Python 加正则就能写，一百行以内。我们把它做成 CI 里的一步，每次构建失败会直接指出哪个页面、缺哪个语言，不用人去翻源码。",[15,281,282],{"id":282},"什么时候不值得做",[11,284,285],{},"只有两三个语言版本、每个版本页面不多的站，别上这套工程。HTML head 里手写一组 link 标签就够，维护成本比写脚本低。语言版本超过 5 个、或者翻译页面超过 500 个，再考虑生成器。",[11,287,288],{},"还有一个判断：如果某个语言版本的内容只是机翻、没有本地化，先把内容补齐再谈 hreflang。语言组里塞一堆机翻页，搜索引擎会整组降低信任，比不配更糟。",[15,290,291],{"id":291},"立场",[11,293,294],{},"没有校验脚本的 hreflang 等于没有 hreflang。配错了搜索引擎不会提醒你，只会安静地展示错的语言版本，然后你以为是内容问题。",{"title":91,"searchDepth":92,"depth":92,"links":296},[297,298,299,300,301,302,303,304],{"id":227,"depth":92,"text":227},{"id":233,"depth":92,"text":233},{"id":239,"depth":92,"text":239},{"id":263,"depth":92,"text":264},{"id":270,"depth":92,"text":270},{"id":276,"depth":92,"text":276},{"id":282,"depth":92,"text":282},{"id":291,"depth":92,"text":291},"2026-06-01","hreflang 难的不是语法，是上千个页面的一致性。我们把 hreflang 做成生成器加校验脚本，接进发布流程，新增语言版本不会再漏。这篇给具体做法和三条校验规则。",{},"\u002Fblog\u002Fhreflang-pipeline-validation",{"title":219,"description":306},"blog\u002Fhreflang-pipeline-validation",[312,313,314],"hreflang","多语言","工程化","mIdVFHXIROXmsqQ4Qb7qxEDoOcsHGJZaKpRBm2Omoug",1794088105151]