# 网站多久更新一次比较合理？

URL: https://caijiao.org/posts/174
Source: docs/posts/174.md
Description: 更新频率不是一个数字，是三类页面各自的节奏：工具页要的是正确性维护而非更新，时效性内容由竞争格局决定，而改 URL 是最贵的那种更新。判断依据来自 Search Console 的日期维度。

这个问题没有统一答案，因为"更新"这个词涵盖了三件代价完全不同的事：修数据、改内容、换 URL。把它们分开之后，频率问题就自己解决了。

## 工具页要的不是更新，是正确性维护

一个换算工具上线之后，页面本身不需要变。它要变的是背后的系数：汇率、税率、单位定义、年份口径。

这类维护的频率由外部数据源决定，不由日历决定。汇率一天一变，税率一年一变，计量单位的定义可能十年不变。按"每周更新一次"去排期，大部分时候是在做无意义的重新构建。

更稳的做法是给每份数据标上"最后核对时间"和"下次核对时间"，到点再更新。Omni Calculator 覆盖 30 多种语言、页面以千计，如果靠人工定期巡检，光是核对一遍就不可行——它靠的是把数据源和页面解耦，页面只是配置的渲染结果。

![Omni Calculator 官网首页截图](/images/2026-09/omnicalculator.com.png)

*Omni Calculator 首页还有一个 Discover Omni 板块，自我介绍是「用计算揭示世界的惊人真相」。*

页面上应该把"数据更新至 X 年 X 月"写出来。这句话对用户是信息，对搜索引擎是明确的时效性声明，比任何"最近更新"的标记都管用。

## 时效性内容由竞争格局决定，不由内容决定

"2026 年怎么配置 nginx"这类内容，更新时间点应该看竞争者在什么时候动。

具体做法：搜这个核心词，看前五条结果的页面上写着什么版本、什么时间。如果它们都停留在上一个大版本，你在新版本发布后一周内更新，就能拿到一段明显的窗口期。如果它们已经在跟进，你慢一周就没什么意义了。

判断标准是这个词的搜索结果页变化速度，不是内容的自然老化速度。有些主题三年不变，你每年重写一遍也没人看；有些主题一个季度一变，四周不更新就开始掉。

## 用数据判断，不要用日历拍

在 [Search Console](/google-search-central/02-search-console-setup) 里按页面筛选，把时间维度拉到 16 个月，看这个页面的展现量曲线。

曲线平稳的页面，不需要更新。曲线缓慢下滑、但查询词没变的，通常是竞争者进来了，值得改。曲线断崖下跌、且查询词发生变化，说明这个词的意图整体迁移了，改页面不如换选题。

这个判断里最容易被忽略的是"查询词变化"。很多时候流量掉了不是页面变差了，是用户换了一种说法，而你的页面还在用旧说法。这种情况下该改的是标题和 H1，不是正文。

还有一类下滑是季节性的，误判的代价最大。把时间维度拉到 16 个月而不是 3 个月，能看出这个曲线是不是每年同期都往下走。季节性下滑的页面去"更新"，唯一的产出是把一个没问题的页面改成了另一个样子。

## 改 URL 是最贵的更新，能不做就不做

三件事里代价最高的是换 URL。它带来一串连锁动作：301 重定向、内链批量修改、sitemap 更新、外链失效（那些你改不了的）。

在 [nginx](/nginx/) 里配 rewrite 规则本身不难，难的是规则会累积。改过三轮之后，站点里会躺着几十条互相覆盖的 rewrite，没人记得哪条还生效。

所以 URL 的设计要在第一次就留够余量。如果确实必须改——比如类别结构整体调整——一次性改完并保留全部旧规则，比分批改更清楚。分批改会让站点在半年内同时存在两套结构，这期间的状态最难诊断。

改之前还有一件事要做：把现有页面的 URL 和外链来源导出一份存档。改完之后核对哪些旧 URL 有外部引用，对这些单独做精确的重定向，而不是靠通配规则兜底。通配规则会把大量无关路径也重定向到首页，那等于把它们全部放弃了。

## 部署节奏跟着构建成本走

静态站点的更新成本主要在构建和部署上。八千页全量构建三分钟，一天构建两次毫无压力；半小时的话，就得做增量构建，只重建变更的类别分片。

用 [Docker](/docker/) 打包部署的站点，更新就是换一个镜像标签，回滚也是换回去。这个能力决定了你敢不敢频繁更新——没有秒级回滚手段的时候，人会本能地降低更新频率，而降低频率往往意味着问题被拖得更久。

我的节奏是：数据类更新自动跑，一天一到两次；内容类更新攒到一定的量再发，不追单次；URL 类变更一年不超过一次，且必须配套完整的重定向映射表。

发布之后别忘了主动通知。sitemap 里带上 lastmod 字段、在 Search Console 里对改动的页面手动请求重新索引，能把重新抓取的等待时间从两周压到几天。这一步在时效性内容上是决定性的——晚一周，窗口期就过去了。

## 一个可以直接照搬的安排

工具页：数据源变更时更新，页面上写明核对时间，不做无意义的重发。

时效性内容页：按竞争者的更新节奏走，通常一个季度到半年过一遍，只改确实过期的部分。

常青内容页：一年看一次数据曲线，下滑了才动。

站点级改动：集中在一两个时间窗口做，做完之后观察一个月，别在这期间叠加其他变更——多个变量同时变，出问题就归因不了。

---

*Omni Calculator 语言与页面规模来自其官网及 Semrush 2026 年 6 月估算。*