本文约 2,922 字，预计阅读 8 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：文章改了五次，快照还停在三个月前
有站长把一篇旧文重写了一遍：补数据、换截图、改标题，发布后满心期待第二天快照更新，结果点开百度结果里的”百度快照”，看到的还是三个月前那版。于是怀疑是不是站点被降权了。实际上，快照滞后是极其正常的现象，而且”快照不更新”与”收录有问题”是两件不同的事。要理解它，先要厘清快照到底是什么。
原理分析：快照是索引时的副产品，不是实时缓存
百度快照是百度在抓取页面时保存的一份 HTML 副本，用于在主站打不开时给用户兜底查看。它的更新依赖一次”成功的重新抓取”：蜘蛛来 → 拿到新内容 → 判断有实质变化 → 更新快照与索引。因此快照不更新，本质是”百度还没重新抓过这个页面”，或”抓过但认为变化不大”。
三个容易混淆的概念：
| 概念 | 含义 | 与快照的关系 |
|---|---|---|
| 抓取 | 蜘蛛成功请求页面 | 快照更新的前置条件 |
| 收录/索引 | 页面进入索引库，可被搜到 | 收录不等于快照最新 |
| 快照 | 抓取时保存的内容副本 | 滞后于实际页面是常态 |
影响快照更新速度的因素：页面历史更新频率（经常更新的站抓得更勤）、页面权重（外链与点击多的页面重抓快）、服务器响应（快则抓取成本低）、内容变化幅度（微小改动可能被判定无需重抓）。此外，站点整体抓取频次下降时，旧页面的快照刷新会被排在后面。
保姆级实操
第一步：先确认页面本身真的更新了
用 curl 看服务端返回的 Last-Modified / ETag 是否正确反映修改时间。很多站点因为页面缓存，返回的还是旧版本，这种情况下百度抓到的就是旧内容，再等也没用。
curl -sI https://mimangfei.com/some-post/ | grep -Ei 'last-modified|etag|cache-control|x-robots-tag'
# 对比实际修改时间
stat -c '%y' /path/to/wp-content/themes/your-theme 2>/dev/null
第二步：让 WordPress 正确输出更新时间
确保模板里输出了真实的修改时间，并且 sitemap 的 lastmod 用的是 get_post_modified_time() 而非发布时间：
<?php
// 子主题：在文章末尾输出"最后更新"（同时给百度一个明确的变化信号）
add_filter( 'the_content', function ( $content ) {
if ( ! is_singular( 'post' ) ) {
return $content;
}
$modified = get_post_modified_time( 'Y-m-d H:i', true );
$published = get_post_time( 'Y-m-d', true );
if ( $modified && gmdate( 'Y-m-d', strtotime( $modified ) ) !== $published ) {
$content .= '<p class="post-updated">最后更新：' . esc_html( $modified ) . '</p>';
}
return $content;
} );
// 让 sitemap 的 lastmod 使用修改时间（WordPress 自带 sitemap 默认如此，
// 若用了插件请在插件设置里核对 "Last Modified" 选项）
add_filter( 'wp_sitemaps_posts_entry', function ( $entry, $post ) {
$entry['lastmod'] = get_post_modified_time( DATE_W3C, true, $post );
return $entry;
}, 10, 2 );
第三步：改动要有”实质幅度”
只改一个错别字、换一张图，很可能被判定为无实质变化。有效更新应包含：新增段落、更新数据、补充章节、修改标题与描述。
第四步：主动推送更新后的 URL（批量更新场景建议同时接入百度API主动推送PHP接入）
单次推送不保证立刻重抓，但可以显著提高进入待抓队列的优先级：
printf 'https://mimangfei.com/some-post/\n' > /tmp/one.txt
curl -s -H 'Content-Type:text/plain' --data-binary @/tmp/one.txt \
"http://data.zz.baidu.com/urls?site=https://mimangfei.com&token=TOKEN"
第五步：清理页面缓存与 CDN
改完文章后清 WordPress 缓存与 CDN 缓存，确保蜘蛛抓到的是新版本（可用 Baiduspider UA 的 curl 验证）。
第六步：保持稳定的更新节奏
站点整体更新频率高，百度会给更高的重抓频率。零散地一年改一次，快照自然长年不变。
常见踩坑
- 把快照日期当成收录日期：快照时间只是某次抓取的时间，与页面是否可搜无直接关系。
- 缓存插件导致 304：服务器对蜘蛛返回 304 Not Modified，百度就没有新内容可存，需检查
Cache-Control与If-Modified-Since处理。 - 只在前端改了显示，没改数据库内容：例如用 JS 替换了日期文案，源码没变，百度抓到的仍是旧内容。
- 频繁无意义改动：天天点”更新”刷时间戳，会被判定为无实质更新，反而降低信任。
- 案例：某站一篇攻略文改了正文却三个月不换快照。用 Baiduspider UA 抓源码后发现返回的是 CDN 缓存的旧版本（
X-Cache: HIT，Last-Modified停留在旧日期）。清理 CDN 缓存并配置文章更新时自动刷新后，一周内快照更新。 - 改了 URL 却没做 301：百度还在抓旧地址，新页面的快照自然永远不会出现。
- 把 noindex 页面当快照问题处理：页面本身已不被索引，讨论快照无意义。
总结
判断标准：快照滞后本身不是故障，只有当”页面已实质更新 + 服务端返回新内容 + 蜘蛛确实来过 + 数周后快照仍不变”时，才需要深入排查（多半是缓存或抓取频次问题）。行动清单：curl 验证 Last-Modified → 清 WordPress 与 CDN 缓存 → 用 wp_sitemaps_posts_entry 保证 lastmod 真实 → 主动推送该 URL → 保持每周稳定更新 → 4 周后再评估。若伴随索引量整体下滑，则应转向百度索引量突然下降的排查流程。
