[{"data":1,"prerenderedAt":278},["ShallowReactive",2],{"blog-product-entity-vs-brand-entity":3,"blog-prev-product-entity-vs-brand-entity":117,"blog-next-product-entity-vs-brand-entity":215},{"id":4,"title":5,"author":6,"body":7,"canonical":102,"category":103,"cover":102,"date":104,"description":105,"draft":106,"extension":107,"keywords":102,"meta":108,"navigation":109,"noindex":106,"ogImage":102,"path":110,"seo":111,"seoDescription":102,"seoTitle":102,"stem":112,"tags":113,"updated":102,"__hash__":116},"blog\u002Fblog\u002Fproduct-entity-vs-brand-entity.md","产品实体和品牌实体混在一页，AI 会把公司当产品","元析智能",{"type":8,"value":9,"toc":92},"minimark",[10,14,19,22,25,28,35,41,47,50,53,56,59,62,65,68,71,74,77,80,83,86,89],[11,12,13],"p",{},"产品名和公司名写在同一个标题里，AI 会把两条实体记录合成一条。这不是理论，是我们 10 月在一个客户身上看到的：他们的产品页标题是\"XX 数据平台 - XX 科技\"，结果搜产品名时，AI 回答的是公司简介；搜公司名时，AI 回答的是产品功能。两边都答得半对。",[15,16,18],"h2",{"id":17},"在-ai-眼里这是两条记录","在 AI 眼里，这是两条记录",[11,20,21],{},"品牌实体是公司：法人、地址、成立时间、员工数、融资、客户。产品实体是软件：功能、版本、定价、部署方式、兼容性、许可证。",[11,23,24],{},"这两条记录在知识图谱里各有节点，用\"开发方\"这类关系连着。你把它们塞进一个页面、一个标题，引擎就得自己猜哪个是哪个。猜错不要紧，要紧的是它猜完就固定了，后面很难改。",[15,26,27],{"id":27},"混写的三个后果",[11,29,30,34],{},[31,32,33],"strong",{},"品牌词回答变窄。"," 搜公司名，回答里全是产品功能，看不到团队规模和客户类型，采购方判断不了你靠不靠谱。",[11,36,37,40],{},[31,38,39],{},"对比类查询缺席。"," 用户搜\"XX 和 YY 哪个好\"，AI 需要一个能被拿来对比的产品条目。条目不存在，它就不提你。我们查了 4 个混写客户的对比类查询，40 个查询里出现 3 次。拆开之后是 17 次。",[11,42,43,46],{},[31,44,45],{},"结构化数据打架。"," 同一页里放 Organization 和 SoftwareApplication，属性互相污染。有人把定价写到 Organization 的 priceRange 里，机器读出来就是\"这家公司收费 99 元\"。",[15,48,49],{"id":49},"拆开的三条做法",[11,51,52],{},"第一，产品页独立。每个产品一条 URL，标题只写产品名，不带公司后缀。公司名放到正文第一段和页脚。",[11,54,55],{},"第二，schema 分开写。Organization 放公司页和全站页脚，SoftwareApplication 放产品页。SoftwareApplication 里至少给 name、applicationCategory、operatingSystem、offers 四项。别偷懒只写 name。",[11,57,58],{},"第三，命名统一。产品名在所有渠道用同一个写法，包括大小写。产品名里有版本号的就别把版本号写进主名称，\"XX 2.0\"和\"XX\"是两个实体。",[15,60,61],{"id":61},"一个客户的六个月",[11,63,64],{},"那个数据平台客户，11 月开始拆。做了三件事：产品页改标题、产品页加 SoftwareApplication、About 页补公司信息。",[11,66,67],{},"六周复查：搜产品名，回答里出现功能描述的比例从 30% 到 78%；搜公司名，出现客户类型和团队规模的比例从 0 到 60%；对比类查询从 3 次到 17 次。",[11,69,70],{},"没有新写内容，只是把已有的信息归位。",[15,72,73],{"id":73},"什么时候不用拆",[11,75,76],{},"只有一个产品、且产品名就是公司名的情况，不用拆。比如很多工具类公司，公司叫 X，产品也叫 X。这时候一条记录更清楚。",[11,78,79],{},"判断标准是：你的客户会不会用\"你们公司\"和\"你们产品\"问两个不同的问题。会，就该拆。不会，别折腾。",[15,81,82],{"id":82},"一个容易被忽略的连带影响",[11,84,85],{},"拆实体还会顺带修好一个东西：AI 回答里的\"适合谁\"。混写的时候，引擎只能从公司层面判断，于是把你们推给所有人，或者推给所有人里最便宜的那批。产品实体独立之后，它能从功能、部署方式、定价区间推出适用规模，推荐就变准了。",[11,87,88],{},"我们那个客户拆完两个月，AI 回答里开始出现\"适合 50 到 200 人的团队\"这类描述。这种句子比任何广告词都值钱，因为它出现在用户提问的那一刻。",[11,90,91],{},"实体这件事，最怕的是模糊。宁可少写，别混着写。",{"title":93,"searchDepth":94,"depth":94,"links":95},"",2,[96,97,98,99,100,101],{"id":17,"depth":94,"text":18},{"id":27,"depth":94,"text":27},{"id":49,"depth":94,"text":49},{"id":61,"depth":94,"text":61},{"id":73,"depth":94,"text":73},{"id":82,"depth":94,"text":82},null,"GEO","2025-11-03","产品名和公司名写在同一个标题里，AI 会把两条实体记录合并。后果是品牌词回答错、产品对比缺席。我们拆开三个客户，六周后对比类查询开始出现他们。",false,"md",{},true,"\u002Fblog\u002Fproduct-entity-vs-brand-entity",{"title":5,"description":105},"blog\u002Fproduct-entity-vs-brand-entity",[103,114,115],"实体优化","结构化数据","BJ2rTzFo_jFABOs70dYQsXk4Ip-VQu59fxf6Vl7DaO0",{"id":118,"title":119,"author":6,"body":120,"canonical":102,"category":203,"cover":102,"date":204,"description":205,"draft":106,"extension":107,"keywords":102,"meta":206,"navigation":109,"noindex":106,"ogImage":102,"path":207,"seo":208,"seoDescription":102,"seoTitle":102,"stem":209,"tags":210,"updated":102,"__hash__":214},"blog\u002Fblog\u002Fold-post-rewrite-judgment.md","旧文翻新前先判断：这篇到底值不值得重写",{"type":8,"value":121,"toc":194},[122,125,129,132,135,139,142,145,149,152,155,158,161,164,167,170,173,176,179,182,185,188,191],[11,123,124],{},"旧文翻新最大的浪费，是把一篇救不回来的文章改了三个版本。我们的做法是先判断，再动手。2025 年 9 月整理了一批 40 篇 2023 年到 2024 年的老文，判断下来只重写 12 篇，8 周后其中 9 篇回到前 20 名，剩下 28 篇里 19 篇合并、9 篇删除。",[15,126,128],{"id":127},"第一个问题还有搜索需求吗","第一个问题：还有搜索需求吗",[11,130,131],{},"翻出这个页面最近 12 个月的曝光和点击。曝光持续下滑到接近 0 的，先别改，去查关键词还在不在被搜。",[11,133,134],{},"有时候不是文章不行，是那个词没人搜了。产品功能改名、行业换说法、用户改用英文缩写，这些都会让一个词直接消失。需求没了，重写就是白写。",[15,136,138],{"id":137},"第二个问题有没有排名基础","第二个问题：有没有排名基础",[11,140,141],{},"看这个 URL 现在排在多少名，有没有外链，收录了多久。",[11,143,144],{},"排在前 30 名以内、有一两个外链的，值得救。排在 100 名开外、零外链的，其实等于新写一篇，成本一样，收益更低。",[15,146,148],{"id":147},"第三个问题原文有没有独家内容","第三个问题：原文有没有独家内容",[11,150,151],{},"翻一遍原文，找那些只能从我们这里得到的东西：实测数据、客户场景、内部截图、踩坑记录。",[11,153,154],{},"一条都没有的，弃掉。这种文章重写之后还是跟同行一个样，问题不在文字，在信息存量。",[15,156,157],{"id":157},"决定重写的怎么改",[11,159,160],{},"URL 不动，标题里的核心词不动，正文重排：结论前置，补近两年的数据，加作者署名和更新日期。",[11,162,163],{},"结构上砍掉一半。老文普遍太啰嗦，2023 年那批平均 3200 字，重写后压到 1800 字左右，可读性和抓取效率都更好。",[15,165,166],{"id":166},"一个反常识的观察",[11,168,169],{},"排名下滑最厉害的那批文章，问题往往不在内容质量，在搜索结果页本身变了。搜同样的词，前十多了文档站、视频和问答，你一篇博客挤不进去。",[11,171,172],{},"这种时候该做的不是翻新，是换页面类型：写文档页、做视频、或者把内容搬到能排上去的载体上。我们 2025 年就干过这事，把 6 篇博客改成了产品文档，流量回来了七成。",[15,174,175],{"id":175},"多久做一次",[11,177,178],{},"我们按季度做，每次只看两类：最近 12 个月曝光下滑超过 50% 的，和排名在 11 到 30 名之间卡住的。前一类救，后一类推。",[11,180,181],{},"一次看 30 到 50 篇，两三个小时能出结论。攒到几百篇一起看，判断质量一定下降。",[15,183,184],{"id":184},"重写之后怎么观察",[11,186,187],{},"发布后第 14 天看是否重新被收录，第 28 天看曝光，第 56 天看排名。三周没收录，先查是不是被 noindex 或者被砍了内链。",[11,189,190],{},"我们自己的一个规律是：重写后曝光恢复通常比排名快两到三周。曝光起来了排名不动，说明内容对了但页面权重不够，该补内链而不是继续改稿。",[11,192,193],{},"翻新不是改字，是给这篇内容换一个能打的版本。",{"title":93,"searchDepth":94,"depth":94,"links":195},[196,197,198,199,200,201,202],{"id":127,"depth":94,"text":128},{"id":137,"depth":94,"text":138},{"id":147,"depth":94,"text":148},{"id":157,"depth":94,"text":157},{"id":166,"depth":94,"text":166},{"id":175,"depth":94,"text":175},{"id":184,"depth":94,"text":184},"内容运营","2025-11-02","翻新旧文先问三个问题：还有搜索需求吗、有没有排名基础、原文有没有别人没有的东西。40 篇老文里我们只重写了 12 篇，8 周后 9 篇回到前 20，其余直接删或并。",{},"\u002Fblog\u002Fold-post-rewrite-judgment",{"title":119,"description":205},"blog\u002Fold-post-rewrite-judgment",[211,212,213],"旧文翻新","内容更新","SEO复盘","jv6-BYvQEOmZQZ02WeVIXY2ClGoGx20kFtU10fn7xmg",{"id":216,"title":217,"author":6,"body":218,"canonical":102,"category":266,"cover":102,"date":267,"description":268,"draft":106,"extension":107,"keywords":102,"meta":269,"navigation":109,"noindex":106,"ogImage":102,"path":270,"seo":271,"seoDescription":102,"seoTitle":102,"stem":272,"tags":273,"updated":102,"__hash__":277},"blog\u002Fblog\u002Fremoved-reciprocal-links-review.md","我们撤掉 23 条友链之后：排名没掉，抓取频次涨了四成",{"type":8,"value":219,"toc":261},[220,223,227,230,233,236,240,243,246,249,252,255,258],[11,221,222],{},"老板最怕的一件事是\"链接一撤，排名就掉\"。今年 7 月我们建议一个做工程管理软件的客户撤掉 23 条存量友链，客户犹豫了两周才同意。撤完 6 周的数据和我们预期的一样：排名没掉，抓取反而变快了。",[15,224,226],{"id":225},"为什么要撤这-23-条","为什么要撤这 23 条",[11,228,229],{},"这 23 条是 2019 到 2021 年之间换的，那时候没人审，谁找上门都换。我们逐条查历史快照后发现：6 条来自同一批注册的域名；4 条页面已经改成了赌博类内容；3 条页面 404；剩下 10 条是导航站和采集站，页面上挂着一两百条外链。",[11,231,232],{},"这种链接挂在站上，唯一的作用是让蜘蛛顺着爬到一堆垃圾页面上。它不会直接让你降权，但会持续稀释抓取预算，也会让站点的链接关系变得混乱。",[11,234,235],{},"撤之前我们做了一张对照表，把每条链接的页面状态、收录情况、历史快照、主题相关度标在一行里。23 条里能通过我们验收四步的只有 1 条。这张表交给客户看的当天，对方就同意了。后来我把它固定成模板，每次盘存量链接都用，比口头讲风险管用得多。",[15,237,239],{"id":238},"撤的过程怎么撤才不伤站","撤的过程：怎么撤才不伤站",[11,241,242],{},"没有一次性删。23 条分三批，每周撤 8 条左右，撤之前存档截图和 URL。不是因为分批有技术上的必要，是为了方便观察，万一有波动能定位到是哪一批。",[11,244,245],{},"对还在运营的站点，我们提前发了通知邮件，说明因站点调整下掉链接，语气客气，留了 7 天时间让对方也处理。对方的反应大多很淡，没人追究。",[11,247,248],{},"有一点要提醒：撤链之前先确认自己的站内结构没问题。如果站内本来就有一堆死链、空分类，撤完看不到变化，就会误判成\"撤链没用\"。",[15,250,251],{"id":251},"六周后我们看的四组数据",[11,253,254],{},"核心词进前 10 的数量，从 11 个变成 12 个；百度蜘蛛日抓取量，从 1400 次涨到 2000 次；首页快照更新时间，从 9 天缩到 2 天；GSC 引荐流量从每月 260 次降到 244 次，掉了 6%。",[11,256,257],{},"最后这个数就是撤链的可见代价，掉了 6% 的引荐流量，换来抓取和快照的改善。我觉得这笔账划算，因为引荐流量里那部分本来也不是目标客户。",[11,259,260],{},"存量垃圾链接是负债。它不像内容那么显眼，但每个月都在产生成本。真要说风险，最大的风险是\"一直没盘点过\"。",{"title":93,"searchDepth":94,"depth":94,"links":262},[263,264,265],{"id":225,"depth":94,"text":226},{"id":238,"depth":94,"text":239},{"id":251,"depth":94,"text":251},"技术SEO","2025-11-04","2025 年 7 月我们建议一个客户撤掉 23 条存量友链，客户最怕排名崩。撤完 6 周的数据：核心词前 10 数量没掉，百度蜘蛛日抓取从 1400 次涨到 2000 次，首页快照从 9 天缩到 2 天。",{},"\u002Fblog\u002Fremoved-reciprocal-links-review",{"title":217,"description":268},"blog\u002Fremoved-reciprocal-links-review",[274,275,276],"友链清理","抓取频次","复盘","pIeWGQT-bSPb3kH5pMywigubVLj7cFQp5N16MOJJdgM",1794088111141]