[{"data":1,"prerenderedAt":301},["ShallowReactive",2],{"blog-monthly-report-what-failed":3,"blog-prev-monthly-report-what-failed":113,"blog-next-monthly-report-what-failed":217},{"id":4,"title":5,"author":6,"body":7,"canonical":97,"category":98,"cover":97,"date":99,"description":100,"draft":101,"extension":102,"keywords":97,"meta":103,"navigation":104,"noindex":101,"ogImage":97,"path":105,"seo":106,"seoDescription":97,"seoTitle":97,"stem":107,"tags":108,"updated":97,"__hash__":112},"blog\u002Fblog\u002Fmonthly-report-what-failed.md","月报里最该写的，是这个月没做成什么，为什么","元析智能",{"type":8,"value":9,"toc":87},"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],[11,12,13],"p",{},"2026 年 4 月一个客户续约时说，他决定续约不是因为数据涨了多少，是因为我们的月报里有一条“这个月有一件事没做成，原因是你们的开发排期排不进去”。他说那一刻觉得我们没在糊弄他。",[15,16,17],"h2",{"id":17},"月报的默认写法有问题",[11,19,20],{},"大多数月报是成果清单：做了多少篇内容、修了多少技术问题、拿到了多少外链。数字摆满一页，读起来很热闹。",[11,22,23],{},"问题是客户心里有三个疑问，成果清单一个都答不了：为什么效果还没起来、你们遇到了什么阻碍、我需要做什么。",[11,25,26],{},"这三个问题不回答，客户只能自己猜。猜的结果通常是“你们没干活”。",[15,28,29],{"id":29},"我们固定留一页写没做成的事",[11,31,32],{},"这一页有三块：没做成的事、原因、需要客户配合的动作。",[11,34,35],{},"比如：原计划上线 8 篇内容，实际上线 5 篇。原因是我们等产品文档更新，晚了 10 天。需要客户配合的是指定一个文档负责人，每周同步一次更新。",[11,37,38],{},"再比如：核心产品页的加载速度没优化到位，因为开发团队这个季度的排期被新功能占满。需要客户配合的，是在下个季度排期里给技术 SEO 留 8 个小时。",[11,40,41],{},"写这一页最难的是承认自己慢。但客户看到的不是慢，是透明。",[15,43,44],{"id":44},"为什么这一页重要",[11,46,47],{},"第一，它把“效果没起来”这个模糊感受变成具体问题。客户知道卡在哪，就不会往“你们不行”上想。",[11,49,50],{},"第二，它把责任分清楚。该我们做的、该客户做的、该第三方做的，各归各位。",[11,52,53],{},"第三，它让下个月的沟通有连续性。上个月说的障碍，这个月有没有解决，一眼能看到。",[15,55,56],{"id":56},"一个具体的写法",[11,58,59],{},"我们不用“部分完成”“稳步推进”这种词。直接写数量和日期：计划 8 篇，完成 5 篇，3 篇卡在等文档，预计 5 月 20 日前补上。",[11,61,62],{},"原因写一句，不辩解。需要客户配合的动作写清楚：谁、做什么、什么时候。",[11,64,65],{},"这三行写不出来，说明这个月的项目其实没推进，只是看起来很忙。",[15,67,68],{"id":68},"数据不好时怎么说",[11,70,71],{},"效果不好的月份，这一页要加一段。写清数据为什么没起来：是收录慢、是算法调整，还是承接页转化差。别用市场波动这种词。",[11,73,74],{},"客户能接受坏消息，不能接受模糊。你给出一个具体原因和一个下一步，他就知道钱还在被认真对待。",[15,76,77],{"id":77},"客户怎么看这一页",[11,79,80],{},"我们统计过，月报发出去之后，客户回复最多的就是这一页。有人回“文档我来盯”，有人回“技术排期我去协调”。",[11,82,83],{},"反过来，只写成果的月报，客户基本不回。不回不是满意，是没什么可说的。",[11,85,86],{},"把没做成的事写清楚，比多写三页漂亮图表有用。",{"title":88,"searchDepth":89,"depth":89,"links":90},"",2,[91,92,93,94,95,96],{"id":17,"depth":89,"text":17},{"id":29,"depth":89,"text":29},{"id":44,"depth":89,"text":44},{"id":56,"depth":89,"text":56},{"id":68,"depth":89,"text":68},{"id":77,"depth":89,"text":77},null,"行业观察","2026-04-17","客户流失很少因为数字难看，多半因为不知道你在干嘛、卡在哪。我们的月报固定留一页写没做成的事、原因和需要客户配合的动作，附一份可直接套用的写法。",false,"md",{},true,"\u002Fblog\u002Fmonthly-report-what-failed",{"title":5,"description":100},"blog\u002Fmonthly-report-what-failed",[109,110,111],"月报","客户沟通","项目管理","4eIXr1LDfdBRiOzXWd7y6MJJM9xviCZHpEChCj_VBSM",{"id":114,"title":115,"author":6,"body":116,"canonical":97,"category":98,"cover":97,"date":206,"description":207,"draft":101,"extension":102,"keywords":97,"meta":208,"navigation":104,"noindex":101,"ogImage":97,"path":209,"seo":210,"seoDescription":97,"seoTitle":97,"stem":211,"tags":212,"updated":97,"__hash__":216},"blog\u002Fblog\u002Fcore-update-recovery-cycle.md","核心更新恢复周期：从掉 40% 到回原位用了 5 个月",{"type":8,"value":117,"toc":196},[118,121,125,128,131,134,138,141,144,147,150,153,156,159,162,166,169,172,175,178,181,184,187,190,193],[11,119,120],{},"2025 年 3 月核心更新后，我们一个站掉了 40%，第 5 个月回到原位，中间经历两次假恢复。这 5 个月每周做了什么、哪些动作有用、两次假恢复怎么识别，都记下来了。",[15,122,124],{"id":123},"前-6-周什么都别做","前 6 周：什么都别做",[11,126,127],{},"更新确认后的前 6 周，我们只做一件事：记录。每周拉一次排名、流量、收录、抓取数据，不做任何改动。",[11,129,130],{},"原因很简单：核心更新的影响要 4 到 6 周才稳定，前期波动大，这时候改东西，分不清是改动生效还是波动。",[11,132,133],{},"这 6 周里，那 40% 的跌幅又往下探了 3 个点，然后停住。",[15,135,137],{"id":136},"第-7-到-12-周改内容","第 7 到 12 周：改内容",[11,139,140],{},"第 7 周开始动手，只改三类页面：掉得最多的 20 个、有搜索需求但内容薄的、作者信息缺失的。",[11,142,143],{},"每改一批观察两周，不一次性全改。第一批改了 20 个页面，4 周后其中 11 个排名回升，9 个没动。",[15,145,146],{"id":146},"恢复期间我们每周看什么",[11,148,149],{},"四个数：核心词排名、自然流量、索引量、抓取频次。每周一拉，记进同一张表。",[11,151,152],{},"这张表的作用不是看趋势，是判断“这次是不是真的在恢复”。单看流量会误判，四个数一起看，假恢复基本能识别出来。",[15,154,155],{"id":155},"恢复期间做错的一件事",[11,157,158],{},"第 11 周我们想加速，把 30 篇旧文一次性重写了标题。结果两周内 6 个核心词掉了 3 到 5 名，我们又把标题改回去一半。",[11,160,161],{},"这件事的教训是：恢复期别批量改标题。标题一改，关键词匹配全变，之前积累的排名会重算。要改就一次改 5 个，观察两周。",[15,163,165],{"id":164},"第-3-到-5-个月恢复曲线","第 3 到 5 个月：恢复曲线",[11,167,168],{},"第 12 周流量回到更新前的 62%，第 16 周回到 78%，第 20 周回到 97%，第 22 周回到 100%。",[11,170,171],{},"不是直线回升，中间有两次掉头。",[15,173,174],{"id":174},"两次假恢复",[11,176,177],{},"第一次在第 10 周，流量一周涨了 15%，我们以为要回来了，第二周又掉回去。查下来是几个长尾词的短期波动，不是真的恢复。",[11,179,180],{},"第二次在第 15 周，这次持续了三周，我们才敢确认。判断标准是：连续三周核心词排名稳定、流量波动在 10% 以内。",[15,182,183],{"id":183},"没能恢复的站有什么共同点",[11,185,186],{},"我们同期处理的 5 个站，2 个没恢复。共同点：内容站、没有产品页、没有品牌搜索、作者信息补了但还是查无此人。还有一个共同点——更新后第 2 周就开始大改，方向从第一步就错了。",[11,188,189],{},"核心更新恢复的本质是站点评级回升，不是修 bug。页面改得再干净，站本身没价值，也回不来。",[15,191,192],{"id":192},"一句判断",[11,194,195],{},"恢复周期按 3 到 6 个月预期，别按 2 周。这期间最忌讳的是频繁大改——改得越多，越分不清哪个动作有用。",{"title":88,"searchDepth":89,"depth":89,"links":197},[198,199,200,201,202,203,204,205],{"id":123,"depth":89,"text":124},{"id":136,"depth":89,"text":137},{"id":146,"depth":89,"text":146},{"id":155,"depth":89,"text":155},{"id":164,"depth":89,"text":165},{"id":174,"depth":89,"text":174},{"id":183,"depth":89,"text":183},{"id":192,"depth":89,"text":192},"2026-04-16","核心更新后的恢复不是线性，也不是所有人都能恢复。2025 年 3 月核心更新后，我们一个站掉了 40%，第 5 个月回到原位，中间经历两次假恢复。这 5 个月每周做了什么、哪些动作有用、两次假恢复怎么识别，都记下来了。",{},"\u002Fblog\u002Fcore-update-recovery-cycle",{"title":115,"description":207},"blog\u002Fcore-update-recovery-cycle",[213,214,215],"核心更新","流量恢复","复盘","pzoeKVvxu50qJjv-KAKwoa5v49ne77Ks0YSn3wvmDso",{"id":218,"title":219,"author":6,"body":220,"canonical":97,"category":289,"cover":97,"date":290,"description":291,"draft":101,"extension":102,"keywords":97,"meta":292,"navigation":104,"noindex":101,"ogImage":97,"path":293,"seo":294,"seoDescription":97,"seoTitle":97,"stem":295,"tags":296,"updated":97,"__hash__":300},"blog\u002Fblog\u002Fbreadcrumb-jsonld-position-errors.md","BreadcrumbList 标了没生效，九成是层级写错",{"type":8,"value":221,"toc":280},[222,225,229,232,235,239,242,246,249,253,256,259,262,265,268,271,274,277],[11,223,224],{},"BreadcrumbList 的报错，九成不是 JSON 语法，是层级和页面对不上。校验工具能指出错在哪一行，但改起来得回到模板。",[15,226,228],{"id":227},"坑一position-不连续","坑一：position 不连续",[11,230,231],{},"position 必须从 1 开始连续编号。模板里按数组索引写，遇到缺一级的页面就会出现 1、3、4，整条标记失效。正确做法是按面包屑的实际层级动态生成 position，别写死。",[11,233,234],{},"我们给客户做结构化数据审计时，第一件事是把全站的 BreadcrumbList 抽出来，用脚本比对每条 item 的 URL 和页面上真实存在的链接。这一步能捞出一半的问题，比等 GSC 报告快得多。",[15,236,238],{"id":237},"坑二name-和页面可见文字不一致","坑二：name 和页面可见文字不一致",[11,240,241],{},"item 里的 name 要和页面上面包屑显示的文字一字不差，URL 要和链接的 href 一致。常见错法：页面上写\"文档中心\"，标记里写\"Docs\"；或者 URL 末尾带斜杠、标记里不带，导致 Google 选不到对应页面。",[15,243,245],{"id":244},"坑三最后一级","坑三：最后一级",[11,247,248],{},"最后一级通常是当前页，可以不写链接，但 name 要保留。有些模板直接从数组里 pop 掉最后一项，结果只剩两级，层级关系错乱。正确做法是保留完整路径，最后一项的 item 可以省略 URL。",[15,250,252],{"id":251},"_2026-年-1-月那次修复","2026 年 1 月那次修复",[11,254,255],{},"一个 4000 页的文档站，GSC 报 1200 条\"缺少字段 item\"。查下来是模板里最后一级用当前页变量渲染，某些页面的变量为空。改模板后两周报错清零，搜索结果里开始出现带路径的展示样式。",[11,257,258],{},"这件事的价值不在展示样式，在于那 1200 个页面的层级关系终于被正确理解，内链和归档页的权重传递顺了一截。",[15,260,261],{"id":261},"怎么验证",[11,263,264],{},"Rich Results Test 跑单页看具体字段；GSC 的\"增强功能 > 面包屑\"看全站报错总数和示例 URL；Screaming Frog 用自定义提取抓 JSON-LD 里的字段做批量比对。三个一起用，通常两天能清完。",[15,266,267],{"id":267},"一个容易忽略的场景",[11,269,270],{},"多语言站的目录层不一样，比如中文是 \u002Fzh\u002Fdocs\u002Fapi，英文是 \u002Fen\u002Fdocs\u002Fapi，但面包屑的层级名称要跟着语言翻译。有些站模板写死了中文的\"产品\"\"文档\"，英文页面也显示中文，用户看不懂，name 和页面文字也对不上。这类问题在 GSC 里会以\"名称不匹配\"的警告出现。",[11,272,273],{},"我们一般把每一级的名称做成语言包，模板按当前语言取，一次改完全站生效。",[15,275,276],{"id":276},"立场",[11,278,279],{},"结构化数据要和页面可见内容同时上线。只有 JSON-LD 没有可见面包屑，属于违规；只有面包屑没有标记，少一个展示机会。两件事一起做，成本多不了半小时。",{"title":88,"searchDepth":89,"depth":89,"links":281},[282,283,284,285,286,287,288],{"id":227,"depth":89,"text":228},{"id":237,"depth":89,"text":238},{"id":244,"depth":89,"text":245},{"id":251,"depth":89,"text":252},{"id":261,"depth":89,"text":261},{"id":267,"depth":89,"text":267},{"id":276,"depth":89,"text":276},"技术SEO","2026-04-18","面包屑结构化数据报错通常不在语法，在层级。我们用 2026 年 1 月一个 4000 页文档站的修复过程，讲清 position 连续性、item 对齐、最后一级这三个坑。",{},"\u002Fblog\u002Fbreadcrumb-jsonld-position-errors",{"title":219,"description":291},"blog\u002Fbreadcrumb-jsonld-position-errors",[297,298,299],"结构化数据","面包屑","JSON-LD","OCyWkXp9Ctvh_qCIckp19K7ii851ypEoyD5P4hnsRrM",1794088106698]