changefreq 填 monthly 还是 daily：24 份 sitemap 实测，17 份两个字段都不发

实测 · 2026-09-09 · 30 个域名 · 24 份可读 sitemap · 单次抓取

样本 / 口径：2026-09-09 当天对 30 个域名各请求一次，桌面 Chrome UA，不执行 JavaScript。先读 robots.txt，取里面第一条 Sitemap: 声明；没有声明的退到 /sitemap.xml。入口文件是 sitemap 索引时，按文档顺序读它的前 3 个子文件。24 个域名返回了可解析的 <url> 条目，6 个一条都没拿到，合计读到 168,434 条。

changefreq 该填 monthly 还是 daily，这个问题下面没有答案，因为两个值都不用填。Google 和 Bing 各自白纸黑字写过一句「我们不看这个字段」。24 份 sitemap 里 17 份已经两个字段都不发了；还在发的 7 份，有 4 份是同一个值盖住整份文件 97% 以上——填了跟没填区分不出任何东西。

出海站为什么会撞上这两个字段

因为大部分人从来没自己填过它，是建站工具替你填的。WordPress 装个 SEO 插件、Shopify 开个店、用 Squarespace 或 Webflow 拖一个站出来，sitemap 都是自动生成的，changefreq 和 priority 跟着一起写进去，设置面板里通常还有一个下拉框让你选 daily 还是 weekly。

这个面板有意思的地方在于：Shopify 和 Squarespace 这两家平台自己的官网，就在往每一条 URL 上盖同一个值。Shopify 官网 557 条 URL 全写 daily，Squarespace 6,352 条里 6,152 条写 monthly。你在后台纠结那个下拉框的时候，工具作者自己也没把它当回事。

一个字段在每条 URL 上取值都一样，它就没有携带任何信息——不管搜索引擎看不看。

怎么测的

整个测量从外面做，不需要任何账号，路径和爬虫走的一样：robots.txt 先看，/sitemap.xml 兜底，然后跟着文件里指的地址往下走。所以同一套命令拿去查竞品和查自己一样快。

# 查一个站的全部动作
curl -s https://example.com/robots.txt | grep -i '^sitemap:'

curl -s https://example.com/sitemap.xml \
  | grep -c '<changefreq>'

curl -s https://example.com/sitemap.xml \
  | grep -oE '<priority>[^<]+' | sort | uniq -c | sort -rn

三条局限，中间那条决定下面的单站数字能读到多细。6 个域名没给出可解析的文件：github.com 对我们的客户端返回 406，mozilla.org、stackoverflow.com、news.ycombinator.com 返回 404，wikipedia.org 在它自己 robots.txt 指定的地址上返回 403，reddit.com 的 /sitemap.xml 返回的是一个 HTML 页面。入口是索引文件的那 15 个域名，我们只读了 3 个子文件，而它们最多有 27,845 个——所以那些条目数是切片不是普查，某个站完全可能在我们没打开的子文件里用了 changefreq。另有 9 个域名的入口就是一份完整的单文件，那 9 份的数字是全量。

第三条局限多抓几次也解决不了：文件里的值我们看得见，谁定的这个值我们看不见。多数站上最合理的猜测是没有人定过，值是插件默认带进来的。这条猜测撑不起结论，所以下面只报数。

两家搜索引擎都写过不看它

两句话，都写在给站长看的页面上，都没有留余地。Google 的 sitemap 文档原句是「Google ignores <priority> and <changefreq> values」（Build and submit a sitemap，2026-09-09 访问）。Bing 站长博客说自己也一样：「Optional sitemap tags like changefreq and priority are ignored by Bing and do not influence how your content is crawled or ranked」（Keeping content discoverable with sitemaps in AI-powered search，2025-07-31 发布，2026-09-09 访问）。

两家都没解释为什么，这一句我们也不替它们补。两家倒是都顺手指了旁边那个字段。Bing 的原话：「The lastmod field in your sitemap remains a key signal, helping Bing prioritize URLs for recrawling and reindexing, or skip them entirely if the content hasn't changed since the last crawl.」Google 对同一个字段加了条件：它用 lastmod，前提是这个值「consistently and verifiably (for example by comparing to the last modification of the page) accurate」。

协议本身对 priority 的态度，也从来没有填它的人那么热情。sitemaps.org 把它定义成「the priority of this URL relative to other URLs on your site」，默认值 0.5，后面跟着一句 2005 年就摆在那儿的提醒：「Assigning a high priority to all of the URLs on your site is not likely to help you. Since the priority is relative, it is only used to select between URLs on your site」（sitemaps.org 协议，2026-09-09 访问）。

