[{"data":1,"prerenderedAt":339},["ShallowReactive",2],{"blog-old-post-rewrite-judgment":3,"blog-prev-old-post-rewrite-judgment":111,"blog-next-old-post-rewrite-judgment":236},{"id":4,"title":5,"author":6,"body":7,"canonical":95,"category":96,"cover":95,"date":97,"description":98,"draft":99,"extension":100,"keywords":95,"meta":101,"navigation":102,"noindex":99,"ogImage":95,"path":103,"seo":104,"seoDescription":95,"seoTitle":95,"stem":105,"tags":106,"updated":95,"__hash__":110},"blog\u002Fblog\u002Fold-post-rewrite-judgment.md","旧文翻新前先判断：这篇到底值不值得重写","元析智能",{"type":8,"value":9,"toc":84},"minimark",[10,14,19,22,25,29,32,35,39,42,45,48,51,54,57,60,63,66,69,72,75,78,81],[11,12,13],"p",{},"旧文翻新最大的浪费，是把一篇救不回来的文章改了三个版本。我们的做法是先判断，再动手。2025 年 9 月整理了一批 40 篇 2023 年到 2024 年的老文，判断下来只重写 12 篇，8 周后其中 9 篇回到前 20 名，剩下 28 篇里 19 篇合并、9 篇删除。",[15,16,18],"h2",{"id":17},"第一个问题还有搜索需求吗","第一个问题：还有搜索需求吗",[11,20,21],{},"翻出这个页面最近 12 个月的曝光和点击。曝光持续下滑到接近 0 的，先别改，去查关键词还在不在被搜。",[11,23,24],{},"有时候不是文章不行，是那个词没人搜了。产品功能改名、行业换说法、用户改用英文缩写，这些都会让一个词直接消失。需求没了，重写就是白写。",[15,26,28],{"id":27},"第二个问题有没有排名基础","第二个问题：有没有排名基础",[11,30,31],{},"看这个 URL 现在排在多少名，有没有外链，收录了多久。",[11,33,34],{},"排在前 30 名以内、有一两个外链的，值得救。排在 100 名开外、零外链的，其实等于新写一篇，成本一样，收益更低。",[15,36,38],{"id":37},"第三个问题原文有没有独家内容","第三个问题：原文有没有独家内容",[11,40,41],{},"翻一遍原文，找那些只能从我们这里得到的东西：实测数据、客户场景、内部截图、踩坑记录。",[11,43,44],{},"一条都没有的，弃掉。这种文章重写之后还是跟同行一个样，问题不在文字，在信息存量。",[15,46,47],{"id":47},"决定重写的怎么改",[11,49,50],{},"URL 不动，标题里的核心词不动，正文重排：结论前置，补近两年的数据，加作者署名和更新日期。",[11,52,53],{},"结构上砍掉一半。老文普遍太啰嗦，2023 年那批平均 3200 字，重写后压到 1800 字左右，可读性和抓取效率都更好。",[15,55,56],{"id":56},"一个反常识的观察",[11,58,59],{},"排名下滑最厉害的那批文章，问题往往不在内容质量，在搜索结果页本身变了。搜同样的词，前十多了文档站、视频和问答，你一篇博客挤不进去。",[11,61,62],{},"这种时候该做的不是翻新，是换页面类型：写文档页、做视频、或者把内容搬到能排上去的载体上。我们 2025 年就干过这事，把 6 篇博客改成了产品文档，流量回来了七成。",[15,64,65],{"id":65},"多久做一次",[11,67,68],{},"我们按季度做，每次只看两类：最近 12 个月曝光下滑超过 50% 的，和排名在 11 到 30 名之间卡住的。前一类救，后一类推。",[11,70,71],{},"一次看 30 到 50 篇，两三个小时能出结论。攒到几百篇一起看，判断质量一定下降。",[15,73,74],{"id":74},"重写之后怎么观察",[11,76,77],{},"发布后第 14 天看是否重新被收录，第 28 天看曝光，第 56 天看排名。三周没收录，先查是不是被 noindex 或者被砍了内链。",[11,79,80],{},"我们自己的一个规律是：重写后曝光恢复通常比排名快两到三周。曝光起来了排名不动，说明内容对了但页面权重不够，该补内链而不是继续改稿。",[11,82,83],{},"翻新不是改字，是给这篇内容换一个能打的版本。",{"title":85,"searchDepth":86,"depth":86,"links":87},"",2,[88,89,90,91,92,93,94],{"id":17,"depth":86,"text":18},{"id":27,"depth":86,"text":28},{"id":37,"depth":86,"text":38},{"id":47,"depth":86,"text":47},{"id":56,"depth":86,"text":56},{"id":65,"depth":86,"text":65},{"id":74,"depth":86,"text":74},null,"内容运营","2025-11-02","翻新旧文先问三个问题：还有搜索需求吗、有没有排名基础、原文有没有别人没有的东西。40 篇老文里我们只重写了 12 篇，8 周后 9 篇回到前 20，其余直接删或并。",false,"md",{},true,"\u002Fblog\u002Fold-post-rewrite-judgment",{"title":5,"description":98},"blog\u002Fold-post-rewrite-judgment",[107,108,109],"旧文翻新","内容更新","SEO复盘","jv6-BYvQEOmZQZ02WeVIXY2ClGoGx20kFtU10fn7xmg",{"id":112,"title":113,"author":6,"body":114,"canonical":95,"category":224,"cover":95,"date":225,"description":226,"draft":99,"extension":100,"keywords":95,"meta":227,"navigation":102,"noindex":99,"ogImage":95,"path":228,"seo":229,"seoDescription":95,"seoTitle":95,"stem":230,"tags":231,"updated":95,"__hash__":235},"blog\u002Fblog\u002Finp-common-questions.md","INP 是什么、怎么测、怎么改：客户最常问的八个问题",{"type":8,"value":115,"toc":218},[116,119,122,128,131,136,139,144,147,150,155,158,163,166,171,174,177,182,185,190,193,198,201,206,209,212,215],[11,117,118],{},"INP 是 Core Web Vitals 里最容易被误解的指标，因为它不像 LCP 那样有一个\"看得见的元素\"。下面是我们被客户问得最多的八个问题，答案尽量短。",[15,120,121],{"id":121},"定义和阈值",[11,123,124],{},[125,126,127],"strong",{},"Q：INP 到底测什么？",[11,129,130],{},"用户每次交互（点击、按键、触摸）到浏览器画出下一帧的延迟，取整个会话里偏差最大的那次作为分数。它衡量页面响应快不快。",[11,132,133],{},[125,134,135],{},"Q：多少算合格？",[11,137,138],{},"低于 200 毫秒算好，200 到 500 毫秒需要改进，超过 500 毫秒算差。和 LCP 一样，要求 75% 的用户访问达标。",[11,140,141],{},[125,142,143],{},"Q：它和 FID 什么关系？",[11,145,146],{},"FID 是旧指标，2024 年 3 月被 INP 替代。FID 只看第一次输入，而且只算输入延迟不算渲染，所以经常一片绿。INP 看所有交互，包含处理耗时和下一帧渲染耗时，严格得多。",[15,148,149],{"id":149},"怎么测",[11,151,152],{},[125,153,154],{},"Q：为什么 PageSpeed 测出来和客户说的不一样？",[11,156,157],{},"PageSpeed 的 INP 是实验室模拟，很多交互它触发不了，有时直接显示无数据。要看真实情况，用 GSC 的 Core Web Vitals 报告或 CrUX。",[11,159,160],{},[125,161,162],{},"Q：移动端为什么普遍比桌面差？",[11,164,165],{},"CPU 性能差，加上主线程任务没有为低端机优化。同一段 JS 在开发机上 30 毫秒，在四年前的中端安卓上就是 200 毫秒。",[11,167,168],{},[125,169,170],{},"Q：有没有必要自己搭 RUM？",[11,172,173],{},"访问量超过每天一千就建议搭。web-vitals 库加一个上报接口，半天能上线。实验室数据只能定位方向，验收必须靠自己的真实数据。",[15,175,176],{"id":176},"怎么改",[11,178,179],{},[125,180,181],{},"Q：改哪里收益最大？",[11,183,184],{},"按我们的经验排序：去掉事件处理器里的同步重活、列表虚拟化、第三方脚本延后、减少首屏水合。这四项能覆盖大多数站。",[11,186,187],{},[125,188,189],{},"Q：加服务器有用吗？",[11,191,192],{},"基本没用。INP 是浏览器主线程的问题，服务器再快，JS 还是要在用户设备上跑。带宽和机器解决 LCP 和 TTFB，解决不了交互。",[11,194,195],{},[125,196,197],{},"Q：改完多久能看到指标变化？",[11,199,200],{},"真实用户数据一般要两到四周才稳定。INP 取的是偏差最大的那次交互，样本量不够的时候波动很大。我们有个客户改完第三天看数据反而变差了，第二周才回落到 180 毫秒。别用三天的数据下结论。",[11,202,203],{},[125,204,205],{},"Q：能不能只改最慢的那个交互？",[11,207,208],{},"可以，而且往往是性价比最高的做法。INP 的分数由少数极差交互决定，修好 P95 那一个交互，整站分数就能上一个台阶。前提是你得先知道是哪一个，这就要有能归因到元素的 RUM。",[15,210,211],{"id":211},"补一句",[11,213,214],{},"INP 有个天然缺陷：它只统计交互延迟，不统计\"用户想点但没有可点元素\"的时间。按钮灰着、加载中不能操作，这些体验问题不会进 INP。所以别把 INP 当体验的全部，它只是一个及格线。",[11,216,217],{},"我们的做法是把 INP 和两个自建指标放一起看：首次可交互时间、关键操作完成时间。三个数一起看，才不容易被漂亮的单项分数骗过去。",{"title":85,"searchDepth":86,"depth":86,"links":219},[220,221,222,223],{"id":121,"depth":86,"text":121},{"id":149,"depth":86,"text":149},{"id":176,"depth":86,"text":176},{"id":211,"depth":86,"text":211},"技术SEO","2025-11-01","INP 是替代 FID 的交互指标，200 毫秒合格、500 毫秒算差。八个高频问题：阈值、和 FID 区别、移动端为什么更差、PSI 为什么测不出、加服务器有没有用、多久见效。",{},"\u002Fblog\u002Finp-common-questions",{"title":113,"description":226},"blog\u002Finp-common-questions",[232,233,234],"INP","问答","Core Web Vitals","522k-jzEwKKosFlHmpbLJLKkw62jUa1ys0fCETNMh6s",{"id":237,"title":238,"author":6,"body":239,"canonical":95,"category":328,"cover":95,"date":329,"description":330,"draft":99,"extension":100,"keywords":95,"meta":331,"navigation":102,"noindex":99,"ogImage":95,"path":332,"seo":333,"seoDescription":95,"seoTitle":95,"stem":334,"tags":335,"updated":95,"__hash__":338},"blog\u002Fblog\u002Fproduct-entity-vs-brand-entity.md","产品实体和品牌实体混在一页，AI 会把公司当产品",{"type":8,"value":240,"toc":320},[241,244,248,251,254,257,263,269,275,278,281,284,287,290,293,296,299,302,305,308,311,314,317],[11,242,243],{},"产品名和公司名写在同一个标题里，AI 会把两条实体记录合成一条。这不是理论，是我们 10 月在一个客户身上看到的：他们的产品页标题是\"XX 数据平台 - XX 科技\"，结果搜产品名时，AI 回答的是公司简介；搜公司名时，AI 回答的是产品功能。两边都答得半对。",[15,245,247],{"id":246},"在-ai-眼里这是两条记录","在 AI 眼里，这是两条记录",[11,249,250],{},"品牌实体是公司：法人、地址、成立时间、员工数、融资、客户。产品实体是软件：功能、版本、定价、部署方式、兼容性、许可证。",[11,252,253],{},"这两条记录在知识图谱里各有节点，用\"开发方\"这类关系连着。你把它们塞进一个页面、一个标题，引擎就得自己猜哪个是哪个。猜错不要紧，要紧的是它猜完就固定了，后面很难改。",[15,255,256],{"id":256},"混写的三个后果",[11,258,259,262],{},[125,260,261],{},"品牌词回答变窄。"," 搜公司名，回答里全是产品功能，看不到团队规模和客户类型，采购方判断不了你靠不靠谱。",[11,264,265,268],{},[125,266,267],{},"对比类查询缺席。"," 用户搜\"XX 和 YY 哪个好\"，AI 需要一个能被拿来对比的产品条目。条目不存在，它就不提你。我们查了 4 个混写客户的对比类查询，40 个查询里出现 3 次。拆开之后是 17 次。",[11,270,271,274],{},[125,272,273],{},"结构化数据打架。"," 同一页里放 Organization 和 SoftwareApplication，属性互相污染。有人把定价写到 Organization 的 priceRange 里，机器读出来就是\"这家公司收费 99 元\"。",[15,276,277],{"id":277},"拆开的三条做法",[11,279,280],{},"第一，产品页独立。每个产品一条 URL，标题只写产品名，不带公司后缀。公司名放到正文第一段和页脚。",[11,282,283],{},"第二，schema 分开写。Organization 放公司页和全站页脚，SoftwareApplication 放产品页。SoftwareApplication 里至少给 name、applicationCategory、operatingSystem、offers 四项。别偷懒只写 name。",[11,285,286],{},"第三，命名统一。产品名在所有渠道用同一个写法，包括大小写。产品名里有版本号的就别把版本号写进主名称，\"XX 2.0\"和\"XX\"是两个实体。",[15,288,289],{"id":289},"一个客户的六个月",[11,291,292],{},"那个数据平台客户，11 月开始拆。做了三件事：产品页改标题、产品页加 SoftwareApplication、About 页补公司信息。",[11,294,295],{},"六周复查：搜产品名，回答里出现功能描述的比例从 30% 到 78%；搜公司名，出现客户类型和团队规模的比例从 0 到 60%；对比类查询从 3 次到 17 次。",[11,297,298],{},"没有新写内容，只是把已有的信息归位。",[15,300,301],{"id":301},"什么时候不用拆",[11,303,304],{},"只有一个产品、且产品名就是公司名的情况，不用拆。比如很多工具类公司，公司叫 X，产品也叫 X。这时候一条记录更清楚。",[11,306,307],{},"判断标准是：你的客户会不会用\"你们公司\"和\"你们产品\"问两个不同的问题。会，就该拆。不会，别折腾。",[15,309,310],{"id":310},"一个容易被忽略的连带影响",[11,312,313],{},"拆实体还会顺带修好一个东西：AI 回答里的\"适合谁\"。混写的时候，引擎只能从公司层面判断，于是把你们推给所有人，或者推给所有人里最便宜的那批。产品实体独立之后，它能从功能、部署方式、定价区间推出适用规模，推荐就变准了。",[11,315,316],{},"我们那个客户拆完两个月，AI 回答里开始出现\"适合 50 到 200 人的团队\"这类描述。这种句子比任何广告词都值钱，因为它出现在用户提问的那一刻。",[11,318,319],{},"实体这件事，最怕的是模糊。宁可少写，别混着写。",{"title":85,"searchDepth":86,"depth":86,"links":321},[322,323,324,325,326,327],{"id":246,"depth":86,"text":247},{"id":256,"depth":86,"text":256},{"id":277,"depth":86,"text":277},{"id":289,"depth":86,"text":289},{"id":301,"depth":86,"text":301},{"id":310,"depth":86,"text":310},"GEO","2025-11-03","产品名和公司名写在同一个标题里，AI 会把两条实体记录合并。后果是品牌词回答错、产品对比缺席。我们拆开三个客户，六周后对比类查询开始出现他们。",{},"\u002Fblog\u002Fproduct-entity-vs-brand-entity",{"title":238,"description":330},"blog\u002Fproduct-entity-vs-brand-entity",[328,336,337],"实体优化","结构化数据","BJ2rTzFo_jFABOs70dYQsXk4Ip-VQu59fxf6Vl7DaO0",1794088111161]