博客首页该按发布时间还是更新时间排序？一次踩坑记录

我干了什么

前几天我把博客首页的信息流改成了「按最近更新时间排序」。

想法很简单：我经常回头修改老文章（补图、改错字、加一段新发现），让它们排到前面，读者和爬虫都能优先看到最新维护过的内容。

结果第二天我自己就把它改回去了。

现象：一年前的文章跑到了第一条

改完之后我随手对比了一下两种排序的结果：

排序方式	首页第一条
按发布时间	《Edge TTS 到底谁在合成…》2026-09-28 当天发布
按修改时间	《空白字符导致 sitemap 无法显示》2025-09-20 发布

第二篇是一年前的文章，那天只是被我编辑过一次（可能只是改了个错字、调了下排版），就顶到了所有新文章前面。

这不是偶发情况，而是这种排序方式的必然结果：

==按修改时间排序 = 谁被碰过谁最大==

而「被碰过」和「内容真的更新了」是两件完全不同的事。

为什么这对收录是有害的

先把话说清楚：排序方式不会直接决定搜索引擎收不收某篇文章。但它是通过下面这几条间接起作用的。

1. 首页是站内权重最高的位置

首页拿到的内部链接权重是整站最高的。按发布时间排序，等于「最新的内容优先获得首页链接」—— 而新文章恰恰是最需要这个助推的：它还没有任何外部链接，也没有任何历史抓取记录。

改成按修改时间排序，就等于把首页的黄金位让给「刚被工具扫过一遍的老文章」，把新文章挤到第二页之后。对新文章的抓取和收录是反向作用。

2. 和 dateModified 用同一个信号，会放大「假更新」的观感

这是更隐蔽的一点。

文章的结构化数据（JSON-LD）里有一个字段叫 dateModified，我原来是用 WordPress 的 get_the_modified_date() 填的。也就是说：

首页排序   ← 按 post_modified
结构化数据 ← dateModified = post_modified

两条线指的是同一个信号。如果这个信号本身不含金（只是改了个错字），那搜索引擎看到的就是「这个站最近更新了一大批文章」，点进去却发现内容根本没变。

搜索引擎对这种情况的处理很直接：忽略与内容变更不符的 dateModified。信号一旦被判定不可信，以后再真更新也不容易被采信。

3. datePublished 和 dateModified 的分工

这两个字段各管一段，不该混用：

字段	含义	谁在用
datePublished	首次公开发布时间	搜索结果的日期展示、判断内容新旧
dateModified	最后一次实质性修改时间	新鲜度信号、内容更新提醒

关键在于 dateModified 前面那两个字：实质性。换封面、改错字都不算。

4. 归档页也被一起改了

我原来的代码里写的是 is_home() || is_archive()，所以分类页、标签页、日期归档页全部跟着变了。分类页里 2024 年的文章排到了 2026 年前面，读者看着乱，主题聚合的意义也没了。

而日期归档页本身就是被 noindex 的薄内容页，为它改变行为就更没必要了。

什么时候按更新时间排才是对的

不是所有站点都该按发布时间排。持续维护的长青文档库（教程、手册、API 文档）按更新时间排是合理的 —— 前提是每次「更新」都是实质性的内容补充，而不是格式微调。

判断标准可以简化成一句：

你的「更新」里，有多大比例是真正加了内容的？

如果超过一半只是格式、错字、图片调整，那按更新时间排序就是在给自己制造噪音。

正确做法：另开一个「最近更新」区块

如果确实想突出「焕新过的老文章」，更稳的做法是别动主信息流，单独做一个区块：

• 首页底部或侧边栏加一个「最近更新」列表，列 3~5 篇
• 区块里的文章按 post_modified 排，但不影响主信息流的 datePublished 排序

这样新文章和焕新的老文章各得其所，首页的新鲜度信号也不会被污染。

顺带一个坑：批量脚本会污染 post_modified

这条踩得更早，也更难发现。

我的博客是用脚本发文章的：写完 Markdown，跑一条命令就发布或更新到线上。问题在于，脚本更新文章时走的是 WordPress 的更新接口，post_modified 会被刷新。

也就是说，一次「批量给老文章补封面图」的操作，会让这几十篇文章的修改时间全部变成同一天。如果首页是按修改时间排序的，第二天打开首页会看到：

首页前面全是一两年前的老文章，而且时间戳都是昨天

顺带一提：只写自定义字段、不动正文的操作不会刷新 post_modified。这个区别在做批量操作时值得留意。

结论

1. 博客的信息流按发布时间排，这是 WordPress 主查询的默认行为，不需要额外写代码
2. 想让老文章被看到，单独开一个「最近更新」区块，不要动主排序
3. dateModified 要用在「实质性更新」上，否则会失去可信度
4. 批量脚本会刷新 post_modified，任何「按修改时间排序或展示」的功能都要当心被它污染

最后补一句代码上的事：我一开始的「改回默认」是在 pre_get_posts 里显式写了一遍 orderby = 'date'。这是多余的 —— WordPress 主查询默认就是 date DESC，「什么都不做」就是对的。显式写一遍反而制造了一个假的「配置项」，让人误以为默认行为需要这段代码来维持。所以最终是把那段代码整个删掉，只留一条注释说明为什么不能按修改时间排。