24 份 sitemap 里，17 份 changefreq 和 priority 都不发

这个面板上多数站已经停了。两个字段基本是绑在一起走的，24 个站里只有 substack.com 一家发了其中一个。

这 17 个里包含面板上除两家外的全部开发者平台、我们能读到的全部新闻站，以及两份最大的文件：framer.com 我们读到 31,084 条，webflow.com 72,559 条，两份里一条 changefreq 都没有。按条目数算差距比按站数更大——168,434 条里带 changefreq 的是 15,836 条，占 9%。

发 lastmod 的有 16 个站，是那两个被忽略字段的两倍多，方向是对的。至于这些日期说的是不是真话，那是另一次测量的事，而且结果不好看：三周前我们读过 sitemap lastmod 值多少，24 个站里 13 个把整份文件盖上了同一个日期。

还在发的 7 份，值几乎是个常数

七个站全在这里。把条目数并排放，规律不用找。

Medium 和 Shopify 是全票通过的：我们从 Medium 读到的每一条都写 monthly，从 Shopify 读到的每一条都写 daily。两份文件对「一个页面多久变一次」的判断，差了三十倍。Ars Technica 的 2,001 条里有 2,000 条写 weekly、同样这 2,000 条写 priority 0.3。七个站里有三个把 priority 1.0 只给了一条 URL——首页拿了那枚徽章，其余每一页都被告知你跟别人一样重要。

Medium 是唯一的例外，也正好撞在协议提醒的那句话上。它的 priority 分了五档，但 5,182 条里有 1,055 条是 1.0：五条里有一条挂着最高优先级，而这个站的 sitemap 子文件有两万多份。这个字段问的是「相对于谁」，1,055 条不是对这个问题的回答。

把 168,434 条条目里出现过的取值拉一遍，一共只用到 5 个词，合法取值里有 2 个从头到尾没出现过。

168,434 条里只有 1 条写了 always，在 Ars Technica 上。整个面板没有一条写 hourly 或 never——包括那几个新闻站，它们的首屏一小时能换几轮，归档页则再也不会变了。

那这块力气该花在哪

打开自己的 sitemap 数一遍。如果 changefreq 在里面，要问的不是它填得准不准，而是那个替你填它的生成器，有没有把真正被读的那个字段也办对。

• 把力气挪到 lastmod 上，并且让它是真的内容修改时间，不是构建时间——两家写明会读的就是这一个字段
• 如果要删这两个字段意味着去改一个你控制不了的插件，那就留着；它们只多花几个字节
• 别给一批页面统一写 priority 1.0，协议说得很清楚，这个值只在你自己站内做比较
• 别把竞品的 changefreq 当成对方的更新排期读——Shopify 在几个月没动过的页面上也写着 daily

如果你还没到审计的阶段，是要从零决定这份文件里该写什么，四个字段各是什么、哪两个会被读，在 网站地图怎么写 里拆开讲过。如果真正的担心是页面根本没被收录，而不是 sitemap 里的标注写得对不对，那从 sitemap 这一头查是走反了方向——缺口诊断要解的是那个问题。

常见问题

你们是怎么测的

2026-09-09 对每个域名请求一次，桌面 Chrome UA，不执行 JavaScript。先看 robots.txt 里有没有 Sitemap: 声明，没有就退到 /sitemap.xml；入口是索引文件时读前 3 个子文件。30 个域名里 24 个返回了可解析条目，合计 168,434 条。上面那三条命令能对任意单个域名复现这些数。

changefreq 到底填 monthly 还是 daily

对 Google 和 Bing 来说填哪个都一样，因为两家都说不看。如果生成器强制要填，随便挑一个跟内容大致对得上的值就行，别在这上面开会。真正会影响重新抓取节奏的是 lastmod。

changefreq 和 lastmod 有什么区别

changefreq 是一个预测——「这一页以后大概多久变一次」；lastmod 是一个事实——「这一页上次变是什么时候」。前者两家都不读，后者两家都读，而且 Google 还要求这个事实经得起核对。

要不要把这两个字段从 sitemap 里删掉

顺手能删就删，要动改不了的插件就别折腾。每条 URL 两个被忽略的元素，代价是几个字节，谈不上占抓取额度。手工从一份每次部署都会重新生成的文件里删它们，是要白做两遍的活。

为什么这么多站还在发它

我们不知道，文件本身也回答不了。取值分布看起来更像生成器默认而不是有人决定过——一份文件通篇一个值，是模板的产物不是编辑的产物——但这些站的后台设置页我们看不到，所以这只是一种读法，不是一个结论。