[{"data":1,"prerenderedAt":245},["ShallowReactive",2],{"blog-baidu-ranking-weight-changes":3,"blog-prev-baidu-ranking-weight-changes":87,"blog-next-baidu-ranking-weight-changes":155},{"id":4,"title":5,"author":6,"body":7,"canonical":71,"category":72,"cover":71,"date":73,"description":74,"draft":75,"extension":76,"keywords":71,"meta":77,"navigation":78,"noindex":75,"ogImage":71,"path":79,"seo":80,"seoDescription":71,"seoTitle":71,"stem":81,"tags":82,"updated":71,"__hash__":86},"blog\u002Fblog\u002Fbaidu-ranking-weight-changes.md","百度排名机制里，我们测出的三个权重变化","元析智能",{"type":8,"value":9,"toc":63},"minimark",[10,14,19,22,25,28,32,35,38,41,45,48,51,54,57,60],[11,12,13],"p",{},"2025 年我们盯了 28 个软件公司的站点，百度排名机制有三个变化比较确定：整站评价压过单页优化、外链权重继续让位给品牌搜索、老内容不更新就往下掉。不是猜的，是同一个词逐月追出来的。",[15,16,18],"h2",{"id":17},"变化一整站评价压过单页优化","变化一：整站评价压过单页优化",[11,20,21],{},"以前一个页面优化到位，能单独把排名顶上去。2025 年下半年开始，这件事越来越难。",[11,23,24],{},"我们有个客户做了个对比：同一个产品词，A 页面优化了标题、正文、内链，但整站有 30% 的页面是空壳；B 页面只做了基础优化，整站结构干净。三个月后 B 排到第 6，A 在第 14 徘徊。",[11,26,27],{},"判断依据：百度现在给的更像是\"站点级\"的评价，单页只占一部分。所以我们给客户做诊断，先看整站有多少页面是\"删掉也没损失\"的，比例超过 30% 就先做减法。",[15,29,31],{"id":30},"变化二外链权重继续让位给品牌搜索","变化二：外链权重继续让位给品牌搜索",[11,33,34],{},"这件事我们从 2024 年就在观察，2025 年更明显。",[11,36,37],{},"监测数据：12 个站里，品牌词月搜索量超过 500 的 5 个站，核心词平均排名第 7；品牌词低于 100 的 7 个站，核心词平均排名第 19。两组站的内容质量、外链数量差不多。这个对比我们去年 11 月又做了一遍，结论没变。",[11,39,40],{},"差异在品牌。用户主动搜你的名字，百度会把这个信号当成\"这个站有人认\"，反过来给核心词加权。买外链做不出这个信号。",[15,42,44],{"id":43},"变化三老内容不更新就往下掉","变化三：老内容不更新就往下掉",[11,46,47],{},"2025 年 9 月我们抽查了 6 个站的 200 个老页面，其中 74 个页面在过去一年没有任何更新，这 74 个里有 51 个排名掉了 5 名以上。",[11,49,50],{},"不是所有内容都要更新。我们的做法是分两类：产品功能页每季度对一遍，价格、版本号、截图必须是最新的；教程类文章每年补一次案例，标题加年份。",[11,52,53],{},"一个做 API 文档的客户，把 30 篇核心教程加了\"2025 年更新\"的版本说明和一段新案例，两个月后这批页面平均排名从 11 升到 8。",[15,55,56],{"id":56},"我们怎么应对",[11,58,59],{},"三件事：砍掉没价值的页面、把品牌词做起来、给老内容定更新节奏。第一件见效最快，通常一个月内能看到收录和抓取的变化。",[11,61,62],{},"品牌这件事最慢，也最难外包。我们的建议是从行业媒体曝光和社区内容开始，先让一部分人搜你的名字，再谈排名。这三个变化，我们每季度会重新验证一次，有变化再更新。顺序别反：先有内容和曝光，再有品牌搜索，最后才是排名加权。",{"title":64,"searchDepth":65,"depth":65,"links":66},"",2,[67,68,69,70],{"id":17,"depth":65,"text":18},{"id":30,"depth":65,"text":31},{"id":43,"depth":65,"text":44},{"id":56,"depth":65,"text":56},null,"行业观察","2025-12-20","2025 年盯了 28 个软件站，百度排名机制有三个变化比较确定：整站评价压过单页优化、外链权重继续让位给品牌搜索、老内容不更新就往下掉。每个变化都有我们自己的监测数据，也都对应了具体的操作调整。",false,"md",{},true,"\u002Fblog\u002Fbaidu-ranking-weight-changes",{"title":5,"description":74},"blog\u002Fbaidu-ranking-weight-changes",[83,84,85],"百度排名","权重变化","监测数据","cUAjsZiBuKrBxPK2fjLE8cSZqCjp81APwyso2dMspT4",{"id":88,"title":89,"author":6,"body":90,"canonical":71,"category":72,"cover":71,"date":144,"description":145,"draft":75,"extension":76,"keywords":71,"meta":146,"navigation":78,"noindex":75,"ogImage":71,"path":147,"seo":148,"seoDescription":71,"seoTitle":71,"stem":149,"tags":150,"updated":71,"__hash__":154},"blog\u002Fblog\u002Fsecurity-software-content-trust.md","安全软件做内容，先过“可验证”这一关",{"type":8,"value":91,"toc":138},[92,95,98,101,104,107,110,113,117,120,123,126,129,132,135],[11,93,94],{},"给安全软件写内容，和给普通 SaaS 写不是一回事。安全产品的读者是攻防背景的人，他们读你的官网时，默认假设你在吹。2025 年 9 月我们接手一个终端检测产品的站，官网首页 300 多字里有 40 多个形容词，具体事实不到 5 个。删改三个月后，官网到 demo 申请的转化从 0.9% 涨到 1.7%。",[15,96,97],{"id":97},"什么是可验证的事实",[11,99,100],{},"三类：数字、方法、第三方。数字是自己能查到的，比如检测延迟、规则更新频率、单机资源占用。方法是“我们怎么做”的具体描述，比如“基于行为链的检测，不看单点特征”。第三方是评测结果、认证、公开的漏洞响应记录。",[11,102,103],{},"不可验证的是：“业界第一个”“检测能力行业靠前”“获多家头部客户认可”。这些话在安全圈是负资产，读者会认为你没东西可说。",[15,105,106],{"id":106},"一个具体的改写",[11,108,109],{},"客户原来的产品页写“实时检测各类高级威胁，防护能力强”。我们改成：检测延迟 200 毫秒以内，规则库每 4 小时更新一次，支持 ATT&CK 矩阵里 11 个战术的 168 个技术点，误报率在 2025 年第三方测试中为 0.7%。",[11,111,112],{},"这段改写里每个数都是客户工程团队给的，我们只负责把它从内部文档搬到官网上。改完之后，产品页的跳出率降了 11 个百分点。",[15,114,116],{"id":115},"博客要写攻防不要写行业趋势","博客要写攻防，不要写行业趋势",[11,118,119],{},"安全读者会看技术分析，不会看“2026 年安全趋势预测”。能带来搜索流量的是具体的攻击手法分析、漏洞响应复盘、配置加固指南。我们做过的一个 LDAP 注入分析页，每月带来 700 多次自然访问，还引来了两个行业媒体的转载。",[11,121,122],{},"写这类内容有个前提：你有真东西。编不了。所以安全软件的内容策略，本质上是把工程团队的知识搬到公开页面，不是市场部写稿。",[15,124,125],{"id":125},"三个不该做的事",[11,127,128],{},"第一，不要在页面上做恐吓式营销。“你的数据可能已被泄露”这类话术，在安全采购里会引起反感，而且容易被平台判定为不良内容。",[11,130,131],{},"第二，不要抄竞品的对比结论。安全产品的对比有实测门槛，抄来的结论一测就穿帮。",[11,133,134],{},"第三，不要用“军用级”“银行级”这类词。国内安全行业早年这么写，现在读者看到只会觉得不靠谱。",[11,136,137],{},"安全软件的内容做得对不对，有个简单判断：把你官网发给一个做安全的朋友，看他会不会问“你们这个是怎么测的”。会问，说明内容有信息量；不会问，说明他已经在心里归档成广告了。",{"title":64,"searchDepth":65,"depth":65,"links":139},[140,141,142,143],{"id":97,"depth":65,"text":97},{"id":106,"depth":65,"text":106},{"id":115,"depth":65,"text":116},{"id":125,"depth":65,"text":125},"2025-12-19","安全产品的读者会验证你说的每句话，形容词越多信任越少。我们把客户官网的形容词删掉 60%，换成可验证的数字、方法和第三方记录，三个月后询盘质量明显变好。",{},"\u002Fblog\u002Fsecurity-software-content-trust",{"title":89,"description":145},"blog\u002Fsecurity-software-content-trust",[151,152,153],"安全软件","内容策略","信任建设","-UletqlWDdBoEwfXhJuxYXDvjGXPhknKAEKc0iTgbfU",{"id":156,"title":157,"author":6,"body":158,"canonical":71,"category":233,"cover":71,"date":234,"description":235,"draft":75,"extension":76,"keywords":71,"meta":236,"navigation":78,"noindex":75,"ogImage":71,"path":237,"seo":238,"seoDescription":71,"seoTitle":71,"stem":239,"tags":240,"updated":71,"__hash__":244},"blog\u002Fblog\u002Fscreaming-frog-large-crawl-config.md","爬十万个页面，Screaming Frog 配置先改五处",{"type":8,"value":159,"toc":225},[160,163,167,170,173,177,180,183,187,190,193,197,200,203,207,210,213,216,219,222],[11,161,162],{},"2025 年 12 月我们爬一个文档站，12 万个 URL，第一次跑完导出结果一看，8 万条是带参数的重复页，真正要看的没几页。不是工具不行，是配置默认值适合小站，大站照默认跑就是浪费时间。",[15,164,166],{"id":165},"第一处渲染方式","第一处：渲染方式",[11,168,169],{},"默认不执行 JavaScript，抓的是源码。内容靠前端渲染的站，这么抓回来一片空白。开渲染之前先确认必要性，开了之后速度会慢好几倍，十几万页能跑到第二天。",[11,171,172],{},"我的做法是先关掉渲染快速跑一遍，看 HTML 里有没有正文。有就不开，没有才开，并且把渲染超时从默认的几秒调到 10 秒左右，否则异步加载的内容抓不全。",[15,174,176],{"id":175},"第二处抓取范围","第二处：抓取范围",[11,178,179],{},"用包含和排除规则把范围框住，比爬完再筛有效。要排除的东西很固定：会话 ID、排序参数、日历归档、筛选参数、文件下载、后台路径。",[11,181,182],{},"我们那 12 万 URL 里，光带排序参数的就有 5 万多。加一条正则排除之后，实际需要爬的只剩 3 万出头。",[15,184,186],{"id":185},"第三处限速和并发","第三处：限速和并发",[11,188,189],{},"默认并发对生产站有压力，尤其是共享服务器的小站。爬之前先跟运维确认能不能爬、什么时段爬。我们通常把并发降到 2，加上延迟，放在夜里跑。",[11,191,192],{},"曾经有一次没降速，把一个客户的电商站爬得响应变慢，第二天被运维投诉。从那以后，我们的规矩是先小样本跑 200 页，看服务器负载再放量。",[15,194,196],{"id":195},"第四处robots-与-ua","第四处：robots 与 UA",[11,198,199],{},"要不要遵守 robots，取决于目的。做诊断时遵守，能真实反映搜索引擎看到的东西；做覆盖度检查时可以临时不遵守，但要标记出来，别把结果混着看。",[11,201,202],{},"UA 也建议改一下，带上自己的标识，万一爬出问题对方能找到人。",[15,204,206],{"id":205},"第五处导出和存储","第五处：导出和存储",[11,208,209],{},"十万页以上，内存吃紧，结果文件也大。分批爬，按目录拆开，每批单独导出。导出时只留要看的列：状态码、标题、字数、内链数、canonical、索引设置。",[15,211,212],{"id":212},"爬完先看什么",[11,214,215],{},"结果出来别急着导全表，先看四组数：状态码分布、重复标题数、canonical 指向不一致的页数、内链深度大于 4 的页数。",[11,217,218],{},"第一次爬那个文档站，状态码分布里 200 占 78%，剩下的 22% 全是 301。301 集中在两个旧目录，说明改版时跳转没做干净。这种结论从全表里翻是翻不出来的。",[11,220,221],{},"还有个习惯，每次爬完把结果存一份带日期的 CSV，下次对比用。三个月后能看出抓取问题是在变好还是变坏，这比单次报告有用。",[11,223,224],{},"我现在的习惯是爬之前先写一句话：这次要回答什么问题。写不出来就别爬。工具跑得快不代表有意义，配置和目的不清，爬一百万页也只是生成一个巨大的 CSV。",{"title":64,"searchDepth":65,"depth":65,"links":226},[227,228,229,230,231,232],{"id":165,"depth":65,"text":166},{"id":175,"depth":65,"text":176},{"id":185,"depth":65,"text":186},{"id":195,"depth":65,"text":196},{"id":205,"depth":65,"text":206},{"id":212,"depth":65,"text":212},"技术SEO","2025-12-21","第一次爬一个 12 万 URL 的文档站，跑完发现 8 万条是重复参数页，等于白爬。这篇写大站爬取前必须改的五个配置，以及限速怎么设才不压垮生产环境。",{},"\u002Fblog\u002Fscreaming-frog-large-crawl-config",{"title":157,"description":235},"blog\u002Fscreaming-frog-large-crawl-config",[241,242,243],"Screaming Frog","爬虫配置","技术检测","DCwAhp0UzCMLPG83vMS3jN3KCdRE8kuHWlMloMd0GYM",1794088109881]