[{"data":1,"prerenderedAt":343},["ShallowReactive",2],{"blog-author-page-eeat-fields":3,"blog-prev-author-page-eeat-fields":109,"blog-next-author-page-eeat-fields":271},{"id":4,"title":5,"author":6,"body":7,"canonical":93,"category":94,"cover":93,"date":95,"description":96,"draft":97,"extension":98,"keywords":93,"meta":99,"navigation":100,"noindex":97,"ogImage":93,"path":101,"seo":102,"seoDescription":93,"seoTitle":93,"stem":103,"tags":104,"updated":93,"__hash__":108},"blog\u002Fblog\u002Fauthor-page-eeat-fields.md","博客作者页该写的七个字段，别只放一张头像","元析智能",{"type":8,"value":9,"toc":86},"minimark",[10,14,19,26,32,38,44,50,56,62,65,68,71,74,77,80,83],[11,12,13],"p",{},"作者页不是装饰，它是搜索引擎和 AI 搜索判断\"这篇文章谁写的、凭什么信\"的落点。我们审过 30 多个软件站的作者页，真正合格的不到三成，多数只放了一张头像和一句\"内容团队\"。",[15,16,18],"h2",{"id":17},"七个字段一个都别省","七个字段，一个都别省",[11,20,21,25],{},[22,23,24],"strong",{},"真实姓名。"," 不是\"运营团队\"\"编辑部\"，是能对应到一个真人。匿名作者页在信任信号上基本等于没有。",[11,27,28,31],{},[22,29,30],{},"职位和负责范围。"," 写清楚这个人负责什么内容，比如\"负责 API 与集成方向的技术内容\"。范围越具体，读者越容易判断该不该信。",[11,33,34,37],{},[22,35,36],{},"履历。"," 做过什么产品、在什么行业待了几年、有没有落地的项目。不需要写成简历，两三句话，但要具体。",[11,39,40,43],{},[22,41,42],{},"可验证痕迹。"," GitHub 账号、知乎主页、领英、公开演讲、开源项目、专利。这一项最值钱，因为别人能去查证。",[11,45,46,49],{},[22,47,48],{},"社交账号互链。"," 从作者页能点到他的公开账号，也能从账号资料点回来。双向可查，可信度才成立。",[11,51,52,55],{},[22,53,54],{},"联系方式。"," 邮箱或表单。能联系上，是\"真人负责\"的最直接证据。",[11,57,58,61],{},[22,59,60],{},"文章列表和更新时间。"," 这个作者写过哪些文章，最近一次更新是什么时候。没有文章列表的作者页，等于一个空壳。",[15,63,64],{"id":64},"我们的两条验收标准",[11,66,67],{},"第一条，把作者名字复制到搜索引擎查一遍，能不能找到这个人的其他痕迹。如果只在你自己的网站上出现，这个人对搜索引擎来说就不存在。",[11,69,70],{},"第二条，作者页上的技术主张和文章内容对不对得上。我们见过作者页写\"十年数据库经验\"，文章里却把主从复制和分片混着讲，这种反而扣分。",[11,72,73],{},"验收标准落地前后的对比很直观：改之前搜署名作者的名字，只出现自家站；改完两周，搜名字能出来 5 条，包括 GitHub 账号和一次行业论坛的发言。",[15,75,76],{"id":76},"常见的糊弄法",[11,78,79],{},"批量上 stock 头像，五个作者用同一个模板，简介只换个名字。或者作者页写得很漂亮，但文章列表是空的。还有一种是找行业里的人挂名，文章其实是实习生写的，这种一旦被问到就露馅。",[11,81,82],{},"2025 年 12 月我们给一个客户重做作者页，三个作者全部换成实名，并且要求每人认领自己写过的文章。有个作者当场发现，两篇挂着别人名字的文章其实是自己写的，这种情况挺常见，改过来对双方都好。",[11,84,85],{},"作者页补起来成本很低，一个下午就能做完，但它是少数\"做了就一直在起作用\"的事。一个能查到的真人，胜过十个\"内容团队\"。",{"title":87,"searchDepth":88,"depth":88,"links":89},"",2,[90,91,92],{"id":17,"depth":88,"text":18},{"id":64,"depth":88,"text":64},{"id":76,"depth":88,"text":76},null,"SEO","2026-01-23","作者页是 E-E-A-T 里最容易补、也最容易被糊弄的一块。这篇给七个必填字段：真实姓名、职位、履历、可验证痕迹、社交账号、负责范围、联系方式，附两条验收标准。",false,"md",{},true,"\u002Fblog\u002Fauthor-page-eeat-fields",{"title":5,"description":96},"blog\u002Fauthor-page-eeat-fields",[105,106,107],"E-E-A-T","作者页","内容信任","-wPumupjPIEC9hVDE9nWd4d_lKCrpPh92m4_bYXJbVI",{"id":110,"title":111,"author":6,"body":112,"canonical":93,"category":259,"cover":93,"date":260,"description":261,"draft":97,"extension":98,"keywords":93,"meta":262,"navigation":100,"noindex":97,"ogImage":93,"path":263,"seo":264,"seoDescription":93,"seoTitle":93,"stem":265,"tags":266,"updated":93,"__hash__":270},"blog\u002Fblog\u002Fparagraph-topic-sentence-test.md","改了 200 个段落的主题句，AI 引用率从 14% 涨到 26%",{"type":8,"value":113,"toc":252},[114,117,120,123,126,129,132,135,138,194,198,201,204,207,210,213,216,222,228,234,237,240,243,246,249],[11,115,116],{},"把段尾的总结句搬到段首，引用率涨 9 个百分点；在段首新加一句主题句、原句不动，只涨 2 个点。2025 年 12 月到 2026 年 2 月，我们在 40 篇文章、200 个段落上做了这组对照，差别不在句子写得好不好，在位置。",[15,118,119],{"id":119},"为什么段尾总结没用",[11,121,122],{},"很多人写段落是归纳式：先讲三个事实，最后来一句\"所以说 XX 更适合中小团队\"。人读着舒服，机器读不到。",[11,124,125],{},"原因在切块。AI 按 token 窗口切，一段 300 字，切点可能落在 220 字。你放在第 280 字的总结句，被切到下一块去了。下一块没了前提，那句话就孤立，引擎不敢用。",[11,127,128],{},"段首句没有这个问题。它在块的起点，一定被包含在内。",[15,130,131],{"id":131},"三组怎么改的",[11,133,134],{},"A 组：段首新加一句主题句，原段落一字不改。\nB 组：把长段落拆成两段，前段给结论，后段展开。\nC 组：把原来的段尾总结句原样搬到段首，删掉段尾那句。",[11,136,137],{},"200 个段落，40 篇文章，三个客户站，各分一组。8 周，每周三跑固定 45 个查询。",[139,140,141,157],"table",{},[142,143,144],"thead",{},[145,146,147,151,154],"tr",{},[148,149,150],"th",{},"组别",[148,152,153],{},"改法",[148,155,156],{},"引用率变化",[158,159,160,172,183],"tbody",{},[145,161,162,166,169],{},[163,164,165],"td",{},"A",[163,167,168],{},"段首加主题句",[163,170,171],{},"+2pp",[145,173,174,177,180],{},[163,175,176],{},"B",[163,178,179],{},"段落拆分",[163,181,182],{},"+6pp",[145,184,185,188,191],{},[163,186,187],{},"C",[163,189,190],{},"总结句前移",[163,192,193],{},"+9pp",[15,195,197],{"id":196},"c-组为什么赢","C 组为什么赢",[11,199,200],{},"因为 C 组改的是同一句话的位置，内容没变，所以变量干净。",[11,202,203],{},"A 组加了新句子，段首变长，反而挤掉了原文里的具体信息。我们回看 A 组的段落，主题句大多是\"本节讨论数据同步的三个关键点\"这种，没有事实，加了等于没加。",[11,205,206],{},"B 组有效，但拆段会让段落数量翻倍，读起来碎。我们后来只在超过 400 字的段落上用。",[11,208,209],{},"C 组的做法最省事：找到段尾那句总结，剪到段首，检查一下衔接。一个编辑一天能改 60 段。",[15,211,212],{"id":212},"主题句怎么写",[11,214,215],{},"三个能直接用的句式：",[11,217,218,221],{},[22,219,220],{},"给判断。","\"同步延迟主要卡在跨区域这一环。\"",[11,223,224,227],{},[22,225,226],{},"给边界。","\"这套方案只适合 500 人以下团队，再大要改分片。\"",[11,229,230,233],{},[22,231,232],{},"给数字。","\"改这一处，平均省 40% 的同步时间。\"",[11,235,236],{},"三种都有共同点：句子本身是完整信息，不需要后文。",[11,238,239],{},"别用的句式：本节将讨论、下面介绍、以下几点。这些句子把信息推到后面，等于把可引用点让出去。",[15,241,242],{"id":242},"一个反常识的结论",[11,244,245],{},"段尾总结在 AI 搜索时代是浪费。它本来是为了让读者不用回看，现在读者是机器，机器不回看，机器只看切出来的那一块。",[11,247,248],{},"我们现在的编辑规范里有一条：段落最后一句不许写总结。要么删，要么移到最前面。",[11,250,251],{},"改完 200 段，最直观的感受是文章变硬了。每段开头都是一句能单独站住的话，读起来像在听人下判断，不是听人铺垫。",{"title":87,"searchDepth":88,"depth":88,"links":253},[254,255,256,257,258],{"id":119,"depth":88,"text":119},{"id":131,"depth":88,"text":131},{"id":196,"depth":88,"text":197},{"id":212,"depth":88,"text":212},{"id":242,"depth":88,"text":242},"GEO","2026-01-22","40 篇文章、三种改法对照 8 周。把段尾总结搬到段首那组涨 9 个百分点，单纯加一句主题句那组几乎没动。差别在句子位置，不在句子质量。",{},"\u002Fblog\u002Fparagraph-topic-sentence-test",{"title":111,"description":261},"blog\u002Fparagraph-topic-sentence-test",[259,267,268,269],"内容写作","主题句","AI引用","LHYrq3mP3cXXJrQrn8FL86UIdtcC5HyitUO0dOUOM8w",{"id":272,"title":273,"author":6,"body":274,"canonical":93,"category":259,"cover":93,"date":333,"description":334,"draft":97,"extension":98,"keywords":93,"meta":335,"navigation":100,"noindex":97,"ogImage":93,"path":336,"seo":337,"seoDescription":93,"seoTitle":93,"stem":338,"tags":339,"updated":93,"__hash__":342},"blog\u002Fblog\u002Fai-tool-citation-tracking.md","AI 搜索带来的流量怎么算：我们用了三个土办法",{"type":8,"value":275,"toc":327},[276,279,283,286,289,293,296,299,303,306,309,312,315,318,321,324],[11,277,278],{},"AI 回答引擎带来的流量，在网站分析工具里基本是隐形的。2025 年 12 月到 2026 年 1 月，我们想搞清楚一个 AI 写作工具的注册里有多少来自 AI 搜索，四个主流分析工具只识别出 3% 到 5%，最后用三个土办法交叉出来一个数：11% 左右。",[15,280,282],{"id":281},"办法一翻服务端日志","办法一：翻服务端日志",[11,284,285],{},"分析工具靠 referrer 识别来源，但 ChatGPT、Perplexity 这类入口的 referrer 经常被抹掉，或者显示成裸 URL。我们直接看服务器访问日志，按 UA 和来源 IP 段筛，把可疑的部分单独统计。",[11,287,288],{},"这个办法不精确，模型调用的抓取和用户点击混在一起，但能看趋势。我们连续看了 6 周，来自几个已知 AI 服务的请求量每周涨 8% 到 15%。",[15,290,292],{"id":291},"办法二注册问卷加一个选项","办法二：注册问卷加一个选项",[11,294,295],{},"在注册表单里加一个下拉：“你是怎么知道我们的”，选项里放“AI 助手推荐”。这个办法的覆盖率低，愿意填的不到四成，但填的人很准。",[11,297,298],{},"那个 AI 写作工具加了这个选项后，第一个月有 62 个人选了 AI 推荐，占注册总数的 9%。加上不填的人按比例折算，接近 11%。",[15,300,302],{"id":301},"办法三看品牌词的搜索形态","办法三：看品牌词的搜索形态",[11,304,305],{},"被 AI 引用多了，品牌词会变异。用户看到推荐后会搜“XX 工具 好用吗”“XX 和 YY 区别”，这类带比较和评价的长尾词会先涨。我们看 Search Console 里品牌词加疑问词组合的展示量，两个月涨了 140%。",[11,307,308],{},"这条线只能当辅助证据，不能当结论。但三条线指向一致时，判断就比较稳了。",[15,310,311],{"id":311},"那到底该怎么优化",[11,313,314],{},"先说一个反直觉的结论：AI 引用和搜索排名不是一回事。我们看过几个页面，Google 排第七第八，被 AI 引用得反而多。原因是 AI 引用更看内容能不能被拆成一句话答案。",[11,316,317],{},"具体做法：每个页面第一段就给结论，别铺垫；关键数据单独成句；给表格和清单，别全是长段落；作者和更新时间写清楚。这些改动对排名的帮助有限，对 AI 引用的帮助明显。",[11,319,320],{},"还有一个观察，AI 引用更偏爱有明确数字和边界的页面。“我们支持 12 种格式”比“支持多种格式”更容易被引用。写内容时把“多、快、好”换成数字，成本很低。",[11,322,323],{},"最后一个建议：把 AI 引用当口碑渠道管。我们每月截一次回答引擎里提到客户产品的原句，看有没有说错、有没有过时信息，发现错误就改对应的源页面，比追排名实在。",[11,325,326],{},"追踪 AI 流量别追精确值，追趋势和结构。知道它大概占多少、哪些页面在被引用、用户来了之后干了什么，够做决策了。",{"title":87,"searchDepth":88,"depth":88,"links":328},[329,330,331,332],{"id":281,"depth":88,"text":282},{"id":291,"depth":88,"text":292},{"id":301,"depth":88,"text":302},{"id":311,"depth":88,"text":311},"2026-01-24","分析工具里 AI 来源的会话大多归到 direct 或 referral。我们用日志、问卷和品牌词三条线交叉验证，摸清了一个 AI 工具客户 11% 的注册来自回答引擎。",{},"\u002Fblog\u002Fai-tool-citation-tracking",{"title":273,"description":334},"blog\u002Fai-tool-citation-tracking",[259,340,341],"AI 搜索","数据分析","zM8SZJ_Nj-cNvUq8iouhDUwCpMo6rqlg6PuQ1Bl4lOY",1794088108980]