[{"data":1,"prerenderedAt":285},["ShallowReactive",2],{"blog-diagnosis-report-length":3,"blog-prev-diagnosis-report-length":108,"blog-next-diagnosis-report-length":192},{"id":4,"title":5,"author":6,"body":7,"canonical":92,"category":93,"cover":92,"date":94,"description":95,"draft":96,"extension":97,"keywords":92,"meta":98,"navigation":99,"noindex":96,"ogImage":92,"path":100,"seo":101,"seoDescription":92,"seoTitle":92,"stem":102,"tags":103,"updated":92,"__hash__":107},"blog\u002Fblog\u002Fdiagnosis-report-length.md","诊断报告别写 80 页，客户只看得下 5 页","元析智能",{"type":8,"value":9,"toc":83},"minimark",[10,14,19,22,25,28,32,35,38,41,44,47,50,53,56,59,62,65,68,71,74,77,80],[11,12,13],"p",{},"2025 年 11 月我们交过一份 80 页的诊断报告，客户后来跟我们说，他翻了前 5 页，剩下的让助理看了。从那次之后，我们的诊断报告固定 5 页，多出来的内容全放附录。",[15,16,18],"h2",{"id":17},"_80-页报告的问题","80 页报告的问题",[11,20,21],{},"第一个问题是没人读。客户是老板或者市场负责人，一天要看几十封邮件，没时间读 80 页。",[11,23,24],{},"第二个问题是重点被淹没。80 页里 200 多个问题，客户看完只记得“问题很多”，不知道该先做哪个。",[11,26,27],{},"第三个问题是显得没做判断。把所有能查的都列一遍，反而说明你没做判断。诊断的价值是排序，不是清单。",[15,29,31],{"id":30},"我们的-5-页结构","我们的 5 页结构",[11,33,34],{},"第一页，结论。三句话：这个站现在最大的问题是什么、三个月内最值得做的三件事、预期多久能看到变化。",[11,36,37],{},"第二页，问题。不超过 8 条，每条一句话说清现象、影响和证据。比如“产品页加载 6.2 秒，移动端跳出率 78%，影响转化”。",[11,39,40],{},"第三页，优先级。把所有问题按影响和成本排成四象限，标出先做什么。",[11,42,43],{},"第四页，动作。未来 4 周的具体动作，每条写清谁做、什么时候做完、怎么验证。",[11,45,46],{},"第五页，数据附录的目录。真实的明细放附录，客户要看能翻，不看也不影响理解。",[15,48,49],{"id":49},"附录怎么组织",[11,51,52],{},"附录按类型分章：收录、抓取、性能、内容、外链。每章开头一句结论，后面放数据表和截图。",[11,54,55],{},"附录的价值在于可查，不在于必读。客户团队里的执行人员会看，老板不会。",[11,57,58],{},"我们现在的规矩是：正文里出现的每个判断，附录里都能找到支撑数据。",[15,60,61],{"id":61},"一个写作技巧",[11,63,64],{},"写报告时先写结论，再回头看要不要补充。很多人是先收集数据，然后从数据里找结论，这样写出来的报告一定是清单式的。",[11,66,67],{},"我的做法是拿到数据先写一句“如果只能改一件事，改什么”，写完再反过来组织证据。这句话往往就是第一页的标题。",[15,69,70],{"id":70},"客户其实只要三件事",[11,72,73],{},"他要知道现在什么情况、下一步做什么、钱花得值不值。80 页报告一个都答不好，5 页报告必须答清楚。",[11,75,76],{},"我们现在的报告最后加一行：如果只做一件事，做这个。## 一个后续",[11,78,79],{},"那份 80 页报告后来被我们当成内部教材，用来训练新人怎么写结论。方法很简单：让新人把 80 页里的每个问题写一句话，然后问哪三件最值得做，答不出来就重写。",[11,81,82],{},"客户反馈这一行最有用。",{"title":84,"searchDepth":85,"depth":85,"links":86},"",2,[87,88,89,90,91],{"id":17,"depth":85,"text":18},{"id":30,"depth":85,"text":31},{"id":49,"depth":85,"text":49},{"id":61,"depth":85,"text":61},{"id":70,"depth":85,"text":70},null,"行业观察","2026-05-11","我们写过 80 页的诊断报告，客户只翻了前 5 页。这篇写怎么把报告压到 5 页：一页结论、一页问题、一页优先级、一页动作、一页数据附录。",false,"md",{},true,"\u002Fblog\u002Fdiagnosis-report-length",{"title":5,"description":95},"blog\u002Fdiagnosis-report-length",[104,105,106],"诊断报告","客户沟通","交付","_y2WASgzGHM9FpCq5K3h5Zn3OeYZiISOfU1UhZpsY44",{"id":109,"title":110,"author":6,"body":111,"canonical":92,"category":180,"cover":92,"date":181,"description":182,"draft":96,"extension":97,"keywords":92,"meta":183,"navigation":99,"noindex":96,"ogImage":92,"path":184,"seo":185,"seoDescription":92,"seoTitle":92,"stem":186,"tags":187,"updated":92,"__hash__":191},"blog\u002Fblog\u002Fshenma-mobile-adaptation.md","神马搜索只做移动端，这套适配不做等于白做",{"type":8,"value":112,"toc":173},[113,116,119,122,125,128,131,134,137,140,143,146,149,152,155,158,161,164,167,170],[11,114,115],{},"神马搜索只做移动端，PC 站做得再好也没用。它的三个硬门槛是移动端可访问、落地页规范、备案，缺一个收录就卡住。我们帮 6 个客户做过神马适配，踩过的坑比想象中多。",[15,117,118],{"id":118},"神马是什么",[11,120,121],{},"神马搜索是阿里旗下的移动搜索引擎，流量入口主要是 UC 浏览器和部分阿里系应用，用户几乎全在手机上。",[11,123,124],{},"这个定位决定了它的规则：只收移动端页面，PC 页面基本不收；对移动端体验的要求比百度严；落地页有明确的规范，弹窗、强制下载、遮挡内容都会被判不合格。",[15,126,127],{"id":127},"三个硬门槛",[11,129,130],{},"第一，移动端可访问且不跳转。用户从神马点进来，落地页必须是移动版，不能先跳到 PC 站再重定向。我们一个客户用了错误的 UA 判断，手机上打开跳到了电脑版，神马收录了 300 页，全部无展现。",[11,132,133],{},"第二，落地页规范。首屏不能有大面积弹窗遮挡正文，不能强制下载 App，不能有自动播放的视频广告。这三条踩一条，页面就会被降权。",[11,135,136],{},"第三，备案。和百度一样，没备案的站在神马基本没有收录机会，这条没有例外。",[15,138,139],{"id":139},"适配怎么做",[11,141,142],{},"2025 年 9 月我们给一个客户做适配时，先做了一次移动端抓取测试：用神马的 UA 请求首页，看返回的 HTML 有没有正文。这一步能提前发现 70% 的问题。",[11,144,145],{},"优先做响应式，一套代码适配所有屏幕，维护成本最低。如果已经是独立移动站，确保移动站和 PC 站的 URL 有明确对应关系，别两套内容各写各的。",[11,147,148],{},"三个细节：viewport 必须写对，别用固定宽度；首屏加载控制在 3 秒内，UC 浏览器的网络环境比想象中差；正文段落别用图片代替文字，神马抓不到。",[11,150,151],{},"我们给一个做在线表单的客户做适配，只改了 viewport 和首屏图片懒加载，移动端收录从 200 页涨到 1100 页。",[15,153,154],{"id":154},"我们踩的坑",[11,156,157],{},"第一个坑：移动端页面用了大量的 JS 渲染，神马抓到的 HTML 是空的。改成服务端渲染后，收录正常。",[11,159,160],{},"第二个坑：移动站和 PC 站内容不一致，移动站只有 200 字摘要，被判低质。补齐正文后恢复。",[11,162,163],{},"第三个坑：为了\"移动体验\"加了一堆浮层和引导下载，落地页被判不合格。砍掉之后，原本收录的页面反而涨了展现。",[15,165,166],{"id":166},"一句判断",[11,168,169],{},"适配之后我们跟进了一个季度：那个客户的移动端收录从 200 页涨到 1100 页，自然访问涨了 45%。投入大概 3 个人天，值得。",[11,171,172],{},"神马适合已经在做移动端的站顺手适配，不适合为它单独建站。如果你的产品是移动端工具或面向 C 端，它值得做；如果是纯 To B 的 SaaS，把基础适配做好就行，别投入内容。",{"title":84,"searchDepth":85,"depth":85,"links":174},[175,176,177,178,179],{"id":118,"depth":85,"text":118},{"id":127,"depth":85,"text":127},{"id":139,"depth":85,"text":139},{"id":154,"depth":85,"text":154},{"id":166,"depth":85,"text":166},"技术SEO","2026-05-10","神马搜索只做移动端，PC 站做得再好也没用。它的三个硬门槛是移动端可访问、落地页规范、备案，缺一个收录就卡住。我们帮 6 个客户做过神马适配，踩过的坑和具体做法都在这篇，最后有一段是适配后的效果数据。",{},"\u002Fblog\u002Fshenma-mobile-adaptation",{"title":110,"description":182},"blog\u002Fshenma-mobile-adaptation",[188,189,190],"神马搜索","移动适配","UC浏览器","U203_bPPHCla7kWQjwUHXPl5FNZ-XP928798C6-4pYk",{"id":193,"title":194,"author":6,"body":195,"canonical":92,"category":180,"cover":92,"date":274,"description":275,"draft":96,"extension":97,"keywords":92,"meta":276,"navigation":99,"noindex":96,"ogImage":92,"path":277,"seo":278,"seoDescription":92,"seoTitle":92,"stem":279,"tags":280,"updated":92,"__hash__":284},"blog\u002Fblog\u002Fduplicate-content-merge.md","站内 70% 相似的页面，该合并还是保留，我们有个判断标准",{"type":8,"value":196,"toc":266},[197,200,203,206,209,212,215,218,221,224,227,230,233,236,239,242,245,248,251,254,257,260,263],[11,198,199],{},"站内相似页面处理错了，比不处理更伤。我们用\"搜索意图是否相同\"做判断：意图相同就合并，意图不同就保留并做差异化。这条标准比相似度百分比好用。",[15,201,202],{"id":202},"先定义什么叫相似",[11,204,205],{},"工具报的相似度是按文本算的，70% 相似只说明文字重合多。但 SEO 关心的是：这两个页面在搜索结果里抢的是不是同一批词。",[11,207,208],{},"我们一般做两步判断。第一步，把两个页面各自排名前 20 的词拉出来，看重合度。第二步，看这些词的搜索意图是不是同一类。",[11,210,211],{},"词重合 80% 以上、意图相同，才算真正重复；文字相似但词不重合，那是两篇不同的内容。",[15,213,214],{"id":214},"三种该合并的",[11,216,217],{},"第一种，同一产品的不同版本页。比如\"项目管理工具\"和\"项目管理软件\"，内容 80% 一样，抢的是同一批词，合并成一个主页面。",[11,219,220],{},"第二种，同一问题的多篇回答。博客里写了三篇\"API 限流怎么办\"，发布时间不同、观点重复，合并成一篇大的，其余 301 过去。",[11,222,223],{},"第三种，模板生成的薄页。地区页、标签页、参数页，内容只差一个地名或参数，合并或者 noindex。",[15,225,226],{"id":226},"两种不该合并的",[11,228,229],{},"第一种，意图不同但文字相似。比如\"什么是 API 网关\"和\"API 网关怎么选\"，文字重合可能 60%，但一个是学习意图、一个是选型意图，合并了反而两边都不讨好。",[11,231,232],{},"第二种，面向不同人群的页面。同一个功能，给开发者和给管理者的落地页，文字有重合，但转化路径完全不同，保留并做差异化更好。",[15,234,235],{"id":235},"合并的操作",[11,237,238],{},"先定主页面，把副页面里有价值的内容并进来，副页面 301 到主页面，不要用 canonical 吊着。",[11,240,241],{},"内链要一起改：原来指向副页面的链接，全部改到主页面。外链改不了的，靠 301 接住。",[11,243,244],{},"合并后观察 4 周，看主页面的排名和流量。我们一般按流量排序，一批合 5 到 10 个，别一次合几百个。",[15,246,247],{"id":247},"一个案例",[11,249,250],{},"一个做数据平台的客户，博客里有 14 篇讲\"数据仓库选型\"的文章，都是不同年份写的。我们合并成 3 篇：一篇讲概念、一篇讲选型标准、一篇讲实施。",[11,252,253],{},"14 篇的流量加起来是每月 1200，合并后 3 篇每月 2100，而且排名更稳。剩下的 11 篇 301 到对应的主页面，没有掉流量。",[15,255,256],{"id":256},"一次翻车",[11,258,259],{},"2026 年 1 月我们给一个客户合并了 60 个\"功能对比页\"，理由都相似度 75%。合完两个月，这批页面的总流量掉了 40%。",[11,261,262],{},"复盘发现：这些对比页面向的是不同竞品的搜索词，用户搜\"我们 vs A\"和\"我们 vs B\"意图不同，合并后反而丢了长尾。后来拆回 25 个，流量慢慢回来。",[11,264,265],{},"这件事之后我们把\"意图判断\"放在相似度前面。工具给的是线索，不是结论。",{"title":84,"searchDepth":85,"depth":85,"links":267},[268,269,270,271,272,273],{"id":202,"depth":85,"text":202},{"id":214,"depth":85,"text":214},{"id":226,"depth":85,"text":226},{"id":235,"depth":85,"text":235},{"id":247,"depth":85,"text":247},{"id":256,"depth":85,"text":256},"2026-05-12","站内相似页面处理错了，比不处理更伤。我们用“搜索意图是否相同”做判断：意图相同就合并，意图不同就保留并做差异化。合并的三种做法、两个不该合的例子和一次翻车都在篇里，最后有个判断标准可以直接用。",{},"\u002Fblog\u002Fduplicate-content-merge",{"title":194,"description":275},"blog\u002Fduplicate-content-merge",[281,282,283],"重复内容","页面合并","站点结构","XkzQ5WOp9o4FerUadrW2sXM6Gnm2Wzn3SR7PLXjfywA",1794088106060]